Additional Merkle tree state verification method based on block chain

Abstract

The invention discloses an additional Merkle tree state verification method based on a block chain, and the method comprises the steps: sorting state data in the block chain according to a key, constructing a Merkle tree based on the sorted state data, and obtaining a Merkle tree root; performing consistency check based on the Merkle tree root, and verifying the consistency of state data reading and writing; for a given key, existence proof is generated based on the position of the key in the Merkle tree, and existence of state data is verified; when the state data is updated, the storage space is optimized by managing node storage in the Merkle tree. According to the method, the Merkle tree is constructed through sorting so as to perform consistency check and existence proof, and tree nodes are dynamically trimmed during data updating so as to optimize storage. While fast state read-write and reliable existence proof are guaranteed, the increase of storage requirements is effectively controlled, and the overall efficiency and expandability are improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain smart contract technology, and in particular to an append-only Merkle tree state verification method based on blockchain. Background Technology

[0002] Ethereum, a popular blockchain platform, supports the development of various on-chain applications through smart contracts. A smart contract is an automatically executing program code, and maintaining the consistency of the smart contract state across all parties is crucial. To address the consistency issue in smart contract state storage, Ethereum employs the Merkle Patricia Tree (MPT) as its primary storage structure for state information. The MPT tree achieves efficient data verification and access through a hash chain, ensuring consistency of state information across all nodes. However, despite its many advantages, the MPT tree's design also introduces some significant drawbacks.

[0003] First, using an MPT tree significantly increases the time cost of data access compared to directly reading and storing data. Specifically, direct key-value pair read and store operations benefit from O(1) time complexity, while MPT trees require O(logN) time complexity, where N refers to the total amount of stored data. This means that as the amount of data increases, the access speed gradually slows down, affecting the efficiency of smart contract execution.

[0004] Secondly, the MPT tree's data structure is relatively complex, requiring nodes to store not only the actual data but also additional information to construct and maintain the MPT tree itself. This additional data storage requirement increases the storage burden, as well as the system complexity and verification process overhead.

[0005] Finally, the processing of historical data also presents a problem. Because the MPT tree design tends to retain all historical state data, this leads to a gradual accumulation of storage space. Over time, this results in data backlog, wasting storage resources and potentially negatively impacting system performance. Therefore, effectively managing and cleaning up historical state data is a pressing issue that needs to be addressed, as it is crucial for maintaining the healthy operation of the system. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the existing technology. To achieve the above objective, an append-based Merkle tree state verification method based on blockchain is adopted to solve the problems mentioned in the background technology.

[0007] An append-only Merkle tree state verification method based on blockchain includes the following steps:

[0008] For state data in the blockchain, sort the state data according to the key, and construct a Merkle tree based on the sorted state data to obtain the Merkle tree root; A consistency check is performed based on the Merkle tree root to verify the consistency of state data reading and writing. For a given key, generate an existence proof based on the key's position in the Merkle tree to verify the existence of the state data; When state data is updated, storage space is optimized by managing node storage in the Merkle tree.

[0009] As a further aspect of the present invention: the sorting of state data according to the key is to sort in ascending or descending order based on the size of the key.

[0010] As a further aspect of the present invention: the specific steps for constructing the Merkle tree include: Calculate the hash value of each state data, and use the hash value as the leaf node according to the sorted order. Calculate the hash value of the parent node layer by layer until the Merkle tree root is generated.

[0011] As a further aspect of the present invention, the specific steps for generating the existence proof include: Obtain the hash value of the given key, and based on the index position of the key in the Merkle tree, obtain the hash value of the sibling node. Calculate the path hash value layer by layer until it is compared with the root of the Merkle tree. If they match, verify that the state data exists.

[0012] As a further aspect of the present invention: the optimization of storage space by managing node storage in the Merkle tree includes: When updating a key-value pair, mark the deletion of the corresponding sibling node of that key in the Merkle tree.

[0013] As a further aspect of the present invention: when marking the deletion of a sibling node, if the parent node of the sibling node does not exist, the parent node of the sibling node and its corresponding node are generated, and then the marking deletion operation is continued.

[0014] As a further aspect of the present invention: when marking the deletion of a sibling node, if the sibling node has already been deleted, then the sibling node of the parent node is marked as deleted, and the parent node generation and marking deletion operations are repeated.

[0015] As a further aspect of the present invention: the mark deletion operation is repeated until the root node, and the root node is not generated.

[0016] As a further aspect of the present invention: the status data is stored in a database in key-value format, and each key is associated with a corresponding block number and index for querying and generating existence proofs.

