# Privacy-Preserving E-Voting System Supporting Score Voting Using Blockchain
## 6 Performance Analysis
### Results  
This section analyzes the results of the conducted experiments. For simplicity, the transactions are split into read transactions to represent transactions such as _tally_, which are used to query the Blockchain and write transactions to represent the _setup_ and _Vote_ algorithms. **Case I**. The effect of increasing the transaction rates on the latency and throughputs is illustrated in Figure 3. It can be seen that the read operations boast considerably higher throughput than the write operations, and also modestly low latency. For example, at a send rate of 200 tps, the read operation has a latency of around 10 s whereas the latency is 16 and 35 s for the transactions that are writing to the Blockchain. Latency appears to bear a modest positive correlation to transaction send rate; the trend seems to be very modest and appears to become more steady after 200 tps (disregarding the read transaction at 300 tps as an outlier, likely due to a hardware slowdown). Throughput appears to decline as the transaction send rate increases, especially for the write transactions; the send rate seems to have less of a correlation with the throughput of read transactions. Additionally, throughput and latency appear to be negatively correlated, as many of the times a stark jump in latency is observed when a corresponding drop in throughput is recorded, and vice versa. This leads uys to conclude the following: the transaction send rate does not have a significant influence throughput; rather, a strong negative correlation between latency and throughput is exhibited. _The transaction send rate of 200 tps was selected as the optimal send rate for the simulation of_ Case II _and_ Case III (at this benchmark the observed send rate was closest to the stipulated send rate of 200 tps). **Case II and Case III. ** Figure 4 illustrates how increasing the number of transactions affects the throughput and latency of the SUT at a fixed transaction rate of 200 tps. It becomes immediately obvious that latency significantly increases after 10,000 transactions for both read and write transactions. Likewise, throughput experienced a significant decline after 10,000 transactions after remaining relatively constants for all transactions. It is interesting to note that despite a significant increase in latency at 20,000 transactions, there is a slight decline in throughput; in fact, it appears to exhibit a slight upward trend, signifying that it seems to increase as the number of transactions sent increases. This could be attributed to the fact that the latency increases more linearly whereas it increases more exponentially for the other transactions. In other words, it experiences less of a latency increase relative to the increase that the other transactions exhibit and thus shows less of a throughput decline relative to the other functions. This would then be expected given the correlation between latency and throughput. The error rate for transactions submitted at 200 tps remained at 0% regardless of the number of transactions, and remained at 0% for other transaction send rates, as well. It is plausible to believe that this perfect success rate on the Ethereum network negatively impacts the performance of the SUT and may be partially responsible for the exponential increases in latency. In summary:  
* At a rate of 200 transactions per second, the throughput experiences little change up to 10,000 transactions. Beyond that, the throughput generally declines;
* Latency exponentially increases for read transactions. Latency increases in a more linearly fashion for write transactions;
* Likely in a trade-off with performance, Ethereum is able to execute the proposed scheme with a 0% error rate regardless of transaction send rates or the number of transactions. To conclude, the proposed system is able to effectively handle transaction loads up to 10,000 at a rate of 200 tps. Figure 3: Impact of increasing transaction rates on latency and throughput.