State verification method and device in blockchain system, node and blockchain system

Abstract

A state verification method and device in a blockchain system, a node, and a blockchain system, the blockchain system comprising a first node and a second node, the first node storing tree state data, a leaf node of the tree state data comprising a state, a node in a path from a root node to the leaf node of the tree state data comprising a key of the state, a parent node in the tree state data comprising a hash value calculated based on data in child nodes thereof, the method being performed by the second node. The method comprises: receiving a plurality of states from the first node; determining a common prefix of keys of the plurality of states; calculating a target hash value of an intermediate node corresponding to the common prefix in the tree state data according to the plurality of states; and verifying the target hash value to verify the plurality of states.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a state verification method, device, node and blockchain system in a blockchain system. 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 state verification method, device, node, and blockchain system in a blockchain system, which can more quickly complete the verification of multiple states, thereby improving the performance of the blockchain system.

[0004] Firstly, a state verification method is provided in a blockchain system. The blockchain system includes a first node and a second node. The first node stores tree-structured state data. The leaf nodes of the tree-structured state data include states. Nodes along the path from the root node to a leaf node in the tree-structured state data include keys for the states. The parent node in the tree-structured state data includes a hash value calculated based on data in its child nodes. The method is executed by the second node. The method includes: receiving multiple first states from the first node; determining a common prefix for the keys of the multiple first states; calculating a target hash value for an intermediate node in the tree-structured state data corresponding to the common prefix based on the multiple first states; and verifying the target hash value to verify the multiple first states.

[0005] Secondly, a state verification device is provided in a blockchain system. The blockchain system includes a first node and a second node. The first node stores tree-structured state data. The leaf nodes of the tree-structured state data include states, and the nodes along the path from the root node to a leaf node in the tree-structured state data include the keys of the states. The parent nodes in the tree-structured state data include hash values ​​calculated based on data in their child nodes. The device is deployed in the second node. The device includes: a communication processing unit for receiving multiple first states from the first node; a prefix processing unit for determining a common prefix for the keys of the multiple first states; a hash calculation unit for calculating a target hash value for an intermediate node in the tree-structured state data corresponding to the common prefix based on the multiple first states; and a verification processing unit for verifying the target hash value to verify the multiple first states.

[0006] Thirdly, a node in a blockchain system is provided. The blockchain system includes a first node and a second node. The first node stores tree-structured state data. The leaf nodes of the tree-structured state data include states, and the nodes along the path from the root node to a leaf node in the tree-structured state data include the keys of the states. The parent node in the tree-structured state data includes a hash value calculated based on the data in its child nodes. The second node includes: a communication processing unit for receiving multiple first states from the first node; a prefix processing unit for determining a common prefix for the keys of the multiple first states; a hash calculation unit for calculating a target hash value for an intermediate node in the tree-structured state data corresponding to the common prefix based on the multiple first states; and a verification processing unit for verifying the target hash value to verify the multiple first states.

[0007] Fourthly, a blockchain system is provided, comprising a first node and a second node. The first node stores tree-structured state data, where leaf nodes of the tree-structured state data include states, nodes along the path from the root node to a leaf node in the tree-structured state data include keys for the states, and parent nodes in the tree-structured state data include hash values ​​calculated based on data in their child nodes. The second node is configured to: receive multiple first states from the first node; determine a common prefix for the keys of the multiple first states; calculate a target hash value for an intermediate node in the tree-structured state data corresponding to the common prefix based on the multiple first states; and verify the target hash value to verify the multiple first states.

[0008] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0009] In a sixth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0010] In the embodiments of this specification, for multiple states from full nodes, if the light node determines that the keys of multiple states have a common prefix, it can calculate the target hash value of the intermediate node corresponding to the common prefix in the tree state data based on the multiple states, and then verify the target hash value to complete the verification of the multiple states. This eliminates the need to verify the multiple states one by one, and can complete the verification of the multiple states more quickly, which is beneficial to improving the performance of the blockchain system. Attached Figure Description

[0011] 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.

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

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

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

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

[0016] Figure 5 This is a flowchart of a state verification method provided in the embodiments of this specification;

[0017] Figure 6 This is a schematic diagram of the state hash tree and storage hash tree provided in the embodiments of this specification;

[0018] Figure 7 This is a schematic diagram of the state hash tree provided in the embodiments of this specification;

[0019] Figure 8This is a schematic diagram illustrating the process of verifying multiple states based on tree-structured verification data provided in the embodiments of this specification;

[0020] Figure 9 This is a flowchart of a consensus method provided in the embodiments of this specification;

[0021] Figure 10 This is a schematic diagram of the structure of a state verification device provided in the embodiments of this specification;

[0022] Figure 11 This specification provides a structural diagram of a node in a blockchain system as an example. Detailed Implementation

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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 1 In 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 a consensus 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.

[0028] 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), and the `to` field, for example, is "0x6f8ae93…", which is the address of the smart contract being invoked. 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.

[0029] 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 proposal is typically determined when a predetermined number of consensus nodes reach the same agreement. 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 the same agreement. In related technologies, to achieve consensus, the entire ledger is stored on the consensus nodes, containing the states 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.

