Table of Links
V. Analysis of EZchain's Performance, Security and Decentralization
VI. Simulation Experiments of EZchain
VII. Conclusions, Acknowledgements, and References
V. ANALYSIS OF EZCHAIN’S PERFORMANCE, SECURITY AND DECENTRALIZATION
A. Analysis of EZchain’s performance
As depicted in Figure 14, EZchain has made significant progress in multiple performance bottleneck indicators.
In terms of consensus and communication, the current majority of layer-1 blockchain still struggle to achieve ideal practical efficiency. In general, the most outstanding works can achieve 100% bandwidth utilization in theory or nearly 10, 000 TPS in expensive bandwidth environments. However, strictly speaking, they have not achieved “scale-out” because when the system reaches the physical limit of bandwidth, adding more nodes and transaction submissions will only worsen the network congestion. Although layer-2 protocols, permissioned chains, and private chains can address the aforementioned dilemma, the former’s security is almost decoupled from the main chain, and the high entry barrier of the latter is unfavorable for decentralization.
EZchain ensures the atomicity and legality of all transactions by only relying on the consensus of the Merkle tree root and the Bloom filter information. As shown in Figure 15, this enables the following benefits: i) The size of the Merkle tree root and Bloom filter will not change with network size and accumulation of transactions, therefore, EZchain block have a constant size; ii) And theoretically accommodating an unlimited number of transactions within the fixed-sized block. These two points collectively contribute to achieving “scaleout” at the consensus and communication levels in EZchain.
In terms of storage cost, due to the special design of EZchain, the block information agreed upon by consensus nodes only includes the Merkle tree root, Bloom filter, random number nonce, timestamp, miner’s signature, miner’s address, and block’s index. Additionally, each EZchain block has a nearly constant size (approximately 0.5 Mb) that does not change with the increase in system throughput and nodes’ scale.[7] This design significantly reduces the storage cost for consensus nodes. For account nodes, they only need to store relevant information about their own holdings (i.e., values, VPB pairs, checkpoints). Moreover, based on subsequent simulation experiments (Subsection VI-D), it can be observed that these storage costs increase very slowly with the system’s runtime. What’s even more exciting is that using reasonable optimization schemes (for example, the selection mechanism of values mentioned in Subsection IV-E), the amount of proof information required for peer-to-peer transmission converges to a fixed value as the system runs (experiment in Figure 22). This means that the transmission and storage costs for account nodes are essentially of constant magnitude, without increasing with the number of nodes and transactions. In conclusion, at the storage level, all nodes in the EZchain system achieve “scale-out”.
In terms of verification costs, the validation cost of consensus nodes is almost constant and does not increase significantly with system throughput and network size. The validation cost of account nodes is also almost constant due to the checkpoint mechanism. Both of these points can be well verified in subsequent simulation experiments.
The visualization of all nodes’ storage and verification costs are shown in Figure 16.
B. Analysis of EZchain’s security and decentralization
Regarding security, although EZchain has implemented significant alterations to the data structure compared to traditional blockchains, the backbone consensus mechanism of its main chain remains unchanged. During the P2P verification phase for account nodes, EZchain’s algorithm guarantees the result certainty. Additionally, all proof transfers occur in a point-topoint manner (between two account nodes or from consensus node to account node), maintaining the network assumptions of the customized backbone consensus algorithm (e.g., asynchrony, weak synchrony and synchrony).
Concerning decentralization, EZchain has effectively lowered various “thresholds”, enabling broader node participation in the system and promoting decentralization. For example, the verification calculation complexity of the consensus node persists at a constant level. Furthermore, the storage and message complexity can approach equivalence to Bitcoin.[8]
Consequently, EZchain retains robust security guarantees stemming from the customized backbone consensus algorithm while enhancing decentralization to some degree.
Authors:
(1) Lide Xue, University of Science and Technology of China, Hefei, China (xldxld@mail.ustc.edu.cn);
(2) Wei Yang, University of Science and Technology of China, Hefei, China (qubit@ustc.edu.cn);
(3) Wei Li, University of Science and Technology of China, Hefei, China (wei123@mail.ustc.edu.cn).
This paper is
[7] Furthermore, consensus nodes also need to store complete Merkle tree information corresponding to recent blocks to respond to “challenges” from other nodes.
[8] EZchain accomplishes this by adjusting the block interval to 10 minutes, reasonably sacrificing a degree of transaction confirmation latency to substantially reduce storage costs without influencing system throughput.