CN110602148A - Method and device for generating state tree of block and verifying data on chain - Google Patents

Abstract

The invention discloses a method and device for generating a state tree of a block and verifying data on the chain, wherein the method for generating a state tree of a block includes: for any block in the block chain, determine the block's The first account and the first account data; the first account is the account whose account data changes after the execution of each transaction in the block, and the first account data is the account data after the change in the first account after each transaction is executed; The state tree of the block formed by the first account and the first account data of each first account, and the root hash of the state tree is stored in the block header of the block, wherein the state tree is stored in the form of key-value pairs. This technical solution is used to simplify the account data used to construct the state tree on the blockchain, thereby shortening the length of the branch path used for verification, and improving the efficiency of the existence verification of the account data.

Description

A method and device for generating a block state tree and verifying data on the chain

technical field

The embodiment of the present invention relates to the field of financial technology (Fintech), and in particular to a method and device for generating a state tree of a block and verifying data on the chain.

Background technique

With the development of computer technology, more and more technologies (such as blockchain (BlockChain), cloud computing or big data) are applied in the financial field. The traditional financial industry is gradually transforming into financial technology, and blockchain technology is not Exceptions, but due to the security and real-time requirements of the financial and payment industries, there are also higher requirements for blockchain technology.

In the state tree and storage tree of Ethereum, if the existence of the contract state in the storage tree is verified, it is necessary to first determine the branch path of the contract state in the storage tree, and verify whether the contract state exists in the corresponding storage tree , then determine the branch path of the account state corresponding to the storage tree in the state tree, and then verify whether the account state exists in the corresponding state tree.

However, as the data on the blockchain continues to grow, blockchain nodes need to obtain longer branch paths for verification, and it takes longer to obtain the branch paths and to verify the existence of them.

Contents of the invention

The embodiment of the present invention provides a method and device for generating a state tree of a block and verifying data on the chain, which is used to simplify the account data used to build the state tree on the block chain, thereby shortening the length of the branch path used for verification , improve the efficiency of the existence verification of account data.

In the first aspect, a method for generating a state tree of a block provided by an embodiment of the present invention includes:

For any block in the block chain, determine the first account and first account data of the block; the first account is the account whose account data changes after each transaction in the block is executed, and the The first account data is the account data changed in the first account after the execution of each transaction;

Constructing the state tree of the block composed of each first account and the first account data of each first account, and storing the root hash of the state tree in the block header of the block, wherein , the state tree is stored in the form of key-value pairs.

In the above technical solution, when constructing the state tree, it is only generated based on the modified or newly added account data during the execution of the current block transaction, and will not be generated based on the unchanged account data corresponding to the original block. This method can greatly reduce the state tree level by streamlining the amount of data.

Optionally, the construction of the state tree of the block composed of each first account and the first account data of each first account includes:

For any first account data of any first account, the identifier of the first account, the identifier of the first account data, and the block height of the block are used as key values, and the first account data is used as The value of the leaf node is used to construct the state tree of the block based on the MPT mode.

In the above technical solution, the key value is directly stored persistently instead of the hash of the key value. In this way, the account data under the same account can be guaranteed to have the same compressed prefix, that is, the account ID or Account address, effectively using the advantages of Patricia Tree, compresses the level of the state tree to the minimum, reduces storage space, and speeds up the construction and verification efficiency of branch paths.

Optionally, the first account data includes block height records, account status and/or contract status that have changed in the first account after the execution of each transaction; the block height records are used to record the first The block height of the block where the account status and/or contract status in the account have changed.

The account state originally belonged to the value in the leaf node of the state tree, and the contract state originally belonged to the value in the leaf node of the storage tree. In the above technical solution, the value in the leaf node of the state tree is moved down to the leaf node of the storage tree The value level in , the state tree and the storage tree are merged into one tree, thereby flattening the hierarchical structure of account data, and speeding up the construction and verification efficiency of branch paths. Further, a key-value key-value pair is added when storage is placed on the disk, wherein the key includes the account ID and the account data ID, the account data ID at this time corresponds to the block height record, and the value is the block height record, the block The high record is used to record the block height of the block where the account data in the account corresponding to the account identifier has changed in the past. In this way, when verifying an account data, first determine the block of the state tree where the account data is located. Then, according to the block, a branch path for verification is determined.

Optionally, the method also includes:

Receive a data acquisition request from the client; the data acquisition request includes the identifier of the second account, the identifier of the second account data, and the first block height;

According to the identification of the second account and the identification of the first high record of the second account, determine the first high record; according to the identification of the second account, the identification of the second account data, The first block is high, determining the second account data;

Obtaining a first branch path for verifying the first high record from the state tree of the first block; the first block is a block corresponding to the highest block height in the first high record;

Obtain the second branch path used to verify the second account data from the state tree of the second block; the second block is the block corresponding to the second block height; the second block height is the the highest block height of all block heights lower than the first block height in the first block height record;

sending the first high record, the first branch path, the second account data, and the second branch path to the client, so that the client can check the first high record and the second account data for verification.

In the above technical solution, the blockchain node returns two sets of data to the client according to the client’s data acquisition request, the first set is the first high record and the first branch path used to verify the first high record, the second The groups are the second account data and the second branch path for verifying the second account data, so that the client can respectively verify the first high record and the second account data according to the two sets of data. Among them, the first branch path and the second branch path are shorter than the branch path in the prior art, the time required for the blockchain node to obtain the branch path is shorter, and the time required for client verification is also shorter , so as to improve the efficiency of client verification data.

In the second aspect, an on-chain data verification method provided by an embodiment of the present invention includes:

Send a data acquisition request to the block chain node; the data acquisition request includes the identification of the second account, the identification of the second account data and the first block height;

Receive the first high record, the first branch path, the second account data, and the second branch path returned by the blockchain node; the first high record and the second account data are the blockchain The node is determined according to the identity of the second account, the identity of the second account data, and the first block; the first branch path is determined by the blockchain node for verifying the first A branch path recorded in the block height; the second branch path is a branch path determined by the block chain node for verifying the second account data;

Verify whether the first high record is correct according to the first branch path, the root hash of the state tree in the block header of the first block stored locally; the block header of the first block stored locally is obtained from Acquired on the blockchain node, the first block is the block corresponding to the highest block height in the first block height record on the blockchain;

After determining that the first block high record is correct, verify whether the second account data is correct according to the second branch path and the root hash of the state tree in the block header of the second block stored locally ; The block header of the second block stored locally is obtained from the block chain node, and the second block is the block corresponding to the second block height on the block chain; the first The second block height is the highest block height of all block heights lower than the first block height in the first block height record.

In the above technical solution, the client sends a data acquisition request to the blockchain node, and the blockchain node returns two sets of data to the client according to the data acquisition request from the client. The first branch path of a piece of high record, the second group is the second account data and the second branch path used to verify the second account data, so that the client can separately record the first piece of high record and the second branch path according to the two sets of data Two account data are verified. Among them, the first branch path and the second branch path are shorter than the branch path in the prior art, the time required for the blockchain node to obtain the branch path is shorter, and the time required for client verification is also shorter , so as to improve the efficiency of client verification data.

