WO2021068728A1 - Methods and apparatus for generating state tree of block and validating on-chain data - Google Patents

Abstract

Disclosed are methods and apparatus for generating a state tree of a block and validating on-chain data. The method for generating a state tree of a block comprises: determining for any block in a blockchain a first account and first account data of the block, the first account being an account in which account data is changed after each transaction is executed in the block, and the first account data being changed account data in the first account after each transaction is executed; and constructing a state tree of a block formed from 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, the state tree being stored as a key-value pair. The described technical solution is used to simplify account data used for constructing a state tree on a blockchain, thereby shortening the length of a branch path used for validation, and improving the efficiency of existence validation of account data.

Description

Method and device for generating block state tree and verifying data on chain

Cross-references to related applications

This application requires a Chinese patent application to be submitted to the Chinese Patent Office on October 10, 2019, with an application number of 201910960376.X, and an application titled "Method and device for generating a state tree of a block and verifying data on the chain" Priority, the entire content of which is incorporated in this application by reference.

Technical field

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

Background technique

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

In the state tree and storage tree of Ethereum (ethereum), if the existence of the contract state in the storage tree is verified, the branch path of the contract state in the storage tree needs to be determined first to verify whether the contract state exists in the corresponding storage tree Then, the branch path of the account state corresponding to the storage tree in the state tree is determined, and then it is verified whether the account state exists in the corresponding state tree.

However, as the data on the blockchain continues to grow, the branch path that blockchain nodes need to obtain for verification is longer, and the time consuming to obtain the branch path and the time consuming to verify the existence are both longer.

Summary of the invention

The embodiment of the present invention provides a method and device for generating the state tree of a block and verifying data on the chain, which is used to streamline the account data used to construct the state tree on the block chain, thereby shortening the length of the branch path 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 the execution of each transaction in the block, the The first account data is the changed account data in the first account after the execution of each transaction; the state of the block composed of each first account and the first account data of each first account is constructed And store the root hash of the state tree in the block header of the block, wherein the state tree is stored in a key-value pair.

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 level of the state tree by reducing the amount of data.

Optionally, the constructing the state tree of the block composed of each first account and the first account data of each first account includes: any first account data for any first account, The identification of the first account, the identification of the first account data, and the block height of the block are used as the key value, and the first account data is used as the value value of the leaf node, and the block is constructed based on the MPT mode State tree.

In the above technical solution, the key value is directly stored persistently instead of the hash of the key value. In this way, it can be ensured that the account data under the same account has the same compression prefix, that is, the account ID or The account address effectively uses the advantages of Patricia Tree to minimize the level of the state tree, reducing storage space and speeding up the construction and verification efficiency of branch paths.

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

The account state originally belongs to the value in the leaf node of the state tree, and the contract state originally belongs 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, merges the state tree and the storage tree into one tree, thereby flattening the hierarchical structure of the account data, and speeding up the construction and verification efficiency of the branch path. Further, a key-value key-value pair is added when placing the disk for storage, where the key includes an account identifier and an 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 high record is used to record the block height of the block where the account data in the account ID corresponds to the previous change. In this way, when verifying a certain account data, the block of the state tree where the account data is located can be determined first. Then determine the branch path for verification based on the block.

Optionally, the method further includes: receiving 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 identifier of the second account And the identifier of the first high record of the second account, determine the first high record; determine according to the identifier of the second account, the identifier of the second account data, and the first high record The second account data; the first branch path used to verify the first block of high records is obtained from the state tree of the first block; the first block is the highest in the first block of high records The block corresponding to the block height; obtain the second branch path for verifying 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 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; the first block height record, the first branch path, and the first block height are recorded. 2. The account data and the second branch path are sent to the client, so that the client verifies the first high record and the second account data.

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, and the second The group is the second account data and the second branch path used to verify the second account data, so the client can verify the first high record and the second account data respectively according to the two sets of data. Among them, the first branch path and the second branch path are shorter than the branch paths 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. , Thereby improving the efficiency of the client to verify 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 blockchain node; the data acquisition request includes the identifier of the second account, the identifier of the second account data, and the first block height; receive the first block height record and the first block height returned by the blockchain node A branch path, second account data, and a second branch path; the first block of high records and the second account data are based on the identification of the second account and the second account data by the blockchain node And the first block height; the first branch path is the branch path determined by the blockchain node for verifying the first block height record; the second branch path is the The branch path determined by the blockchain node to verify the second account data; verify the first block according to the first branch path and the root hash of the state tree in the block header of the first block stored locally Whether the high record is correct; the block header of the first block stored locally is obtained from the blockchain node, and the first block is in the first high record on the blockchain The block corresponding to the highest block height; after determining that the first block height record is correct, verify the root hash of the state tree in the block header of the locally stored second block according to the second branch path Whether the second account data is correct; the block header of the locally stored second block is obtained from the block chain node, and the second block is the second 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.

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 client's data acquisition request. The first set is the first high record and is used to verify the first high record. A piece of high-record first branch path, 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 check the first piece of high record and the second branch according to the two sets of data 2. Account data is verified. Among them, the first branch path and the second branch path are shorter than the branch paths 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. , Thereby improving the efficiency of the client to verify data.