[0030] Figure 2This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2 As 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, the storage consistency of nodes n1, n2, and n3 is achieved. This means that 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.

[0031] Figure 3 This 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 (prev Hash 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 (Block Num), a state tree root hash (State_Root), a transaction tree root hash (Transaction_Root), and a receipt tree root hash (Receipt_Root). The Prev Hash 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).

[0032] 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.

[0033] 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.

[0034] 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 Node t2 in the middle corresponds to Figure 3 In the state tree, nodes t2 and t4 correspond to 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".

[0035] 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:

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

[0037] 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.

[0038] 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.

[0039] 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.

[0040] Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has some state, which is defined by state variables within the smart contract and generates new values ​​during the creation and execution of the smart contract. 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.

[0041] 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.

[0042] The state tree and storage tree described above can both be represented as tree-like state data. Nodes in a blockchain system can be divided into two types: full nodes and light nodes. In general, full nodes can store tree-like state data. The leaf nodes of the tree-like state data include the state of user accounts or variables belonging to contract accounts. Each node in the path from the root node to a leaf node in the tree-like state data includes the state key. The parent node in the tree-like state data includes a hash value calculated based on the data in its child nodes. Light nodes may not store the aforementioned tree-like state data; for example, they may only store block headers, or only store block headers and a relatively small amount of tree-like verification data that can be used to verify the state from full nodes. The structure of the tree-like verification data will be described in detail below.

[0043] In some technical scenarios, light nodes may need to verify multiple states from all nodes. If light nodes verify each state from all nodes one by one, it will undoubtedly take a lot of time and affect the performance of the blockchain system.

[0044] This specification provides at least one state verification method, apparatus, node, and blockchain system in the embodiments. For multiple states received by a light node from all nodes, if the light node determines that the keys of these multiple states have a common prefix, it can calculate the target hash value of the intermediate node corresponding to the common prefix in the tree-structured state data based on these multiple states, and then verify the target hash value to complete the verification of these multiple states. Because it is not necessary to verify each of the multiple states individually, the verification of these multiple states can be completed more quickly, which is beneficial to improving the performance of the blockchain system.

[0045] Figure 5 This is a flowchart of a state verification method provided in the embodiments of this specification. See also... Figure 5 As shown, the method may include, but is not limited to, some or all of the following steps S501 to S507.

[0046] Step S501: The light node receives multiple states from the full node.

[0047] Multiple states from full nodes can be partial states from the tree-structured state data stored by full nodes. These states can be the states of user accounts or the values ​​of variables belonging to contract accounts. Light nodes may act as consensus nodes participating in consensus proposals initiated by full nodes. In this case, the aforementioned multiple states and their keys may be located within the consensus proposal from full nodes; more specifically, these multiple states and their keys belong to the read set included in the consensus proposal, and may appear as multiple key-value pairs within the read set.

[0048] In step S503, the light node determines the common prefix of the keys for the multiple states.

[0049] See Figure 4 As shown, assuming that the multiple states from the full set of nodes include state1 and state2, and the keys of state1 and state2 are f5324 and f574a respectively, then the common prefix of the keys of state1 and state2 is f5.

[0050] Step S505: Calculate the target hash value of the intermediate node corresponding to the common prefix in the tree-structured state data or tree-structured verification data based on multiple states.

[0051] In one possible implementation, the paths from leaf nodes to intermediate nodes of multiple states can be retrieved from the tree-structured state data based on the common prefix and the keys of the multiple states. Sibling nodes of other nodes on these paths (excluding the intermediate node) will participate in calculating the target hash value of the intermediate node. For example, please see [link to example]. Figure 4In the tree-structured state data, the intermediate node corresponding to the common prefix "f5" is node t11. The path from leaf nodes t4 and t6 of state1 and state2 to the intermediate node t11 includes nodes t4, t6, t8, and t11. Among the other nodes on this path besides the intermediate node t11, node t6 has a sibling node, which includes node t7. Thus, for example, the target hash value included in node t11 can be calculated using the expression hash(hash(324,hash(state1)),hash(hash(a,hash(state2)),hash(c,hash(state3))))

[0052] In one possible implementation, the light node can store tree verification data corresponding to the tree state data. The tree verification data mainly includes two types: state hash value tree and storage hash value tree. Figure 6 This is a schematic diagram of the state hash tree and storage hash tree stored by the light node in the embodiments of this specification. See also Figure 6 As shown, in the state hash tree and the storage hash tree, with Figure 3 Compared to the state tree and storage tree, the state in the leaf nodes of the state tree and storage tree is replaced with the hash value of that state. For example, state1 in node t4 of the state tree is replaced with hash(state1) in node t4 of the state hash tree, and state5 in node st2 of the storage tree is replaced with hash(state5) in node st2 of the storage hash tree. Figure 7 for Figure 6 A schematic diagram of the state hash tree in the image. (See diagram below.) Figure 7 As shown, in the state hash tree, the leaf nodes include the last character of the account address and the state hash value of the corresponding leaf node in the state tree. For example, leaf node t4 in the state hash tree includes the hash(state1) of "state1" in leaf node t4 of the state tree. The hash values ​​included in each node in the state hash tree, except for the leaf nodes and the root node, can be generated using the same calculation method as in the state tree. For example, Figure 7 The hash(324,74) of the node containing "5" can be calculated using the formula (1) above. The storage hash tree can also have... Figure 7 The structure shown is similar to the structure shown. Thus, Figure 6 The data contained in the state hash tree and the storage hash tree, excluding the leaf nodes, are related to... Figure 3 The corresponding nodes in the state tree and the storage tree are the same, therefore Figure 6 The root hash value of node t1 in the data is... Figure 3The root hash value of node t1 in the array is the same.