Optionally, verifying whether the first block high record is correct according to the first branch path and the root hash of the state tree in the block header of the locally stored first block includes:

Determine a first root hash according to the first block high record and the data of leaf nodes and branch nodes in the first branch path;

If the first root hash is equal to the root hash of the state tree in the block header of the locally stored first block, it is determined that the first block high record is correct.

In the above technical solution, the client realizes the verification of the first high record according to the root hash of the state tree and the first branch path in the block header of the first block stored locally.

Optionally, the verifying whether the second account data is correct according to the second branch path and the root hash of the state tree in the block header of the locally stored second block includes:

determining a second root hash according to the second account data and the data of leaf nodes and branch nodes in the second branch path;

If the second root hash is equal to the root hash of the state tree in the block header of the locally stored second block, it is determined that the second account data is correct.

In the above technical solution, the client realizes the verification of the second account data according to the root hash of the state tree in the block header of the second block stored locally and the second branch path.

Optionally, the method also includes:

Send a query request to the blockchain node;

receiving the query result returned by the block chain node; the query result is the current block height of the block chain returned by the block chain node after receiving the query request;

Judging whether the highest block height of the locally stored block header is less than the current block height, if so, sending a block header acquisition request to the blockchain node; the block header acquisition request includes the block to be acquired high;

Receive the block header returned by the blockchain node, and store the received block header locally.

In the above technical solution, the client regularly goes to the blockchain node to obtain the block header of the latest block, which can ensure that when the account data needs to be verified, the block header information of the block used for verification is locally stored.

Optionally, before storing the received block header locally, it also includes:

Obtain N pieces of signature information in the received block header;

Verify the N signature information according to the consensus node list; the consensus node list is the consensus node determined according to the block header of the genesis block of the blockchain to the previous block header of the received block header list of components;

If the N pieces of signature information pass the verification, it is determined that the received block header is correct.

Optionally, the verification of the N signature information according to the list of consensus nodes includes:

Determine the N consensus nodes corresponding to the N signature information;

judging M consensus nodes in the list of consensus nodes among the N consensus nodes;

If M meets the preset condition, it is determined that the N pieces of signature information pass the verification.

Through the above method, the client will verify the block header information of the genesis block from the genesis block, and each time a block header is added, it will combine the consensus nodes in the current consensus node list to verify the block header information of the currently added block. Verification to ensure that the block header information of the block saved locally is correct, thereby ensuring the correctness of the root hash of the state tree in the block header used to verify the account data, thereby realizing the verification of the account data.

In a third aspect, an apparatus for generating a state tree of a block provided by an embodiment of the present invention includes:

The determination unit is configured to determine the first account and the first account data of the block for any block in the block chain; the first account is that the account data in the block changes after the execution of each transaction account, the first account data is the account data changed in the first account after the execution of each transaction;

A construction unit, configured to construct the state tree of the block composed of each first account and the first account data of each first account, and store the root hash of the state tree in the block In the block header, the state tree is stored in the form of key-value pairs.

Optionally, the construction unit is specifically used for:

For any first account data of any first account, the identifier of the first account, the identifier of the first account data, and the block height of the block are used as key values, and the first account data is used as The value of the leaf node is used to construct the state tree of the block based on the MPT mode.

Optionally, the first account data includes block height records, account status and/or contract status that have changed in the first account after the execution of each transaction; the block height records are used to record the first The block height of the block where the account status and/or contract status in the account have changed.

Optionally, the device further includes a processing unit;

The processing unit is used for:

Receive a data acquisition request from the client; the data acquisition request includes the identifier of the second account, the identifier of the second account data, and the first block height;

According to the identification of the second account and the identification of the first high record of the second account, determine the first high record; according to the identification of the second account, the identification of the second account data, The first block is high, determining the second account data;

Obtaining a first branch path for verifying the first high record from the state tree of the first block; the first block is a block corresponding to the highest block height in the first high record;

Obtain the second branch path used to verify the second account data from the state tree of the second block; the second block is the block corresponding to the second block height; the second block height is the the highest block height of all block heights lower than the first block height in the first block height record;

sending the first high record, the first branch path, the second account data, and the second branch path to the client, so that the client can check the first high record and the second account data for verification.

In the fourth aspect, an on-chain data verification device provided by an embodiment of the present invention includes:

A transceiver unit, configured to send a data acquisition request to the block chain node; the data acquisition request includes the identification of the second account, the identification of the second account data and the first block height;

The transceiver unit is also used to receive the first high record, the first branch path, the second account data, and the second branch path returned by the block chain node; the first high record and the second The account data is determined by the block chain node according to the identification of the second account, the identification of the second account data and the first block height; the first branch path is determined by the block chain node The branch path used to verify the first block high record; the second branch path is the branch path determined by the block chain node for verifying the second account data;

The verification unit is used to verify whether the first block high record is correct according to the first branch path and the root hash of the state tree in the block header of the locally stored first block; the locally stored first block The block header is obtained from the blockchain node, and the first block is the block corresponding to the highest block height in the first block height record on the blockchain;

The verification unit is further configured to verify that the first block high record is correct according to the second branch path and the root hash of the state tree in the block header of the second block stored locally. Whether the above-mentioned second account data is correct; the block header of the second block stored locally is obtained from the block chain node, and the second block is the second high-level block on the block chain Corresponding block; the second block height is the highest block height of all block heights lower than the first block height in the first block height record.

Optionally, the verification unit is specifically used for:

Determine a first root hash according to the first block high record and the data of leaf nodes and branch nodes in the first branch path;

If the first root hash is equal to the root hash of the state tree in the block header of the locally stored first block, it is determined that the first block high record is correct.

Optionally, the verification unit is specifically used for:

determining a second root hash according to the second account data and the data of leaf nodes and branch nodes in the second branch path;

If the second root hash is equal to the root hash of the state tree in the block header of the locally stored second block, it is determined that the second account data is correct.

Optionally, the device further includes a synchronization unit;

The synchronization unit is used for:

Send a query request to the blockchain node;

receiving the query result returned by the block chain node; the query result is the current block height of the block chain returned by the block chain node after receiving the query request;

Judging whether the highest block height of the locally stored block header is less than the current block height, if so, sending a block header acquisition request to the blockchain node; the block header acquisition request includes the block to be acquired high;

Receive the block header returned by the blockchain node, and store the received block header locally.

Optionally, before the synchronization unit stores the received block header locally, it is also used for:

Obtain N pieces of signature information in the received block header;

Verify the N signature information according to the consensus node list; the consensus node list is the consensus node determined according to the block header of the genesis block of the blockchain to the previous block header of the received block header list of components;

If the N pieces of signature information pass the verification, it is determined that the received block header is correct.

Optionally, the synchronization unit is specifically used for:

Determine the N consensus nodes corresponding to the N signature information;

judging M consensus nodes in the list of consensus nodes among the N consensus nodes;

If M meets the preset condition, it is determined that the N pieces of signature information pass the verification.

In a fifth aspect, an embodiment of the present invention further provides a computing device, including:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute the method for generating the state tree of the above block according to the obtained program.

In the sixth aspect, the embodiment of the present invention also provides a computer-readable non-volatile storage medium, including computer-readable instructions, and when the computer reads and executes the computer-readable instructions, the computer executes the above-mentioned blocks. The generation method of the state tree.

