Storage and verification method of blockchain state and blockchain node

Abstract

A blockchain state storage and verification method and a blockchain node, target state data to be stored is state data of a first parameter in a blockchain. The storage method comprises: obtaining a first state tree corresponding to a previous block and a first Merkle tree from the blockchain, the first Merkle tree comprising a plurality of first state data of the first parameter, and the first state tree comprising a first root hash value of the first Merkle tree. Based on the target state data, the first Merkle tree is updated to obtain a second Merkle tree, the second Merkle tree comprising a second root hash value. Based on the second root hash value, the first state tree is updated to obtain a second state tree. The second state tree and the second Merkle tree are stored in association with a current block.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for storing and verifying blockchain state and a blockchain node. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and application. In a blockchain system, full nodes are generally used as the minimum requirement for participating in consensus; a full node needs to include all data to support the consensus function. Summary of the Invention

[0003] The purpose of this invention is to provide a method for storing and verifying blockchain state and a blockchain node, which can realize the verification of fine-grained data.

[0004] This specification provides a method for storing blockchain state, executed by a blockchain node, wherein the target state data to be stored is the state data of a first parameter in the blockchain; the method includes:

[0005] Obtain the first state tree and the first Merck tree corresponding to the previous block from the blockchain. The first Merck tree includes multiple first state data of the first parameter and the first state tree includes the first root hash value of the first Merck tree.

[0006] Based on the target state data, the first Merck tree is updated to obtain a second Merck tree, which includes a second root hash value;

[0007] Based on the second root hash value, update the first state tree to obtain the second state tree;

[0008] The second state tree and the second Merck tree are stored in association with the current block.

[0009] The second aspect of this specification provides a method for verifying the state of a blockchain, wherein the target state data to be verified is the state data of a first parameter corresponding to a first block, and the method includes:

[0010] Obtain first proof data, which is determined based on the state tree and the position of the root hash value of the Merck tree corresponding to the first block; the Merck tree includes multiple state data of the first parameter;

[0011] Obtain second proof data, which is determined based on the Merck tree and the location of the target state data;

[0012] Based on the first proof data, the second proof data, and the pre-acquired block header of the first block, the existence of the target state data is verified.

[0013] A third aspect of this specification provides a blockchain node for storing target state data, which is state data of a first parameter in the blockchain; the blockchain node includes:

[0014] The acquisition unit is used to acquire the first state tree and the first Merk tree corresponding to the previous block from the blockchain. The first Merk tree includes multiple first state data of the first parameter and the first state tree includes the first root hash value of the first Merk tree.

[0015] An update unit is used to update the first Merck tree based on the target state data to obtain a second Merck tree, wherein the second Merck tree includes a second root hash value;

[0016] The update unit is further configured to update the first state tree based on the second root hash value to obtain a second state tree;

[0017] A storage unit is used to store the second state tree and the second Merck tree in association with the current block.

[0018] This specification provides a fourth aspect of a blockchain node for verifying target state data, wherein the target state data is state data of a first parameter corresponding to a first block; the blockchain node includes:

[0019] The acquisition unit is used to acquire first proof data, which is determined based on the state tree and the position of the root hash value of the Merck tree corresponding to the first block; the Merck tree includes multiple state data of the first parameter.

[0020] The acquisition unit is further configured to acquire second proof data, which is determined based on the Merck tree and the location of the target state data;

[0021] The verification unit is used to verify the existence of the target state data based on the first proof data, the second proof data, and the block header of the first block obtained in advance.

[0022] A fifth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods described in the first and second aspects.

[0023] The sixth aspect of this specification provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the methods described in the first and second aspects.

[0024] In the embodiments of this specification, a new Merck tree is created for each block. This Merck tree includes multiple unencoded state data (also called plaintext state data) corresponding to a certain parameter in the blockchain. It should be understood that in traditional blockchain storage schemes, only encoded state data is typically stored, which is usually obtained by encoding several plaintext state data. Therefore, traditional schemes can only verify coarse-grained data. This scheme, however, by creating a Merck tree for the unencoded state data, enables verification of fine-grained data. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A blockchain architecture diagram in one embodiment is shown;

[0027] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0028] Figure 3 This is a schematic diagram of the blockchain data storage structure of consensus nodes in related technologies;

[0029] Figure 4 This is a schematic diagram of the MPT tree structure;

[0030] Figure 5 This diagram illustrates the method for constructing a binary Merck tree from application-layer data.

[0031] Figure 6a This is a schematic diagram of a k-ary tree and a binary tree in the embodiments of this specification;

[0032] Figure 6b This is a schematic diagram of a binary Merck tree in the embodiments of this specification;

[0033] Figure 7 This is a flowchart illustrating a method for storing blockchain state in one embodiment of this specification.

[0034] Figure 8 This is a schematic diagram of the first state tree and the first Merck tree in the embodiments of this specification;

[0035] Figure 9 This is a flowchart of a blockchain state verification method in one embodiment of this specification;

[0036] Figure 10 This is a diagram of a blockchain node structure in one embodiment of this specification;

[0037] Figure 11 This is a diagram of a blockchain node structure in another embodiment of this specification. Detailed Implementation

[0038] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0039] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transmission between nodes.