Optionally, the verifying whether the first block height 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 includes: according to the first block The high record and the data of the leaf node and the branch node in the first branch path determine the first root hash; if the first root hash is equal to the value of the state tree in the block header of the first block stored locally Root hash, it is determined that the first high record is correct.

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

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: according to the The second account data and the data of the leaf nodes and branch nodes in the second branch path determine the second root hash; if the second root hash is equal to the state in the block header of the second block stored locally The root hash of the tree determines that the second account data is correct.

In the above technical solution, the client implements 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 further includes: sending a query request to the blockchain node; receiving a query result returned by the blockchain node; the query result is that the blockchain node receives the query The current block height of the blockchain returned after the request; determine whether the highest block height of the locally stored block header is less than the current block height, and if so, send a block header acquisition request to the blockchain node; The block header obtaining request includes the block height of the block header to be obtained; receiving the block header returned by the blockchain node, and storing 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 stored locally.

Optionally, before storing the received block header locally, the method further includes: obtaining N signature information in the received block header; verifying the N signature information according to the consensus node list; The consensus node list is a list of consensus nodes determined from the block header of the genesis block of the blockchain to the previous block header of the received block header; if the N signature information passes verification, then Make sure that the received block header is correct.

Optionally, the verification of the N signature information according to the consensus node list includes: determining the N consensus nodes corresponding to the N signature information; determining that the N consensus nodes are in the consensus node list If M meets the preset conditions, it is determined that the N signature information passes verification.

Through the above method, the client verifies the block header information of the genesis block from the beginning of the genesis block, and each time the block header of a block is added, the consensus node in the current consensus node list will be combined with the block header of the currently added block. Verification is to ensure that the block header information of the block saved locally is correct, so as to ensure the correctness of the root hash of the state tree in the block header used to verify the account data, and then to realize the verification of the account data.

In a third aspect, the present application also provides a device that has the function of realizing any method provided in the above-mentioned first aspect or any method provided in the above-mentioned second aspect. The device can be realized by hardware, or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above-mentioned functions.

In a possible implementation manner, the device includes a processor configured to support the device to execute the steps in the method shown above. The device may also include a memory, which may be coupled with the processor, which stores program instructions and data necessary for the device. Optionally, the device further includes a communication interface for supporting communication between the device and other devices.

In a possible implementation manner, the device includes corresponding functional units, which are respectively used to implement the steps in the above method. The function can be realized by hardware, or the corresponding software can be executed by hardware. The hardware or software includes one or more units corresponding to the above-mentioned functions.

In a fourth aspect, the embodiments of the present invention also provide a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores computer instructions, and when it runs on a computer, the computer executes the first aspect described above. The method for generating the state tree of the block in any one of the implementation manners, or the method for performing on-chain data verification in any one of the implementation manners of the second aspect described above.

In a fifth aspect, an embodiment of the present invention also provides a computer program product containing instructions. The computer program product includes a calculation program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer executes the state tree generation method of the block in any one of the implementations of the first aspect, or executes the on-chain data verification in any one of the implementations of the second aspect. Methods.

Description of the drawings

In order to explain the technical solutions in the embodiments of the present invention more clearly, the following will briefly introduce the drawings needed 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, without creative work, other drawings can be obtained based on these drawings.

Figure 1 is a schematic diagram of a Merkle Tree;

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

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

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

5 is a schematic diagram of the flow of a method for generating a state tree of a block according to 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 according to an embodiment of the present invention;

8 is a schematic diagram of a process for a client to obtain a block header according to an embodiment of the present invention;

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

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

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