In the seventh aspect, the embodiment of the present invention also provides a computing device, including:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute the above-mentioned on-chain data verification method according to the obtained program.

In the eighth aspect, the embodiment of the present invention also provides a computer-readable non-volatile storage medium, including computer-readable instructions, when the computer reads and executes the computer-readable instructions, the computer executes the above-mentioned on-chain data method of verification.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For Those of ordinary skill in the art can also obtain other drawings based on these drawings without making creative efforts.

Figure 1 is a schematic diagram of a Merkle Tree;

Fig. 2 is a schematic diagram of state tree and storage tree in Ethereum in the prior art;

FIG. 3 is a schematic diagram of a state tree and a storage tree provided by an embodiment of the present invention;

FIG. 4 is a schematic diagram of another state tree and storage tree provided by an embodiment of the present invention;

FIG. 5 is a schematic diagram of the flow of a method for generating a state tree of a block provided by an embodiment of the present invention;

FIG. 6 is a system architecture applicable to on-chain data verification provided by an embodiment of the present invention;

FIG. 7 is a schematic diagram of the flow of a method for on-chain data verification provided by an embodiment of the present invention;

FIG. 8 is a schematic diagram of a process for a client to obtain a block header provided by an embodiment of the present invention;

FIG. 9 is another system architecture applicable to on-chain data verification provided by the embodiment of the present invention;

FIG. 10 is a schematic structural diagram of an apparatus for generating a state tree of a block provided by an embodiment of the present invention;

Fig. 11 is a schematic structural diagram of an on-chain data verification device provided by an embodiment of the present invention.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present invention, rather than all of them. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

In order to better explain the present invention, the professional terms involved in the present invention are first explained as follows:

1. Merkle Tree

Merkle Tree is a binary tree composed of leaf nodes, intermediate nodes and root nodes. Among them, what the leaf node records is the hash value of the data (such as the account data mentioned in the embodiment of the present invention), and what the intermediate node records is the hash value calculated after the composition of its two child nodes (the child nodes may be leaf nodes or other intermediate nodes). Hash value, the calculation method of the value recorded by the root node is similar to the calculation method of the value recorded by the intermediate node.

Merkle Tree can be shown in Figure 1. The bottom-up construction process of Merkle Tree is as follows: D1-D7 is the basic data (used to build leaf nodes), H1-H7 records the hash value of the corresponding data (H1-H7 is is a leaf node). Going up one level, H9 is an intermediate node, which records the value obtained by hashing the nodes H2 and H1 as inputs. The above calculation process is repeated cyclically, and finally the hash value of the last node is calculated, which is the root node, and the recorded hash value is the hash value of the entire Merkle Tree.

2. Merkle proof

From the construction process of Merkle Tree, we can find that the data recorded by any leaf node is modified, and the hash value of the leaf node will change accordingly, which will eventually affect the hash value of the root node. Therefore, the hash value of the root node can be used as the unique summary of a set of data. At the same time, based on the Merkle Tree, we can verify the existence of the data by providing the Merkle branch path of a certain data. This proof is the Merkle proof.

As shown in Figure 1, if the verifier wants to verify whether D2 exists in the Merkle Tree, the blockchain node can provide the Merkle branch path of D1-H10-H14, and the verifier can calculate the hash values of D1 and D2 according to the branch path , then calculate the hash value of H1 and H2, then calculate the hash value with H10, and finally calculate the hash value with H14, if the obtained hash value is consistent with the hash value recorded by the root node, it means that D2 exists in the Merkle Tree middle.

2. Trie Tree (prefix tree)

Trie Tree is a search tree, also known as Digital Tree (dictionary tree). Unlike a binary tree, the key value of a Trie Tree is not stored by a node in the tree, but depends on its position in the tree (that is, the path from the root node to a specific node). All descendants of a node have the same prefix, which is the string corresponding to this node (the root node corresponds to an empty string). Only leaf nodes have corresponding storage values.

3. Patricia Tree (compressed prefix tree)

Patricia Tree is a more space-saving prefix tree. If a node has no sibling nodes, it is merged with its parent node.

4. The state tree and storage tree of Ethereum

As shown in Figure 2, Ethereum includes a state tree and a storage tree. The state tree can be a state MPT (which can be considered as MPT=Merkle Tree+Patricia Tree) or a state Merkle Tree, and the storage tree can be a storage MPT or a storage MerkleTree.

The state tree is composed of Ethereum accounts, and the hash of the root node of the state tree is recorded in the state root field of each block header. The storage tree is a structure for storing data associated with an account. This item is only available for contract accounts. All smart contract data is stored in the storage tree in the form of a 32-byte map. The hash value of the root node of the storage tree is recorded in the storage root field of the account.

The state MPT or the leaf node of the storage MPT records the value of the key-value data item, and its key code is composed of the path from the root node to the leaf node of the MPT.

In the state tree and storage tree of Ethereum, the existence of account data (including account status and contract status) can still be verified based on Merkle proofs. Taking Figure 2 as an example, to verify that one of the contract statuses is 27 in block 60 , then it is necessary to determine the branch path used to verify 27 in the storage tree, and verify whether 27 constitutes the storage tree of Account 175 according to the branch path, and also need to determine the branch used to verify Account 175 in the state tree path, and verify whether Account 175 constitutes the state tree of block 59 according to the branch path, that is, two Merkle proofs are required.

However, with the continuous growth of blockchain data, more additional space needs to be allocated on the chain to store tree construction relationships. In addition, the increase in data on the chain also makes it more and more time-consuming to provide branch paths and external Merkle proofs.

In order to solve the above problems, the embodiment of the present invention provides a new construction relationship between the state tree and the storage tree, wherein the state tree and the storage tree are only used to store the account data modified during the execution of the current block transaction, such as the new Added account data or modified account data. The embodiment of the present invention provides a state tree and a storage tree as shown in FIG. 3, which are explained as follows compared with FIG. 2:

In the state tree and storage tree shown in Figure 2, the contract state of Account 175 is modified during the execution of block 60, and 27 becomes 45. Then, the parent is determined based on the original contract state 26 of Account 175 and the modified contract state 45. The hash value in the node, and store the root node hash value of the constructed storage tree in the storageroot field of Account 175 in block 60; based on the account status of the original Account 174 and the account of the modified Account 175 The state determines the hash value in the parent node, and stores the hash value of the root node of the constructed state tree in the state root field of the block 60 .

As shown in the state tree and storage tree of Figure 3, the contract state of Account 175 is modified during the execution of block 60, and 27 becomes 45, then the hash in the parent node is only determined based on the modified contract state 45 of the current Account 175 value, and store the hash value of the root node of the constructed storage tree in the storage root field of Account 175 of block 60; determine the hash value in the parent node based on the account status of the modified Account 175, and store The hash value of the root node of the constructed state tree is stored in the state root field of block 60 .