[0040] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0041] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0042] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0043] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0044] The consensus mechanism in blockchain is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. In various consensus algorithms, consensus on a consensus proposal is typically determined after a predetermined number of consensus nodes reach agreement on the data to be agreed upon. Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated; that is, consensus is considered successful when 2f+1 out of N consensus nodes reach agreement. In related technologies, to achieve consensus, the entire ledger is stored on the consensus nodes, storing the state of all blocks and all accounts. Thus, each node in the blockchain can produce the same state in the blockchain by executing the same transaction, so that each node in the blockchain stores the same state database.

[0045] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can proceed to the commit phase. For example, if... Figure 2 As shown, after receiving the signatures from nodes n2 and n3, node n1 verifies that both signatures are correct for the consensus proposal, thus determining that the preparation phase is complete. Similarly, after receiving and verifying the signatures from node n3 and node n1 (from the preparation phase), node n2 determines that the preparation phase is complete. In the commit phase, each consensus node signs the consensus proposal and sends it to the other consensus nodes. Each consensus node, after receiving the commit phase signatures from 2f = 2 other consensus nodes, determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures from nodes n2 and n3, node n1 determines that the commit phase is complete. Therefore, node n1 can execute the multiple transactions according to the consensus proposal, generate and store a block (e.g., block N) including the multiple transactions, update the world state based on the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, update the world state based on the execution results of the multiple transactions, and generate and store block N. Through the above process, storage consistency is achieved among nodes n1, n2, and n3. In other words, even with the presence of a malicious node, nodes n1 through n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block.

[0046] Figure 3This is a schematic diagram of the blockchain data storage structure for consensus nodes in related technologies. Figure 3 In the blockchain data storage shown, each block's header includes several fields, such as the previous block hash (prevHash in the diagram), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled), a timestamp, a block number (BlockNum), a state tree root hash (State_Root), a transaction tree root hash (Transaction_Root), and a receipt tree root hash (Receipt_Root). The PrevHash in the header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the block hash value of the previous block (i.e., the hash value of the block header). In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, state_root is the hash value of the root of the state trie, which consists of the states of all accounts in the current block. This state trie can be, for example, an MPT tree (Merkle Patricia Tree).

[0047] MPT trees are tree structures that combine Merkle trees and Patricia trees (compressed prefix trees, a more space-efficient trie tree). The Merkle tree algorithm calculates a hash value for each leaf node, then joins each node pairwise and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, which is, for example, a 16-ary tree structure.

[0048] The state tree contains key-value pairs representing the stored content for each account on the Ethereum network. The "key" in the state tree can be a 160-bit identifier (the address of the Ethereum account), and the characters in this address are distributed across nodes along the path from the root node to a leaf node of the state tree. (See reference) Figure 3 As shown, the leaf nodes of the MPT state tree (e.g., nodes t4 and t5) also include the values ​​for each account. Specifically, when the account is a user account (also known as an external account), for example... Figure 3 Account A in the context of the database has a Value that includes a Nonce and a Balance. When the account is a contractual account, for example... Figure 3Account B in the context of the database has a Value that includes a Nonce, a Balance, a CodeHash, and a Storage_root hash. The Nonce represents the number of transactions sent from the account address for external accounts, and the number of contracts created by the account for contract accounts.

[0049] The nodes in the state tree are connected by hashes. Specifically, a hash value can be generated based on the data in the child nodes of the parent node, and the generated hash value is stored in the parent node. Figure 4 This is a schematic diagram of the MPT tree structure. Assume... Figure 4 The node labeled "t2" corresponds to Figure 3 In the state tree, node t2 corresponds to the node labeled "t4". Figure 3 The leaf node t4 in the state tree. For example... Figure 4 As shown, Figure 4 The states contained in each leaf node are represented as state1, state2, state3, and state4, respectively, and each state is also the value of each account. Figure 4 The characters in the left-hand box of each node are used to index the account. The characters in each node along the path from the leaf node to the root node are concatenated to form the account address corresponding to that leaf node. For example, the nodes from the leaf node containing state1 to the root node include the characters "f", "5", and "324", so the account address corresponding to state1 is "f5324".

[0050] exist Figure 4 In the example, the child nodes of the node containing "5" include leaf nodes. When calculating the hash(324,74) contained in this node, it can be calculated using the following formula (1):

[0051] hash(324,74)=hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)

