# 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?
The total number of transactions that can be issued every 10 ms for 5 min is 30,000, but 3848 (=30,000 \(-\) 26,152) and 5827 (=30,000 \(-\) 24,173) are missed due to the performance limitation of Hyperledger Besu and our approach. For the experiment with 40 blockchain nodes, IBFT processed 1563 transactions, while CC + IBFT processed 6607 transactions, indicating a 322.71% (=(6607 \(-\) 1563)/1563) performance improvement. Thus, in all node configurations with 10 ms of transaction issue interval, the combination of IBFT and our consensus coordinator obtained 37.75% (=(154,782 \(-\) 112,361)/11,2361) performance improvement on average. Figure 6 shows the result of the experiment where the interval is 25 ms. As the transaction time interval is 25 ms, the total number of transactions that can be issued for 5 min is 12,000 (=300/0.025), which is the maximum number of transactions that can be contained in generated blocks. In four blockchain nodes, the numbers of IBFT and CC + IBFT are 11,900 and 12,000, respectively, in which most of the issued transactions are contained in generated blocks. Thus, the gap between the two numbers of transactions is not big. However, for 20 nodes, CC + IBFT achieved 53.25% (=(11,255 \(-\) 7344)/7344) performance improvement. In addition, CC + IBFT obtained 344.81% (=(7584 \(-\) 1705)/1705) performance improvement in the case of 40 blockchain nodes, compared to onlyusing the IBFT. In all node configurations, the combinational use of IBFT and our approach gained 61.81% (=((103,348 \(-\) 63,868)/63,868)) performance improvement on average. Thus, it is possible to conclude that our approach contributed to improving the performance of a specific blockchain node configuration and improving the IBFT consensus algorithm's scalability because the loss of performance is smaller depending on the increase of the blockchain nodes. All datasets resulting from this experiment are presented in the AppendixA. While carrying out this experiment, we observed that the proportion of equal and unequal transactions in consensus coordinator, as shown in Table 2. As the coordinator execution interval is 10 s, our approach's maximum number of execution is 30 for 5 min. Then, we counted the number of cases that carry out equal transactions, that is, the case of Step 3.1 Handling Equal Transactions and the number of unequal transaction cases that process _Step 3.2 Handling Unequal Transactions_. Each of them is expressed in _Equal Txs_ and _Unequal Txs_ in the table. In four nodes with 10 and 25 ms, all transactions of the transaction pool of all nodes are equal, which are 93.33% and 96.67% of 30 coordinator executions, respectively. However, the number of nodes is increased, the higher proportion of the case for equal transactions is decreased, and that of unequal transactions is increased. As a result, average equal and unequal transactions are 55.33% and 44.67% in the case of 10-ms transaction issue interval, while those of the 25-ms case are 72% and 28%, respectively. Thus, we recognized that our contribution to the performance and scalability improvement is positively associated with the proportion of equal transactions, as pointed by Equation (1). Figure 5: Comparing the amount of transactions between IBFT and CC + IBFT when the transaction generation interval is 10 ms.