It can be seen from the above that the state tree and storage tree in the embodiment of the present invention are only generated based on the modified or newly added account data during the execution of the current block transaction, and will not be based on the unchanged account data corresponding to the original block. Account data generation, this method can greatly reduce the level of the state tree and storage tree by streamlining the amount of data. For example, the existing technology uses 10,000 accounts to construct the state tree corresponding to block 60, but in the embodiment of the present invention, if only the account data of 1,000 accounts change after all transactions in block 60 are executed, the present invention implements For example, only 1,000 accounts need to be used to build the state tree corresponding to block 60, and the 1,000 accounts build their own storage trees based on their changed contract data, the data volume of the embodiment of the present invention is reduced to 1/10 of the original data volume , can greatly reduce the level of state tree and storage tree.

In addition, in the state tree and storage tree of Ethereum, two Merkle proofs are used, first to prove that the contract state is in the storage tree, and then to prove that the account state is in the state tree. The embodiment of the present invention can combine the state tree and the storage tree into one A tree, the value in the leaf node of the state tree is moved down to the same level as the value in the leaf node of the storage tree, thereby flattening the hierarchical structure of the account data. The embodiment of the present invention provides a new state tree as shown in FIG. 4 . The block corresponds to a state tree. The leaf nodes of the state tree include the account state and the contract state. In this way, only one Merkle proof is needed to verify the existence of the account data. For example, it is necessary to verify that the contract state 27 is in block 60 existence, it is necessary to obtain the branch path used to verify the 27 in the state tree, and verify whether 27 constitutes the state tree of the block 60 according to the branch path. Compared with the prior art, the level of the state tree becomes smaller, and speeds up the construction and verification efficiency of branch paths.

In the embodiment of the present invention, the key used for disk storage can be defined as "account identifier + account data identifier + write/modify the block height where the key-value is located", and the value value is the account data corresponding to the account data identifier. In addition , in the above key, the account ID can be understood as the account address; the account data ID can be understood as the serial number of the data that needs to be stored persistently, or the ID of the data that needs to be stored persistently. For example, the account data is the account balance in the account status, and the account data The identifier can be "balance". For example, if the account data is a value in the contract state, then the account data identifier can be a set serial number. For example, the identifier of the contract state 27 in Figure 4 is 2. The leaf node in the embodiment of the present invention stores the hash value of the account data.

Constructing a state tree based on key-value may be constructing a state MPT. The key value indicates the path from the root node to the leaf node in the MPT. As shown in FIG. 4 , key(0x234_balance_60)=100.

Considering that the state tree constructed by the embodiment of the present invention is only constructed based on the change account data of the change account, there is a problem in this construction method, that is, it cannot prove the correctness of a non-existent data, which is equivalent to being unable to prove that a data that does not constitute a certain Whether the account data of the state tree of a block exists in the state tree of the block. For example, if the block height of the current blockchain is 100, and the account data of an account has only changed at block height 20, the account data of the account can only be verified based on the state tree of the block height 20. The correctness of the account data of the account cannot be verified based on the state tree of any block after block height 20.

In order to solve the above problems, the embodiment of the present invention will add another set of key-value key-value pairs on the basis of storing the above-mentioned key-value key-value pairs, wherein the key includes the account identifier and the account data identifier, at this time The account data identifier corresponds to the block height record, and the value value is the block height record. The block height record is used to record the block height of the block where the account data in the account corresponding to the account identifier has been changed.

For example, as shown in Figure 4, the current block height of the blockchain is 60, 0x234_1 is the key for persistent storage, 1 is the identifier of the block height record, and 12-45-50 is the recorded block height record, which is understandable Write at block height 12 for account 0x234, and modify at block height 45 and 50. Four key-value key-value pairs are stored on the current blockchain as shown in Table 1. Among them, the first key-value key-value pair indicates the block height record of the account 0x234, and the second to fourth key The -value key-value pair indicates the balance value when the account 0x234 is written or modified at the corresponding block height.

Table 1

key value 0x234_1 12-45-50 0x234_balance_12 100 0x234_balance_45 300 0x234_balance_50 200

By storing the key-value key-value pair, the block height of the block where the account data corresponding to the account has been changed can be quickly determined, and further determine which block's state tree should be used to verify the correctness of the data to be verified , the specific implementation manner can be described in detail below.

Based on the above description, FIG. 5 exemplarily shows the flow of a method for generating a state tree of a block provided by an embodiment of the present invention. The flow can be executed by a device for generating a state tree of a block, and the device can be located at Among the blockchain nodes, it may be the blockchain node.

In step 501, the blockchain node determines the first account and the first account data of any block in the blockchain.

Wherein, the first account is an account whose account data changes after each transaction is executed in the block, and the first account data is the account data after each transaction is changed in the first account after each transaction is executed.

In the specific implementation, the blockchain node determines the accounts involved in each transaction based on the transactions in the current block, and judges whether the account data in the accounts involved in each transaction has changed, and the account whose account data has changed is the first For an account, the changed account data is the first account data, and there may be one first account data or multiple first account data in a first account.

Optionally, the first account data that may exist in the first account may include block height records, account statuses and/or contract statuses that have changed in the first account after execution of each transaction. As an example in Table 1, the first account data that may be included in the first account 0x234 of block 50 has a block height record of 12-45-50 and a value of 200 for balance.

For another example, each transaction in the current block involves a total of 100 accounts, and there are 98 accounts whose account data has changed. At this time, there are 98 first accounts corresponding to the current block, and each of the 98 accounts All accounts correspond to at least one changed account data. Here, one transaction or multiple transactions in the current block may cause the state data of an account to remain unchanged after the execution of the current block is completed.

In step 502, the block chain node constructs a state tree of a block composed of each first account and the first account data of each first account, and stores the root hash of the state tree in the block header of the block.

Among them, the state tree is stored in the form of key-value pairs.

During the construction process, for any first account data of any first account, the identifier of the first account, the identifier of the first account data and the block height of the block can be used as the key value, and the first account data can be used as the leaf node The value value of the block is based on the MPT mode to build the state tree of the block.

In the embodiment of the present invention, the key value is directly stored persistently instead of the hash of the key value. In this way, the account data under the same account can be guaranteed to have the same compressed prefix, that is, the account ID Or account address, as shown in Figure 4, all account data keys of 0x234 have the same prefix, that is, 0x234, so at least all account data keys of 0x234 can be compressed with the common prefix 0x234. However, in the prior art, after the hash calculation is performed on all account data keys of 0x234, there are fewer common prefixes, and the state tree is formed with a deeper level. Therefore, the embodiment of the present invention can effectively utilize the advantages of the Patricia Tree, compress the level of the state tree to the minimum, reduce the storage space, and speed up the construction and verification efficiency of the branch path.

Based on the above construction scheme of the state tree in the blockchain node, the embodiment of the present invention also provides a method for data verification on the chain, which is applicable to the system architecture shown in Figure 6, and the system architecture can include the client and the district Blockchain nodes. Among them, the client can be understood as the data user, and the blockchain node can be understood as the data provider; the blockchain node is any blockchain node in the blockchain system that the client can access.

Figure 7 is the flow of the method for on-chain data verification shown in the embodiment of the present invention, the flow specifically includes:

Step 701, the client sends a data acquisition request to the blockchain node.

The data acquisition request includes the identifier of the second account, the identifier of the second account data, and the first block, and the data acquisition request is used to instruct to acquire the value of the second account data of the second account on the first block.