[0052] In other words, in calculation Figure 4 When calculating the hash value of leaf node t4 (hash(324, hash(state1)), the hash value of "324" in node t4 is concatenated with the hash value of state1 (hash(state1),) and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. Figure 4When hashing a non-leaf node (e.g., a node containing "74") using hash(74, hash(a, c)), the data in that node is directly concatenated, and then the hash value is calculated from the concatenated data. It can be understood that the hash value of a node in the state tree is calculated based on all the data of that node. The hash value of a non-leaf node, and a non-root node, is obtained by concatenating the hash values ​​of all its child nodes and then taking the hash value.

[0053] This allows us to calculate the hash value included in each node between the leaf node and the root node in the state tree from bottom to top, thus ultimately allowing us to obtain the calculated hash value. Figure 3 The hash value of node t2 is concatenated with the hash value of node t3, and the hash of the concatenated data is then taken to generate the hash value of node t1. The hash value of node t1 is the state root of this state tree and is recorded in the State_Root field of block N.

[0054] In one variant of the MPT tree, branch nodes may be included. Each branch node can connect to multiple child nodes, and each branch node includes the hash value of the data in each of its connected child nodes. That is, each branch node includes multiple hash values ​​corresponding to multiple master nodes. Leaf nodes are connected after the branch nodes. This variant also includes extension nodes, which can be connected before or after the branch nodes. Each extension node has one child node and includes the hash values ​​of all the data in its connected child nodes. Similarly, in this MPT tree variant, the hash value of the root node can be recursively obtained based on the nodes at each level. The embodiments described in this specification are also applicable to this MPT tree variant.

[0055] Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has some states, which are defined by state variables within the smart contract and generate new values ​​when the smart contract is created and executed. For example... Figure 3 As shown, the contract's relevant state is stored in a storage trie. Figure 3 The diagram illustrates the storage tree of the contract corresponding to account B. The hash value of the root node st1 is stored in the aforementioned storage_root, thus locking all states of the contract to the Value (i.e., account state) of the contract account in the state tree through the root hash. The storage tree can also have an MPT tree structure, similar to... Figure 4 Similarly, in the illustrated state tree, each node on the path from the root node to a leaf node can include characters used to address variable names, and the leaf nodes store the values ​​of the variables, thus storing a key-value mapping from variable names (also called state addresses) to state values. For example, see [reference]. Figure 3The storage tree in the storage tree has leaf nodes st2 and st3, which include, for example, the value of variable a and the value of variable b. Taking variable a as an example, the characters included in each node in the node path from the root node to the leaf node st2 in the storage tree constitute the variable name of variable a. This variable name can be similarly composed of hexadecimal characters.

[0056] The calculation of the hash value of each node in the storage tree can refer to the method for calculating the hash value of nodes in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash value of a portion of the key included in the leaf node and the hash value of the state in the leaf node are concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. When calculating the hash value of a non-leaf node and a non-root node in the storage tree, the data in the node is directly concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of that node.

[0057] As mentioned above, the storage tree is a subtree of the state tree. In other words, the state tree includes the storage tree. Therefore, in the following description of this specification, the state tree and the storage tree will no longer be distinguished, but will be referred to together as the state tree.

[0058] As mentioned earlier, the leaf nodes in the state tree store key-value pairs, also known as system-layer state data (hereinafter referred to as system-layer data). Some key-value pairs in the state tree correspond to application-layer state data (hereinafter referred to as application-layer data), for example, they are obtained by encoding several application-layer data. It should be understood that the state tree can be used to verify system-layer data; however, in most cases, there is a need to verify application-layer data, or in other words, to prove the existence of application-layer data. For example, for a data asset management contract, the state tree may store key-value pairs of a contract variable of the contract, where the key corresponds to the variable name of the contract variable, and the value stores multiple assets in the form of an array. Usually, what needs to be proven is not the key-value pairs themselves, but the existence of one of the multiple assets. Here, "assets" can be called application-layer data. In addition, business contracts may have their own unique data existence proof protocols based on their specific business needs, requiring them to generate proofs themselves. Finally, a key-value pair in a state tree is often thousands of bytes in size, but an application layer data may only be tens of bytes. A key-value pair may contain hundreds or thousands of application layer data. Therefore, how to provide fine-grained data verification is also an urgent issue to consider.

[0059] Some solutions propose using the state tree in the blockchain to prove the existence of the encoded data (i.e., key-value pairs) corresponding to the application layer data, and then decoding this data into plaintext data to indirectly verify the application layer data. However, this solution has the following problems.

[0060] 1. Validating application layer data based on the state tree of storage system layer data leads to tight coupling between the two storage layers, which is not conducive to system upgrades and maintenance.

[0061] 2. Even if it is proven that the encoded data (i.e., system-level data) exists on the state tree, it cannot be directly proven that the corresponding application-level data also exists in the blockchain. The bijectivity of the encoding and decoding protocol must be formally proven.

[0062] 3. It can only prove the existence of coarse-grained data, but cannot prove the existence of fine-grained data, and cannot support the richer existence proof needs and scenarios of the business layer.

[0063] To address this, this solution proposes constructing a Merck tree (also known as an application-layer Merck tree) for application-layer data and anchoring the root hash value of this Merck tree to a state tree, thus forming a two-layer state tree. Based on this two-layer state tree, application-layer data can be verified securely, efficiently, and reliably.

[0064] In one implementation, the aforementioned Merck tree is a binary Merck tree. The method for constructing this binary Merck tree is described below.

[0065] Figure 5 The flowchart illustrates the method for constructing a binary Merck tree from application-layer data, as follows: Figure 5 As shown, the method may include the following steps:

[0066] Step S502: Obtain a k-ary tree pre-constructed for multiple application layer data, where each node in the k-ary tree corresponds to one application layer data.

[0067] The application layer data mentioned above can be, for example, assets or images.

[0068] In one implementation, the aforementioned application-layer data can be obtained by executing transactions that create / invoke smart contracts. Specifically, the k-ary tree can be constructed based on the organizational structure of multiple application-layer data defined by the user within the smart contract using contract variables (hereinafter referred to as parameters). These variables can be, for example, arrays, lists, or trees, etc.

[0069] It should be understood that since each node in a k-ary tree corresponds to one application layer data, it can also be stated that a k-ary tree includes multiple application layer data.

[0070] Step S504: Convert the k-ary tree into a binary tree.

[0071] In one implementation, any known conversion method can be used to convert a k-ary tree into a binary tree, such as the "left child right sibling" method.

[0072] In another implementation, converting a k-ary tree to a binary tree may include: completing the k-ary tree into a complete k-ary tree. The nodes at each level of the complete k-ary tree are numbered from top to bottom. Each node in the complete k-ary tree is then stored sequentially as an array element in a target array according to its number. A binary tree is then constructed based on the target array.

[0073] Figure 6a This is a schematic diagram of a k-ary tree and a binary tree in the embodiments of this specification. Figure 6a In this context, a k-ary tree is specifically a 4-ary tree. The "key" in a k-ary tree represents the node position, which can also be understood as the position of the application layer data within the k-ary tree. Similarly, the "idx" in a binary tree represents the node position, which also represents the position of the application layer data within the binary tree.

[0074] It should be noted that the node positions in the k-ary tree and the node positions in the binary tree are in one-to-one correspondence. That is, for each position of application layer data in the k-ary tree, its position in the binary tree can be determined.

[0075] Step S506: For the above binary tree, calculate the target hash value of each node in the order from bottom to top until the root node is reached; thus, a binary Merck tree is obtained.

[0076] The calculation of the target hash value for each node at each level includes: calculating the initial hash value for each node based on the application layer data corresponding to each node in the binary tree. For the current node, if it is a leaf node, its corresponding initial hash value is used as the target hash value. If it is a non-leaf node, the target hash values ​​of its left and right children are concatenated with the initial hash value of the current node, and then hashed again to obtain the target hash value of the current node. In this way, the target hash values ​​for each node can be obtained.

[0077] by Figure 6a Taking the binary tree shown as an example, the corresponding binary Merck tree can be as follows: Figure 6b As shown. Figure 6b In the diagram, H0-H8 represent the initial hash values ​​for each node, H0'-H8' represent the target hash values ​​for each node, and "H()" represents the hash operation.

[0078] Based on the above process of generating a binary Merck tree, it can be concluded that each node in the binary Merck tree constructed through the embodiments of this specification includes two hash values: an initial hash value and a target hash value. The root hash value of the binary Merck tree described in this specification refers to the target hash value of the root node of the binary Merck tree. For example, Figure 6b In the binary Merkle tree, the root hash value is: H0'.

[0079] Furthermore, since the aforementioned binary Merck tree is derived from a k-ary tree, it includes multiple application layer data.

[0080] Thus, we obtain the Merck trees corresponding to multiple application-layer data defined based on a single variable. It should be understood that when a user customizes multiple sets of application-layer data based on multiple variables in a smart contract, a corresponding Merck tree can be constructed based on each set of application-layer data, thereby allowing the creation of multiple Merck trees.

[0081] It is understood that the embodiments in this specification are not limited to constructing a binary Merck tree; for example, a ternary Merck tree can also be constructed, and this is not a limitation. Furthermore, the embodiments in this specification are not limited to... Figure 6a and Figure 6b The diagram illustrates the construction of a binary Merck tree. For example, it can also be constructed as a standard Merck tree, where multiple application-layer data are used only as leaf nodes. In this case, the hash value of a leaf node in the Merck tree is the hash value of the data within that leaf node, and the hash value of a parent node in the Merck tree is the hash value of the concatenated data of the hash values ​​of its child nodes. Figure 6a and Figure 6b The binary Merck tree shown has fewer tree nodes and occupies less storage space compared to a typical Merck tree.

[0082] It should be noted that the Merck tree described in this specification corresponds one-to-one with a block, and this Merck tree can be constructed or updated when a block is generated. For a constructed Merck tree, its root hash value can be anchored to the corresponding state tree to ensure the immutability of data in the blockchain. The specific anchoring method will be explained later.

[0083] Furthermore, the term "update" is used because in this embodiment, blocks can share the nodes of the Merck tree. In other words, after constructing the Merck tree for the current block, only the changed nodes in the Merck tree need to be updated to obtain the Merck tree for the next block. It should be understood that the update of the Merck tree for the current block is based on the newly generated state data, and thus this update process can also be understood as a storage process for the state data of the parameters. This storage process is described below.

[0084] Figure 7This is a flowchart illustrating a blockchain state storage method in one embodiment of this specification, which is executed by a blockchain node when generating the current block. Figure 7 As shown, the method may include the following steps.

[0085] Step S702: Obtain the first state tree and the first Merk tree corresponding to the previous block from the blockchain. The first Merk tree includes multiple first state data of the first parameter and the first root hash value of the first Merk tree.

[0086] The first state tree here can be in the form of a Merck tree, which can be obtained by transforming an MPT tree.

[0087] The first state data here is the application layer data mentioned above. The first Merck tree is constructed based on multiple application layer data points with the first parameter. For specific construction methods, please refer to... Figure 5 The methods and steps described in this specification will not be repeated here.

[0088] The first parameter may be, for example, a variable 'a' defined in the contract. In this case, the first state tree includes a node (e.g., the first node) corresponding to variable 'a'. Alternatively, the first parameter may be an account A in the blockchain (including external accounts and contract accounts). In this case, the first state tree includes a node corresponding to account A. The following description uses a variable defined in the contract as the first parameter as an example. It can be understood that when the first parameter is an account, the same processing can be applied to multiple state data included in the account's value; this will not be elaborated further.

[0089] In one implementation, including the first root hash value of the first Merkle tree in the first state tree can be understood as including the first root hash value in the first node. Specifically, the first root hash value is included in the value of the first node.

[0090] When the first node includes the first root hash value, the first state tree and the first Merkle tree described above can be as follows: Figure 8 As shown. Figure 8 In this context, the first-level state tree and the second-level state tree together constitute the first state tree. The first-level state tree stores the value of account B, and the second-level state tree stores the variable 'a' defined in the smart contract corresponding to account B. Variable 'a' corresponds to node st6 (i.e., the first node), and node st6 includes the Merkle_root of the first Merkle tree (i.e., the first hash value). Figure 8 In the example, assume the first Merck tree is a binary Merck tree, and that nodes mst0-mst7 are respectively connected to... Figure 6b The middle node mst0 corresponds to the middle node mst7.

[0091] In another implementation, the inclusion of the first root hash value of the first Merkle tree in the first state tree can be understood as the inclusion of the first root hash value in the second node, which is a node associated with the first node. Specifically, the key of the second node can be, for example, a combination of the account address and prefix / suffix characters of the contract account used to define the multiple first state data, and the value of the second node includes the first root hash value. In one example, the prefix / suffix characters here can be the variable name of variable 'a'.

[0092] In summary, through the two implementation methods described above, the first hash value of the first Merck tree can be anchored to the first state tree.

[0093] Step S704: Based on the target state data to be stored, update the first Merck tree to obtain the second Merck tree, which includes the second root hash value.

[0094] The target state data to be stored can be understood as the updated first state data, which can be obtained by executing a transaction that calls a smart contract in the current block. In this smart contract, the user has customized multiple application-layer data using the first parameter.

[0095] The aforementioned update of the first Merck tree may include: updating the hash value of the target node in the first Merck tree corresponding to the target state data based on the target state data; and updating the hash values ​​of all other nodes on the path from the target node to the root node of the first Merck tree from the bottom up.

[0096] Specifically, see reference Figure 8 Assuming the target state data corresponds to node mst4, then updating the hash value of the target node corresponding to the target state data in the first Merkle tree is equivalent to updating the two hash values ​​included in node mst4. Specifically, both the initial hash value H4 and the target hash value H4' are updated to the hash value of the target state data. The updated target hash value of node mst4 is denoted as H4″.

[0097] Furthermore, updating the hash values ​​of the other nodes involves sequentially updating the target hash values ​​of nodes mst1 and mst0. The updated target hash value of node mst1 is denoted as H1″, and the updated target hash value of node mst0 is denoted as H0″. Then, H1″ = H(H3″║H1║H4″), and H0″ = H(H1″║H0║H2″), where "H()" represents the hash operation, and "║" represents the concatenation operation, joining the two characters together.

[0098] It should be understood that after updating the target hash value of node mst0, the second Merkle tree is obtained, and the updated target hash value H0″ of node mst0 is the second root hash value of the second Merkle tree.

[0099] In one scenario, the target state data might be a newly generated state data for the first parameter during contract execution, meaning the existing Merck tree (i.e., the first Merck tree) does not contain a node corresponding to this target state data. In this case, a new node corresponding to the target state data can be created in the k-ary tree first, and a binary Merck tree can be regenerated based on the updated k-ary tree to obtain the second Merck tree.

[0100] by Figure 8 For example, the above-mentioned regeneration of the binary Merck tree specifically includes: creating a node mst9 in the binary Merck tree that corresponds to the new node in the k-ary tree. Figure 8 (Not shown in the diagram), calculate the hash value of the target state data, and use this calculated hash value as the initial hash value H9 and the target hash value H9' of node mst9, respectively, and store both hash values ​​in node mst9. Then, update each node associated with the tree path from node mst9 to node mst0. The specific update method can be found above and will not be repeated here.

[0101] Step S706: Update the first state tree based on the second root hash value to obtain the second state tree.

[0102] The aforementioned update of the first state tree may include: updating the hash value of the target node corresponding to the first root hash value in the first state tree based on the second root hash value; and updating the hash values ​​of all other nodes on the path from the target node to the root node of the state tree from the bottom up.

[0103] In the case where the first node includes the first root hash value, updating the hash value of the target node corresponding to the first root hash value in the first state tree involves replacing the first root hash value in the value of the first node with the second root hash value, thus obtaining the updated value of the first node. Similarly, updating the hash values ​​of all other nodes involves concatenating the hash value of the updated value with the hash values ​​of the sibling nodes of the first node, calculating the hash value again, and then using this calculated hash value to replace the hash value of the parent node of the first node. This process continues until the root node of the first state tree is reached, thus obtaining the second state tree.

[0104] Specifically, see reference Figure 8We can replace the Merkle_root in node st6 with the second root hash value to obtain the updated value of node st6. Then, we can concatenate the hash value of the updated value of node st6 with the hash value of node st7, calculate the hash value again, and use the calculated hash value to replace the hash value of node st4, and so on, until we reach node st1, to obtain the updated second-level state tree.

[0105] Next, the updated hash value of node st1 is used to replace Storage_root in node t5, resulting in the updated value of node t5. Based on the updated value of node t5, the hash values ​​of each node associated with the tree path from node t5 to node t1 in the first-level state tree are updated, resulting in the second state tree.

[0106] In the case where the second node includes the first hash value, updating the hash value of the target node corresponding to the first hash value in the first state tree involves replacing the first hash value in the value of the second node with the second hash value. Similarly, updating the hash values ​​of all other nodes involves concatenating the second hash value with the hash values ​​of the second node's sibling nodes, calculating the hash value, and then using the calculated hash value to replace the hash value of the second node's parent node. This process continues until the root node of the first state tree is reached, thus obtaining the second state tree.

[0107] Step S708: Store the second state tree and the second Merck tree in association with the current block.

[0108] The storage method for the second state tree can refer to the traditional storage method.

[0109] For the second Merck tree, its implementation is as follows Figure 8 Taking the binary Merck tree shown as an example, the corresponding storage method can be as follows:

[0110] In a binary Merkle tree, each node has a fixed size, consisting of two hash values. Since this binary Merkle tree can be viewed as a complete binary tree, it can be stored sequentially, storing the nodes at each level in a sequential manner. If the binary Merkle tree is deep and the underlying storage system uses key-value pairs, the sequentially stored binary Merkle tree can be split into smaller blocks of a fixed size, storing each block in a key-value pair. Because there is a one-to-one correspondence between the node positions in a K-ary tree and the node positions in a binary Merkle tree, and since a binary Merkle tree can be used as a complete binary tree with sequential storage, the node positions in the K-ary tree will correspond one-to-one with the hash value at a specific position in a specific key-value pair within the sequential storage.

[0111] This completes the update of the state tree and Merck tree for the current block, or in other words, it completes the storage of the target state data to be stored. Similarly, state data for other parameters can also be stored.

[0112] In summary, this scheme allows for the maintenance of multiple Merck trees for the same contract account, each used to store multiple sets of application-layer data defined in the smart contracts created by that contract account.

[0113] In summary, the blockchain state storage method provided in the embodiments of this specification can realize the storage of application layer data, thereby facilitating the generation of proof of existence of application layer state data.

[0114] It should be understood that the application layer data included in the Merck tree can also be verified for existence (e.g., SPV verification). Existence verification can be used to verify whether data exists on a specific block using simple methods with minimal communication and computational overhead; that is, to prove the existence of the data.

[0115] In one implementation, the user may request a blockchain node through their user device to generate proof data for the target state data to be verified, and then verify the target state data based on this proof data.

[0116] In another implementation, the target state data can be verified by blockchain nodes.

[0117] The following describes the method for verifying the state of the blockchain performed by blockchain nodes.

[0118] Figure 9 This is a flowchart of a blockchain state verification method in one embodiment of this specification. The method is executed by a blockchain node, and the target state data to be verified can be application layer data corresponding to the first parameter of any first block in the blockchain. Figure 9 As shown, the method may include the following steps.

[0119] Step S902: Obtain first proof data, which is determined based on the state tree corresponding to the first block and the position of the root hash value of the Merck tree corresponding to the first block in the state tree.

[0120] The Merck tree here can be referred to above, which can include multiple state data (i.e., application layer data) of the first parameter. In other words, each node in the Merck tree corresponds to a state data.

[0121] Furthermore, the aforementioned first proof data may include the hash values ​​of multiple nodes associated with the tree path from the node corresponding to the root hash value of the Merck tree to the root node in the state tree. These hash values ​​of multiple nodes are used in the subsequent verification process of the existence proof of the first node.

[0122] Specifically, see reference Figure 8 For example, if the node to be verified is node mst4, since the root hash value of the Merck tree containing node mst4 is stored in the value of variable a, then the hash values ​​of the above multiple nodes include the hash values ​​of nodes st7, st5 and st3 in the second-level state tree, the hash values ​​of the sibling nodes of node t5 in the first-level state tree, and the hash values ​​of the sibling nodes of the parent node of node t5, etc.

[0123] Step S904: Obtain second proof data, which is determined based on the Merck tree corresponding to the first block and the position of the target state data in the Merck tree.

[0124] The second proof data mentioned above may include the hash values ​​of multiple nodes associated with the tree path from the node corresponding to the target state data to the root node in the Merck tree. These hash values ​​are used in the subsequent verification process to prove the existence of the nodes in the Merck tree corresponding to the target state data.

[0125] Also using the node to be verified as Figure 8 Taking node mst4 as an example, the hash values ​​of the above nodes include: the target hash value of node mst3, the initial hash value of node mst1, the target hash value of node mst2, and the initial hash value of node mst0.

[0126] It should be understood that the first proof data and the second proof data mentioned above together constitute the existence proof of the target state data. That is to say, in the embodiments of this specification, the proof data of the application layer data includes two parts.

[0127] Step S906: Based on the first proof data, the second proof data, and the block header of the pre-acquired first block, verify the existence of the target state data.

[0128] It should be understood that the block header of the first block here stores the root hash value of the state tree of the first block.

[0129] The verification of the above existence proof can include the following two aspects:

[0130] First, based on the first proof data, prove the existence of the root hash value of the Merck tree corresponding to the first block. Specifically, based on the hash values ​​of each other node in the tree path included in the first proof data, calculate the root hash value of the state tree; compare the calculated root hash value with the root hash value of the state tree stored in the block header to determine whether the root hash value of the Merck tree exists in the state tree.

[0131] Specifically, see reference Figure 8 First, in the first-level state tree, the hash value of the value of node st6 is calculated, and this hash value is concatenated with the hash value of node st7 to calculate the hash value. Then, the calculated hash value is concatenated with the hash value of node st5 and the hash value is calculated again. Finally, the recalculated hash value is concatenated with the hash value of node st3 and the hash value is calculated to obtain the root hash value corresponding to the second-level state tree.

[0132] Next, in the first-level state tree, based on the root hash value corresponding to the second-level state tree calculated above, and the hash value of the sibling node of node t5, the hash value is calculated from bottom to top until the root hash value of the first-level state tree is obtained, that is, the hash value of node t1 is obtained. The hash value of node t1 is compared with the State_Root in the block header to determine whether the root hash value of the Merck tree exists in the state tree.

[0133] Second, based on the second proof data, prove the existence of the target state data. Specifically, based on the hash values ​​of each other node in the tree path included in the second proof data, calculate the root hash value of the Merck tree; compare the calculated root hash value with the root hash value of the Merck tree found based on the location of the target state data to determine whether the target state data exists in the Merck tree. In one example, the correspondence between the root hash value of the Merck tree and each state data in the Merck tree can be recorded in a mapping table.

[0134] Specifically, see reference Figure 8 First, the target hash value of node mt4 is calculated. Then, the target hash values ​​of node mt4, mst3, and mst1 are concatenated, and the hash value is calculated again. Finally, the calculated hash value, the target hash value of node mst2, and the initial hash value of node mst0 are concatenated, and the hash value is calculated again. The recalculated hash value is compared with the root hash value of the Merck tree to determine whether the target state data exists in the Merck tree.

[0135] It should be understood that once the verifications in both of the above aspects are passed, then the verification of the existence proof of the target state data is passed.

[0136] In summary, the blockchain state verification method provided in this specification decouples the existence proof of application layer data from its storage structure in the state tree, facilitating upgrades and maintenance. Furthermore, the root hash value of the Merkle tree, when anchored to the state tree, uses simple and direct encoding, eliminating the need for formal proof of the bijectivity of its encoding / decoding protocol. Finally, the application layer data existence proof method in this scheme can be applied to application layer data of arbitrary granularity, and is particularly advantageous for proving the existence of fine-grained data.

[0137] Furthermore, this solution innovates in the following aspects: It introduces business semantics into existence proofs, enabling application-layer contracts to combine their own business logic to provide semantically meaningful existence proofs for their business data, rather than simply key-value pairs. Secondly, this solution empowers application-layer contracts to generate business-customized data existence proofs through platform-layer APIs. Existing existence proofs are generally generated by a unified mechanism provided by the platform or storage layer. This solution, through platform-layer API empowerment, allows business contracts to generate customized existence proofs based on their own business needs, providing possibilities for innovative business scenarios. Finally, this solution provides fine-grained data existence proofs. Existing existence proofs generally only provide existence proofs for key-value pairs. This solution adds support for fine-grained data, enabling business contracts to prove the existence of fine-grained data such as monotonic assets.

[0138] Figure 10 This is a diagram of a blockchain node structure according to one embodiment of this specification. The blockchain node is used to store target state data, which is the state data of the first parameter in the blockchain. Specifically, the blockchain node executes actions such as... Figure 7 The method shown implements the storage of target state data, which includes:

[0139] The acquisition unit 1002 is used to acquire the first state tree and the first Merk tree corresponding to the previous block from the blockchain. The first Merk tree includes multiple first state data of the first parameter and the first root hash value of the first Merk tree.

[0140] Update unit 1004 is used to update the first Merck tree based on the target state data to obtain a second Merck tree, which includes a second root hash value.

[0141] Update unit 1004 is also used to update the first state tree based on the second root hash value to obtain the second state tree.

[0142] Storage unit 1006 is used to store the second state tree and the second Merck tree in association with the current block.

[0143] Figure 11This is a blockchain node structure diagram from another embodiment of this specification. The blockchain node is used to verify target state data, which is the state data of the first parameter corresponding to the first block. Specifically, the blockchain node executes, as follows: Figure 9 The method shown verifies the target state data, and includes:

[0144] The acquisition unit 1102 is used to acquire first proof data, which is determined based on the state tree and the position of the root hash value of the Merck tree corresponding to the first block. The Merck tree includes multiple state data of the first parameter.

[0145] The acquisition unit 1102 is also used to acquire second proof data, which is determined based on the Merck tree and the location of the target state data.

[0146] Verification unit 1104 is used to verify the existence of target state data based on first proof data, second proof data, and the block header of the first block obtained in advance.

[0147] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 5 , Figure 7 or Figure 9 The method shown.

[0148] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 5 , Figure 7 or Figure 9 The method shown.

[0149] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0150] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0151] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0152] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0153] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0154] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0155] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0156] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0157] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0158] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0159] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0160] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0161] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0162] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0163] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for storing blockchain state, executed by a blockchain node, wherein the target state data to be stored is the state data of a first parameter in the blockchain; the method includes: Retrieve the first state tree and the first Merck tree corresponding to the previous block from the blockchain. The first Merck tree includes multiple first state data points with a first parameter, and the first state tree includes the first root hash value of the first Merck tree. The multiple first state data points are multiple application layer data points defined in the smart contract based on the first parameter. The first Merck tree is a binary Merck tree, and each node of the binary Merck tree includes an initial hash value and a target hash value. The first root hash value is the target hash value of the root node of the binary Merck tree. Based on the target state data, the first Merck tree is updated to obtain a second Merck tree, which includes a second root hash value; Based on the second root hash value, update the first state tree to obtain the second state tree; The second state tree and the second Merck tree are stored in association with the current block; Calculating the target hash value of each level node in a binary Merck tree includes: Based on the first state data corresponding to each tree node in the binary Merck tree, calculate the initial hash value corresponding to each tree node. For the current node in each of the tree nodes, if the current node is a leaf node, then the corresponding initial hash value is used as the target hash value of the current node. If the current node is not a leaf node, then the target hash value of the left child node, the target hash value of the right child node, and the initial hash value of the current node are concatenated and then hashed to obtain the target hash value of the current node.