FIG. 12 is a schematic structural diagram of a computing device provided by this application.

Detailed ways

In order to make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part 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 those of ordinary skill in the art without creative work shall fall within the protection scope of the present invention.

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

1. Merkle Tree

Merkle Tree is a binary tree composed of leaf nodes, intermediate nodes and root nodes. The leaf node records the hash value of the data (such as account data mentioned in the embodiment of the present invention), and the intermediate node records the calculation after 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, D1-D7 are basic data (used to build leaf nodes), and 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, and it records the value obtained after hashing with nodes H2 and H1 as inputs. Repeat the above calculation process cyclically, and finally calculate the hash value of the last node, 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 only summary of a set of data. At the same time, we can verify the existence of a certain data by providing the Merkle branch path of the data based on the Merkle Tree. The 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 calculates 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 Merkle Tree in.

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 the nodes 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. Ethereum's state tree and storage tree

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

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 mapping. 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 storing the MPT records the value of the key-value data item, and the 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 state and contract state) can still be verified based on Merkle proof. Take Figure 2 as an example, if you want to verify that one of the contract states 27 is in block 60 If the existence of, you need 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 According to the branch path, it is verified whether Account 175 constitutes the state tree of block 59, 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 the relationship of the tree construction. In addition, the increase in data on the chain also makes it more and more time-consuming to provide branch paths and perform external Merkle proofs.

In order to solve the above problems, the embodiments of the present invention provide 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 new Increased 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 in comparison 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. The parent is determined based on the contract state 26 of the original Account 175 and the modified contract state 45. The hash value in the node, and the hash value of the root node of the constructed storage tree is stored in the storage root field of Account 175 in block 60; based on the account status of the original Account 174 and the modified Account 175 The account 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.

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

It can be seen from the above that the state tree and the storage tree in the embodiment of the present invention are only generated based on the modified or newly added account data during the transaction execution of the current block, and will not be based on the unchanged 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 prior art uses 10,000 accounts to construct the state tree corresponding to the block 60, and in the embodiment of the present invention, if only the account data of the 1,000 accounts change after all transactions in the block 60 are executed, the present invention is implemented For example, only 1000 accounts need to be used to construct the state tree corresponding to block 60, and the 1000 accounts build their own storage trees based on the contract data that have changed. The data amount in the embodiment of the present invention is reduced to 1/10 of the original data amount. , Can greatly reduce the level of the state tree and storage tree.

In addition, in the state tree and storage tree of Ethereum, two Merkle proofs are used to prove that the contract state is in the storage tree, and then the account state is in the state tree. The embodiment of the present invention can merge the state tree and the storage tree into one. A tree moves the value in the leaf node of the state tree 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. A block corresponds to a state tree. The leaf nodes of the state tree include account state and contract state. In this way, only one Merkle proof is needed to verify the existence of account data. For example, it is necessary to verify that the contract state 27 is in block 60. For the existence of the state tree, 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 It 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 placement storage can be defined as "account ID + account data ID + write/modify the block height of the key-value", and the value value is the account data corresponding to the account data ID. In addition, In the above key, the account identification can be understood as the account address; the account data identification can be understood as the serial number of the data that needs to be stored persistently, or the identification of the data that needs to be stored persistently, for example, the account data is the account balance in the account status, then the account data The identifier can be "balance". For example, the account data is the value in the contract status, and the account data identifier can be a set serial number. The identifier of the contract status 27 in FIG. 4 is 2. The leaf node in the embodiment of the present invention stores the hash value of the account data.

Building a state tree based on key-value can be a state MPT. The key value indicates the path from the root node to the leaf node in the MPT, as shown in Figure 4, key(0x234_balance_60)=100.

Considering that the state tree constructed in the embodiment of the present invention is only constructed based on the change account data of the change account, there is a problem with this construction method, that is, the correctness of a non-existent data cannot be proved, which is equivalent to the inability to prove that a non-existent data is not constituted 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, there is an account whose account data has only changed when the block height is 20, and the account data of the account can only be verified based on the state tree of the block height of 20 The correctness of the account data cannot be verified based on the state tree of any block after the block height is 20.

