# A Coordination Technique for Improving Scalability of Byzantine Fault-Tolerant Consensus
## 4 Evaluation
### RQ3: How Much Can Our Approach Improve the Scalability of IBFT of Hyperledger Besu? We established the third research question regarding the applicability of our approach to the real-world open-source blockchain framework using another BFT-based consensus algorithm. We selected _Hyperledger Besu_, a popular implementation of Ethereum client that supports public and private blockchain. It uses IBFT (Istanbul Byzantine Fault Tolerance) that enhances the performance by decreasing the number of nodes for transaction confirmation from \(3f+1\) to \(2f+1\) (IBFT [[https://github.com/ethereum/EIPs/issues/650](https://github.com/ethereum/EIPs/issues/650)]([https://github.com/ethereum/EIPs/issues/650](https://github.com/ethereum/EIPs/issues/650))). In the experiment for RQ3, we modified the Hyperledger Besu source code to communicate with our _Controller_ for requesting new block generation and accessing transaction pool (our source code for implementing the BFT network is available at [[https://github.com/jungwonrs/JwRalph_Seo/tree/master/lab/besu_backup](https://github.com/jungwonrs/JwRalph_Seo/tree/master/lab/besu_backup)]([https://github.com/jungwonrs/[PERSON]_Seo/tree/master/lab/besu_backup](https://github.com/jungwonrs/[PERSON]_Seo/tree/master/lab/besu_backup))). Then, we performed an experiment similar to that of RQ1 to figure out how much our approach can improve the IBFT consensus protocol's performance. Experimental setting of \(RQ3\). We modified Hyperledger Besu 1.5.1 ([[https://github.com/hyperledger/besu/tree/1.5.1](https://github.com/hyperledger/besu/tree/1.5.1)]([https://github.com/hyperledger/besu/tree/1.5.1](https://github.com/hyperledger/besu/tree/1.5.1))) to communicate with our consensus coordinator. For the experiment, we transmitted random transactions to Hyperledger Besu on a regular basis during the designated period. Initially, the number of nodes was four and we gradually increased the number of nodes until it reached 40. Then, we measured the number of transactions contained in generated blocks to recognize its throughput. We set the block generation time of the Hyperledger Besu to 10 s, and our coordinator execution interval was also set into 10 s because this time showed the best performance. The experiment was also carried out every 5 min (=300 s and 30 block generations) for each node configuration. In the experiment, the interval of the transaction transmission started from 10 ms, because a significant number of transactions was missed in Hyperledger Besu in the case of under 10-ms interval. We carried out this experiment with the transaction transmission interval of 5 ms from 10 to 40 ms. Our hardware specification as a blockchain node and consensus coordinator was Intel i7-8700, 3.2 GHz CPU with 24 GB RAM and Windows 10 OS. All nodes and the consensus coordinator were executed on one computer. Due to the hardware specification limitation, the maximum node number of Hyperledger Besu was set to 40. In addition, the gas limitation of Hyperledger Besu was removed to generate transactions continuously (we refer to the method shown on the official Besu website: [[https://besu.hyperledger.org/en/stable/HowTo/Configure/FreeGas/](https://besu.hyperledger.org/en/stable/HowTo/Configure/FreeGas/)]([https://besu.hyperledger.org/en/stable/HowTo/Configure/FreeGas/](https://besu.hyperledger.org/en/stable/HowTo/Configure/FreeGas/))). Experimental results of \(RQ3\). Figure 5 shows the result of the experiment where its transmission interval is 10 ms with from 4 to 40 blockchain nodes. In the figure, results of only using the IBFT and IBFT equipped with our approach are expressed in \(IBFT\) and \(CC\) + \(IBFT\), respectively. The y-axis indicates the number of transactions contained in the generated blocks for 5 min. For four blockchain nodes, the number of transactions of IBFT and CC + IBFT contained in 30 generated blocks were 24,173 and 26,152, respectively. CC + IBFT achieves 8.19% (=(26,152 \(-\) 4173)/24,173) performance improvement.