2. The method according to claim 1, wherein, The update of the first Merck tree includes: Based on the target state data, update the hash value of the first tree node in the first Merck tree that corresponds to the target state data; Update the hash values ​​of all other tree nodes in the path from the first tree node to the root node of the first Merck tree from the bottom up.

3. The method according to claim 1, wherein, Updating the first state tree includes: Based on the second root hash value, update the hash value of the second tree node in the first state tree that corresponds to the first root hash value; Update the hash values ​​of all other tree nodes in the path from the second tree node to the root node of the state tree from the bottom up.

4. The method according to claim 1, wherein, The target status data corresponds to the asset or image.

5. The method according to claim 1, wherein, The binary Merck tree is constructed through the following steps: Obtain a k-ary tree pre-constructed for the plurality of first state data; each tree node in the k-ary tree corresponds to a first state data. Convert the k-ary tree into a binary tree; For the binary tree, the target hash value of each level of the tree node is calculated in order from bottom to top until the root node is reached; thus, the binary Merck tree is obtained.

6. The method according to claim 5, wherein, The step of converting the k-ary tree into a binary tree includes: Complete the k-ary tree into a complete k-ary tree; The nodes of each level in the complete k-ary tree are numbered in a top-to-bottom order; According to the numbering, each tree node in the complete k-ary tree is used as an array element and stored sequentially in the target array; Based on the target array, construct the binary tree.

