CN115641141A

CN115641141A - State verification method and device in block chain system, node and block chain system

Info

Publication number: CN115641141A
Application number: CN202211213673.6A
Authority: CN
Inventors: 卓海振
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2023-01-24
Also published as: WO2024066009A1

Abstract

A method, a device, a node and a block chain system for verifying the state in the block chain system are provided, the block chain system comprises a first node and a second node, the first node stores tree state data, the leaf nodes of the tree state data comprise the state, the nodes in the path from the root node to the leaf nodes of the tree state data comprise the key of the state, the father node in the tree state data comprises the hash value calculated based on the data in the child nodes, and the method is executed by the second node. The method comprises the following steps: receiving a plurality of states from a first node; determining a common prefix for keys for a plurality of states; calculating a target hash value of an intermediate node corresponding to the public prefix in the tree state data according to the plurality of states; the target hash value is verified to verify the plurality of states.

Description

State verification method and device in block chain system, node and block chain system

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a state verification method, a state verification device, a node and a block chain system in a block chain system.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsified and forged is guaranteed in a cryptology mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people. In a blockchain system, generally, a whole node is used as a minimum facility for participating in consensus, and the whole node needs to include a whole amount of data to support the consensus function.

Disclosure of Invention

The invention aims to provide a method and a device for verifying states in a block chain system, a node and the block chain system, which can be used for rapidly completing verification of a plurality of states so as to improve the performance of the block chain system.

In a first aspect, a method for verifying a state in a blockchain system is provided, where the blockchain system includes a first node and a second node, the first node stores tree state data, leaf nodes of the tree state data include a state, nodes on a path from a root node to the leaf nodes in the tree state data include keys of the state, a parent node in the tree state data includes a hash value calculated based on data in its child nodes, and the method is executed by the second node. The method comprises the following steps: receiving a plurality of first states from the first node; determining a common prefix for keys of the plurality of first states; according to the plurality of first states, calculating a target hash value of an intermediate node corresponding to the public prefix in the tree state data; verifying the target hash value to verify the plurality of first states.

In a second aspect, a state verification apparatus in a blockchain system is provided, where the blockchain system includes a first node and a second node, the first node stores tree state data, a leaf node of the tree state data includes a state, a node on a path from a root node to the leaf node in the tree state data includes a key of the state, a parent node in the tree state data includes a hash value calculated based on data in its child node, and the apparatus is deployed in the second node. The device comprises: a communication processing unit for receiving a plurality of first states from the first node; a prefix processing unit for determining a common prefix of the keys of the plurality of first states; a hash calculation unit, configured to calculate a target hash value of an intermediate node corresponding to the common prefix in the tree state data according to the plurality of first states; and the verification processing unit is used for verifying the target hash value so as to verify the plurality of first states.

In a third aspect, a node in a blockchain system is provided, where the blockchain system includes a first node and a second node, the first node stores tree state data, leaf nodes of the tree state data include a state, nodes on a path from a root node to the leaf nodes in the tree state data include keys of the state, and a parent node in the tree state data includes a hash value calculated based on data in its child nodes. The second node comprises: a communication processing unit for receiving a plurality of first states from the first node; a prefix processing unit for determining a common prefix of the keys of the plurality of first states; a hash calculation unit, configured to calculate a target hash value of an intermediate node corresponding to the common prefix in the tree state data according to the plurality of first states; and the verification processing unit is used for verifying the target hash value so as to verify the plurality of first states.

In a fourth aspect, a blockchain system is provided, where the blockchain system includes a first node and a second node, the first node stores tree state data, a leaf node of the tree state data includes a state, a node on a path from a root node to the leaf node in the tree state data includes a key of the state, and a parent node in the tree state data includes a hash value calculated based on data in its child node. Wherein: the second node is configured to receive a plurality of first states from the first node; determining a common prefix of keys for the plurality of first states; according to the plurality of first states, calculating a target hash value of an intermediate node corresponding to the public prefix in the tree state data; verifying the target hash value to verify the plurality of first states.

In a fifth aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first aspect.

In a sixth aspect, there is provided a computing device comprising a memory having stored therein executable code and a processor that, when executing the executable code, implements the method of the first aspect.

In the solution of the embodiment of the present specification, for a plurality of states from a full number of nodes, when determining that keys of the plurality of states have a common prefix, a light node may calculate a target hash value of an intermediate node corresponding to the common prefix in tree state data according to the plurality of states, and then verify the target hash value to complete verification of the plurality of states.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 illustrates a block chain architecture in one embodiment;

FIG. 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm;

fig. 3 is a schematic diagram of a block chain data storage of a common node in the related art;

FIG. 4 is a schematic diagram of the structure of an MPT tree;

FIG. 5 is a flow chart of a method of state verification provided in an embodiment of the present description;

FIG. 6 is a schematic diagram of a state hash value tree and a stored hash value tree provided in embodiments of the present description;

FIG. 7 is a schematic diagram of a state hash value tree provided in an embodiment of the present description;

FIG. 8 is a schematic diagram of a process for verifying multiple states based on tree verification data provided in an embodiment of the present specification;

FIG. 9 is a flow chart of a consensus method provided in an embodiment of the present specification;

fig. 10 is a schematic structural diagram of a state verifying apparatus provided in an embodiment of the present specification;

fig. 11 is a block diagram of a node in a blockchain system according to an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the blockchain architecture diagram shown in fig. 1, a blockchain 100 includes N nodes, which are schematically shown as nodes 1-8 in fig. 1. The connecting lines between the nodes schematically represent P2P (Peer to Peer) connections, which may be, for example, TCP connections or the like, for transmitting data between the nodes.

A transaction in the blockchain domain may refer to a unit of task that is performed in the blockchain and recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates the address of the account From which the transaction was initiated (i.e., from which a transfer task To another account was initiated), the To field indicates the address of the account From which the transaction was received (i.e., from which a transfer was received), and the Data field includes the transfer amount.

The block chain may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed by a transaction trigger on the blockchain system. An intelligent contract may be defined in the form of code. Calling the intelligent contract in the blockchain initiates a transaction pointing to the address of the intelligent contract, so that each node in the blockchain runs the intelligent contract code in a distributed mode.