[0053] It should be noted that the tree-based validation data may not be limited to, for example, Figure 6 or Figure 7 The structure is shown. For the variant of the MPT tree described above, it is only necessary to delete the state in the leaf nodes of the MPT tree variant, and then the hash value tree after deletion can be used as the tree-structured verification data stored in the light nodes.

[0054] Based on the tree-structured verification data stored in the light node, the path from the leaf node to the intermediate node of each of the multiple states can be retrieved from the tree-structured verification data according to the common prefix and the key of the multiple states. The sibling nodes of other nodes on this path, excluding the intermediate node, will participate in calculating the target hash value of the intermediate node. The process of calculating the target hash value based on the tree-structured verification data is basically similar to that based on the tree-structured state data. The only difference is that if a sibling node participating in the calculation of the target hash value is a leaf node, the hash value of the corresponding state can be directly obtained from that sibling node without recalculating the hash value of the corresponding state. Continuing with the example of calculating the target hash value of node t11 using the aforementioned expression hash(hash(324,hash(state1)),hash(hash(a,hash(state2)),hash(c,hash(state3)))), in the process of calculating the target hash value based on the tree-structured verification data, hash(state3) in this expression can be obtained from... Figure 7 It can be obtained from node t7 without performing a hash operation on state3.

[0055] For example, a light node may store, for instance, Figure 8The example tree-structured verification data provided in the example, and the light node receives multiple state keys from the full nodes including AccountID010086, AccountID130086, AccountID140086, and AccountID150086, then the light node can determine that the intermediate node to calculate the target hash value is "countID" through the common prefix "AcountID" of the aforementioned four keys, determine that the nodes corresponding to the hash values ​​of the aforementioned four keys are "10086", "30086", "40086", and "50086" respectively, and determine that the tree node to be used to calculate the target hash value included in the intermediate node is "20086". Furthermore, the hash values ​​of the states of the aforementioned four keys can be calculated. Based on the string and hash value included in "20086", the hash values ​​of the states of the aforementioned four keys, and the strings included in nodes "10086", "30086", "40086" and "50086", the hash value included in node "0" and the hash value included in node "1" can be calculated layer by layer upwards. Finally, the target hash value that the intermediate node "countID" should include can be calculated.

[0056] Step S507: Verify the target hash value to verify multiple states.

[0057] In one possible implementation, the light node can verify whether the target hash value included in the intermediate node is the same as the current hash value included in the intermediate node; if they are the same, it means that the multiple states have passed verification. For example, please continue to see... Figure 4 or Figure 7 The states from all nodes include state1 and state2, and the intermediate node is t11. If the current hash value included in node t11 is the same as the calculated target hash value, then the target hash value is verified, which also means that state1 and state2 are verified.