In order to solve the above-mentioned problem, the embodiment of the present invention will add another set of key-value key-value pairs based on storing the above-mentioned key-value key-value pairs, where the key includes an account identifier and an account data identifier. 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 of persistent storage, 1 is the identifier of the block height record, and 12-45-50 is the block height record of the record. It is understandable For account 0x234, write at block height 12 and modify at block heights 45 and 50. The current blockchain stores four key-value key-value pairs 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 keys The -value key-value pair indicates the balance value of the account 0x234 when writing or modifying 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, it is possible to quickly determine the block height of the block where the account data corresponding to the account has undergone previous changes, and further determine which block's state tree should be used to verify the correctness of the data to be verified , The specific implementation 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 may be executed by a device for generating a state tree of a block, and the device may be located in Among the blockchain nodes, it can be the blockchain node.

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

Among them, 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 the execution of each transaction.

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

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

For another example, each transaction in the current block involves a total of 100 accounts, and the number of accounts whose account data has changed is 98. At this time, the first account corresponding to the current block is 98, and each of the 98 accounts Each account corresponds to at least one account data that has changed. Here, it may be that one transaction or multiple transactions in the current block cause the status data of a certain account to not change after the current block is executed.

In step 502, the blockchain node constructs a state tree of the 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.

In the construction process, for any first account data of any first account, the identification of the first account, the identification 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, it can be ensured that the account data under the same account have the same compressed prefix, that is, the account identifier. Or the account address, as shown in Figure 4, all the keys of the account data of 0x234 have the same prefix, that is, 0x234, so at least the keys of all the account data of 0x234 can be compressed with the common prefix 0x234. In the prior art, after hashing the keys of all account data of 0x234, there are fewer common prefixes, and the level of the state tree is deeper. Therefore, the embodiment of the present invention can effectively utilize the advantages of Patricia Tree, compress the level of the state tree to a minimum, reduce storage space, and speed up the construction and verification efficiency of branch paths.

Based on the above-mentioned construction scheme of the state tree in the blockchain node, the embodiment of the present invention also provides a method for on-chain data verification. The method is suitable for the system architecture shown in FIG. 6, and the system architecture may include a client and a zone. Block chain node. 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.

Fig. 7 is the flow of the method for on-chain data verification shown in the embodiment of the present invention, and 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 height, 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 height.

Step 702: The blockchain node determines the first high record according to the identifier of the second account and the identifier 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 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 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 identification of the second account, the identification of the second account data, and the height of the first block.

The blockchain node determines the second account data according to the identification of the second account, the identification 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, the identification of the second account is determined to be 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.

In step 704, the blockchain node obtains the first branch path for verifying the high record of the first block from the state tree of the first block.

Step 705: The blockchain node obtains the second branch path for verifying the second account data from the state tree of the second block.

Since the state tree of a certain block constructed 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, to verify the existence of the second account data, the second account needs to be determined first 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 determine the block height record recorded when the account data of the second account has been previously modified, that is, the first block height record needs to be determined. After the first block height record is determined, 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 is ready to use After recording the last modified account data of the second account before the first block height, the second branch path for verifying the second account data is determined according to the state tree of the second block.

In addition, in order to ensure the correctness of the first block of high records, it is also necessary to determine the first block corresponding to the state tree where the first block of high records is located, and then determine the first block to verify the first block according to the state tree The first branch path recorded. Specifically, the first block may be the 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 of block height 50, and the second branch path is corresponding to the second block of block height 45 The state tree is determined.

In 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 of high records 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 blockchain, which are used for receiving the first high record, the first branch path, the second account data, and the second branch path sent by the blockchain node. The information in the corresponding block header verifies the first high record and the second account data.

In one implementation method, the client can periodically go to the blockchain node to obtain the block header of the latest block. In another implementation method, the client can go to the blockchain when it needs to verify the received data. Get it on the node. The former can be specifically shown in Figure 8 and 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 obtained by the client;

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

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

In step 801 to step 807, the client sends a query request to the blockchain node. After receiving the query request, the blockchain node will feedback the current block height on the current blockchain to the client, and the client will receive the query request. The query result of the current block height is used to determine whether the block header needs to be synchronized with the blockchain node according to the query result. Specifically, the client determines whether the highest block height of the locally stored block header is less than the current block height on the blockchain. If it is, it is determined to synchronize the block header to the blockchain node, and send a block header acquisition request to the blockchain node, where 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 blockchain of the blockchain node is 100, and the highest block height of the block header stored locally by the client is 98, the client determines that it needs to obtain the 99th and 100th from the blockchain node. For the block header of each block, the client sends a block header acquisition request to the blockchain node, where the block header acquisition request includes the block heights of the block header to be acquired as 99 and 100.