Step 702, the block chain node determines the first high record according to the identification of the second account and the identification of the first high record of the second account.

After the blockchain node receives the data acquisition request sent by the client, it will determine the first high record according to the identification of the second account and the identification of the first high record of the second account, as shown in Table 1, the second account's The ID is 0x234, and the ID of the first high record of the second account is 1, then the composed key is 0x234_1. According to the key-value key-value pair stored in the persistent storage, the value corresponding to the key 0x234_1 is determined to be 12-45-50 .

Step 703, the blockchain node determines the second account data according to the identifier of the second account, the identifier of the second account data, and the first block height.

The blockchain node determines the second account data according to the identity of the second account, the identity of the second account data, and the height of the first block. As shown in Table 1, if the height of the first block is 48, it is determined that the identity of the second account is 0x234, the identifier of the second account data is balance, and the composed key is 0x234_balance_45. According to the key-value key-value pair in the persistent storage, the value corresponding to the key 0x234_balance_45 is determined to be 300.

Step 704, the block chain node obtains the first branch path for verifying the first high record from the state tree of the first block.

Step 705, the block chain node obtains the second branch path for verifying the second account data from the state tree of the second block.

Since the construction of a state tree of a certain block in the embodiment of the invention can only be used to verify the existence of the account data corresponding to the state tree of the block, so to verify the existence of the second account data, it is necessary to first determine the existence of the second account data. The second block corresponding to the state tree where the data is located, and then according to the state tree of the second block, determine the second branch path for verifying the second account data.

When determining the second block corresponding to the state tree where the second account data is located, it is necessary to first determine the block height record recorded when the account data of the second account has been modified, that is, it is necessary to determine the first block height record. After determining the first block height record, the block corresponding to the highest block height of all block heights lower than the first block height in the first block height record can be used as the second block, and the second block can be used After recording the latest modified account data of the second account before the first block, and then according to the state tree of the second block, determine the second branch path for verifying the second account data.

In addition, in order to ensure the correctness of the first high record, it is also necessary to determine the first block corresponding to the state tree where the first high record is located, and then according to the state tree of the first block, determine the The first branch path recorded. Specifically, the first block may be a block corresponding to the highest block height in the first block height record.

As shown in Table 1, if the first block height is 48, the first branch path is determined by the state tree corresponding to the first block with a block height of 50, and the second branch path is corresponding to the second block with a block height of 45 The state tree is determined.

Step 706, the blockchain node sends the first high record, the first branch path, the second account data, and the second branch path to the client.

Step 707, the client verifies whether the first block high record is correct according to the first branch path and the root hash of the state tree in the block header of the first block stored locally;

The client locally stores the block headers of each block on the block chain, which is used to calculate the block header according to the The information in the corresponding block header is used to verify the first high record and the second account data.

In one way of implementation, the client can regularly go to the blockchain node to obtain the block header of the latest block. In another way, the client can go to the blockchain node when it needs to verify the received data. obtained on the node. The former can be specifically shown in Figure 8, which is completed by the interaction between the client and the blockchain node.

Step 801, the client sends a query request to the blockchain node;

Step 802, the blockchain node sends the current block height of the blockchain to the client;

Step 803, the client determines that the highest block height of the locally stored block header is smaller than the current block height;

Step 804, the client sends a block header acquisition request to the blockchain node;

Step 805, the blockchain node determines the block header to be acquired by the client;

Step 806, the blockchain node sends the block header to be acquired to the client;

Step 807, the client receives the block header returned by the blockchain node, and stores the received block header locally.

From step 801 to step 807, the client sends a query request to the blockchain node, and the blockchain node will feed back the current block height on the current blockchain to the client after receiving the query request, and the client receives the query request, which includes The query result of the current block height is used to judge whether the block header needs to be synchronized to the blockchain node according to the query result. Specifically, the client judges whether the highest block height of the locally stored block header is smaller than the current block height on the blockchain. If so, determine to synchronize the block header with the blockchain node, and send a block header acquisition request to the blockchain node, wherein the block header acquisition request includes the block height of the block header to be acquired.

For example, if the current block height of the block chain of the blockchain node is 100, and the highest block height of the block header stored locally by the client is 98, then the client determines that it needs to obtain the 99th and 100th blocks from the blockchain node. The client sends a block header acquisition request to the blockchain node, wherein the block header acquisition request includes the block heights of the block header to be acquired as 99 and 100.

In the above implementation method, the client regularly goes to the blockchain node to obtain the block header of the latest block, which can ensure that when the account data needs to be verified, the block header information of the block used for verification is locally stored.

It can be seen from the above that the client can determine whether the first block high record is correct according to the first branch path and the root hash of the state tree in the block header of the first block stored locally. Here, the first block stored locally by the client is also the block corresponding to the highest block height in the first block height record obtained by the client from the blockchain node.

In the specific verification process, the client determines the first root hash according to the first high record and the data of the leaf nodes and branch nodes in the first branch path. If the client determines that the first root hash is equal to the first area stored locally The root hash of the state tree in the block header of the block determines that the first block high record is correct.

Step 708: After determining that the first high record is correct, the client verifies whether the second account data is correct according to the second branch path and the root hash of the state tree in the block header of the second block stored locally.

The client first judges whether the first high record is correct. If it is correct, it can further verify the correctness of the second account data according to the second branch path and the root hash of the state tree in the block header of the second block stored locally. In particular, the block header of the second block stored locally by the client is obtained from the blockchain node, the second block is the block corresponding to the second block height on the blockchain, and the second block height is the The highest block height of all block heights lower than the first block height in the block height record.

In the specific verification process, the client can determine the second root hash according to the second account data and the data of the leaf nodes and branch nodes in the second branch path. If the client determines that the second root hash is equal to the second area stored locally The root hash of the state tree in the block header of the block determines that the second account data is correct.

It should be noted that although it is provided in the embodiment of the present invention that the client first obtains the first high record and the second account data, and verifies the first high record based on the first block and verifies the first high record based on the second block. The second account data is verified, but in the embodiment of the present invention, the client can also obtain the first high record first, and verify the first high record based on the first block, and then verify the first high record After passing, the second account data is further obtained, and the second account data is verified based on the second block.

It should be noted that since the client verifies the first block high record based on the root hash of the state tree of the block header of the first block stored locally, and the state tree of the block header of the second block stored locally The root hash of the second account is verified, so the client first needs to confirm that the locally stored block header information is correct.

In order to prove the correctness of the information in the block header, in the specific implementation, the signature list of the nodes on the chain to the block header is added in the block header. After the client obtains the block header, it will verify the block header according to the signature list in the block header. The correctness of the block header, specifically, before the client stores the received block header locally, obtain the N signature information in the received block header, and verify the N signature information according to the local consensus node list, if If the N signature information is verified, it is determined that the received block header is correct. Here, the list of consensus nodes is a list of consensus nodes determined by the client based on the block header in the genesis block of the blockchain to the previous block header of the received block header, such as the current block header obtained by the client is the block header of the 100th block, the client needs to verify the signature information of the current block header according to the list of consensus nodes determined by the block headers of the 0th block (genesis block) to the 99th block .

