# PVPBC: Privacy and Verifiability Preserving E-Voting Based on Permissioned Blockchain
## 8 Performance Analysis
### Prototype System: Voter Registration and Authentication Scheme
If the transaction is valid, the node forwards it to its neighbours. Alternatively, invalid transactions are discarded. We conducted the following experiment to characterise this performance metric. The latency incurred when a valid authentication transaction is created and sent in the DLT network is measured. We also recorded the time at which the access token is retrieved. The goal was to understand the time required to send and receive a response to an access request, which was sent by the EA. We repeated the experiment 30 times for each function call using one client system. Figure 9 plots the latency incurred by this process. The access-request transaction incurs an average latency of 6.275 ms in Figure 9. It is important to note that the block time of Quorum affects the value of the transaction latency in the system. The block time is defined as the time it takes to add a new block to the blockchain. We employed the default block time of 50 ms, which was set for the \begin{table}
\begin{tabular}{c c c} \hline \hline
**Contract** & **Time (s)** & **Cost (Gas)** \\ \hline
1 & 49 & 582033 \\
2 & 25 & 539234 \\
3 & 30 & 524892 \\
4 & 35 & 489234 \\
5 & 28 & 547834 \\
6 & 20 & 542934 \\
7 & 27 & 593485 \\
8 & 42 & 534584 \\
9 & 39 & 558394 \\
10 & 35 & 584574 \\ \hline Average & 33 & 549719 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Voter authentication: The average deployment time for 10 contracts and the associated costs are given for 30 experiments. The average of these contract deployment times is 33 s and the average cost is 549719. RAFT consensus in this experiment. However, the research of [41] has shown that an increase in block time and transaction rate increases the latency of transactions in the system. This change is because transactions will have to wait longer before they are added to a block, thereby increasing the latency. Current blockchain consensus protocols are not well-adapted for e-voting systems, considering the fact that the existing proof- and voting-based consensus mechanisms may affect the performance of the e-voting systems due to latency and transaction throughput challenges. In future work, we will investigate and design a blockchain consensus protocol suitable for e-voting systems, where transactions are validated with lower latency to ensure fair and efficient performance without compromising security. A related line of attack could also involve adapting modern machine-learning approaches that estimate variation in propagation times [27], improving monitoring [42] and deep-learning classification schemes [29] that aim to perform better utilization of the underlying network resources. Figure 8: The voter authorisation time is plotted as a function of the number of voters. The authorisation time is an approximately linear function of the voter population size, when it is the range 100 to 500 voters, which underlines the scalability of PVPBC. Figure 9: The time required to send and receive a response to an access request is illustrated as a function of the number of requests. The access-request transaction incurs an average latency of 6.275 ms.