In the foregoing implementation manner, 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 stored locally.

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 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 block of high records 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 block of high records 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 based on 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 by the client is obtained from the blockchain node, the second block is the block corresponding to the second block on the blockchain, and the second block is the first block. The highest block height of all block highs in a block high record lower than the first block height.

During 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 block of high records and the second account data, and verifies the first block of high records based on the first block, and based on the second block pair The second account data is verified, but in the embodiment of the present invention, the client may first obtain the first block of high records, and verify the first block of high records based on the first block, and then verify the first block of high records. After passing, the second account data is obtained, and the second account data is verified based on the second block.

It should be noted that the client verifies the first block of high records based on the root hash of the state tree of the block header of the first block stored locally, and the state tree based on the block header of the second block stored locally The root hash of to verify the data of the second account, so the client first needs to make sure 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 node on the chain is added to the block header. After obtaining the block header, the client will verify the block header according to the signature list in the block header. The correctness of the block header, specifically, before storing the received block header locally, the client obtains the N signature information in the received block header, and verifies 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 consensus node list is a list of consensus nodes determined by the client according to 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 based on the consensus node list determined by the block headers of the 0th block (the genesis block) to the 99th block .

The explanation is 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 in the genesis block have 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 consensus after the transaction in the block is executed Consensus node E is added to the node list. At this time, the consensus nodes in the consensus node list are A, B, C, D, E; the consensus node in the consensus node list from the 50th block to the 99th block No change has occurred; therefore, when the client verifies the N signature information in the 100th block header, it can be based on the consensus node list determined from the 0th block to the 99th block. authenticating.

In the above embodiment, although the consensus node list is determined based on 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 first block is directly used. The list of consensus nodes in the block header of 99 blocks can be verified, because the block header of the 99th block has passed the verification of the consensus node list 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, the first block The block header of the block has passed the verification of the consensus node list in the block header of the 0th block.

In addition, after the transaction of the current block is executed, the consensus node in the consensus node list changes, which is equivalent to a change in a certain contract data, 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 using the consensus node list of the block header of the previous block of the current block to verify the signature information in the current block header is equivalent to using the consensus node list of the block header of the previous block of the current block to verify the current block The correctness of the root hash of the state tree in the block header of the block. Still taking the above example to illustrate, if the consensus node E is added to the consensus node list after the transaction in the 50th block is executed, the contract data of the state tree corresponding to the 50th block will change, such as adding a certain contract data (representing 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 to use the consensus node list of the 49th block for 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, determine 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) 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 Through verification, where f=(N-1)/3. In another implementation method, 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 represents 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 certain number of consensus nodes on the blockchain is consistent, it recognizes the genesis block. The specific number here may be the aforementioned preset threshold.

Through the above method, the client verifies the block header information of the genesis block from the beginning of the genesis block, and each time the block header of a block is added, the consensus node in the current consensus node list will be combined with the block header of the currently added block. Verification is to ensure that the block header information of the block saved locally is correct, so as to ensure the correctness of the root hash of the state tree in the block header used to verify the account data, and then to realize the verification of the account data.

It can be seen from the above that when the client verifies certain account data, the verification flow is creation block → consensus node → block header information → state tree root hash → account data, that is, the creation 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 one-way nature of the 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 is not modified. In addition, the above-mentioned relevant verification point information is provided by the nodes on the chain. For consortium chains 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 embodiments of the present invention, a complete example of on-chain data verification is provided below in conjunction with Table 1. The details are as follows:

The client requests the blockchain node to obtain the balance of the account 0x234 on the block height 48. The blockchain node first determines the first block height record 12-45-50 according to 0x234_1, and the blockchain node according to the block height 50 The state tree of the first block determines the first branch path used to verify the first block of high record 12-45-50; the blockchain node determines the first branch according to the first block of high record 12-45-50 and block height 48 The block height record is smaller than the block height 48 and the largest block height is 45. The blockchain node first determines the balance to be 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 a block height of 45 Branch path. The blockchain node sends the first block of high record 12-45-50, the first branch path, balance 300, and the second branch path to the client, and the client uses the locally stored block height 50 of the first block. Block header, combined with the first branch path to verify the correctness of the first block of high record 12-45-50, based on the proven first block of 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 is combined with the verification of the second branch path to verify the correctness of the balance 300. Combining the above process, the client has completed the process of querying and verifying that the balance of account 0x234 on the block with block height 48 is 300.