In the scenario of contract deployment, for example, bob sends a transaction containing information to create an intelligent contract (i.e., a deployment contract) into the blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is null to indicate that the transaction is for contract deployment. After the nodes are identical through a consensus mechanism, determining a contract address of the contract of 0x6f8ae93 \8230, adding a contract account corresponding to the contract address of the intelligent contract in a state database by each node, allocating state storage corresponding to the contract account, storing a contract code, and storing a hash value of the contract code in the state storage of the contract, thereby successfully creating the contract.

In the scenario of invoking a contract, for example, bob sends a transaction for invoking a smart contract into the blockchain as shown in fig. 1, where the from field of the transaction is the address of the account of the transaction initiator (i.e., bob), and the to field is, for example, "0x6f8ae93 \8230", described above, i.e., the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is identified in the blockchain, each node in the blockchain can execute the transaction respectively, so that the contract is executed respectively, and the state database is updated based on the execution of the contract.

The consensus mechanism in the blockchain is a mechanism in which blockchain nodes achieve the same consensus on blockinformation (or called blockdata) in the whole network, and can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), proof of stock (POS), proof of commission rights (DPOS), practical Byzantine Fault Tolerance (PBFT) algorithm, etc. In various consensus algorithms, after a predetermined number of consensus nodes agree on data to be agreed (i.e., a consensus proposal), it is determined that the consensus proposal is successful. Specifically, in the PBFT algorithm, f malicious nodes can be tolerated for N ≧ 3f +1 consensus nodes, that is, when 2f +1 nodes in the N consensus nodes reach the same, the consensus can be determined to be successful. In the related art, in order to implement the consensus function, a full-amount ledger, that is, the states of all blocks and all accounts are stored on the consensus node. Thus, each node in the blockchain may generate the same state in the blockchain by performing the same transaction, such that each node in the blockchain stores the same state database.

FIG. 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm. As shown in fig. 2, according to the PBFT consensus algorithm, the consensus process can be divided into four phases of Request (Request), prepare (Pre-Prepare, PP), prepare (Prepare, P), and Commit (Commit, C). Assuming that a blockchain includes four common nodes, i.e., a node n 1-a node n4, where the node n1 is, for example, a master node, and the node n 2-a node n4 is, for example, a slave node, according to the PBFT algorithm, f =1 malicious nodes can be tolerated in the nodes n 1-a node n 4. In particular, during the request phase, the users of the blockchain may send requests, e.g. in the form of blockchain transactions, to node n1 via their user equipment. In the preparation stage, after receiving multiple transactions from one or more user devices, the node n1 may package the multiple transactions into a consensus proposal, and send the consensus proposal and the signature of the consensus proposal by the node n1 to other consensus nodes (i.e., the node n 2-the node n 4) for generating blocks, where the consensus proposal may include information about transaction bodies of the multiple transactions and a submission order of the multiple transactions. In the preparation phase, each slave node may sign the consensus proposal and send it to other respective nodes. Assuming that node n4 is a malicious node, after receiving the signatures of the consensus proposals for 2f =2 other consensus nodes, respectively, node n1, node n2 and node n3 may determine that the preparation phase is complete and may enter the commit phase. For example, as shown in fig. 2, after receiving the signatures of the nodes n2 and n3, the node n1 verifies that the signatures of the nodes n2 and n3 are both correct signatures of the consensus proposal, and then determines that the preparation phase is completed, and after receiving the signature of the node n3 and the signature of the node n1 in the preparation phase and verifying them, the node n2 determines that the preparation phase is completed. In a submission stage, each consensus node signs the consensus offer in the submission stage and sends the consensus offer to other consensus nodes, and after receiving the signatures of 2f =2 other consensus nodes in the submission stage, each consensus node determines that the submission stage is completed and the consensus is successful. For example, node N1, after receiving signatures of the commit phases of nodes N2 and N3 and verifying, determines that the commit phase is complete, so that node N1 may execute the plurality of transactions according to the consensus proposal, generate and store a block (e.g., block N) including the plurality of transactions, update the world state according to the execution results of the plurality of transactions, and return the execution results of the plurality of transactions to the user device. Similarly, the node N2 and the node N3 execute the plurality of transactions after determining that the commit phase is completed, update the world state according to the execution results of the plurality of transactions, and generate and store the block N. Through the above process, storage identity of the node n1, the node n2 and the node n3 is realized. That is, the nodes n1 to n4 can still realize successful consensus on the consensus proposal in the presence of a malicious node, and complete the execution of the block.

Fig. 3 is a schematic structural diagram of blockchain data storage of a common node in the related art. In the blockchain data store shown in fig. 3, the blockhead of each Block includes fields such as the last blockhash previous _ Hash (prevhash in the figure), the random number Nonce (this Nonce is not a random number in some blockchain systems or is not enabled in some blockchain systems), the Timestamp, the blocknumber Block Num, the State tree Root Hash State _ Root, the Transaction tree Root Hash Transaction _ Root, the Receipt tree Root Hash receiptjroot, and so on. 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 header). In this way, the next block is locked to the previous block by the block head on the block chain. Specifically, as described above, the state _ root is a hash value of the root of a state Tree (state trie) composed of the states of all accounts in the current block, and the state Tree is, for example, an MPT Tree (Merkle Patricia Tree).

An MPT Tree is a Tree structure that combines a Merkle Tree and a Patricia Tree (a compressed prefix Tree, a more space-saving Trie, a dictionary Tree). The Merkle Tree algorithm computes a Hash value for each leaf node, and then computes the Hash again by connecting two by two until the top-most Merkle root. The etherhouse uses a modified MPT tree, which is, for example, a 16-way tree structure.

The state tree includes key and value pair values (key and value pair) of the storage content corresponding to each account in the ethernet network. The "key" in the state tree may be a 160-bit identifier (address of the etherhouse account) with the characters contained in the account address distributed among the nodes in the path from the root node to the leaf nodes of the state tree. Referring to fig. 3, leaf nodes (e.g., node t4 and node t 5) of the MPT state tree also include values for the respective accounts. When the account is a user account (also called an external account), such as account a in fig. 3, the Value of the account includes a counter (Nonce) and a Balance (Balance). When the account is a contract account, such as account B in fig. 3, the Value of the account includes a counter (Nonce), a Balance (Balance), a contract code hash Value (CodeHash), and a Storage tree root hash Value (Storage _ root). Wherein the counter represents, for an external account, the transaction amount sent from the account address; for a contract account, it is the number of contracts that the account creates.