It is explained that the consensus nodes in the consensus node list are determined in the genesis block of the blockchain, and may change in subsequent block transactions. For example, the consensus nodes in the consensus node list determined in the genesis block include A, B, C, D; From the 0th block to the 49th block, the consensus node in the consensus node list in the block header has not changed; at the 50th block, the transaction in the block is executed after the consensus Add consensus node E to the node list, then at this time, the consensus nodes in the consensus node list include A, B, C, D, E; the consensus nodes in the consensus node list from the 50th block to the 99th block No change; therefore, when the client verifies the N signature information in the 100th block header, it can be based on the consensus node list determined by the block headers from the 0th block to the 99th block. authenticating.

In the above embodiment, although the list of consensus nodes is determined according to the block headers of the 0th block to the 99th block, when verifying the signature information in the block header of the 100th block, the The list of consensus nodes in the block header of the 99th block can be verified, because the block header of the 99th block has passed the verification of the list of consensus nodes in the block header of the 98th block, and the block header of the 98th block has passed the verification of the consensus node list in the block header of the 97th block, and so on, the block header of the second block has passed the verification of the consensus node list in the block header of the first block, and the first block The block header of the block has been verified by the list of consensus nodes in the block header of the 0th block.

In addition, if the consensus node in the consensus node list changes after the transaction of the current block is executed, it means that a certain contract data changes, and the state tree root hash of the block header of the current block needs to be used to verify the correctness of the contract data. and use the consensus node list of the block header of the previous block to verify the signature information in the current block header, which is equivalent to using the consensus node list of the block header of the previous block to verify the current block. The correctness of the hash of the state tree root in the block header of the block. Still using the above example to illustrate, after the transaction in the 50th block is executed, the consensus node E is added to the consensus node list, and the contract data of the state tree corresponding to the 50th block changes, such as adding a certain contract data (representing the consensus Node E), it is necessary to use the root hash of the state tree in the 50th block to verify the existence of the added contract data, and use the consensus node list of the 49th block to verify the existence of the 50th block. The block header information is verified, that is, the root hash of the state tree in the block header of the 50th block is verified.

In the specific verification process, the client can determine the N consensus nodes corresponding to the N signature information, and determine the M consensus nodes in the consensus node list among the N consensus nodes. If M meets the preset conditions, then determine the N consensus nodes. The signature information is verified. M meets the preset condition, which means that the number of M meets the preset threshold. In the case of different consensus algorithms, the preset threshold can take different values. In one implementation, the PBFT (Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance) consensus algorithm is adopted, and the preset threshold is f+1. When the number of consensus nodes is greater than or equal to f+1, it represents the block header information of the block Pass the verification, where f=(N-1)/3. In another implementation, the POW (Proof of Work) consensus algorithm is adopted, and the preset threshold is N/2+1. When the number of consensus nodes is greater than or equal to N/2+1, it means that the block The block header information of is verified, where N is the number of consensus nodes in the consensus list.

In addition, the client also needs to verify the correctness of the genesis block information. When the client verifies that the genesis block information of a specific number of consensus nodes on the blockchain is consistent, the genesis block is approved. The specific number here may be the aforementioned preset threshold.

Through the above method, the client will verify the block header information of the genesis block from the genesis block, and each time a block header is added, it will combine the consensus nodes in the current consensus node list to verify the block header information of the currently added block. Verification to ensure that the block header information of the block saved locally is correct, thereby ensuring the correctness of the root hash of the state tree in the block header used to verify the account data, thereby realizing the verification of the account data.

It can be seen from the above that when the client verifies an account data, the verification flow is genesis block→consensus node→block header information→state tree root hash→account data, that is, the genesis block verifies the consensus node, The consensus node verifies the block header information, the block header information verifies the state tree root hash, and the state tree root hash verifies the account data. Moreover, when the state tree is constructed, based on the unidirectionality of hash calculation, once the leaf node (account data) is modified, the root hash of the state tree will be changed, that is, to further ensure that the account data cannot be modified. In addition, the above-mentioned relevant verification point information is provided by the nodes on the chain. For the consortium chain with the concept of access, the nodes on the chain need to perform authentication before providing information to the client to further ensure the accuracy of data verification.

In order to better explain the embodiment of the present invention, a complete example of on-chain data verification is provided below in conjunction with Table 1, as follows:

The client requests the block chain node to obtain the balance of the account 0x234 on the block with a block height of 48. The block chain node first determines the first block high record 12-45-50 according to 0x234_1, and the block chain node determines The state tree of the first block determines the first branch path used to verify the first block height record 12-45-50; the blockchain node determines the first branch path based on the first block height record 12-45-50 and block height 48 In the block height record, the block height is smaller than block height 48 and the maximum block height is 45. The blockchain node first determines that the balance is 300 according to 0x234_balance_45, and determines the second block used to verify the balance 300 according to the state tree of the second block with block height 45. branch path. The blockchain node sends the first block height record 12-45-50, the first branch path, balance 300, and the second branch path to the client, and the client bases the area of the first block with a block height of 50 stored locally Block header, combined with the first branch path to verify the correctness of the first block high record 12-45-50, based on the proven first block high record 12-45-50, determine that the balance is modified at block 45, then use the local The stored block header of the second block with a block height of 45, combined with the verification of the second branch path, verifies the correctness of balance 300. Combining the above process, the client has completed the process of querying and verifying that the account 0x234 has a balance of 300 on the block with a block height of 48.

It should be noted that the client in Figure 6 can also be a blockchain node of a different alliance chain from the blockchain node, as shown in Figure 9, it can include the first blockchain node and the second blockchain node; where , the first blockchain node can be understood as a data user, and the second blockchain node can be understood as a data provider; the first blockchain node and the second blockchain node belong to different alliance chains.

Based on the same inventive concept, FIG. 10 exemplarily shows the structure of an apparatus for generating a state tree of a block provided by an embodiment of the present invention, and the apparatus can execute the flow of a method for generating a state tree of a block.

The unit includes:

The determining unit 1001 is configured to, for any block in the block chain, determine the first account and the first account data of the block; the first account is the account data that occurs after each transaction in the block is executed. A changed account, the first account data is the changed account data in the first account after the execution of each transaction;

The construction unit 1002 is configured to construct the state tree of the block composed of each first account and the first account data of each first account, and store the root hash of the state tree in the block In the block header of , the state tree is stored in the form of key-value pairs.

Optionally, the construction unit 1002 is specifically used for:

For any first account data of any first account, the identifier of the first account, the identifier of the first account data, and the block height of the block are used as key values, and the first account data is used as The value of the leaf node is used to construct the state tree of the block based on the MPT mode.

Optionally, the first account data includes block height records, account status and/or contract status that have changed in the first account after the execution of each transaction; the block height records are used to record the first The block height of the block where the account status and/or contract status in the account have changed.

Optionally, the device further includes a processing unit 1003;

The processing unit 1003 is used for:

Receive a data acquisition request from the client; the data acquisition request includes the identifier of the second account, the identifier of the second account data, and the first block height;

According to the identification of the second account and the identification of the first high record of the second account, determine the first high record; according to the identification of the second account, the identification of the second account data, The first block is high, determining the second account data;

Obtaining a first branch path for verifying the first high record from the state tree of the first block; the first block is a block corresponding to the highest block height in the first high record;

