# Exploiting Blockchain Technology for Enhancing Digital Twins' Security and Transparency
## 4 Experimental Results
### Performance Benchmarks
#### 4.3.1 Performance Metrics  
Evaluating the performance of a blockchain network is critical and requires a thorough analysis, as it cannot rely on a single factor. Assessing network quality extends beyond simply measuring transaction validation speed; a comprehensive examination of all available metrics is essential. As discussed in Section 2.1, a critical aspect of network transaction speed and overall quality concerns the choice of a suitable consensus algorithm for the designed problem. This section provides a quantitative analysis of several suitable protocols to facilitate a data-driven approach in selecting the optimal solution. More generally, network quality is assessed by identifying specific characteristics of the network and then selecting those that best align with the requirements of the intended application. A short summary of the included characteristics:  
* Finality: capability of blockchain protocols to reach consensus between nodes without creating additional branches in the network.
* Vitality: assessed through the maximum number of failing validation nodes before reaching the collapse of the network's validation capabilities.
* Throughput: speed at which transactions are evaluated and accepted by the network and inserted in blockchain blocks.
* BFT (Byzantine fault tolerance): capability of the network to reach consensus in case of partial validation node failing.
* Scalability refers to the network's ability to sustain its validation rate as its configuration change. Scalability is further divided into horizontal and vertical scalability. Horizontal scalability measures the validation rate as the number of network validator changes, while vertical scalability assesses the validation rate in response to variations in available hardware resources.  
While the characteristics outlined above provide valuable insights into the metrics relevant for our testing phase, it is crucial to distinguish consensus protocols based on their specific use cases. In this section, we analyzed several algorithms suitable for our objectives, focusing in particular on the Clique, IBFT 2.0, and QBFT protocols. A short description of the main characteristics of each of those protocols is provided:  
* Clique: This protocol is designed for environments similar to Ethereum's mainnet. It allows for faster block addition and can operate with just one validator, making it suitable for testing and demonstration purposes. However, it does not guarantee immediate finality, which means forks can occur if the network experiences issues or if there are insufficient validators available [38].
* IBFT 2.0 (Istanbul Byzantine Fault Tolerance): An evolution of the original IBFT protocol, IBFT 2.0 requires at least four validators to ensure Byzantine fault tolerance. It guarantees immediate finality, meaning once a block is added, it cannot be altered or removed from the chain. This makes it suitable for production environments where reliability is crucial [39].
* QBFT (Quorum Byzantine Fault Tolerance): Developed as an enterprise-grade version of IBFT, QBFT also requires four validators and offers immediate finality. It incorporates a more efficient leader election process and reduces communication roundsneeded for consensus compared to IBFT, making it better suited for larger networks with higher scalability needs [38].  
The unique characteristics, along with the primary similarities and differences of each protocol, are summarized in Table 2. This table serves as a key reference in order to validate our selection of the most appropriate consensus mechanism for our peculiar use case.