7. The method according to claim 1, wherein, The first state tree is a Merck tree, which is obtained by transforming an MPT tree.

8. A method for verifying the state of a blockchain, wherein the target state data to be verified is the state data of a first parameter corresponding to a first block, the method comprising: First proof data is obtained, which is determined based on the state tree corresponding to the first block and the position of the root hash value of the Merck tree corresponding to the first block in the state tree; the Merck tree includes multiple first state data based on the first parameter, and the state tree includes the first root hash value of the Merck tree; the multiple first state data are multiple application layer data defined in the smart contract based on the first parameter; the Merck tree is a binary Merck tree, and each node of the binary Merck tree includes an initial hash value and a target hash value, and the first root hash value is the target hash value of the root node of the binary Merck tree; Obtain second proof data, which is determined based on the Merck tree and the position of the target state data in the Merck tree; Based on the first proof data, the second proof data, and the pre-acquired block header of the first block, the existence of the target state data is verified. Calculating the target hash value of each level node in a binary Merck tree includes: Based on the first state data corresponding to each tree node in the binary Merck tree, calculate the initial hash value corresponding to each tree node. For the current node in each of the tree nodes, if the current node is a leaf node, then the corresponding initial hash value is used as the target hash value of the current node. If the current node is not a leaf node, then the target hash value of the left child node, the target hash value of the right child node, and the initial hash value of the current node are concatenated and then hashed to obtain the target hash value of the current node.