Obtain the second branch path used to verify the second account data from the state tree of the second block; the second block is the block corresponding to the second block height; the second block height is the the highest block height of all block heights lower than the first block height in the first block height record;

sending the first high record, the first branch path, the second account data, and the second branch path to the client, so that the client can check the first high record and the second account data for verification.

Based on the same inventive concept, FIG. 11 exemplarily shows the structure of an on-chain data verification device provided by an embodiment of the present invention, and the device can execute the flow of the on-chain data verification method.

The unit includes:

The transceiver unit 1101 is configured to send a data acquisition request to the block chain node; the data acquisition request includes the identification of the second account, the identification of the second account data and the first block height;

The transceiver unit 1101 is also configured to receive the first high record, the first branch path, the second account data, and the second branch path returned by the blockchain node; the first high record and the second The second account data is determined by the block chain node according to the identity of the second account, the identity of the second account data, and the first block height; the first branch path is the block chain node The determined branch path for verifying the first high record; the second branch path is the branch path determined by the block chain node for verifying the second account data;

The verification unit 1102 is configured to verify whether the first block high record is correct according to the first branch path and the root hash of the state tree in the block header of the locally stored first block; the locally stored first area The block header of the block is obtained from the blockchain node, and the first block is the block corresponding to the highest block height in the first block height record on the blockchain;

The verification unit 1102 is further configured to, after determining that the first block high record is correct, verify according to the second branch path and the root hash of the status tree in the block header of the locally stored second block Whether the second account data is correct; the block header of the second block stored locally is obtained from the block chain node, and the second block is the second block on the block chain The block corresponding to the height; the second block height is the highest block height of all block heights lower than the first block height in the first block height record.

Optionally, the verification unit 1102 is specifically configured to:

Determine a first root hash according to the first block high record and the data of leaf nodes and branch nodes in the first branch path;

If the first root hash is equal to the root hash of the state tree in the block header of the locally stored first block, it is determined that the first block high record is correct.

Optionally, the verification unit 1102 is specifically configured to:

determining a second root hash according to the second account data and the data of leaf nodes and branch nodes in the second branch path;

If the second root hash is equal to the root hash of the state tree in the block header of the locally stored second block, it is determined that the second account data is correct.

Optionally, the device further includes a synchronization unit 1103;

The synchronization unit 1103 is used for:

Send a query request to the blockchain node;

receiving the query result returned by the block chain node; the query result is the current block height of the block chain returned by the block chain node after receiving the query request;

Judging whether the highest block height of the locally stored block header is less than the current block height, if so, sending a block header acquisition request to the blockchain node; the block header acquisition request includes the block to be acquired high;

Receive the block header returned by the blockchain node, and store the received block header locally.

Optionally, before the synchronization unit 1103 stores the received block header locally, it is further configured to:

Obtain N pieces of signature information in the received block header;

Verify the N signature information according to the consensus node list; the consensus node list is the consensus node determined according to the block header of the genesis block of the blockchain to the previous block header of the received block header list of components;

If the N pieces of signature information pass the verification, it is determined that the received block header is correct.

Optionally, the synchronization unit 1103 is specifically configured to:

Determine the N consensus nodes corresponding to the N signature information;

judging M consensus nodes in the list of consensus nodes among the N consensus nodes;

If M meets the preset condition, it is determined that the N pieces of signature information pass the verification.

Based on the same inventive concept, an embodiment of the present invention also provides a computing device, including:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute the method for generating the state tree of the above block according to the obtained program.

Based on the same inventive concept, an embodiment of the present invention also provides a computer-readable non-volatile storage medium, including computer-readable instructions, when the computer reads and executes the computer-readable instructions, the computer executes the above block The generation method of the state tree.

Based on the same inventive concept, an embodiment of the present invention also provides a computing device, including:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute the above-mentioned on-chain data verification method according to the obtained program.

Based on the same inventive concept, an embodiment of the present invention also provides a computer-readable non-volatile storage medium, including computer-readable instructions. When a computer reads and executes the computer-readable instructions, the computer executes the above-mentioned on-chain The method of data validation.

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 should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

While preferred embodiments of the invention have been described, additional changes and modifications to these embodiments can be made by those skilled in the art once the basic inventive concept is appreciated. Therefore, it is intended that the appended claims be construed to cover the preferred embodiment as well as all changes and modifications which fall within the scope of the invention.

Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.

Claims (24)

1. A method for generating a state tree of a block, comprising:

for any block in a block chain, determining a first account and first account data for the block; the first account is an account of which the account data changes after each transaction in the block is executed, and the first account data is the account data of which the account data changes after each transaction is executed;

and constructing a state tree of the block, wherein the state tree is composed of each first account and first account data of each first account, and storing a root hash of the state tree in a block header of the block, wherein the state tree is stored in a key-value pair mode.

2. The method of claim 1, wherein said building a state tree of the block comprised of each first account and first account data for the each first account comprises:

and aiming at any first account data of any first account, taking the identification of the first account, the identification of the first account data and the block height of the block as key values, taking the first account data as value values of leaf nodes, and constructing a state tree of the block based on the MPT mode.

3. The method of claim 2, wherein the first account data includes a block height record, an account status, and/or a contract status of changes in the first account after execution of the respective transaction; the block height record is used for recording the block height of a block where the account state and/or the contract state in the first account are/is changed for each time.

4. The method of claim 3, wherein the method further comprises:

receiving a data acquisition request of a client; the data acquisition request comprises an identifier of a second account, an identifier of second account data and a first block height;

determining a first block high record according to the identifier of the second account and the identifier of the first block high record of the second account; determining the second account data according to the identification of the second account, the identification of the second account data and the first block height;

obtaining a first branch path for verifying the first block height record from a state tree of a first block; the first block is a block corresponding to the highest block height in the first block height record;

obtaining a second branch path for verifying the second account data from a state tree of a second block; the second block is a block corresponding to the second block height; the second block height is the highest block height of all block heights in the first block height record that are lower than the first block height;

and sending the first block height record, the first branch path, the second account data and the second branch path to the client so that the client verifies the first block height record and the second account data.

5. A method of on-chain data validation, comprising:

sending a data acquisition request to the block link points; the data acquisition request comprises an identifier of a second account, an identifier of second account data and a first block height;

receiving a first block height record, a first branch path, second account data and a second branch path returned by the block chain node; the first block height record and the second account data are determined by the blockchain node according to the identification of the second account, the identification of the second account data and the first block height; the first branch path is a branch path determined by the blockchain node for verifying the first blockheight record; the second branch path is a branch path determined by the blockchain node for verifying the second account data;

verifying whether the first block height record is correct according to the first branch path and the root hash of a state tree in a block head of a first block stored locally; the block head of the first locally stored block is obtained from the block chain node, and the first block is a block corresponding to the highest block height in the first block height record on the block chain;

after the first block height record is determined to be correct, verifying whether the second account data is correct according to the second branch path and a root hash of a state tree in a block header of the locally stored second block; the block header of the locally stored second block is obtained from the block chain node, and the second block is a block corresponding to a second block height in the block chain; the second block height is the highest block height of all block heights in the first block height record that are lower than the first block height.

