# PVPBC: Privacy and Verifiability Preserving E-Voting Based on Permissioned Blockchain
## 8 Performance Analysis
### Prototype System: Voter Registration and Authentication Scheme
If the status of any token is not valid, the authorisation process stops and a deny-access request is sent back to the subject. The EA goes through all the access rules specified in the retrieved token to decide whether to grant the access to the ballot, or not (e.g., Flag 'voted'). The process checks whether or not the request made by the voter (REST-ful method) to access the ballot matches the access rules in the retrieved access token. **Time and gas cost:** We measured the gas required to deploy the authorisation contract and the associated time. The experiments were repeated 30 times for each contract, and the results obtained are given in Table 3. The average time reported is 33 s, which is similar to the average time report for voter registration; however, the average gas cost reported is significantly larger, e.g., 549719. **Authorisation time:** The duration between when an access request is submitted to the front-end system and when the request is granted or acted upon is called the authorisation time. To measure the authorisation time, we used the ConsenSys Quorum blockchain to emulate the authentication DLT. For the blockchain private network, we implemented three nodes, which were distributed over three Linux machines, to mimic the TTP nodes. We developed a PoC front-end system which allows the voter to submit the VID to the EA. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Contract** & **Time (s)** & **Cost (Gas)** \\ \hline
1 & 32 & 182000 \\
2 & 35 & 173000 \\
3 & 33 & 185000 \\
4 & 34 & 180000 \\
5 & 35 & 182000 \\
6 & 35 & 179000 \\
7 & 34 & 184000 \\
8 & 33 & 186000 \\
9 & 35 & 175000 \\
10 & 34 & 184000 \\ \hline Average & 34 & 181000 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Voter registration: The average contract deployment time for 10 contracts, where the average computed for 30 experiments is given and the cost of gas is reported. The average time for deployment over all trials is 34 s and the associated average cost is 181000. To evaluate the authorisation time, we conducted an experiment which measured the time that elapsed between when the voter access request was made and when the access request was granted. Specifically, we registered voters with the TTP using the registerVoter() function. Access tokens and VID's were created and placed on the DLT. The next step started when VIDs were sent at the same time, \(T_{1}\), via the front-end application. The experiment used the accessRequest() function in the smart-contract authorisation. This function used VID to fetch the associated token data from the TTP DLT, and it checked the current capability status of the token. We measured the time, \(T_{2}\), which was when the access token was retrieved and access was granted. The authorisation time, \(T_{A}\), was measured as the time difference between \(T_{2}\) and \(T_{1}\),  
\[T_{A}=T_{2}-T_{1}. \tag{9}\]  
In order to determine the impact of different voter population sizes, we ran the experiment several times and increased the voter population for each experiment. The voter population sizes used were 100, 150, 200, 250, 300, 350, 400, 450, 500 voters. Figure 8 illustrates the average authentication time for each voter population size. Figure 8 provides evidence that the authorisation time increases linearly as a function of the voter population size. For example, the average latency associated with 100 voters obtaining access to the election process is on average 20 s. The average latency increases approximately linearly. When the voter population size is 500 voters, the recorded authentication time latency is approximately 80 s. This linear increase suggests that the voter authorisation time scales well over population sizes of 100 to 500 voters. The access-request-transaction latency within the authentication DLT network is an important performance metric. The transaction latency in the blockchain environment is the time taken to complete information (transaction) verification. When a node receives a transaction, it verifies whether it is valid or not.