9. The method according to claim 8, wherein, The method is executed by a user device, and the first proof data and the second proof data are obtained by the user device from the blockchain.

10. A blockchain node for storing target state data, the target state data being state data of a first parameter in the blockchain; The blockchain nodes include: The acquisition unit is used to acquire the first state tree and the first Merck tree corresponding to the previous block from the blockchain. The first Merck tree includes multiple first state data of the first parameter, and the first state tree includes the first root hash value of the first Merck tree. The multiple first state data are multiple application layer data defined in the smart contract based on the first parameter. The first Merck tree is a binary Merck tree, and each node of the binary Merck tree includes an initial hash value and a target hash value. The first root hash value is the target hash value of the root node of the binary Merck tree. An update unit is used to update the first Merck tree based on the target state data to obtain a second Merck tree, wherein the second Merck tree includes a second root hash value; The update unit is further configured to update the first state tree based on the second root hash value to obtain a second state tree; A storage unit is used to store the second state tree and the second Merck tree in association with the current block; The calculation unit is used to calculate the initial hash value corresponding to each tree node based on the first state data corresponding to each tree node in the binary Merkle tree. For the current node in each of the tree nodes, if the current node is a leaf node, then the corresponding initial hash value is used as the target hash value of the current node. If the current node is not a leaf node, then the target hash value of the left child node, the target hash value of the right child node, and the initial hash value of the current node are concatenated and then hashed to obtain the target hash value of the current node.