6. The method of claim 5, wherein said verifying whether the first chunk high record is correct according to the first branch path, a root hash of a state tree in a chunk header of the first chunk stored locally, comprises:

determining a first root hash according to the first block height record and the data of the leaf node and the branch node in the first branch path;

and if the first root hash is equal to the root hash of the state tree in the block header of the locally stored first block, determining that the first block height record is correct.

7. The method of claim 5, wherein verifying whether the second account data is correct based on the second branch path, a root hash of a state tree in a chunk header of the locally stored second chunk comprises:

determining a second root hash according to the second account data and the data of the leaf node and the branch node in the second branch path;

and if the second root hash is equal to the root hash of the state tree in the block header of the locally stored second block, determining that the second account data is correct.

8. The method of claim 5, wherein the method further comprises:

sending a query request to the block nodes;

receiving a query result returned by the block chain node; the query result is that the current block height of the block chain returned by the block chain node after receiving the query request is high;

judging whether the highest block height of the locally stored block header is smaller than the current block height, if so, sending a block header acquisition request to the block link point; the block head acquiring request comprises the block height of a block head to be acquired;

and receiving the block head returned by the block chain node, and storing the received block head locally.

9. The method of claim 8, wherein prior to storing the received chunk header locally, further comprising:

acquiring N pieces of signature information in the received block header;

verifying the N signature information according to a common node list; the common identification node list is a list formed by common identification nodes determined from a block head of a creation block of the block chain to a block head before the received block head;

and if the N pieces of signature information pass the verification, determining that the received block header is correct.

10. The method of claim 9, wherein said verifying said N signature messages according to a list of consensus nodes comprises:

determining N common identification nodes corresponding to the N pieces of signature information;

judging M consensus nodes in the consensus node list in the N consensus nodes;

and if the M meets the preset condition, determining that the N pieces of signature information pass the verification.

11. An apparatus for generating a state tree of a block, comprising:

the determining unit is used for determining a first account and first account data of any block in a block chain; the first account is an account of which the account data changes after each transaction in the block is executed, and the first account data is the account data of which the account data changes after each transaction is executed;

a building unit, configured to build a state tree of the block, where the state tree is formed by each first account and first account data of each first account, and store a root hash of the state tree in a block header of the block, where the state tree is stored in a key-value pair manner.

12. The apparatus of claim 11, wherein the construction unit is specifically configured to:

and aiming at any first account data of any first account, taking the identification of the first account, the identification of the first account data and the block height of the block as key values, taking the first account data as value values of leaf nodes, and constructing a state tree of the block based on the MPT mode.

13. The apparatus of claim 12, wherein the first account data comprises a block height record, an account status, and/or a contract status of changes in the first account after execution of the respective transaction; the block height record is used for recording the block height of a block where the account state and/or the contract state in the first account are/is changed for each time.

14. The apparatus of claim 13, wherein the apparatus further comprises a processing unit;

the processing unit is configured to:

receiving a data acquisition request of a client; the data acquisition request comprises an identifier of a second account, an identifier of second account data and a first block height;

determining a first block high record according to the identifier of the second account and the identifier of the first block high record of the second account; determining the second account data according to the identification of the second account, the identification of the second account data and the first block height;

obtaining a first branch path for verifying the first block height record from a state tree of a first block; the first block is a block corresponding to the highest block height in the first block height record;

obtaining a second branch path for verifying the second account data from a state tree of a second block; the second block is a block corresponding to the second block height; the second block height is the highest block height of all block heights in the first block height record that are lower than the first block height;

and sending the first block height record, the first branch path, the second account data and the second branch path to the client so that the client verifies the first block height record and the second account data.

15. An apparatus for on-chain data validation, comprising:

the receiving and sending unit is used for sending a data acquisition request to the block link points; the data acquisition request comprises an identifier of a second account, an identifier of second account data and a first block height;

the receiving and sending unit is further configured to receive a first block height record, a first branch path, second account data, and a second branch path returned by the block chain node; the first block height record and the second account data are determined by the blockchain node according to the identification of the second account, the identification of the second account data and the first block height; the first branch path is a branch path determined by the blockchain node for verifying the first blockheight record; the second branch path is a branch path determined by the blockchain node for verifying the second account data;

a verification unit, configured to verify whether the first block height record is correct according to the first branch path and a root hash of a state tree in a block header of a locally stored first block; the block head of the first locally stored block is obtained from the block chain node, and the first block is a block corresponding to the highest block height in the first block height record on the block chain;

the verification unit is further configured to verify whether the second account data is correct according to the second branch path and a root hash of a state tree in a block header of the locally stored second block after determining that the first block height record is correct; the block header of the locally stored second block is obtained from the block chain node, and the second block is a block corresponding to a second block height in the block chain; the second block height is the highest block height of all block heights in the first block height record that are lower than the first block height.

16. The apparatus as recited in claim 15, wherein said verification unit is specifically configured to:

determining a first root hash according to the first block height record and the data of the leaf node and the branch node in the first branch path;

and if the first root hash is equal to the root hash of the state tree in the block header of the locally stored first block, determining that the first block height record is correct.

17. The apparatus as recited in claim 15, wherein said verification unit is specifically configured to:

determining a second root hash according to the second account data and the data of the leaf node and the branch node in the second branch path;

and if the second root hash is equal to the root hash of the state tree in the block header of the locally stored second block, determining that the second account data is correct.

18. The apparatus of claim 15, wherein the apparatus further comprises a synchronization unit;

the synchronization unit is configured to:

sending a query request to the block nodes;

receiving a query result returned by the block chain node; the query result is that the current block height of the block chain returned by the block chain node after receiving the query request is high;

judging whether the highest block height of the locally stored block header is smaller than the current block height, if so, sending a block header acquisition request to the block link point; the block head acquiring request comprises the block height of a block head to be acquired;

and receiving the block head returned by the block chain node, and storing the received block head locally.

19. The apparatus of claim 18, wherein the synchronization unit, prior to the storing the received chunk header locally, is further to:

acquiring N pieces of signature information in the received block header;

verifying the N signature information according to a common node list; the common identification node list is a list formed by common identification nodes determined from a block head of a creation block of the block chain to a block head before the received block head;

and if the N pieces of signature information pass the verification, determining that the received block header is correct.

20. The apparatus as recited in claim 19, wherein said synchronization unit is specifically configured to:

determining N common identification nodes corresponding to the N pieces of signature information;

judging M consensus nodes in the consensus node list in the N consensus nodes;

and if the M meets the preset condition, determining that the N pieces of signature information pass the verification.

21. A computing device, comprising:

a memory for storing program instructions;

a processor for calling program instructions stored in said memory to execute the method of any one of claims 1 to 4 in accordance with the obtained program.

22. A computer-readable non-transitory storage medium including computer-readable instructions which, when read and executed by a computer, cause the computer to perform the method of any one of claims 1 to 4.

23. A computing device, comprising:

a memory for storing program instructions;

a processor for calling program instructions stored in said memory to execute the method of any one of claims 5 to 10 in accordance with the obtained program.

24. A computer readable non-transitory storage medium including computer readable instructions which, when read and executed by a computer, cause the computer to perform the method of any one of claims 5 to 10.