[0017] Compared with the prior art, the present invention has the following technical advantages: The above technical solution constructs a Merkle tree by sorting state data by key and uses the generated root for consistency verification of read and write operations. It also generates a short existence proof based on a Merkle path for any key-value data. Furthermore, the solution incorporates an innovative storage optimization mechanism: when data is updated, it efficiently cleans up historical proof data and controls storage growth by dynamically marking and deleting unnecessary sibling nodes and related parent nodes in the Merkle tree. This achieves efficient state data read / write and block verification, significantly improving system performance. It provides cryptographically robust state existence proofs and greatly reduces the storage overhead of storing all historical proof data through an efficient node deletion algorithm, making the entire state storage solution more scalable and practical. Attached Figure Description

[0018] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings: Figure 1 This is a schematic diagram illustrating the steps of the tree state verification method according to an embodiment of this application; Figure 2 This is a schematic diagram of Merkle tree generation according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the existence proof of an embodiment disclosed in this application; Figure 4 This is a schematic diagram illustrating the updating of the value corresponding to key2 in an embodiment disclosed in this application; Figure 5 This is a schematic diagram illustrating the updating of the value corresponding to key4 in an embodiment disclosed in this application; Figure 6 This is a schematic diagram of the node to be deleted, K4_3 Hash, in an embodiment disclosed in this application. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Please refer to Figure 1In this embodiment of the invention, an append-only Merkle tree state verification method based on blockchain includes the following steps: Step S1: For the state data in the blockchain, sort the state data according to the key, and construct a Merkle tree based on the sorted state data to obtain the Merkle tree root; In this embodiment, the state data is sorted according to the key by either ascending or descending order based on the size of the key.

[0021] In this embodiment, the specific steps for constructing a Merkle tree include: Calculate the hash value of each state data, and use the hash value as the leaf node according to the sorted order. Calculate the hash value of the parent node layer by layer until the Merkle tree root is generated.

[0022] Step S2: Perform a consistency check based on the Merkle tree root to verify the consistency of state data reading and writing; Specifically, the consistency check steps are as follows: All state data is read and written, and sorted according to the key. After sorting, a round of Merkle tree calculation is performed to obtain the final root. This root is consistent, which ensures that the read and write results for this block are consistent.

[0023] For example, there are key1-value, key2-value, key3-value, and key4-value.

[0024] Step 1: Sort by key size to get: key2>key1>key4>key3 Step 2: Calculate the Merkle Root; like Figure 2 As shown, the diagram illustrates the generation of a Merkle tree; Step 3: Consistency check.

[0025] If the generated tree roots are consistent, it means that the read and write results in that block are consistent.

[0026] Step S3: For a given key, generate an existence proof based on the key's position in the Merkle tree to verify the existence of the state data; In this embodiment, the specific steps for generating the existence proof include: Get the hash value of the given key, and based on the index position of the key in the Merkle tree, get the hash value of the sibling node. Calculate the path hash value layer by layer until it is compared with the root of the Merkle tree. If they match, verify that the state data exists.

[0027] Specifically, the steps for proving existence are as follows: like Figure 3 As shown, the diagram illustrates the proof of existence. Since key->value / block number / index is stored in the database in this format, when searching for the key, the block number and index can be found. Therefore, the Merkle root can be found in the specific block, and a key-value proof can be generated based on the index.

[0028] Suppose we need to prove that the value corresponding to key4 exists. First, obtain the hash value K4 Hash of key4. Then, calculate the Merkle path based on K4 Hash, K3 Hash, K2 Hash || K1 Hash. If all hash values ​​are calculated correctly and are consistent with the hash value of the root node, it means that the value corresponding to key4 exists in the Merkle tree.

[0029] Step S4: When the state data is updated, optimize storage space by managing the node storage in the Merkle tree.

[0030] In this embodiment, optimizing storage space by managing node storage in the Merkle tree includes: When updating a key-value pair, mark the deletion of the corresponding sibling node of that key in the Merkle tree.

[0031] In this embodiment, when marking the deletion of a sibling node, if the parent node of the sibling node does not exist, the sibling node and its corresponding parent node are generated, and then the marking deletion operation continues.

[0032] In this embodiment, when marking the deletion of a sibling node, if the sibling node has already been deleted, the parent node's sibling node is marked as deleted, and the parent node generation and deletion marking operations are repeated.

[0033] In this embodiment, the mark deletion operation is repeated until the root node, and the root node is not generated.

[0034] In this embodiment, the status data is stored in the database in key-value format, and each key is associated with a corresponding block number and index for querying and generating existence proofs.

[0035] Specifically, the storage optimization steps are as follows: While ensuring existence proofs, the data must also be eradicateable. Each state data is stored in duplicate: one copy is stored directly in the database as a key-value pair, and the other copy is stored within the block (because the calculation of the Merkle root hash value requires specific key-value pairs). Therefore, the more blocks there are, the more proof data is stored. Furthermore, because the data is frequently updated, retaining proofs for all past key-value pairs would result in very high storage costs; therefore, it is necessary to consider how to delete proof data from blocks.

