Table of Links
V. Analysis of EZchain's Performance, Security and Decentralization
VI. Simulation Experiments of EZchain
VII. Conclusions, Acknowledgements, and References
IV. DESIGN OF EZCHAIN
A. Core ideas of EZchain
This subsection aims to provide an intuitive and informal introduction to the fundamental concepts underlying the design of EZchain, enabling readers to gain a comprehensive overview of EZchain’s system and algorithm design. We shall commence with a story
The core ideas of EZchain are succinctly explained in the previous story:
-
Create a new data structure for each value (i.e., coin).
-
The main chain only needs to validate, consensus, and store these “two magics”—Merkle tree root and Bloom filter (along with other necessary information).
-
Recipient can independently verify any transactions through the main chain and the proof provided by the sender.
While the approach of EZchain shares similarities with offchain and zero-knowledge proofs, its essence is different. Firstly, unlike off-chain solutions, any transaction generated within the EZchain system will be included in a Merkle tree root, ensuring the security of all transactions through the main chain. Secondly, unlike zero-knowledge proof blockchains, EZchain does not rely on any prior zero-knowledge algorithms. Its verification algorithm is concise, allowing for operations such as proof generation and validation to be conducted within a 10-millisecond timeframe while also ensuring that the size of the proof converges to a constant value.
From an information theory perspective, EZchain enables the validation of transaction legitimacy in decentralized networks with malicious nodes without the need for transmitting and storing the entire global history. We have also discovered that a relatively small amount of information (in terms of transmission and storage) can fully support transaction validation in a decentralized and trustless environment[3]. As shown in Figure 4, a specific value (depicted as a blue cargo box) is continually exchanged among different transactions (T xn#4 − 6). By receiving this value, account l can verify the legitimacy of T xn#6 by checking the legitimacy of this value. This verification involves checking if all the transactions encountered by this value prior to T xn#6 are legitimate and whether T xn#6 itself is legitimate. Importantly, these verifications are independent of T xn#1 − 3. Therefore, when verifying T xn#6, the information contained in T xn#1 − 3 does not need to be transmitted or stored. This concept forms the fundamental idea behind EZchain, similar to the principle of “Occam’s Razor” in blockchain consensus. The goal of EZchain is to eliminate unnecessary information that is irrelevant to consensus and verification, thereby achieving optimized transmission, storage, and verification processes.
B. Overview of EZchain System
Overall research ideas and design framework of EZchain are illustrated in Figure 5. EZchain’s consensus algorithm supports various consensus mechanisms, including Proof of Work (PoW), Byzantine Fault-Tolerant (BFT), Proof of Stake (PoS), and Delegated Proof of Stake (DPoS). In terms of consensus information and data structures, EZchain adopts an innovative “value”-based mechanism instead of relying on the account or UTXO mechanism. This mechanism primarily focuses on recording and verifying the entire ledger from the perspective of value transfer. On-chain, EZchain utilizes an extremely lightweight data structure wherein each block occupies approximately 0.5 Mb. However, in theory, it can accommodate an infinite number of transactions, achieving “scale-out” in terms of information stored within a block. Furthermore, the validation of on-chain information is convenient and efficient, requiring only necessary signature and hash validation without the need to backtrack and validate transaction history and logic. This approach also addresses the initial trust issue that arises when new nodes join the EZchain system. Specific transaction validation is deferred to the “p2p transaction validation” part of account nodes. This means that transaction participants are responsible for verifying the legitimacy of their own transactions, which serves as a positive incentive and decentralizes the validation pressure on consensus nodes.
The overall design logic of EZchain’s consensus mechanism is illustrated in Algorithms 1 and 2, respectively. It can be observed that EZchain does not rely on the underlying design of leader election and block generation logic. Therefore, it can adapt to various existing consensus algorithms. In fact, we highly recommend Algorand’s consensus mechanism— VRF + BFT [6], due to its ability to minimize forks, which aligns well with EZchain’s high-speed block generation performance.[4] The specific details of the data structures involved in Algorithms 1 and 2 will be explained in the subsequent subsection.
C. EZchain’s data structure
Compared with traditional blockchains, EZchain undergoes a meticulous redesign of the data structure regarding blocks, verification, and proofs, as shown in Figure 6. The specific explanation is as follows:
- The previously mentioned “value” is not the same as the token or UTXO in classical blockchain. Its data structure is defined as value = (Begin Index, End Index), and it possesses the following characteristics: i) the value is essentially an integer set: {x, x ∈ [Begin Index, End Index] and x is an integer}, ii) different values do not intersect, i.e., ∀x and ∀y, x∩y = ∅, iii) the value can be split into smaller sets, and the union of these subsets still equals the original set, iv) the number of values can be calculated based on the Begin Index and End Index (i.e., Value’s number = End Index − Begin Index + 1).
D. Analysis of specific transaction cases in EZchain
This subsection provides a detailed analysis of the involvement of each node in the EZchain system during various stages of a transaction, including initiation, submission, consensus, and confirmation. We will also explain the operational process of the EZchain system using the example depicted in Figure 10.
The aforementioned verification process requires b to combine information from the main chain and the proof provided by a to jointly verify the legitimacy of the transaction. The on-chain information of EZchain ensures that a cannot provide false or tampered “value’s history”. Therefore, a can only provide truthful, complete, and verifiable proof to b.
E. Optimized design of EZchain
1) Selection mechanism of values during transaction: During the transaction, assuming that account a wants to pay a target amount x to account b, then a needs to collect the target amount from the values it holds. The simplest way is to iterate through the values from the beginning until finding the values whose cumulative amount satisfies x (as shown in Figure 11).
However, the account node can analyze the specific situation and select the value set that is most suitable for this transaction. For example, a can choose the value set that requires the smallest proof, or does not require splitting (change), etc. (as shown in Figure 12), after comprehensive consideration, each account can customize its own optimization selection strategy according to its own situation.
2) Check point mechanism: The requirement to indiscriminately request all transfer records and proofs for any given value from an account is not necessary. Here is a simple and intuitive example to illustrate (as shown in Figure 13): In block α, a transfers a certain value number (e.g., 100) to b. In a subsequent block β (β > α), d wants to transfer a value of 100 back to a. In this case, d can choose the value that was previously transferred from a and inform a that this value does not need to be revalidated before block α, as it has already been locally validated by a. In other words, a only needs to verify the legality of the value within the block height ranging from α+1 to β. This design concept constitutes the foundation of EZchain’s check point mechanism. As the transactions progress, accounts can continuously update the check points for the held values to save on storage, communication, and verification costs.
Authors:
(1) Lide Xue, University of Science and Technology of China, Hefei, China ([email protected]);
(2) Wei Yang, University of Science and Technology of China, Hefei, China ([email protected]);
(3) Wei Li, University of Science and Technology of China, Hefei, China ([email protected]).
This paper is
[3] However, we acknowledge that the current design of EZchain may still require more information than the minimum necessary amount.
[4] Note that the main algorithm of EZchain does not use the Algorand consensus mechanism for explanation, because the Algorand consensus mechanism is more complex than PoW. Considering readability, we mainly use the PoW version of EZchain for display and explanation.
[5] Due to the possibility of false positives in a bloom filter, indicating that elements (account addresses) not belonging to the target set may be included, it is necessary to furnish information that can completely reconstruct this bloom filter (i.e., all elements of the target set) as evidence.
[6] Consensus nodes may repeatedly add the addresses and transactions of honest accounts to the Bloom filter and Mtree in the EZchain block. As a result, EZchain allows honest accounts to issue “challenges” to the consensus node responsible for publishing the corresponding block. These challenges require the consensus node to provide relevant proof, specifically the necessary information required to reconstruct the Bloom filter or Mtree, in order to resolve the challenge. Legitimate proof can demonstrate that honest account nodes either suffered from false positives in the Bloom filter or were redundantly submitted by the consensus node.