[0058] In one possible implementation, the light node can verify the target hash value based on a tree-like state tree. For example, the light node can obtain the first hash value of the root node and the hash values ​​of several tree nodes in the tree-like state data, calculate the second hash value of the root node based on the hash values ​​of the several tree nodes and the target hash value, and verify whether the second hash value is the same as the first hash value. More specifically, the path from the intermediate node to the root node can be queried from the tree-like state data. The sibling nodes of the nodes located on this path will participate in calculating the target hash value of the intermediate node; in other words, the aforementioned several tree nodes refer to the sibling nodes of the nodes located on this path. For example, please continue to see... Figure 6 and Figure 7The path between intermediate node t11 and root node t1 includes nodes t11, t2, and t1. Node t11's sibling node is node t10, and node t2's sibling node is node t3. The hash values ​​of each tree node, such as t10 and t3, will be used to calculate the second hash value of root node t1. For example, the second hash value of root node t1 can be calculated using the expression hash(hash(hash(5,hash(327,74)),hash(d,hash(886,…))),hash(t3)). In this expression, hash(5,hash(327,74) represents the target hash value, and hash(t3) represents the hash value calculated by concatenating the components of the key included in node t3 with the hash values ​​included in node t3.

[0059] See also Figure 8 The light node can query the stored tree verification data of the intermediate node "countID" to determine the specific tree nodes that need to be used to calculate the second hash value corresponding to the root node "Root". These nodes include "sset" and "Dept". Based on the string included in the intermediate node "Dept", the target hash value, the string included in the node "sset", and the hash value, the light node calculates the hash value that node "A" should include. Then, based on the string included in node "A", the hash value that node "A" should include, the string included in the node "Dept", and the hash value, the light node calculates the second hash value corresponding to the root node "Root" and determines whether the calculated second hash value is the same as the first hash value stored in the root node "Root".

[0060] In one possible implementation, when the light node stores tree-structured verification data, the light node can verify the target hash value based on the tree-structured verification data. For example, the light node can obtain the first hash value of the root node and the hash values ​​of several tree nodes in the tree-structured verification data, calculate the second hash value of the root node based on the hash values ​​of the several tree nodes and the target hash value, and verify whether the second hash value is the same as the first hash value. The process of verifying the target hash value based on the tree-structured verification data is basically similar to the process of verifying the target hash value based on the tree state number data. The only difference is that if the tree node / sibling node participating in the verification of the target hash value is a leaf node, the hash value of the corresponding state can be obtained directly from that tree node / sibling node without recalculating the hash value of the corresponding state. Therefore, it will not be described in detail.

[0061] The light nodes mentioned above can participate as consensus nodes in reaching consensus on consensus proposals initiated by all nodes. In this case, for the convenience of describing the technical solutions provided in the embodiments of this specification, the all nodes that initiate consensus proposals are referred to as Full Validating Peers (FVPs), and the light nodes that receive consensus proposals are referred to as Light Validating Peers (LVPs). The light consensus nodes typically store the tree-structured validation data mentioned above.

[0062] Figure 9 This is a flowchart of a consensus method provided in the embodiments of this specification. See also... Figure 9 As shown, the method may include, but is not limited to, some or all of the following steps S901 to S915.

[0063] Step S901: FVP obtains the read sets corresponding to multiple transactions.

[0064] Assuming FVP1 is the master node in the blockchain system, the following description uses FVP1 as an example. FVP1 can receive transactions sent by users from user clients or other FVPs. These transactions can be transfer transactions or transactions that invoke contracts, etc. After receiving a certain number of transactions, FVP1 can select several transactions from the received transactions for consensus to generate a new block. After selecting several transactions, FVP1 obtains the read set corresponding to these transactions. This read set includes the state of account and / or contract variables read from the tree-structured state data based on the read operations included in these transactions. This read set is essentially the state of account and / or contract variables that these transactions need to read from the tree-structured state data when executed. The tree-structured state data includes, for example, the states of account and / or contract variables read from the tree-structured state data. Figure 3 The state tree and storage tree are shown in the diagram.

[0065] Specifically, FVP1 can acquire read sets from multiple transactions and then merge these read sets. Specifically, it selects the key-value pairs of each variable (including account and contract variables) read from the tree-structured state data during the initial read of each variable from the individual read sets of each transaction, thus obtaining the read sets corresponding to multiple transactions. Assuming one of the multiple transactions involves updating the balance of account A (e.g., reducing a preset amount), this transaction, when executed, first needs to read the value of account A (i.e., including Nonce and Balance). Then, based on the read value of account A, it obtains the new value of account A. For example, the transaction increments the Nonce value by 1 and reduces the Balance value by a preset amount, obtaining the updated Nonce and Balance values ​​of account A, which constitute the updated value of account A. Therefore, the read set of this transaction includes the read key-value pairs of account A, and the write set of this transaction includes the written key-value pairs of account A. The read set of these multiple transactions includes key-value pairs of account A read from the tree-structured state data, where the key is the account address of account A and the value is the state of account A, which includes the Nonce value and Balance value in the leaf node corresponding to account A.

[0066] Suppose one of these multiple transactions includes an update operation on variable 'a' in the contract corresponding to account B. Since writing to variable 'a' will update the Storage_root in account B, this transaction also includes a write operation to account B. To write to account B and variable 'a', the read set of this transaction needs to include the key-value pair for account B and the key-value pair for variable 'a'. Assuming this transaction's read of account B and variable 'a' is the first read from the tree-structured state data, the read set of multiple transactions will also include the key-value pair for account B and the key-value pair for variable 'a' read from the tree-structured state data based on this transaction. Specifically, in the key-value pair for account B, the key is the account address of account B, and the value is the state of account B, which includes the values ​​of the Nonce, Balance, CodeHash, and Storage_root fields in the leaf node corresponding to account B. In the key-value pair for variable 'a', the key is the variable name of variable 'a', and the value is the state value of variable 'a'. Based on the read set of multiple transactions, when writing to account B in the execution of the transaction, the updated Storage_root can be calculated based on the updated value of variable a, and then merged with the Nonce, Balance, and CodeHash of account B in the read set to obtain the updated value of account B. The updated value of variable a and the updated value of account B will be recorded in the write set of the transaction to update the tree-structured state data.

[0067] In one implementation, FVP1 can perform static analysis on each transaction, analyzing the transaction body and the contract code of the contracts called within the transaction, thereby determining the account and / or variable names (keys) that each transaction needs to read during execution. Using the obtained keys, the value corresponding to the key is read from the tree-structured state data, thus generating a read set corresponding to the multiple transactions. In another implementation, FVP1 can pre-execute the multiple transactions. FVP1 can pre-execute the multiple transactions according to a preset order, or FVP1 can pre-execute the multiple transactions according to the order in which they are received, and determine the order of the multiple transactions in the consensus proposal based on the pre-execution order of the transactions.

[0068] When FVP1 pre-executes multiple transactions, upon first reading the value of an account or contract variable, it reads it from the tree-structured state data and generates a read set for the multiple transactions based on that initial read value. Simultaneously, FVP1 caches the initially read values ​​of account or contract variables. When these initially read values ​​are updated during the pre-execution of the multiple transactions, the cached values ​​are updated. When these values ​​are read again during the pre-execution of the multiple transactions, the cached values ​​are read. However, the values ​​of user accounts or variables belonging to contract accounts that are read again do not need to be written to the read set for the multiple transactions.

[0069] As can be seen from the above, the read set can include the states of variables belonging to multiple user accounts or contract accounts. Furthermore, the read set can also include keys for multiple states within the read set, where each key represents a corresponding user account or variable belonging to a contract account. More specifically, the read set obtained by FVP can essentially include multiple key-value pairs.

[0070] In step S903, FVP sends a consensus proposal to LVP, which includes a read set of the multiple transactions.

[0071] FVP1 can generate consensus proposals for reaching a consensus on the order of these multiple transactions.

[0072] The consensus proposal may also include a transaction list of the multiple transactions, which includes the transaction bodies of the multiple transactions arranged in sequence. Alternatively, the consensus proposal may also include transaction identifiers (such as the hash values ​​of each transaction) of the multiple transactions arranged in sequence; at the same time, FVP1 or other FVPs that receive transactions from user equipment can broadcast the transaction bodies of the multiple transactions to other consensus nodes, thereby reducing the data size of the consensus proposal and saving the computational load used for signing during the consensus process.

[0073] By including a reading set in the consensus proposal, reference Figure 2 The consensus process shown can verify the read set during the PP stage, that is, determine whether FVP1 is malicious during the PP stage. If FVP1 is determined to be malicious during the PP stage, the consensus process can be terminated early without the need for subsequent preparation and commit stages, saving computing resources and improving the system efficiency in the blockchain.

[0074] In step S905, LVP divides the multiple states into several state groups based on the keys of the multiple states included in the read set.

[0075] Keys for states within the same state group share a common prefix, while keys for states in different state groups do not. For example, if the key for state 1 is f5324, the key for state 2 is f574a, and the key for state 6 is mnf25, then f5324 and f574a share the common prefix f5, so state 1 and state 2 should be assigned to the same state group 1. However, mnf25 does not share a common prefix with f5324 and f574a, so state 6 should be assigned to a different state group 2 than state group 1.

[0076] In step S907, LVP verifies whether the states in several state groups are correct.

[0077] A single state group may include multiple states. For multiple states located in the same group, the method described above can be used. Figure 5 The method described in the illustrated embodiment completes the verification of these multiple states. More specifically, it can be achieved through the aforementioned... Figure 5 In the method embodiment shown, steps 503 to 507 complete the verification of multiple states in a single state group, so as to more quickly complete the verification of all states included in the read set.

[0078] LVP can also perform SPV verification on each state one by one based on tree-structured verification data such as state hash trees and storage hash trees, without grouping the states in the read set. For example, if the read set includes the value of account A, LVP can calculate the hash value (e.g., hash1) of the value of account A in the read set. Based on the values ​​of other leaf nodes in the state hash tree (i.e., state hash values) and hash1, it calculates the hash values ​​of each node layer by layer upwards until it calculates the root hash value (e.g., root1) of the state hash tree. It then determines whether root1 is the same as the root hash value of the state hash tree stored in the LVP. If they are the same, the value of account A in the read set is considered correct. If the read set includes the value of account B and the value of variable a, LVP can similarly perform SPV verification on the value of account B and the value of variable a based on the state hash tree and storage hash tree.

[0079] If all states in the read set pass verification, that is, if the LVP confirms that the read set is correct, the following step S909 can be executed: the consensus nodes (including FVP and LVP) complete the consensus process for multiple transactions.

[0080] If the read set is confirmed to be correct, LVP can perform node functions similar to FVP in subsequent processes, such as executing transactions and generating blocks. Furthermore, if the read set is confirmed to be correct, LVP can complete the consensus process for multiple transactions, including completing processes such as... Figure 2 The diagram illustrates the PP, P, and C phases. If the read set fails verification, it indicates the master node may be malicious. LVP can then terminate the consensus process early and begin the process of replacing the master node, thereby improving the efficiency of the blockchain system.

[0081] In step S911, LVP executes multiple transactions based on the read set.

[0082] LVP can execute multiple transactions in a consensus proposal based on the state in the read set. Specifically, when LVP needs to read the state of an account or variable during transaction execution, if it is the first read of that account or variable, it can find the state of the account or variable in the read set and execute the transaction based on that state. Based on the write operations on the account or contract variable in the transaction, a write set for the transaction is obtained. This write set includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables, used to update the state in the state data. After reading the state of an account or contract variable from the read set, LVP can cache that state and update the state of that account or contract variable in the cache when performing a write operation, for subsequent reads of the state of that account or contract variable during transaction execution. The state of the account or variable in the read set has been verified as the correct current state of the account or variable; therefore, the execution result obtained by executing a transaction based on the state in the read set is the same as the execution result obtained by FVP based on the state in the state data.

[0083] Specifically, assuming that one of the multiple transactions mentioned above includes updating the balance of account A, LVP first reads the value of account A from the read set of multiple transactions (assuming the read value is V1) and stores it in the cache. Based on the transaction, V1 is updated to obtain the updated value of account A (assuming the value is V2), where V2 includes the updated Nonce value and the updated Balance value. Thus, the updated key-value pair of account A can be written to the write set of the transaction, and the value of account A in the cache is updated.

[0084] Suppose that one of a series of transactions includes writing to variable 'a' in the contract corresponding to account B. The LVP first reads the value of account B (let's say V3) and the value of variable 'a' (let's say V4) from the read set of multiple transactions. Based on this transaction, it processes V4 to obtain the updated value of variable 'a' (let's say V5), calculates the hash value of V5, and substitutes it into... Figure 5 The storage hash tree in the data is used to calculate the hash value of the root node st1. The hash value of the root node st1 is used as the storage_root for the update of account B. Combined with the Nonce, Balance and CodeHash of account B in the read set of the transaction, the updated value of account B (let's assume it is V6) is calculated. Thus, the updated key-value pair of account B and the updated key-value pair of variable a can be included in the write set of the transaction.

[0085] While LVP executes multiple transactions based on the read set, if FVP1 has previously pre-executed multiple transactions, as mentioned earlier, the order in which FVP1 pre-executes these transactions corresponds to the order of transactions in the consensus proposal. Therefore, FVP1's reading, updating, and writing of the state during pre-execution of multiple transactions are the same as when executing multiple transactions. Thus, the write set obtained from pre-executing multiple transactions can be used as the write set for executing the multiple transactions, and receipts for the multiple transactions can be obtained from this write set. If FVP1 has not previously pre-executed multiple transactions, it can execute these multiple transactions according to the read set or by reading the state from the state data, following the order of transactions in the consensus proposal. In both methods, the write set and receipts for the multiple transactions obtained by FVP1 are the same as those obtained by LVP when executing multiple transactions.

[0086] In step S913, consensus nodes (including FVP and LVP) reach a consensus on the execution results of multiple transactions.

[0087] Consensus nodes can similarly pass through Figure 2 The consensus process shown achieves consensus on the execution results of multiple transactions. Specifically, after executing multiple transactions and obtaining the write sets and receipts for each transaction, each consensus node calculates the state tree root hash value, transaction tree root hash value, and receipt tree root hash value corresponding to each transaction based on the transaction bodies, write sets, and receipts. Based on the state tree root hash value, transaction tree root hash value, receipt tree root hash value, and the block hash of the previous block (i.e., the block header hash value, such as...),... Figure 3 The Prev Hash (as shown in the diagram) calculates the block hash (i.e., the block header hash of block B1) of the block corresponding to these multiple transactions. FVP1 can send a consensus proposal to other consensus nodes during the PP phase, which includes the block hash of block B1. After receiving this consensus proposal, LVP compares the block hash received from FVP1 with its own calculated block hash of block B1. If they match, LVP signs the block hash and sends it to all other consensus nodes. This completes the process. Figure 2 After the PP, P, and C phases, consensus on the block hash is achieved. Once the consensus nodes have reached a consensus on the block hash, it is guaranteed that the execution results of multiple transactions are identical across all nodes, allowing each node to update its storage based on the execution results of multiple transactions.

[0088] In step S915, LVP updates the tree-based verification data based on the write sets of multiple transactions.

[0089] Specifically, after obtaining the write sets of each transaction, LVP generates a corresponding write set (e.g., wset1) based on these write sets. This wset1 includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables that will be used to update the tree-structured state data based on the write operations of the multiple transactions. After successful consensus on the execution results of the multiple transactions, LVP can update the tree-structured verification data in LVP based on the hash values ​​of each state in wset1.

[0090] In one implementation, the tree-structured verification data in LVP includes hash values ​​of the states of each account and each contract variable. Assuming that write set wset1 contains key-value pairs for account A to be written, LVP can find the storage location of the hash value of the value corresponding to that key in the tree-structured verification data based on the key of account A in wset1, and write the hash value of the state corresponding to that key in wset1 to that storage location.

[0091] Assuming the write set wset1 contains key-value pairs for account B and variable a, the LVP first calculates the updated state hash value based on the updated value of variable a and updates the state hash value of variable a in the tree-based validation data. Then, the LVP calculates the updated state hash value for account B based on the updated value of account B and updates the state hash value of account B in the tree-based validation data.

[0092] In another implementation, the tree-structured validation data stored in the LVP includes, for example: Figure 5 As shown in the state hash tree and storage hash tree, LVP can first update the state hash values ​​in the leaf nodes corresponding to multiple states in the write set, as described in the previous embodiment. Then, based on the updated leaf nodes, the hash values ​​included in each level of nodes in the state hash tree and storage hash tree can be updated upwards until the hash value of the root node of the state hash tree and storage hash tree is updated.

[0093] In addition, after LVP reaches consensus on the block hash, it can store the block header of the generated block for SPV verification and for generating the next block.

[0094] While LVP updates the storage, FVP1 also updates the storage based on the execution results of multiple transactions. Specifically, FVP1 updates the storage based on the write sets of multiple transactions, such as... Figure 3The diagram shows the state tree and storage tree, as well as block B1 storing the multiple transactions. This block includes a block header and a block body, which contains data such as the transaction bodies and receipts of the multiple transactions. After both LVP and FVP in the blockchain system update their storage based on the execution results of the multiple transactions, the tree-structured verification data in LVP still corresponds to the tree-structured state data in FVP, so as to continue consensus on the next batch of multiple transactions.

[0095] Based on the same concept as the aforementioned method embodiments, this specification provides a state verification device in a blockchain system. The blockchain system includes a first node and a second node. The first node stores tree-like state data. The leaf nodes of the tree-like state data include states. Nodes along the path from the root node to a leaf node in the tree-like state data include the keys of the states. The parent node in the tree-like state data includes a hash value calculated based on the data in its child nodes. The device is deployed in the second node. Figure 10 As shown, the device includes: a communication processing unit 1001, configured to receive multiple first states from the first node; a prefix processing unit 1003, configured to determine a common prefix of the keys of the multiple first states; a hash calculation unit 1005, configured to calculate a target hash value of an intermediate node in the tree-structured state data corresponding to the common prefix based on the multiple first states; and a verification processing unit 1007, configured to verify the target hash value to verify the multiple first states.

[0096] Based on the same concept as the aforementioned method embodiments, this specification provides a node in a blockchain system. The blockchain system includes a first node and a second node. The first node stores tree-like state data. The leaf nodes of the tree-like state data include states. Nodes along the path from the root node to a leaf node in the tree-like state data include the keys of the states. The parent node in the tree-like state data includes a hash value calculated based on the data in its child nodes. For example... Figure 11 As shown, the second node includes: a communication processing unit 1101, used to receive multiple first states from the first node; a prefix processing unit 1103, used to determine a common prefix of the keys of the multiple first states; a hash calculation unit 1105, used to calculate a target hash value of an intermediate node in the tree-structured state data corresponding to the common prefix based on the multiple first states; and a verification processing unit 1107, used to verify the target hash value to verify the multiple first states.

[0097] Based on the same concept as the aforementioned method embodiments, this specification provides a blockchain system comprising a first node and a second node. The first node stores tree-like state data, where leaf nodes of the tree-like state data include states, nodes along the path from the root node to a leaf node in the tree-like state data include keys for the states, and parent nodes in the tree-like state data include hash values ​​calculated based on data in their child nodes. The second node is configured to: receive multiple first states from the first node; determine a common prefix for the keys of the multiple first states; calculate a target hash value for an intermediate node in the tree-like state data corresponding to the common prefix based on the multiple first states; and verify the target hash value to verify the multiple first states.

[0098] This specification also provides a computer-readable storage medium storing a computer program that, when executed in a computer, causes the computer to perform the method described in the foregoing method embodiments, which is executed by a full node, a light node, an LVP node, or an FVP node.

[0099] This specification also provides a computing device in the embodiments, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements the method executed by the full node, light node, LVP node or FVP node in the foregoing method embodiments.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

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

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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 state verification method in a blockchain system, the blockchain system comprising a first node and a second node, the first node storing tree-structured state data, the leaf nodes of the tree-structured state data including states, the nodes on the path from the root node to the leaf node in the tree-structured state data including keys of the states, the parent node in the tree-structured state data including hash values ​​calculated based on data in its child nodes, the method being executed by the second node, comprising: Receive multiple first states from the first node; Determine the longest common prefix of the keys in the plurality of first states; Based on the plurality of first states, and the remaining nodes in the target path excluding the intermediate node, and the sibling nodes of the remaining nodes, the target hash value of the intermediate node is calculated. The intermediate node is the node in the tree state data or its corresponding tree verification data that corresponds to the longest common prefix. The target path is the path from the leaf node to the intermediate node of the plurality of first states. The tree verification data is stored in the second node. The target hash value is verified to complete the verification of the multiple first states.

2. The method according to claim 1, wherein verifying the target hash value includes: Obtain the first hash value of the root node and the hash values ​​of several tree nodes in the tree-like state data. Calculate the second hash value of the root node based on the hash values ​​of the several tree nodes and the target hash value. Verify whether the second hash value is the same as the first hash value.

3. The method according to claim 1, wherein the second node stores tree verification data corresponding to the tree state data, the leaf nodes of the tree verification data include the hash value of the state, the nodes on the path from the root node to the leaf node in the tree verification data include the key of the state, and the parent node in the tree verification data includes the hash value calculated based on the data in its child nodes; The verification of the target hash value includes: Obtain the first hash value of the root node and the hash values ​​of several tree nodes in the tree-structured verification data. Calculate the second hash value of the root node based on the hash values ​​of the several tree nodes and the target hash value. Verify whether the second hash value is the same as the first hash value.

4. The method according to claim 2 or 3, wherein the tree node is a sibling node of a node on the path from the root node to the intermediate node.

5. The method according to claim 1, wherein verifying the target hash value includes: Determine whether the current hash value of the intermediate node is the same as the target hash value.

6. The method according to claim 1, wherein the key of the first state represents a user account registered in the blockchain system; or, the key of the first state represents a variable belonging to a contract account registered in the blockchain system.

7. The method according to claim 1, wherein when the child node of the parent node is a leaf node, the hash value of the parent node is calculated based on the hash value of the state included in the child node of the parent node and the components of the key of the state included in the child node of the parent node.

8. The method according to claim 1, wherein receiving a plurality of first states from the first node includes: The consensus proposal is received from the first node, the consensus proposal including a read set of multiple transactions to be executed, the read set including multiple first states read by the first node from the tree state data based on the multiple transactions; The method further includes: reaching consensus on the consensus proposal with the first node and other consensus nodes in the blockchain system based on the verification results of the plurality of first states.

9. The method according to claim 8, wherein the consensus proposal further includes the order in which the plurality of transactions are arranged, and the method further includes: If a consensus is reached on the consensus proposal, the plurality of transactions are executed according to the arrangement order and the read set to obtain a write set, which is used to update several second states.

10. The method according to claim 9, wherein the second node stores tree verification data corresponding to the tree state data, the leaf nodes of the tree verification data include the hash value of the state, the nodes in the path from the root node to the leaf node in the tree verification data include the key of the state, and the parent node in the tree verification data includes a hash value calculated based on the data in its child nodes; The method further includes: Update the tree-structured verification data based on the write set.

11. The method according to claim 10, further comprising: A block header is generated based on the write set and the updated tree verification data, the block header including the hash value of the root node in the updated tree verification data.

12. A state verification device in a blockchain system, the blockchain system comprising a first node and a second node, the first node storing tree-structured state data, the leaf nodes of the tree-structured state data including states, the nodes on the path from the root node to the leaf node in the tree-structured state data including keys of the states, the parent node in the tree-structured state data including hash values ​​calculated based on data in its child nodes, the device being deployed in the second node, comprising: The communication processing unit is configured to receive multiple first states from the first node; A prefix processing unit is used to determine the longest common prefix of the keys in the plurality of first states; A hash calculation unit is used to calculate the target hash value of the intermediate node based on the plurality of first states, the remaining nodes in the target path excluding the intermediate node, and the sibling nodes of the remaining nodes. The intermediate node is the node in the tree state data or its corresponding tree verification data that corresponds to the longest common prefix. The target path is the path from the leaf node to the intermediate node of the plurality of first states. The tree verification data is stored in the second node. The verification processing unit is used to verify the target hash value in order to complete the verification of the plurality of first states.

13. A node in a blockchain system, the blockchain system comprising a first node and a second node, the first node storing tree-structured state data, the leaf nodes of the tree-structured state data including states, the nodes on the path from the root node to the leaf node in the tree-structured state data including keys of the states, the parent node in the tree-structured state data including hash values ​​calculated based on data in its child nodes, the second node comprising: The communication processing unit is configured to receive multiple first states from the first node; A prefix processing unit is used to determine the longest common prefix of the keys in the plurality of first states; A hash calculation unit is used to calculate the target hash value of the intermediate node based on the plurality of first states, the remaining nodes in the target path excluding the intermediate node, and the sibling nodes of the remaining nodes. The intermediate node is the node in the tree state data or its corresponding tree verification data that corresponds to the longest common prefix. The target path is the path from the leaf node to the intermediate node of the plurality of first states. The tree verification data is stored in the second node. The verification processing unit is used to verify the target hash value in order to complete the verification of the plurality of first states.

14. A blockchain system, comprising a first node and a second node, the first node storing tree-like state data, wherein the leaf nodes of the tree-like state data include states, the nodes on the path from the root node to the leaf node in the tree-like state data include keys of the states, and the parent node in the tree-like state data includes a hash value calculated based on the data in its child nodes; wherein: The second node is used to receive multiple first states from the first node; Determine the longest common prefix of the keys in the plurality of first states; Based on the plurality of first states, and the remaining nodes in the target path excluding the intermediate node, and the sibling nodes of the remaining nodes, the target hash value of the intermediate node is calculated. The intermediate node is the node in the tree state data or its corresponding tree verification data that corresponds to the longest common prefix. The target path is the path from the leaf node to the intermediate node of the plurality of first states. The tree verification data is stored in the second node. The target hash value is verified to complete the verification of the multiple first states.

15. 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-11.

Images