It should be noted that the client in FIG. 6 may also be a blockchain node of an alliance chain different from the blockchain node. As shown in FIG. 9, it may include a first blockchain node and a second blockchain node; where , The first blockchain node can be understood as the data user, and the second blockchain node can be understood as the 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 the method for generating a state tree of a block.

The device includes: a determining unit 1001 for determining a first account and first account data of the block for any block in the block chain; the first account is the execution of each transaction in the block After the account data has changed, the first account data is the account data after the change in the first account after the execution of each transaction; the construction unit 1002 is used to construct the first account and the first account. The first account data of the first account constitutes the state tree of the block, and the root hash of the state tree is stored in the block header of the block, wherein the state tree is a key-value pair Way to store.

Optionally, the construction unit 1002 is specifically configured to: for any first account data of any first account, combine the identification of the first account, the identification of the first account data, and the identification of the block The block height is used as the key value, the first account data is used as the value value of the leaf node, and the state tree of the block is constructed based on the MPT mode.

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

Optionally, the device further includes a processing unit 1003; the processing unit 1003 is configured to: 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; determine the first block height record according to the identification of the second account and the identification of the first block height record of the second account; according to the identification of the second account and the second account data The identification of the first block height, the second account data is determined; the first branch path used to verify the first block height record is obtained from the state tree of the first block; the first block Is the block corresponding to the highest block height in the first block height record; the second branch path for verifying the second account data is obtained 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 highest block height of all block heights lower than the first block height in the first block height record; the first block height is recorded , The first branch path, the second account data, and the second branch path are sent to the client, so that the client verifies the first high record and the second account data.

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 device includes: a transceiver unit 1101, configured to send a data acquisition request to a blockchain node; the data acquisition request includes the identifier of the second account, the identifier of the second account data, and the first block height; the transceiver unit 1101, It is also used to receive the first block of high records, the first branch path, the second account data, and the second branch path returned by the blockchain node; the first block of high records and the second account data are the The blockchain node is determined 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 blockchain node for verification The branch path of the first block of high records; the second branch path is the branch path determined by the blockchain node for verifying the second account data; the verification unit 1102 is configured to follow the first branch Path, the root hash of the state tree in the block header of the first block stored locally to verify whether the first block high record is correct; the block header of the first block stored locally is from the blockchain node 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 also used for determining the first block height After the 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 locally stored second block; the locally stored second The block header of the block is obtained from the block chain node, the second block is the block corresponding to the second block height on the block chain; the second block height is the first block height The block height records the highest block height of all block heights lower than the first block height.

Optionally, the verification unit 1102 is specifically configured to: determine the first root hash according to the first block height record and the data of leaf nodes and branch nodes in the first branch path; if the first root If the hash is equal to the root hash of the state tree in the block header of the first block stored locally, it is determined that the high record of the first block is correct.

Optionally, the verification unit 1102 is specifically configured to: determine a second root hash according to the second account data and data of leaf nodes and branch nodes in the second branch path; If it 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 configured to: send a query request to the blockchain node; receive the query result returned by the blockchain node; the query result is all The current block height of the block chain returned by the block chain node after receiving the query request; determine whether the highest block height of the locally stored block header is less than the current block height, and if so, send it to the district The block chain node sends a block header acquisition request; the block header acquisition request includes the block height of the block header to be acquired; receives the block header returned by the blockchain node, and stores the received block header locally.

Optionally, before storing the received block header locally, the synchronization unit 1103 is further configured to: obtain N signature information in the received block header; N signature information verification; the consensus node list is a list of consensus nodes determined from the block header of the genesis block of the blockchain to the previous block header of the received block header; if the N If the signature information is verified, 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; determine the M consensus nodes in the consensus node list among the N consensus nodes; if M If the preset condition is met, it is determined that the N signature information passes the verification.

Based on the same concept as the method shown in FIG. 5 or FIG. 7, the present application also provides a computing device. As shown in FIG. 12, the computing device includes at least one processor 1220 for implementing the method provided in the embodiment of the present application. Either method in Figure 5 or Figure 7.

The computing device 1200 may also include at least one memory 1230 for storing program instructions and/or data. The memory 1230 and the processor 1220 are coupled. The coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, and may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules. The processor 1220 may operate in cooperation with the memory 1230. The processor 1220 may execute program instructions stored in the memory 1230. At least one of the at least one memory may be included in the processor.