11. A blockchain node for verifying target state data, wherein the target state data is state data of a first parameter corresponding to a first block; The blockchain nodes include: The acquisition unit is used to acquire first proof data, which is determined based on the state tree corresponding to the first block and the position of the root hash value of the Merck tree corresponding to the first block in the state tree; the Merck tree includes multiple first state data of the first parameter, and the state tree includes the first root hash value of the Merck tree; the multiple first state data are multiple application layer data defined in the smart contract based on the first parameter; the Merck tree is a binary Merck tree, and each node of the binary Merck tree includes an initial hash value and a target hash value, and the first root hash value is the target hash value of the root node of the binary Merck tree; The acquisition unit is further configured to acquire second proof data, which is determined based on the Merck tree and the position of the target state data in the Merck tree; The verification unit is used to verify the existence of the target state data based on the first proof data, the second proof data, and the block header of the first block obtained in advance. The calculation unit is used to calculate the initial hash value corresponding to each tree node based on the first state data corresponding to each tree node in the binary Merkle tree. For the current node in each of the tree nodes, if the current node is a leaf node, then the corresponding initial hash value is used as the target hash value of the current node. If the current node is not a leaf node, then the target hash value of the left child node, the target hash value of the right child node, and the initial hash value of the current node are concatenated and then hashed to obtain the target hash value of the current node.

12. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-9.

13. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images