## 4 Experiments and Results Discussion
### Performance Evaluation under Different Parameters
We can find that appropriately shortening the bpi effectively reduces the average response time and confirmation time and increases the throughput. Figure 10: Average confirmation time with variable block production interval. Figure 9: Average response time with variable block production interval. For an appropriate bpi, the average response time and confirmation time should not be too long, and the throughput should not be too low. However, the block size will also affect the throughput, which should not be increased by excessively shortening the interval. Too short an interval is not conducive to the necessary steps, such as verification, execution, signature, network propagation, etc. Therefore, we recommend setting the block production interval to 3 s.  
By submitting a large number of transactions, A, B, C, D and E, at one time, Figure 12 shows that the throughput can be linearly increased by expanding the block size. Ethereum can control the block size through a unique dynamic algorithm. In short, if the current block size exceeds the threshold, then the maximum limit will be increased; otherwise, it will be reduced. The initial block size of the Ethereum main network is far from the current size. If this dynamic control algorithm is used, we do not have to set a larger block size at the beginning. To control the variables in subsequent experiments, we fixed the block size to 7,000,000 gas. Without exceeding the throughput, Figure 13 shows that the average response time is negligibly affected by the number of BPNs or total nodes, whether for one-step transactions or two-step transactions. Although the network propagation delay increases with the increase in nodes, even in the Ethereum main network, the average network propagation delay is less than 0.3 s. However, the average confirmation time increases linearly with the number of nodes. This is due to the increase in BPNs (delegates), which leads to a longer  
Figure 11: Submission throughput with variable block production interval. Figure 12: Submission throughput with variable block size. consensus time for a block in DPoS. Even with 21 delegates, the average confirmation time is shorter than that in PoW (Bitcoin takes one hour and Ethereum takes six minutes [56]). The DPoS consensus is partially scalable for the node network scale, and there can be a lot of ordinary nodes, but the number of delegates is not recommended to exceed 21. Since only a few delegates are required to verify transactions and produce and confirm blocks without competition, the DPoS consensus is scalable for the transaction scale and the throughput is not affected by the total number of nodes. To explore the impact of block-producing nodes offline, zero to four of them are taken offline in turn (the system will no longer be secure when more than one-third of the BPNs are offline). By submitting a large number of transactions, A, B, C, D and E, at one time, Figure 14 shows that the throughput decreases linearly with the increase in offline BPNs. In the worst case, it decreases by a quarter. Without exceeding the throughput, the test results of the average response time and confirmation time are shown in Figure 15. These times all increase with the increase of offline BPNs, and the increasing trend is also rising. If more transactions are performed, the trend will be faster. Because transactions committed within the time windows allocated to offline BPNs cannot be processed in time, active BPNs are allowed to remove lazy BPNs from delegates by voting, thereby reducing these effects. Before the completion of the voting adjustment, the performance is still acceptable and better than that in PoW when a few BPNs are temporarily offline. Figure 14: Submission throughput under different offline rates of BPNs. Figure 13: Average response time and confirmation time with variable number of nodes. Query transactions are not recorded in the blockchain, so the query delay is very short.