In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

It should be noted that the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capability. In the implementation process, the steps of the foregoing method embodiments can be completed by hardware integrated logic circuits in the processor or instructions in the form of software. The above-mentioned processor may be a general-purpose processor, a digital signal processing circuit (digital signal processor, DSP), a dedicated integrated circuit (application specific integrated circuit, ASIC), a field programmable gate array (field programmable gate array, FPGA) or other Programming logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps, and logical block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

It can be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), and electrically available Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of exemplary but not restrictive description, many forms of RAM are available, such as static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), and synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM) ) And direct memory bus random access memory (direct rambus RAM, DR RAM). It should be noted that the memories of the systems and methods described herein are intended to include, but are not limited to, these and any other suitable types of memories.

The computing device 1200 may further include a communication interface 1210 for communicating with other devices through a transmission medium, so that the device used in the computing device 1200 can communicate with other devices. In the embodiment of the present application, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface. In the embodiment of the present application, when the communication interface is a transceiver, the transceiver may include an independent receiver and an independent transmitter; it may also be a transceiver with integrated transceiver functions, or an interface circuit.

The computing device 1200 may also include a communication line 1240. Among them, the communication interface 1210, the processor 1220, and the memory 1230 may be connected to each other through a communication line 1240; the communication line 1240 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (extended industry standard architecture). , Referred to as EISA) bus and so on. The communication line 1240 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used in FIG. 12 to represent it, but it does not mean that there is only one bus or one type of bus.

Based on the same inventive concept, the embodiments of the present invention also provide a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores computer instructions, and when it runs on a computer, the computer executes as shown in Figure 5. The method of generating the state tree of the block in the related embodiment, or the method of performing on-chain data verification in the related embodiment of FIG. 7.

Based on the same inventive concept, embodiments of the present application provide a computer program product. The computer program product includes a calculation program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When executed by a computer, the computer is caused to execute the method of generating the state tree of the block in the related embodiment of FIG. 5, or execute the method of on-chain data verification in the related embodiment of FIG. 7.

The present invention is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present 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. In this way, 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 is also intended to include these modifications and variations.

Claims (23)

1. A method for generating a state tree of a block, which is characterized in that it 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 the execution of each transaction in the block, the The first account data is the account data after the change in the first account after the execution of each transaction;

   Construct a 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 header of the block, wherein , The state tree is stored in the form of key-value pairs.
2. The method according to claim 1, wherein said constructing the state tree of the block composed of each first account and the first account data of each first account comprises:

   For any first account data of any first account, the identification of the first account, the identification of the first account data, and the block height of the block are used as the key value, and the first account data is used as The value value of the leaf node constructs the state tree of the block based on the MPT mode.
3. The method according to claim 2, wherein 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 The high record is used to record the block height of the block where the account status and/or contract status in the first account has been changed.
4. The method of claim 3, wherein the method further comprises:

   Receiving 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;

   Determine the first high record according to the identifier of the second account and the identifier of the first high record of the second account; according to the identifier of the second account, the identifier of the second account data, The first block is high, and the second account data is determined;

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

   Obtain the second branch path for verifying 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 in the first block height record lower than the first block height;

   Send the first block of high records, the first branch path, the second account data, and the second branch path to the client, so that the client can record the first block of high records Verification with the second account data.
5. A method for on-chain data verification, which is characterized in that it includes:

   Send 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 height;

   Receive the first block of high records, the first branch path, the second account data, and the second branch path returned by the blockchain node; the first block of high records and the second account data are the blockchain The node is determined 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 blockchain node to verify the first The branch path of the block height record; the second branch path is the branch path determined by the blockchain node for verifying the second account data;

   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 block header of the locally stored first block is from Obtained on the blockchain node, the first block is a 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 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 the block corresponding to the second block on the block chain; the first 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.
6. The method of claim 5, wherein the first branch path and the root hash of the state tree in the block header of the first block stored locally verify whether the first block high record is correct ,include:

   Determine the first root hash according to the first block high record and the data of the leaf nodes and the 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.
7. The method of claim 5, wherein the second account data is verified according to the second branch path and the root hash of the state tree in the block header of the locally stored second block Is correct, including:

   Determine 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.
8. The method of claim 5, wherein the method further comprises:

   Sending a query request to the blockchain node;

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

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

   Receive the block header returned by the blockchain node, and store the received block header locally.