Nodes in the state tree are connected by hashing, and specifically, a hash value may be generated based on data in a child node of a parent node, and the generated hash value may be stored in the parent node. Fig. 4 is a schematic structural diagram of an MPT tree. Assume that node t2 in fig. 4 corresponds to node t2 in the state tree in fig. 3 and node t4 corresponds to leaf node t4 in the state tree in fig. 3. As shown in fig. 4, the states included in each leaf node in fig. 4 are represented as state1, state2, state3, and state4, respectively, and each state is also Value of each account. Characters in a left frame of each node in fig. 4 are used for indexing the account, and characters included in each node in a path from a leaf node to a root node are spliced together to be the account address corresponding to the leaf node. For example, each node between the leaf node where state1 is located and the root node includes characters "f", "5", and "324", so that the account address corresponding to state1 is "f5324".

In fig. 4, leaf nodes are included in the child nodes of the node including "5", and when the hash (324, 74) included in the node is calculated, it can be calculated by the following formula 1:

hash(324,74)＝hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)

that is, when the hash value hash (324, hash (state 1)) of the leaf node t4 in fig. 4 is calculated, "324" of the node t4 and the hash value hash (state 1) of state1 are concatenated, and then a hash value is calculated for the concatenated data to obtain a hash value of the leaf node, when the hash value hash (74, hash (a, c)) of the non-leaf node (e.g., the node including "74") in fig. 4 is calculated, the data in the node is directly concatenated, and then a hash value is calculated for the concatenated data.

Therefore, the hash value included in each node between the leaf node and the root node can be calculated in the state tree from bottom to top, the calculated hash value of the node t2 in the graph 3 can be spliced with the hash value of the node t3, the spliced data is hashed, and the hash value of the node t1 is generated. The hash value of the node t1 is the status Root of the status tree and is recorded in the State _ Root field of the block N.

In a variation of the MPT tree, a branch node may be included, the branch node may connect a plurality of child nodes, and the branch node includes a hash value of data in each child node to which the branch node is connected, that is, the branch node includes a plurality of hash values respectively corresponding to the plurality of main nodes, and the leaf node is connected after the branch node. The extension node is connected to the front or back of the branch node, and has a child node, and the extension node comprises the hash value of all data in the child node connected with the extension node. In this MPT tree variant, the hash value of the root node can likewise be recursively derived based on the level nodes. The embodiments of the present description are equally applicable to this MPT tree variation.

After the intelligent contract is deployed on the block chain, a corresponding contract account is generated. This contract account will typically have states that are defined by state variables in the intelligent contract and that produce new values when the intelligent contract is created and executed. As shown in fig. 3, the relevant state of the contract is stored in a storage tree (storage tree), and the storage tree of the contract corresponding to account B is schematically shown in fig. 3. The hash Value of the root node st1 of the storage tree is stored in the storage _ root, so that all states of the contract are locked to the Value (i.e., the account state) of the contract account in the state tree through the root hash. The storage tree may also have an MPT tree structure, and similar to the state tree shown in fig. 4, each node in the path from the root node to the leaf nodes may include characters for addressing variable names, and the leaf nodes have variable values stored therein, thereby storing a key-Value mapping of variable names (which may also be referred to as state addresses) to state values. For example, referring to the storage tree in fig. 3, the leaf nodes st2, st3 of the storage tree include, for example, value of variable a, value of variable b, etc., taking variable a as an example, characters included in each node in a node path from a root node to the leaf node st2 in the storage tree constitute a variable name of variable a, which may similarly be constituted by 16-ary characters.

Wherein, the calculation of the hash value of each node in the storage tree can refer to the hash value calculation method of the node in the state tree. Specifically, when the hash value of a leaf node in the storage tree is calculated, the hash values of the state in the leaf node and part of keys included in the leaf node are spliced, and then the hash value is calculated for the spliced data to obtain the hash value of the leaf node. When the hash value of the node which is not a leaf node and a root node in the storage tree is calculated, the data in the node is directly spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the node.

Both the state tree and the memory tree exemplarily described above can be expressed as tree-like state data. The nodes in the block chain system can be divided into a full node (full node) and a light node (light node). In summary, tree state data may be stored in the full-scale node, a leaf node of the tree state data includes a state of a user account or a variable belonging to a contract account, each node in a path from a root node to the leaf node in the tree state data includes a key of the state, and a parent node in the tree state data includes a hash value calculated based on data in its child node. The light nodes may not have stored therein the aforementioned tree state data, such as only the header of a memory block, or only the header of a memory block and tree verification data which is relatively small in data amount and can be used to verify the state from the nodes of the full amount, the structure of which will be described in detail below.

In some technical scenarios, a light node may need to verify multiple states from a full number of nodes. If the light node verifies the states from the full-scale nodes one by one, it will take much time to affect the performance of the blockchain system.

The embodiment of the specification at least provides a method, a device, a node and a blockchain system for verifying the state in the blockchain system. For a plurality of states received by the light node from the full number of nodes, under the condition that the keys of the states have the public prefix, the light node can calculate the target hash value of the intermediate node corresponding to the public prefix in the tree state data according to the states, and then verify the target hash value to complete the verification of the states.

Fig. 5 is a flowchart of a status verification method provided in an embodiment of the present specification. Referring to fig. 5, the method may include, but is not limited to, some or all of the following steps S501 to S507.

In step S501, the light node receives a plurality of states from the full node.

The plurality of states from the quorum nodes may be partial states in tree state data stored by the quorum nodes. The status may be a status of a user account or a value of a variable belonging to a contract account. The light node may act as a consensus node participating in consensus on consensus proposals initiated by the full-scale node, in which case the aforementioned multiple states and the keys of the multiple states may be located in the consensus proposals from the full-scale node, and more specifically the multiple states and the keys of the multiple states belong to a reading set included in the consensus proposals, and may appear as multiple key-value pairs in the reading set.

In step S503, the light node determines a common prefix of the keys of the plurality of states.

Referring to fig. 4, assuming that a plurality of states from the quorum node include state1 and state2, keys of state1 and state2 are f5324 and f574a, respectively, a common prefix of keys of state1 and state2 is f5.

