Architecture-Centric Evaluation of Blockchain-Based Smart Contract e-voting for National Elections

Table 2. Cont.
S
/N
Phase 1
Description of Activity
4.
Identify Architectural
Approaches
The architectural approaches that have been adopted and the rationale
for adopting them were explained. The summary of quality attributes
and the approach
/component that seeks to address them is presented
as follows:
•
Voters Smart card—Identification, Authentication,
and Authorisation
•
Zero-knowledge protocol—Security
•
Hyperledger Fabric Blockchain:
â
Public
/private key Encryption—Security, Functional Suitability
â
Modular Architecture—Reliability
â
REST API’s—Reliability, Security, Performance
â
Permissioned Blockchain network—Security,
Functional Suitability
â
Isolation of system services—Performance, Security
â
Distributed processing—Security
â
Decentralised processing and storage—Functional
Suitability, Reliability
â
Immutability—Security, Functional Suitability
5.
Generate Quality Attribute
Utility Tree
The quality attribute utility tree was generated from the questions from
the participating experts in their attempt to further understand the
architecture design and process, together with stated concerns and
scenario discussion and elicitation. The utility tree allows for the
prioritisation of specific quality attribute requirements, as they relate to
the scenarios.
6.
Analyse Architectural
Approaches
The prioritised list of scenarios, which is the output of the previous step
is used to probe the architectural approaches to realise the important
quality attributes. This step was used to identify any risks, sensitivity
points, and trade-o
ffs within the design architecture. The 3 highest
priority scenarios were mapped to the relative architectural approach.
The approaches were analysed by identifying risks, scenarios that were
concerned with more than one approach was identified as a sensitivity
point.
The following scenarios were included:
Scenario 1—Connections outside of the blockchain network are
hampered by a Man-in-the-middle attack.
Scenario 2—Vote verification introduces the risk of coercion.
Scenario 3—High volumes of tra
ffic is affecting accessibility and
reliability.
Phase 2
7.
Brainstorm and Prioritise
Scenarios
The discussion included both sets of stakeholder representatives to elicit
new scenarios that the expert group may have thought of and to
identify any other scenarios from an end-user, voters, perspective. The
generated utility tree from Step 5, aided in the discussion and elicitation
of a larger set of scenarios.
8.
Analyse Architectural
Approaches
Present Results
This step is a reiteration of step 6 if the highest-ranked scenarios of the
first iteration of step 6 di
ffer from the highest-ranked scenarios
identified in step 7. In the case of our ATAM, the highest priority
scenarios of step 6 remained the same.
9
Present Results
This is the step where the results of the evaluation are presented. From
the result of the ATAM evaluation, the major trade-o
ff is the aspect of
vote validation. To forestall the possibility of voters’ coercion the vote
validating nodes should be restricted to only secure locations.

---

Informatics 2020, 7, 16
12 of 22
Informatics 2020, 7, x FOR PEER REVIEW 
11 of 21 
6. 
Analyse 
Architectural 
Approaches 
The prioritised list of scenarios, which is the output of the previous step is used to probe the 
architectural approaches to realise the important quality attributes. This step was used to 
identify any risks, sensitivity points, and trade-offs within the design architecture. The 3 
highest priority scenarios were mapped to the relative architectural approach. The approaches 
were analysed by identifying risks, scenarios that were concerned with more than one 
approach was identified as a sensitivity point.$$ 
The following scenarios were included: $$