# Exploiting Blockchain Technology for Enhancing Digital Twins' Security and Transparency
## 4 Experimental Results
### Performance Benchmarks
#### 4.3.2 Benchmarks on Throughput  
The initial test conducted on our network configuration focused on evaluating the network throughput by incrementally increasing the Transactions Per Second (TPS) sent to the network for validation. In this analysis, we examined both the throughput and latency performance across different consensus protocols to identify the most optimal protocol in terms of transaction approval rate. The transaction load began at a baseline of 100 TPS and progressively increased until it reached 700 TPS. The transactions involved were associated with the \"send hash\" functionality, which is designed to enable multiple concurrent connections to the digital twin system. This setup served as a practical scenario for assessing the network's ability to handle varying levels of transaction demands while maintaining system efficiency. As shown in Figure 5(a), the results of the tests indicated that the throughput values were generally similar across the three analyzed algorithms, with Clique exhibiting greater instability in the number of transactions approved. Regarding the latency in Figure 5(b), the Clique algorithm slightly outperformed the others, showing a momentary equality when reaching 600 transactions per second. In comparison, both QBFT and IBFT 2.0 demonstrated nearly identical performance, with comparable latency times, reinforcing their similarity in terms of overall performance. Although the Clique protocol showed some important advantages in terms of validation speed, its inability to provide a consistent and stable environment for the digital twin's update requests made this protocol not well suited for our purposes in terms of reliability. In the following tests, we still provided measurements utilizing that consensus protocol as a comparison with the IBFT 2.0 and the QBFT counterparts. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Feature** & **Clique** & **IBFT 2.0** & **QBFT** \\ \hline Consensus type & Proof of Authority (PoA) & Byzantine fault tolerance (BFT) & Byzantine fault tolerance (BFT) \\ \hline Fault tolerance & Up to 50\% of nodes & Up to 33\% of nodes & Up to 33\% of nodes \\ \hline Performance & High transaction throughput & Moderate transaction throughput & Moderate to high transaction throughput \\ \hline Block finality & Probabilistic & Immediate & Immediate \\ \hline Use cases & Private networks & High-security applications & High-security applications \\ \hline Strengths & Simple, fast, effective in trusted environments & Strong finality, fault tolerance & Strong finality, improved performance in BFT environments \\ \hline Limitations & Lacks finality, vulnerable if over 50\% nodes fail & Lower throughput compared to PoA & Similar limitations as IBFT 2.0 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison of consensus protocols: Clique, IBFT 2.0, and QBFT. The next test aimed to evaluate the scalability characteristics of the consensus protocols under consideration, with particular emphasis on their horizontal scalability. To investigate that behavior, we assessed the network's performance by gradually increasing the number of validators, starting from a baseline of 4 and scaling up to a maximum of 14. During that process, transactions were sent at a rate of 400 transactions per second, for a total of 2000 transactions. The obtained results regarding the transaction throughput and the effective latency are outlined in Figure 7a,b, respectively. Figure 6: The plot in (**a**) shows measurements of the average throughput due to a progressive increase in transaction sending rate. Instead, the plot in (**b**) highlights the registered latency of the three networks in the same scenario. (**a**) Throughput plot with respect to the consensus protocols. (**b**) Latency plot with respect to the consensus protocols. Figure 7: Performance of the different consensus protocols in increasing network’s size configurations. (**a**) Throughput plot with respect to the horizontal scalability. (**b**) Latency plot with respect to the horizontal scalability.