Step S505, calculating a target hash value of an intermediate node corresponding to the common prefix in the tree state data or the tree verification data according to the plurality of states.

In one possible implementation, a path from the leaf node to the intermediate node to which the plurality of states belong can be queried from the tree state data according to the common prefix and the keys of the plurality of states, and siblings of nodes other than the intermediate node on the path participate in calculating the target hash value of the intermediate node. For example, please continue to refer to fig. 4, the intermediate node corresponding to the common prefix "f5" in the tree state data is a node t11, the paths from the leaf nodes t4 and t6 to the intermediate node t11 to which the states 1 and 2 belong include the node t4, the node t6, the node t8, and the node t11, in each node except the intermediate node t11 in the path, the node t6 has a sibling node, and the sibling node includes a node t7; thus, the target hash value included in the node t11 is calculated by, for example, expressions hash (hash (324, hash (state 1)), hash (hash (a, hash (state 2)), hash (c, hash (state 3))).

In a possible implementation manner, the light node may store therein tree verification data corresponding to the tree state data, and the tree verification data mainly includes two types, namely a state hash value tree and a storage hash value tree. Fig. 6 is a schematic diagram of a state hash value tree stored by a light node and a stored hash value tree in an embodiment of the present specification. Referring to fig. 6, in the state hash value tree and the stored hash value tree, compared with the state tree and the storage tree in fig. 3, the state in the leaf node in the state tree and the storage tree is replaced with the hash value of the state, for example, the state1 in the node t4 in the state tree is replaced with the hash (state 1) in the node t4 in the state hash value tree, and the state5 in the node st2 in the storage tree is replaced with the hash (state 5) in the node st2 in the stored hash value tree. FIG. 7 is a diagram of the state hash tree of FIG. 6. As shown in fig. 7, in the state hash value tree, the leaf node includes the last character of the account address and the state hash value of the corresponding leaf node in the state tree. For example, the leaf node t4 in the state hash value tree includes the hash (state 1) of "state1" in the leaf node t4 in the state tree. Hash values included in respective nodes other than the leaf nodes and the root node in the state hash value tree may be generated using the same calculation method as in the state tree. For example, the hash (324, 74) in the node including "5" in fig. 7 can be calculated by the above formula (1). The stored hash value tree may also have a structure similar to that shown in fig. 7. As such, the nodes other than the leaf nodes in the state hash value tree and the storage hash value tree in fig. 6 include the same data as the corresponding nodes in the state tree and the storage tree in fig. 3, and thus the root hash value of the node t1 in fig. 6 is the same as the root hash value of the node t1 in fig. 3.

It should be noted that the tree verification data may not be limited to include the structure shown in fig. 6 or fig. 7. For the above-described MPT tree modification, only the state in the leaf node in the MPT tree modification needs to be deleted, i.e., the deleted hash value tree can be used as the tree verification data stored in the light node.

On the basis that the light node stores the tree-shaped verification data, the paths from the leaf nodes to the intermediate nodes of the plurality of states can be inquired from the tree-shaped verification data according to the public prefix and the keys of the plurality of states, and brother nodes of other nodes except the intermediate nodes on the paths participate in calculating the target hash value of the intermediate nodes. The process of calculating the target hash value based on the tree verification data is substantially similar to the process of calculating the target hash value based on the tree state number data, except that if a certain sibling node participating in calculating the target hash value is a leaf node, the hash value of the corresponding state can be directly obtained from the sibling node without recalculating the hash value of the corresponding state. Continuing with the example of calculating the target hash value included in the node t11 by using the aforementioned expression hash (hash (324, hash (state 1)), hash (hash (a, hash (state 2)), hash (c, hash (state 3)))), the hash (state 3) in the expression can be obtained from the node t7 in fig. 7 without performing a hash operation on the state3 in calculating the target hash value based on the tree verification data.

Illustratively, the light node stores therein the tree-shaped verification data exemplarily provided in fig. 8, and the key in which the light node receives the plurality of states from the full-volume node includes AcountID010086, acountID130086, acountID140086, and AcountID150086, then the light node may determine, through the common prefix "AcountID" of the foregoing 4 keys, that the intermediate node that needs to calculate the target hash value is "countID", determine that the nodes corresponding to the hash values of the foregoing 4 keys respectively are "10086", "30086", "40086", and "50086", and determine that the tree node that needs to calculate the target hash value included in the intermediate node includes "20086". Further, the hash values of the states of the four keys may be calculated, and the hash value included in the node "0" and the hash value included in the node "1" may be calculated layer by layer upward from the character string and the hash value included in the "20086" and the hash values of the states of the four keys, and the character strings included in the nodes "10086", "30086", "40086", and "50086", and finally the target hash value that the intermediate node "countID" should include may be calculated.

In step S507, the target hash value is verified to verify a plurality of states.

In a possible implementation manner, the light node may verify whether the target hash value included in the intermediate node is the same as the current hash value included in the intermediate node, and if the target hash value is the same as the current hash value, the multiple states are verified. For example, with continued reference to fig. 4 or fig. 7, the state from the full-volume node includes state1 and state2, the intermediate node is t11, and if the current hash value included in the node t11 is the same as the calculated target hash value, the target hash value is verified, which means that state1 and state2 are verified.

In one possible implementation, the light node may verify the target hash value based on a tree-like state tree. For example, the light node may obtain a first hash value of a root node and hash values of a plurality of tree nodes in the tree state data, calculate a second hash value of the root node according to the hash values of the plurality of tree nodes and the target hash value, and verify whether the second hash value is the same as the first hash value. More specifically, a path from an intermediate node to a root node may be queried from the tree state data, and siblings of nodes located on the path will participate in calculating a target hash value of the intermediate node, in other words, the tree nodes refer to siblings of nodes located on the path. For example, with continued reference to fig. 6 and fig. 7, the path between the intermediate node t11 and the root node t1 includes a node t11, a node t2, and a node t1, the sibling node of the node t11 includes a node t10, the sibling node of the node t2 includes a node t3, and the hash values included in the tree nodes such as the node t10 and the node t3 respectively are used to calculate the second hash value of the root node t 1; the second hash value of the root node t1 may be computed, for example, by an expression hash (hash (hash (5, hash (327, 74)), hash (d, hash (886, \8230))), hash (t 3)), where hash (5, hash (327, 74) represents the target hash value, hash (t 3) represents the components of the key included in node t3 and the concatenation result of the hash values included in node t 3.

With reference to fig. 8, the light node may query the tree verification data stored in the intermediate node "countID" according to the intermediate node "countID", determine that the tree node that needs to be used for calculating the second hash value corresponding to the Root node "Root" specifically includes the node "sset" and the node "Dept", calculate the hash value that the node "a" should include according to the character string included in the intermediate node "Dept", the target hash value, the character string included in the node "sset", and the hash value, calculate the second hash value corresponding to the Root node "Root" according to the character string included in the node "a", the hash value that the node "a" should include, the character string included in the node "Dept", and the hash value, and determine whether the calculated second hash value is the same as the first hash value stored in the Root node "Root".

In one possible embodiment, in the case where the light node stores tree verification data, the light node may verify the target hash value based on the tree certificate verification. For example, the light node may obtain a first hash value of a root node and hash values of a plurality of tree nodes in the tree verification data, calculate a second hash value of the root node according to the hash values of the plurality of 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 verification data is basically similar to the process of verifying the target hash value based on the tree state data, and the difference is that if the tree node/sibling node participating in verifying the target hash value is a leaf node, the hash value of the corresponding state can be directly obtained from the tree node/sibling node without recalculating the hash value of the corresponding state, so detailed description is omitted.

The light node as described above may participate in consensus on consensus-proposed nodes initiated by the full-scale nodes as consensus nodes. In this case, for convenience of describing the technical solution provided in the embodiment of the present specification, the Full amount of nodes initiating the consensus proposal will be referred to as Full consensus nodes (FVPs) in the following, and the Light nodes receiving the consensus proposal will be referred to as Light consensus nodes (LVPs), where the Light consensus nodes typically store the tree-like verification data described above.

Fig. 9 is a flowchart of a consensus method provided in an embodiment of the present specification. Referring to fig. 9, the method may include, but is not limited to, some or all of the following steps S901 to S915.

In step S901, the FVP obtains a reading set corresponding to a plurality of transactions.

Assuming that FVP1 in the block chain system is the master node, FVP1 is described as an example hereinafter. The FVP1 may receive the transaction sent by the user from the user client or other FVPs. The transaction may be a transfer transaction, or may be a contract-invoked transaction, or the like. After receiving a certain amount of transactions, FVP1 may select multiple transactions for consensus among the received transactions for generating a new tile. After the multiple transactions are selected, the FVP1 acquires the reading sets corresponding to the multiple transactions. The read set includes the states of the account and/or contract variables read from the tree-like state data according to the read operations included in the transactions, i.e., the states of the account and/or contract variables that the transactions need to read from the tree-like state data when executed, wherein the tree-like state data includes, for example, the state tree and the storage tree shown in fig. 3.

Specifically, the FVP1 may obtain respective reading sets of multiple transactions, and then may merge the reading sets of the transactions, that is, select, from the respective reading sets of the multiple transactions, a key-value pair of each variable (including an account and a contract variable) read from the tree-like state data when the variable is read for the first time, so as to obtain the reading sets corresponding to the multiple transactions. Assuming that one of the plurality of transactions includes an update to the Balance of account a (e.g., a reduction by a preset amount), the transaction, when executed, needs to first read the Value of account a (i.e., including Nonce and Balance), and then obtain a new Value of account a according to the read Value of account a, for example, add 1 to the Nonce Value according to the transaction, and reduce the preset amount to the Balance Value, resulting in an updated Nonce Value and Balance Value of account a, which constitute an updated Value of account a. Thus, the read set of transactions includes the key-value pairs of account A that were read, and the write set of transactions includes the key-value pairs of account A that were written. The read set of the multiple transactions includes a Key-Value Key Value pair of the account a read from the tree state data, where Key is an account address of the account a, value is a state of the account a, and the state includes a Nonce Value and a Balance Value in a leaf node corresponding to the account a.

Assuming that one of the transactions includes an update operation to the variable a in the contract corresponding to account B, the transaction also includes a write operation to account B because writing to the variable a results in an update to the Storage _ root in account B. To write to account B and variable a, the read set of the transaction needs to include the Key-Value pair of account B and the Key-Value pair of variable a. Assuming that the reading of account B and variable a by the transaction is the first reading from the tree state data, the read set of multiple transactions also includes the key-value pair of account B and the key-value pair of variable a read from the tree state data based on the transaction. The Key in the Key-Value Key Value pair of the account B is the account address of the account B, the Value is the state of the account B, and the state includes the values of each field of Nonce, balance, codeHash and Storage _ root in the leaf node corresponding to the account B. The Key in the Key-Value Key Value pair of the variable a is the variable name of the variable a, and the Value is the state Value of the variable a. According to the read sets of the multiple transactions, when the account B is written in the execution of the transaction, the updated Storage _ root can be calculated according to the updated value of the variable a, and is merged with the Nonce, balance and CodeHash of the account B in the read set to obtain the updated value of the account B, and the updated value of the variable a and the updated value of the account B are recorded in the write set of the transaction to update the tree state data.

In one embodiment, the FVP1 may perform static analysis on each transaction, analyze a transaction body of the transaction and a contract code of a contract called in the transaction, thereby determine an account and/or a variable name, i.e., a key, that needs to be read when each transaction is executed, and read a value corresponding to the key from the tree state data through the obtained key, thereby generating a read set corresponding to the plurality of transactions. In another embodiment, the FVP1 may pre-execute the plurality of transactions in a preset order of arrangement of the plurality of transactions, or the FVP1 may pre-execute the plurality of transactions according to an order of receipt of the respective transactions and determine an order of arrangement of the plurality of transactions in the consensus offer according to the order of pre-execution of the respective transactions.

When a plurality of transactions are executed in advance, the FVP1 reads the value of the account or the contract variable for the first time, reads from the tree state data, and generates a read set of the plurality of transactions according to the value of the account or the contract variable read for the first time. Meanwhile, the FVP1 caches values of the first read accounts or contract variables, updates the values of the first read accounts or contract variables in the cache when the values of the first read accounts or contract variables are updated in pre-executing the plurality of transactions, and reads the values of the accounts or contract variables in the cache when the values of the accounts or contract variables are read again in pre-executing the plurality of transactions, wherein the values of the user accounts or variables belonging to the contract account read again do not need to be written into the read sets of the plurality of transactions.

As can be seen in conjunction with the above, the read set may include the status of multiple user accounts or variables belonging to a contract account. The read set may further include keys of a plurality of states in the read set, the keys being used to characterize a corresponding user account or a variable belonging to a contract account. More specifically, the FVP-derived read set may essentially comprise a plurality of key-value pairs.

In step S903, the FVP sends a consensus proposal to the LVP, which includes the readings of the plurality of transactions.

The FVP1 may generate a consensus offer for consensus on the ranked order of the plurality of transactions.

The consensus proposal may further include a transaction list of the plurality of transactions, the transaction list including transaction bodies of the plurality of transactions arranged in sequence. Alternatively, the consensus proposal may further include transaction identifications (such as hash values of the respective transactions) of a plurality of transactions arranged in sequence; meanwhile, the FVP1 or other FVPs receiving transactions from the user equipment may broadcast the transaction entities for the multiple transactions to other consensus nodes via broadcast, thereby reducing the amount of data for the consensus proposal and saving the amount of computation for signatures during the consensus process.

By including the reading set in the consensus proposition, referring to the consensus process shown in fig. 2, the reading set can be verified in the PP stage, that is, whether the FVP1 is malignant is determined in the PP stage, and if the FVP1 is determined to be malignant in the PP stage, the consensus process can be ended in advance without performing the subsequent preparation stage and submission stage, thereby saving the computing resources and improving the system efficiency in the block chain.

In step S905, the LVP divides the plurality of states into several state groups according to the keys of the plurality of states included in the read set.

Keys located in states in the same state group have a common prefix, and keys located in different state groups do not have a common prefix. For example, state 1's key is f5324, state 2's key is f574a, state 6's key is mnf25, f5324 and f574a have a common prefix f5, so state1 and state2 need to be divided into the same state packet 1, mnf25 does not have a common prefix with f5324, f574a, so state6 needs to be divided into state packet 2 different from state packet 1.

In step S907, the LVP verifies whether the states in the several state packets are correct, respectively.

A single state packet may include multiple states, and for multiple states located in the same packet, verification of the multiple states may be accomplished using the method described in the method embodiment of fig. 5 above. More specifically, the verification of multiple states in a single state packet can be completed through the aforementioned processes shown in steps 503 to 507 in the embodiment of the method shown in fig. 5, so that the verification of all states included in the read set can be completed more quickly.

Instead of grouping the states in the read set, the LVP may perform verification of each state one by one based on tree verification data such as the state hash tree and the storage hash tree. For example, the Value of the account a is included in the read set, the LVP may calculate a hash Value (e.g., hash 1) of the Value of the account a in the read set, calculate hash values of respective nodes layer by layer upward based on values (i.e., state hash values) of other leaf nodes in the state hash Value tree and the hash1 until a root hash Value (e.g., root 1) of the state hash Value tree is calculated, determine whether the root hash values of the root1 and the state hash Value tree stored in the LVP are the same, and if the root hash values are the same, consider the Value of the account a in the read set to be correct. Where account B Value and variable a Value are included in the read set, the LVP may similarly spv verify account B Value and variable a Value based on the state hash Value tree and the stored hash Value tree.

In the case that all the statuses in the read set pass the verification, that is, in the case that the LVP confirms that the read set is correct, step S909 is executed, where the consensus node (including the FVP and the LVP) completes the consensus process for multiple transactions.

In the case that the LVP confirms that the read set is correct, the LVP may perform node functions, such as performing transactions, generating blocks, and the like, in a subsequent process based on the read set, similarly to the FVP. Furthermore, the LVP may complete the consensus process for multiple transactions, including the PP phase, P phase and C phase as shown in fig. 2, in case the read set is confirmed to be correct. If the read set is not verified, it can be determined that the master node has the possibility of doing malicious work, and the LVP can end the consensus process as early as possible and start the process of replacing the master node, thereby improving the efficiency of the blockchain system.

At step S911, the LVP performs a plurality of transactions based on the read sets.

The LVP may perform multiple transactions in the consensus proposal based on the state in the read set. Specifically, when the LVP needs to read the state of an account or a variable during the process of executing a transaction, if the account or the variable is read for the first time, the state of the account or the variable may be found from the read set, the transaction is executed based on the state of the account or the variable, and a write set of the transaction is obtained according to a write operation on the account or the contract variable during the transaction, where the write set includes a key-value pair of the account or a key-value pair of the contract account and the contract variable, and is used to update the state in the state data. The LVP may cache the status of an account or contract variable after reading it from the read set and update the status of the account or contract variable in the cache when a write to the account or contract variable is performed for a subsequent read of the status of the account or contract variable during execution of the transaction. The status of the account or variable in the read set has been verified, i.e., is the current and correct status of the account or variable, and thus, the execution of a transaction based on the status in the read set results in the same execution as the execution of a transaction based on the status in the status data by the FVP.

Specifically, assuming that one of the transactions includes an update to the Balance of account a as described above, the LVP first reads the value of account a from the read set of the transactions (assuming that the read value is V1) and stores it in the cache, updates V1 according to the transaction, and thus obtains an updated value of account a (assuming that the value is V2), where V2 includes an updated Nonce value and an updated Balance value, so that the updated key-value pair of account a can be written in the write set of the transaction, and the value of account a in the cache can be updated.

Assuming that one transaction of the transactions includes writing of a variable a of a contract corresponding to the account B, the LVP first reads a value of the account B (assumed to be V3) and a value of the variable a (assumed to be V4) from a read set of the transactions, processes V4 according to the transactions to obtain an updated value of the variable a (assumed to be V5), calculates a hash value of V5, substitutes the stored hash value tree in fig. 5 to calculate a hash value of the root node st1, uses the hash value of the root node st1 as an updated storage _ root of the account B, and calculates an updated value of the account B (assumed to be V6) by combining Nonce, balance, and CodeHash of the account B in the read set of the transaction, so that the write set of the transaction may include an updated key-value pair of the account B and an updated key-value pair of the variable a.

While the LVP executes multiple transactions according to the read set, the FVP1, if multiple transactions have been previously pre-executed, since the sequence in which the FVP1 pre-executes the multiple transactions corresponds to the ordering of the multiple transactions in the consensus proposal, as described above, the reading, updating and writing of the status when multiple transactions are pre-executed is the same as when multiple transactions are executed, and thus, a write set resulting from pre-executing the multiple transactions can be used as a write set to execute the multiple transactions and a receipt for the multiple transactions can be derived from the write set. The FVP1 may execute the plurality of transactions in the ranked order of the plurality of transactions in the consensus proposal based on the read set, or by reading the status from the status data, if the plurality of transactions were not previously pre-executed. In both of the above approaches, the write set and receipt for multiple transactions obtained in FVP1 are the same as the write set and receipt for multiple transactions performed by the LVP.

In step S913, the consensus node (including the FVP and the LVP) performs consensus on the execution results of the plurality of transactions.

The consensus node may similarly perform consensus on the results of the execution of multiple transactions through the consensus process shown in fig. 2. Specifically, after executing a plurality of transactions to obtain a write set and a receipt of each transaction, each consensus node may calculate a state tree root hash value, a transaction tree root hash value, and a receipt tree root hash value corresponding to the plurality of transactions according to transaction entities of the plurality of transactions, the write set and the receipt of each transaction. The Hash of the block (i.e., the Hash of the head of the block B1) corresponding to the plurality of transactions is calculated based on the Hash of the head of the block (i.e., the Hash of the head of the block B1) of the previous block, the Hash of the root of the transaction, the Hash of the root of the receipt tree, and the Hash of the state tree corresponding to the plurality of transactions. The FVP1 may send a consensus proposal including the block hash of block B1 to other consensus nodes during the PP phase. After receiving the consensus proposal, the LVP may compare whether the chunk hash received from the FVP1 is the same as the chunk hash of the chunk B1 computed by itself, and if so, sign the chunk hash and send it to other respective consensus nodes. Thus, after the PP, P, and C phases in fig. 2 are completed, the consensus on the block hash is completed. After the consensus node finishes the consensus on the block hash, the execution results of the multiple transactions of each consensus node can be guaranteed to be the same, and therefore each node can update and store the execution results according to the multiple transactions.

In step S915, the LVP updates the tree verification data according to the write set of the plurality of transactions.

Specifically, after obtaining the write set of each transaction, the LVP obtains the write set (e.g. wset 1) corresponding to the multiple transactions according to the write set of each transaction, where the write set wset1 includes a key-value pair of an account or a contract account and a contract variable to be used for updating the tree state data according to the write operations of the multiple transactions. After successful consensus on the execution results of multiple transactions, the LVP may update the tree verification data in the LVP based on the hash values of the respective states in wset 1.

In one embodiment, the tree validation data in the LVP includes hash values of the states of the individual accounts and the individual contract variables. Assuming that write set wset1 includes the key-value pair of account a to be written, LVP may find, based on the key of account a in wset1, a storage location of the hash value of the value corresponding to the key in the tree-like verification data, and write the hash value of the state corresponding to the key in wset1 at the storage location.

Assuming that write set wset1 includes a key-value pair of account B to be written and a key-value pair of variable a, the LVP first calculates an updated state hash value according to the updated value of variable a, and updates the state hash value of variable a in the tree verification data. And then, the LVP calculates an updated state hash value according to the updated value of the account B, and updates the state hash value of the account B in the tree-shaped verification data.

In another embodiment, where the LVP stored tree verification data includes a state hash tree and a storage hash tree as shown in fig. 5, the LVP may first update the state hash values in the leaf nodes of the state hash tree and the storage hash tree corresponding to the plurality of states in the write set as described in the previous embodiment. Hash values included in each level of nodes in the state hash value tree and the stored hash value tree may then be updated upward based on the updated leaf nodes until the hash values of the root nodes of the state hash value tree and the stored hash value tree are updated.

In addition, the LVP may store the chunk headers of the generated chunks after consensus on the chunk hashes is completed for SPV verification and for generation of the next chunk.

While the LVP updates the storage, the FVP1 also updates the storage according to the execution results of the multiple transactions, specifically, the FVP1 updates the state tree and the storage tree shown in fig. 3 according to the write set of the multiple transactions, and stores a block B1 corresponding to the multiple transactions, the block including a block header and a block body, and the block body includes data such as the transaction body of the multiple transactions, a receipt, and the like. After the LVP and FVP in the blockchain system are both updated and stored according to the execution results of the multiple transactions, the tree verification data in the LVP still corresponds to the tree state data in the FVP for continued consensus on the next multiple transactions.

The present specification provides a state verification apparatus in a blockchain system, where the blockchain system includes a first node and a second node, the first node stores tree state data, a leaf node of the tree state data includes a state, a node on a path from a root node to the leaf node in the tree state data includes a key of the state, a parent node in the tree state data includes a hash value calculated based on data in its child node, and the apparatus is deployed in the second node. As shown in fig. 10, the apparatus includes: a communication processing unit 1001 for receiving a plurality of first states from the first node; a prefix processing unit 1003 configured to determine a common prefix of the keys of the plurality of first states; a hash calculation unit 1005 configured to calculate a target hash value of an intermediate node corresponding to the common prefix in the tree state data according to the plurality of first states; a verification processing unit 1007 configured to verify the target hash value to verify the plurality of first states.

Based on the same concept as the foregoing method embodiment, an embodiment of the present disclosure provides a node in a blockchain system, where the blockchain system includes a first node and a second node, the first node stores tree-like state data, a leaf node of the tree-like state data includes a state, a node on a path from a root node to the leaf node in the tree-like state data includes a key of the state, and a parent node in the tree-like state data includes a hash value calculated based on data in a child node thereof. As shown in fig. 11, the second node includes: a communication processing unit 1101 for receiving a plurality of first states from the first node; a prefix processing unit 1103 configured to determine a common prefix of the keys of the plurality of first states; a hash calculation unit 1105, configured to calculate a target hash value of an intermediate node corresponding to the common prefix in the tree state data according to the plurality of first states; a verification processing unit 1107 is configured to verify the target hash value to verify the plurality of first states.

Based on the same concept as the foregoing method embodiment, an embodiment of the present specification provides a blockchain system, where the blockchain system includes a first node and a second node, the first node stores tree state data, a leaf node of the tree state data includes a state, a node on a path from a root node to the leaf node in the tree state data includes a key of the state, and a parent node in the tree state data includes a hash value calculated based on data in its child nodes, where: the second node is configured to receive a plurality of first states from the first node; determining a common prefix for keys of the plurality of first states; according to the plurality of first states, calculating a target hash value of an intermediate node corresponding to the public prefix in the tree state data; verifying the target hash value to verify the plurality of first states.

Also provided in embodiments of the present specification is a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the preceding method embodiment, which is performed by the full-volume node, the light node, the LVP node or the FVP node.

The embodiment of the present specification further provides a computing device, which includes a memory and a processor, where the memory stores executable code, and when the processor executes the executable code, the method performed by the full-volume node, the light node, the LVP node or the FVP node in the foregoing method embodiments is implemented.

In the 90's of the 20 th century, improvements to a technology could clearly distinguish between improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements to process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain a corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical blocks. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is an integrated circuit whose Logic functions are determined by a user programming the Device. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be regarded as a hardware component and the means for performing the various functions included therein may also be regarded as structures within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When implemented in an actual device or end product, can be executed sequentially or in parallel according to the methods shown in the embodiments or figures (e.g., parallel processor or multi-thread processing environments, even distributed data processing environments). The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in processes, methods, articles, or apparatus that include the recited elements is not excluded. For example, the use of the terms first, second, etc. are used to denote names, but not to denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, which are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present 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 flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" or the like means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A method for verifying a state in a blockchain system, the blockchain system including a first node and a second node, the first node storing tree-like state data, leaf nodes of the tree-like state data including a state, nodes on a path from a root node to the leaf nodes in the tree-like state data including a key of the state, a parent node in the tree-like state data including a hash value calculated based on data in its child nodes, the method being performed by the second node, the method comprising:

receiving a plurality of first states from the first node;

determining a common prefix for keys of the plurality of first states;

according to the plurality of first states, calculating a target hash value of an intermediate node corresponding to the public prefix in the tree state data;

verifying the target hash value to verify the plurality of first states.

2. The method of claim 1, the verifying the target hash value comprising: acquiring a first hash value of a root node and hash values of a plurality of tree nodes in the tree state data, calculating a second hash value of the root node according to the hash values of the plurality of tree nodes and the target hash value, and verifying 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 therein tree-like verification data corresponding to the tree-like state data, leaf nodes of the tree-like verification data including therein hash values of the states, nodes on paths from a root node to the leaf nodes in the tree-like verification data including keys of the states, parent nodes in the tree-like verification data including hash values calculated based on data in child nodes thereof;

the verifying the target hash value includes: and acquiring a first hash value of a root node and hash values of a plurality of tree nodes in the tree verification data, calculating a second hash value of the root node according to the hash values of the plurality of tree nodes and the target hash value, and verifying whether the second hash value is the same as the first hash value.

4. A method according to claim 2 or 3, the tree node being a sibling of a node on the path of the root node to the intermediate node.

5. The method of claim 1, the validating the target hash value comprising: determining whether the current hash value of the intermediate node is the same as the target hash value.

6. The method of claim 1, the key of the first state characterizing a user account registered in the blockchain system; alternatively, the key of the first state characterizes a variable belonging to a contract account registered in the blockchain system.

7. The method of claim 1, wherein in the case that the child node of the parent node is a leaf node, the hash value included in the parent node is calculated based on the hash value of the state included in the child node of the parent node and a key component of the state included in the child node of the parent node.

8. The method of claim 1, the receiving a plurality of first states from the first node, comprising: receiving a consensus offer from the first node, the consensus offer comprising a read set of a plurality of transactions to be performed, the read set comprising the plurality of first states read by the first node from the tree state data according to the plurality of transactions;

the method further comprises the following steps: consensus is made on the consensus proposal with the first node, other consensus nodes in the blockchain system, according to the verification results of the plurality of first states.

9. The method of claim 8, further comprising an ordered sequence of the plurality of transactions in the consensus proposal, the method further comprising: in the event of agreement on the consensus proposal, performing the plurality of transactions according to the rank order and the read set to obtain a write set, the write set used to update a number of second states.

10. The method according to claim 9, wherein the second node stores therein tree verification data corresponding to the tree state data, leaf nodes of the tree verification data include hash values of the state, nodes in a path from a root node to a leaf node in the tree verification data include keys of the state, and a parent node in the tree verification data includes hash values calculated based on data in child nodes thereof;

the method further comprises the following steps: and updating the tree verification data according to the write set.

11. The method of claim 10, further comprising: and generating a block head according to the write set and the updated tree verification data, wherein the block head comprises the hash value of the root node in the updated tree verification data.

12. A state verification apparatus in a blockchain system, the blockchain system including a first node and a second node, the first node storing tree state data, leaf nodes of the tree state data including states, nodes on a path from a root node to a leaf node in the tree state data including keys of the states, parent nodes in the tree state data including hash values calculated based on data in child nodes thereof, the apparatus being disposed in the second node, comprising:

a communication processing unit for receiving a plurality of first states from the first node;

a prefix processing unit for determining a common prefix of the keys of the plurality of first states;

the hash calculation unit is used for calculating a target hash value of an intermediate node corresponding to the public prefix in the tree-shaped state data according to the plurality of first states;

and the verification processing unit is used for verifying the target hash value so as to verify the plurality of first states.

13. A node in a blockchain system, the blockchain system including a first node and a second node, the first node storing tree state data, leaf nodes of the tree state data including a state, nodes on a path from a root node to a leaf node in the tree state data including a key of the state, a parent node in the tree state data including a hash value calculated based on data in its child nodes, the second node comprising:

a hash calculation unit, configured to calculate a target hash value of an intermediate node corresponding to the common prefix in the tree state data according to the plurality of first states;

14. A block chain system comprises a first node and a second node, wherein the first node stores tree state data, leaf nodes of the tree state data comprise states, nodes on paths from root nodes to the leaf nodes in the tree state data comprise keys of the states, and father nodes in the tree state data comprise hash values calculated based on data in child nodes of the father nodes; wherein: the second node is configured to receive a plurality of first states from the first node; determining a common prefix of keys for the plurality of first states; according to the plurality of first states, calculating a target hash value of an intermediate node corresponding to the public prefix in the tree state data; verifying the target hash value to verify the plurality of first states.

15. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-11.