Can Blockchain Scale Efficiently? EZchain’s Simulations Say Yes

Table of Links

Abstract and I. Introduction

II. Related Works

III. System Models

IV. Design of EZchain

V. Analysis of EZchain's Performance, Security and Decentralization

VI. Simulation Experiments of EZchain

VII. Conclusions, Acknowledgements, and References

VI. SIMULATION EXPERIMENTS OF EZCHAIN

In this section, we assess performance by implementing a simulation prototype of EZchain (including the network transport layer) and concentrating primarily on the subsequent aspects: i) The average throughput of the EZchain system; ii) Storage consumption and verification time for EZchain consensus nodes; iii) Storage consumption and transaction confirmation latency for EZchain account nodes.

A. Experimental setup of EZchain

1) Experimental equipment: In this experiment, we utilized a hardware platform equipped with an 11th Gen Intel(R) Core(TM) i7-1165G7 processor (2.80GHz, octa-core) and 16.0 GB of memory to conduct simulations for EZchain. The experimental setup varied in node count, with the largest configuration comprising 100 consensus nodes and 180 account nodes. The maximum number of simulation rounds is set to 1200, allowing for a comprehensive assessment of EZchain’s performance under large-scale node deployment and extended operational durations. The simulator, written in Python, can be accessed on Github[9].

2) Simulation system setup: The quantity of consensus nodes and account nodes can be configured flexibly. Given device memory limitations, parameters for this experiment range from 3 to 160 nodes. All nodes of EZchain randomly establish P2P connections, with each node having a maximum of 30 neighboring nodes, and the bandwidth is uniformly set to

1 Mbits/s. Communication latency between consensus nodes (referring here to queuing delays, excluding transmission times, and similarly below) falls within 1 s as a random variable. Communication latency between consensus nodes and account nodes is fixed at 1.5 s, while latency between account nodes is likewise 1.5 s. The genesis block records the ownership of all initial values. In each simulation round (block generation), account nodes spontaneously engage in random transactions, with the transaction amounts adjustable based on the experiment.

B. EZchain system throughput test

Due to equipment constraints and to maximize the test of EZchain’s throughput limits, we reduce execution rounds and increase extension nodes while enlarging the transaction scale. Additionally, given the quadratic relationship between account nodes and injected transactions per round[10], we configure 100 consensus nodes and 3 to 160 account nodes, with throughput test results shown in Figure 17. The red dotted line is the throughput of the classic blockchain with 100% utilization of bandwidth resources, and the yellow bar indicates the floating range of the test results. Results demonstrate EZchain can achieve over 10,000 Transactions Per Second (TPS), with each block readily accommodating approximately 15,000 transactions. The system throughput can exceed the bandwidth’s limit to meet “scale-out”.

Ultra-high throughput does not affect other performances. At over 10,000 TPS, storage requirements for each blocks less than 0.5 Mb, which are lower than the block size in Bitcoin, despite thousands-fold higher throughput versus Bitcoin. For validation time, EZchain’s consensus node block verification occurs primarily within the order of 1 millisecond, while the account node’s transaction confirmation delay also approaches 10 seconds.

C. Storage and verification cost of EZchain consensus node

Given device constraints, and to extensively test consensus node storage and validation overheads, we require expanded experimental rounds (system runtime) to observe long-term costs. Consequently, this experiment utilizes 3 consensus nodes and 3 account nodes across 1,200 rounds (blocks) to assess cost trends for EZchain consensus nodes. Results in Figure 18 that storage requirements approximate 150 Mb across 1,200 blocks with a linear growth trend. As shown in Figure 19, validation times per block remain entirely independent of system throughput, transaction count, and runtime, persisting below 1 millisecond.

D. Storage and verification cost of EZchain account node

In this experiment, we establish 3 consensus nodes and 3 account nodes, executing 1200 rounds (blocks) to monitor the consumption trends of EZchain account node’s storage cost. The results are depicted in Figure 20, where the red line represents the smoothed cost (an average value is taken every 50 rounds), and the black line represents the amount of information that the account node needs to store under the

same centralized architecture. The average trends indicates that the storage cost of account nodes does not exhibit a substantial increase as the number of system rounds rises. Furthermore, the storage cost does not exhibit an order of magnitude difference compared to that of centralized account nodes.

Regarding transaction confirmation delay, the results, as shown in Figure 21, demonstrate that the transaction confirmation delay for account nodes predominantly falls within 10 seconds. Besides, this delay does not change with the system throughput or system running rounds.

For the transmission and verification costs of account nodes, we assume that account nodes randomly conduct transactions at a frequency with a fixed expectation. This allows us to conveniently configure specific experiments, and reflect the transmission and validation costs by tracking the number of holders the value goes through on each transfer. The results, as shown in Figure 22, demonstrate that as transactions progress, the amount of information required for transmission and validation by the account nodes converges to a fixed value. Intuitively, this conclusion shows that the length of the VPB (the width of the red dotted box) in Figure 10 will converge

to a fixed value, which strongly supports EZchain’s scale-out in terms of account node.

Furthermore, based on the results of this experiment, we can formally prove an important conclusion:

Conclusion 1. For an EZchain account node Acc:

when the above three conditions all have constant upper bounds, the storage cost of Acc will have a fixed constant upper bound, which remains unaltered with respect to the system’s running time, cumulative transactions, network size, and other factors.

E. Performance Comparison between EZchain and other solutions

The comparative analysis concentrates on EZchain in comparison to other layer-1 solutions. Although most layer-2 solutions demonstrate remarkable performance, they function independently from the underlying blockchain and necessitate more robust security assumptions for transactions. The comparative results, illustrated in Table I, emphasize our main considerations: system throughput, transaction confirmation latency, and node storage costs. The data pertaining to other solutions primarily originates from respective experimental sources, with certain data subjected to reasonable scaling adjustments to facilitate improved comparisons.

EZchain demonstrates the second-highest throughput while utilizing minimal network size and the lowest bandwidth resources. Notably, S-HS necessitates 100 times more bandwidth resources compared to EZchain, yet achieves only double the throughput. Moreover, Subsection VI-B validates EZchain’s ability to meet scale-out within limited bandwidth constraints. There are compelling indications that with enhanced experimental infrastructure (such as significantly increased memory resources), EZchain could potentially outperform S-HS entirely. Notably, EZchain consistently delivers confirmation latency within practical levels suitable for consumer-grade applications.

When considering storage costs, EZchain’s consensus nodes exhibit a substantially lower storage consumption, at least an order of magnitude less when compared to the optimal sharding solution, as detailed in the provided table. While the storage cost for account nodes is relatively high, Conclusion 1 provides evidence that this cost converges to a fixed value, unlike in other solutions where it grows indefinitely with increasing transaction volumes.

[9] https://github.com/Re20Cboy/Ezchain-py