9. The method according to claim 8, wherein before storing the received block header locally, the method further comprises:

   Acquiring N signature information in the received block header;

   According to the consensus node list, verify the N signature information; the consensus node list is a consensus node determined from 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 signature information passes the verification, it is determined that the received block header is correct.
10. The method according to claim 9, wherein the verifying the N signature information according to the consensus node list comprises:

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

    Judging the M consensus nodes in the consensus node list among the N consensus nodes;

    If M meets the preset condition, it is determined that the N signature information passes verification.
11. A device for generating a state tree of a block is characterized in that it comprises:

    The determining unit is configured to determine the first account and first account data of the block for any block in the block chain; the first account is the change in account data after each transaction in the block is executed The first account data is the account data after the change in the first account after the execution of each transaction;

    The construction unit is used 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's In the block header, the state tree is stored in the form of key-value pairs.
12. The device according to claim 11, wherein the construction unit is specifically configured to:

    For any first account data of any first account, the identification of the first account, the identification of the first account data, and the block height of the block are used as the key value, and the first account data is used as The value value of the leaf node constructs the state tree of the block based on the MPT mode.
13. The device according to claim 12, wherein the first account data includes a block height record, an account status, and/or a contract status that have changed in the first account after the execution of each transaction; the block The high record is used to record the block height of the block where the account status and/or contract status in the first account has been changed.
14. The device according to claim 13, wherein the device further comprises a processing unit;

    The processing unit is used for:

    Receiving 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;

    Determine the first high record according to the identifier of the second account and the identifier of the first high record of the second account; according to the identifier of the second account, the identifier of the second account data, The first block is high, and the second account data is determined;

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

    Obtain the second branch path for verifying 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 in the first block height record lower than the first block height;

    Send the first block of high records, the first branch path, the second account data, and the second branch path to the client, so that the client can record the first block of high records Verification with the second account data.
15. A device for data verification on a chain, which is characterized in that it comprises:

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

    The transceiver unit is further configured to receive the first block of high records, the first branch path, the second account data, and the second branch path returned by the blockchain node; the first block of high records and the second branch path The account data is determined by the blockchain node based on the identifier of the second account, the identifier of the second account data, and the first block height; the first branch path is determined by the blockchain node The branch path used to verify the first block of high records; the second branch path is the branch path determined by the blockchain node for verifying the second account data;

    The verification unit 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 block The block header of 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, after determining that the first block high record is correct, verify the root hash of the state tree in the block header of the locally stored second block according to the second branch path Whether the second account data is correct; the block header of the locally stored second block is obtained from the block chain node, and the second block is the second 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.
16. The device according to claim 15, wherein the verification unit is specifically configured to:

    Determine the first root hash according to the first block high record and the data of the leaf nodes and the 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.
17. The device according to claim 15, wherein the verification unit is specifically configured to:

    Determine 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.
18. The device according to claim 15, wherein the device further comprises a synchronization unit;

    The synchronization unit is used for:

    Sending a query request to the blockchain node;

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

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

    Receive the block header returned by the blockchain node, and store the received block header locally.
19. The apparatus according to claim 18, wherein the synchronization unit is further configured to: before storing the received block header locally:

    Acquiring N signature information in the received block header;

    According to the consensus node list, verify the N signature information; the consensus node list is a consensus node determined from 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 signature information passes the verification, it is determined that the received block header is correct.
20. The device according to claim 19, wherein the synchronization unit is specifically configured to:

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

    Judging the M consensus nodes in the consensus node list among the N consensus nodes;

    If M meets the preset condition, it is determined that the N signature information passes verification.
21. A computing device, which is characterized by comprising a processor, a memory, and a communication interface, wherein the processor, the memory and the communication interface are connected by a bus;

    The processor is configured to read the program in the memory, and execute the method described in any one of claims 1 to 4, or the method described in any one of claims 5 to 10;

    The memory is used to store one or more executable programs and store data used by the processor when performing operations.
22. A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to make the computer execute the method described in any one of claims 1 to 4 , Or the method of any one of claims 5 to 10.
23. A computer program product, characterized in that the computer program product includes a calculation program stored on a non-transitory computer-readable storage medium, the computer program includes program instructions, and when the program instructions are executed by a computer, The computer executes the method described in any one of claims 1 to 4, or the method described in any one of claims 5 to 10.

Images