[0036] For example, if key1 is updated, the value corresponding to key1 does not need to be retained, so the proof information can be deleted. However, since it still needs to verify other key-value pairs, it is not directly deleted itself. Therefore, the following steps are involved in updating data (once updated, it will no longer exist): a. When updating a key-value pair, instead of deleting itself, it marks its sibling nodes as deleted. This is because it no longer needs its sibling nodes for verification.

[0037] For example, to update the value corresponding to key2, the node K1 Hash is deleted.

[0038] like Figure 4 As shown in the diagram, this is a schematic diagram of updating the value corresponding to key2; b. When updating a node, if the parent node does not exist (whether it exists or has been deleted is not necessary), then the parent node of both nodes is generated, and then the operation in step a is performed.

[0039] For example, update the value corresponding to key4, but at this time its corresponding parent node is empty (does not exist). Therefore, it is necessary to first generate the parent node K4_3 Hash of both K4 Hash and K3 Hash (from null->K4_3 Hash), and then delete the sibling node of the marked node.

[0040] like Figure 5 As shown in the diagram, this is a schematic diagram of updating the value corresponding to key4; c. When updating its own sibling node, if it finds that it has also been deleted, then mark its parent node's sibling node as deleted and return to step b.

[0041] For example, when updating the value corresponding to key2, if K1 Hash has already been deleted, then the node actually deleted is K4_3Hash.

[0042] like Figure 6 As shown in the diagram, the node to be deleted is K4_3 Hash; d. The root node does not need to be generated; the process ends at the root node.

[0043] The beneficial effects of this invention are: 1. High-efficiency state storage solution. A state storage method based on a key-value database is designed, which allows direct access to state data without the need to construct an MPT tree. This solution significantly improves state read / write speed and block verification efficiency.

[0044] 2. Existence Proof and Storage Optimization. A state existence proof mechanism is introduced to the key-value storage scheme, and an efficient Merkle tree element deletion algorithm is used to reduce the data increment rate, making the growth of storage requirements more controllable.

[0045] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention. The scope of the invention is defined by the appended claims and their equivalents, all of which should be included within the scope of protection of the invention.

Claims

1. A blockchain-based append-only Merkle tree state verification method, characterized in that, Includes the following steps: For state data in the blockchain, sort the state data according to the key, and construct a Merkle tree based on the sorted state data to obtain the Merkle tree root; A consistency check is performed based on the Merkle tree root to verify the consistency of state data reading and writing. For a given key, generate an existence proof based on the key's position in the Merkle tree to verify the existence of the state data; When state data is updated, storage space is optimized by managing node storage in the Merkle tree.

2. The append-only Merkle tree state verification method based on blockchain according to claim 1, characterized in that, The sorting of state data based on the key is done by sorting in ascending or descending order according to the size of the key.

3. The append-only Merkle tree state verification method based on blockchain according to claim 1, characterized in that, The specific steps for constructing the Merkle tree include: Calculate the hash value of each state data, and use the hash value as the leaf node according to the sorted order. Calculate the hash value of the parent node layer by layer until the Merkle tree root is generated.

4. The append-only Merkle tree state verification method based on blockchain according to claim 1, characterized in that, The specific steps for generating the existence proof include: Obtain the hash value of the given key, and based on the index position of the key in the Merkle tree, obtain the hash value of the sibling node. Calculate the path hash value layer by layer until it is compared with the root of the Merkle tree. If they match, verify that the state data exists.

5. The append-only Merkle tree state verification method based on blockchain according to claim 1, characterized in that, The optimization of storage space by managing node storage in the Merkle tree includes: When updating a key-value pair, mark the deletion of the corresponding sibling node of that key in the Merkle tree.

6. The append-only Merkle tree state verification method based on blockchain according to claim 5, characterized in that, When marking a sibling node for deletion, if the parent node of the sibling node does not exist, the parent node of the sibling node and its corresponding node are generated, and then the marking deletion operation continues.

7. The blockchain-based append-only Merkle tree state verification method according to claim 6, characterized in that, When marking a sibling node for deletion, if the sibling node has already been deleted, then mark the parent node's sibling node as deleted, and repeat the parent node generation and deletion marking operations.

8. The append-only Merkle tree state verification method based on blockchain according to claim 7, characterized in that, The marker deletion operation is repeated until the root node is reached, and the root node is not generated.

9. The append-only Merkle tree state verification method based on blockchain according to claim 1, characterized in that, The status data is stored in the database in key-value format, and each key is associated with a corresponding block number and index, which is used for querying and generating existence proofs.

Images