## 5 Experimental Design
### Experimental Testing  
The performance compares the throughput and transaction confirmation latency of different sharding protocols for one epoch in the alliance chain with a shard configuration of 4 or 6 nodes. The performance expands the alliance chain by increasing the number of shards from 4 to 8 to evaluate the impact of different network sizes on protocol performance. According to the data in Figures 5(a) and 6(a), this protocol has a throughput difference of more than 66% compared to traditional Elastico. Compared to Sharper and AHL sharding protocols for permissioned chain, this protocol increases throughput by 20% and 27%, respectively. Compared with high-performance Fleetchain, the throughput of this protocol has increased by 19%. With the expansion of network scale, this protocol maintains performance advantages compared with other sharding protocols, highlighting its superior scalability. Figures 5(b) and 6(b) describe the transaction confirmation latency comparison between this protocol and mainstream sharding protocols as the number of nodes in each shard increases. Although the performance gap between this protocol and Fleetchain has narrowed, it still achieves a 12% reduction in latency over the latter. An overview of the above results shows that the system performance advantage of this protocol remains stable as the number of shards increases. \begin{table}
\begin{tabular}{c c} \hline \hline
**Software and Hardware Environment** & **Configure** \\ \hline CPU & 2.40 GHz Intel Core i5-9300H \\ RAM & 16 GB 2667 MHz DDR4 \\ System & Windows 11 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Software and hardware environment configuration. Figure 6: System throughput averages comparison for shard counts ranging from [4, 5,..., 8]. Other factors (_Tct_ = 3, block size = 800 transactions) are the same except for the sharding configuration. Next, test whether _Tct_ affects system performance. Set up a client to send transactions to alliance chain with different shard configurations (4 shards, each with 8 or 9 nodes) and adjust _Tct_ simultaneously. Measure the performance of the alliance chain under different _Tct_ and average the results, as shown in the Figures 8 and 9. Experimental results show that _Tct_ does not affect the system throughput or transaction confirmation latency in the absence of erroneous transactions. Therefore, at the initial stage of system operation, _Tct_ should be set within the range of \(\frac{1}{3}\) to \(\frac{2}{3}\) of the number of shard nodes to ensure stability. This experiment tests the effect of the total amount of transactions in an epoch on the performance of the protocol. Control the shard configuration and _Tct_, only adjust the size of the bigblock, and take the average value of the performance of multiple measurement systems, as shown in Figure 10.  
Figure 8: System throughput averages comparison for different _Tct_ values from {2, 3,..., 6}. Experiments are conducted in two shard configurations, where the number of shards is 4, but the number of nodes within the shards is 8 and 9 (the total number of nodes is 32 and 36), respectively. Figure 7: System latency averages comparison for shard counts ranging from {4, 5,..., 8}. Other factors (_Tct_ = 3, block size = 800 transactions) are the same except for the sharding configuration. Increasing the block size can achieve the goal of enhancing the throughput but will result in longer block times. Therefore, when setting the block size in practice, it is necessary to consider the requirements of the application scenario for throughput and transaction confirmation latency. While the simulations may not perfectly reflect the complexities of real distributed environments, they allow researchers to examine and evaluate the protocol's behavior under controlled conditions. The experiments aim to understand the overall process and evaluate the scalability improvement provided by the protocol compared to existing methods. Additionally, there may be differences when applying the protocol to a real distributed environment.