CN110602148A

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

Info

Publication number: CN110602148A
Application number: CN201910960376.XA
Authority: CN
Inventors: 陈宇; 莫楠; 李辉忠; 张开翔; 范瑞彬
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2019-10-10
Filing date: 2019-10-10
Publication date: 2019-12-20
Anticipated expiration: 2039-10-10
Also published as: CN110602148B; CN113329031B; CN113329031A; WO2021068728A1

Abstract

The invention discloses a method and a device for generating a state tree of a block and verifying data on a chain, wherein the method for generating the state tree of the block comprises the following steps: determining, for any tile in the chain of tiles, a first account and first account data for the tile; the first account is an account of which the account data changes after each transaction in the block is executed, and the first account data is the changed account data in the first account after each transaction is executed; and constructing a state tree of the blocks formed by the first accounts and the first account data of the first accounts, and storing root hash of the state tree in block headers of the blocks, wherein the state tree is stored in a key-value pair mode. The technical scheme is used for simplifying the account data used for constructing the state tree on the block chain, so that the length of a branch path used for verification is shortened, and the efficiency of existence verification of the account data is improved.

Description

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

Technical Field

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

Background

With the development of computer technology, more and more technologies (such as BlockChain (BlockChain), cloud computing or big data) are applied in the financial field, the traditional financial industry is gradually shifting to financial technology, and the BlockChain technology is no exception, but due to the security and real-time requirements of the financial and payment industries, higher requirements are also put forward on the BlockChain technology.

In a state tree and a storage tree of an ether house (ethereum), if the existence of a contract state in the storage tree is verified, a branch path of the contract state in the storage tree needs to be determined first, whether the contract state exists in the corresponding storage tree is verified, then a branch path of an account state corresponding to the storage tree in the state tree is determined, and whether the account state exists in the corresponding state tree is verified.

However, as data on the block chain continuously grows, the branch path required to be acquired for verification by the block chain link point is long, and both the time for acquiring the branch path and the time for existence verification are long.

Disclosure of Invention

The embodiment of the invention provides a method and a device for generating a block state tree and verifying data on a chain, which are used for simplifying account data used for constructing the block state tree on the block chain, so that the length of a branch path used for verification is shortened, and the efficiency of existence verification of the account data is improved.

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

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

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

In the technical scheme, when the state tree is constructed, the state tree is generated only based on the account data modified or newly added in the current block transaction execution process, and is not generated based on the account data which is not changed and corresponds to the original block.

Optionally, the constructing a state tree of the block formed by the first accounts and the first account data of the first accounts includes:

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

According to the technical scheme, the key value is directly stored in a persistent mode, the hash of the key value is not stored in a persistent mode, account data under the same account can be guaranteed to have the same compression prefix, namely account identification or account address, the advantages of the Patricia Tree are effectively utilized, the level of the state Tree is compressed to the minimum, the storage space is reduced, and meanwhile the construction and verification efficiency of the branch path is accelerated.

Optionally, the first account data includes a block height record, an account status and/or a contract status that changes in the first account after execution of each transaction; the block height record is used for recording the block height of a block where the account state and/or the contract state in the first account are/is changed for each time.

In the technical scheme, the values in the leaf nodes of the state tree are moved down to be level with the values in the leaf nodes of the storage tree, and the state tree and the storage tree are combined into one tree, so that the hierarchical structure of account data is flattened, and the construction and verification efficiency of a branch path is improved. Furthermore, a key-value key value pair is added during the disk-down storage, wherein the key comprises an account identifier and an account data identifier, the account data identifier at the moment corresponds to a block height record, the value is the block height record, and the block height record is used for recording the block height of a block where the account data in the account corresponding to the account identifier is subjected to historical change.

Optionally, the method further includes:

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

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

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

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

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

In the technical scheme, the block link point returns two groups of data to the client according to a data acquisition request of the client, wherein the first group is a first block height record and a first branch path for verifying the first block height record, and the second group is a second account data and a second branch path for verifying the second account data, so that the client can respectively verify the first block height record and the second account data according to the two groups of data. Compared with the branch paths in the prior art, the first branch path and the second branch path are shorter, the required time of the blockchain node for obtaining the branch paths is shorter, and the required time of the client for verifying is shorter, so that the data verification efficiency of the client is improved.

In a second aspect, an embodiment of the present invention provides a method for verifying data on a chain, including:

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

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

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

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

In the technical scheme, the client sends a data acquisition request to the block chain link point, the block chain link point returns two groups of data to the client according to the data acquisition request of the client, the first group is a first block height record and a first branch path used for verifying the first block height record, and the second group is a second account data and a second branch path used for verifying the second account data, so that the client can verify the first block height record and the second account data respectively according to the two groups of data. Compared with the branch paths in the prior art, the first branch path and the second branch path are shorter, the required time of the blockchain node for obtaining the branch paths is shorter, and the required time of the client for verifying is shorter, so that the data verification efficiency of the client is improved.

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 locally stored first block includes:

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

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

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

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 chunk header of the locally stored second chunk includes:

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

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

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

Optionally, the method further includes:

sending a query request to the block nodes;

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

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

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

In the technical scheme, the client regularly removes the block head of the block chain node to obtain the latest block, so that the block head information of the block for verification is locally stored when the account data needs to be verified.

Optionally, before storing the received block header locally, the method further includes:

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

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

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

Optionally, the verifying the N signature information according to the consensus node list includes:

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

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

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

Through the method, the client verifies the block head information of the created block from the created block, and when the block head of one block is added, the block head of the currently added block is verified by combining the common identification node in the current common identification node list so as to ensure that the block head information of the locally stored block is correct, thereby ensuring the correctness of the root hash of the state tree in the block head for verifying the account data and further realizing the verification of the account data.

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

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

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

Optionally, the building unit is specifically configured to:

Optionally, the apparatus further comprises a processing unit;

the processing unit is configured to:

In a fourth aspect, an apparatus for on-chain data verification provided in an embodiment of the present invention includes:

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

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

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

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

Optionally, the verification unit is specifically configured to:

Optionally, the apparatus further comprises a synchronization unit;

the synchronization unit is configured to:

sending a query request to the block nodes;

Optionally, before the locally storing the received chunk header, the synchronization unit is further configured to:

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

Optionally, the synchronization unit is specifically configured to:

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

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

a memory for storing program instructions;

and the processor is used for calling the program instructions stored in the memory and executing the generation method of the state tree of the block according to the obtained program.

In a sixth aspect, an embodiment of the present invention further provides a computer-readable non-volatile storage medium, which includes computer-readable instructions, and when the computer-readable instructions are read and executed by a computer, the computer-readable instructions cause the computer to perform the method for generating the state tree of the block.

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

a memory for storing program instructions;

and the processor is used for calling the program instructions stored in the memory and executing the method for verifying the data on the chain according to the obtained program.

In an eighth aspect, the embodiments of the present invention further provide a computer-readable non-volatile storage medium, which includes computer-readable instructions, and when the computer-readable instructions are read and executed by a computer, the computer is caused to execute the above method for verifying the on-chain data.

Drawings

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

FIG. 1 is a schematic representation of a Merkle Tree;

FIG. 2 is a diagram of a state tree and a storage tree in an Etherhouse according to the prior art;

FIG. 3 is a diagram illustrating a state tree and a memory tree according to an embodiment of the present invention;

FIG. 4 is a diagram illustrating another state tree and a memory tree according to an embodiment of the present invention;

fig. 5 is a schematic diagram illustrating a flow of a method for generating a block status tree according to an embodiment of the present invention;

fig. 6 is a system architecture suitable for on-chain data verification according to an embodiment of the present invention;

FIG. 7 is a flowchart illustrating a method for on-chain data verification according to an embodiment of the present invention;

fig. 8 is a schematic diagram of a process of acquiring a block header by a client according to an embodiment of the present invention;

FIG. 9 is a block diagram of another system architecture for on-chain data verification according to an embodiment of the present invention;

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

fig. 11 is a schematic structural diagram of an apparatus for verifying data on a chain according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

For a better explanation of the invention, the terms of art to which the invention relates are explained as follows:

1. merkle Tree (Mercker Tree)

The Merkle Tree is a binary Tree consisting of leaf nodes, intermediate nodes and root nodes. The leaf node records the hash value of data (such as account data mentioned in the embodiment of the present invention), the intermediate node records the hash value calculated after two child nodes (the child nodes may be leaf nodes or other intermediate nodes) are combined, and the calculation method of the value recorded by the root node is similar to that of the value recorded by the intermediate node.

The Merkle Tree can be shown in fig. 1, and the construction process of the Merkle Tree from bottom to top is that D1-D7 are basic data (used for constructing leaf nodes), and H1-H7 record hash values of corresponding data (H1-H7 are leaf nodes). In the previous layer, H9 is an intermediate node, and values obtained by hashing the nodes H2 and H1 as inputs are recorded. And circularly repeating the calculation process, and finally calculating to obtain the hash value of the last node, wherein the node is a root node, and the recorded hash value is the hash value of the whole Merkle Tree.

2. Merkle certification

From the construction process of the Merkle Tree, it can be found that the data recorded by any leaf node is modified, the hash value of the leaf node is changed correspondingly, and the hash value of the root node is influenced finally. The hash value of the root node may thus serve as a unique digest of a set of data. Meanwhile, based on the Merkle Tree, the existence verification of certain data can be realized by providing a Merkle branch path of the data, and the verification is Merkle verification.

As shown in fig. 1, if the verifier wants to verify whether D2 exists in the Merkle Tree, the chunk link point may provide a Merkle branch path of D1-H10-H14, the verifier calculates hash values of D1 and D2 according to the branch path, then calculates hash values of H1 and H2, then calculates hash values of H10 and finally calculates hash values of H14, and if the obtained hash values are consistent with the hash values recorded in the root node, it indicates that D2 exists in the Merkle Tree.

2. Trie Tree (prefix Tree)

The Trie Tree is a search Tree, also called a Digital Tree. Unlike binary trees, key values of Trie trees are not stored by nodes in the Tree, but depend on their position in the Tree (i.e., the path from the root node to a particular node). All descendants of a node have the same prefix and are the character strings corresponding to the node (the root node corresponds to an empty character string). Only leaf nodes have corresponding stored values.

3. Patricia Tree (compressed prefix Tree)

A Patricia Tree is a more space-efficient prefix Tree, where a node is merged with its parent if it has no sibling.

4. Status tree and storage tree of ether house

As shown in fig. 2, the etherhouse includes a state Tree and a storage Tree, the state Tree may be a state MPT (which may be regarded as a Merkle Tree + Patricia Tree) or a state Merkle Tree, and the storage Tree may be a storage MPT or a storage MerkleTree.

The state tree is composed of ether house accounts, and the hash of the root node of the state tree is recorded in the state tree root (state root) field of each block header. A storage tree is a structure that holds data associated with an account, which is unique to a contract account, and all intelligent contract data is held in the storage tree in 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 value of the key-value data item is recorded by the state MPT or the leaf node storing the MPT, and the key code thereof is composed of the path of the MPT from the root node to the leaf node.

In the state tree and the storage tree of the ethernet, the presence verification of the Account data (including the Account status and the contract status) may still be performed based on the Merkle proof, taking fig. 2 as an example, if the presence of 27, which is one of the contract statuses, in the block 60 is to be verified, a branch path for verifying 27 needs to be determined in the storage tree, and whether the storage tree of Account 175 is configured according to the branch path verification 27, and a branch path for verifying Account 175 needs to be determined in the state tree, and whether Account 175 forms the state tree of the block 59 according to the branch path verification, that is, two Merkle proofs need to be performed.

But as the data of the blockchain grows, more extra space needs to be allocated on the chain to store the construction relationship of the tree. In addition, the increase in data on the chain also makes it more and more time consuming to provide branch paths and perform Merkle proofs externally.

In order to solve the above problem, embodiments of the present invention provide a new construction relationship between a state tree and a storage tree, where the state tree and the storage tree are only used for storing account data modified during the execution of a current block transaction, such as new account data or modified account data. An embodiment of the present invention provides a state tree and a storage tree, which are shown in fig. 3 and explained as follows in comparison with fig. 2:

as in the state tree and the storage tree of fig. 2, if the contract state of Account 175 is modified in the execution process of block 60, and 27 is changed to 45, the hash value in the parent node is determined based on the contract state 26 of the original Account 175 and the modified contract state 45, and the hash value of the root node of the constructed storage tree is stored in the storageoot field of Account 175 of block 60; and determining a hash value in the parent node based on the Account state of the original Account 174 and the Account state of the modified Account 175, and storing the hash value of the root node of the constructed state tree into a state root field of the block 60.

As in the state tree and the storage tree of fig. 3, the contract state of Account 175 is modified during the execution of block 60, and 27 is changed to 45, then the hash value in the parent node is determined based only on the modified contract state 45 of current Account 175, and 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; and determining a hash value in the parent node based on the modified Account state of the Account 175, and storing the hash value of the root node of the constructed state tree into a state root field of the block 60.

As can be seen from the above, the state tree and the storage tree in the embodiment of the present invention are generated only based on the account data modified or newly added in the transaction execution process of the current block, and are not generated based on the account data corresponding to the original block that has not changed. For example, 10000 accounts are used to construct the status tree corresponding to the block 60 in the prior art, but in the embodiment of the present invention, if only the account data of 1000 accounts is changed after all transactions in the block 60 are executed, the embodiment of the present invention only needs to use 1000 accounts to construct the status tree corresponding to the block 60, and the 1000 accounts construct respective storage trees based on the respective changed contract data, and the data volume of the embodiment of the present invention is reduced to 1/10 of the original data volume, so that the levels of the status tree and the storage tree can be greatly reduced.

In addition, in the state tree and the storage tree of the ether house, Merkle certification is adopted twice, the contract state is firstly certified in the storage tree, and then the account state is certified in the state tree. An embodiment of the present invention provides a new state tree as shown in fig. 4. The block corresponds to a state tree, leaf nodes of the state tree include an account state and a contract state, and the presence verification of the account data can be realized only by one Merkle proof in the mode, for example, if the presence of the contract state 27 in the block 60 needs to be verified, a branch path for verifying the contract state 27 needs to be acquired in the state tree, and whether the state tree of the block 60 is formed by the contract state 27 is verified according to the branch path.

In the embodiment of the invention, the key used for the disk-dropping storage can be defined as 'account number identification + account data identification + writing/modifying block height of the key-value', the value is the account data corresponding to the account data identification, and in addition, the account number identification can be understood as the account number address in the key; the account data identifier may be understood as a serial number of the data to be stored persistently, or an identifier of the data to be stored persistently, for example, if the account data is an account balance in the account status, the account data identifier may be "balance", for example, if the account data is a value in the contract status, the account data identifier may be a set serial number, for example, the identifier of the contract status 27 in fig. 4 is 2. The leaf node in the embodiment of the invention stores the hash value of the account data.

The state tree is constructed based on key-value, which may be a constructed state MPT, and the key value indicates a path from the root node to the leaf node in the MPT, as in fig. 4, key (0x234_ balance _60) is 100.

Considering that the status tree constructed by the embodiment of the present invention is constructed only based on changed account data of changed accounts, the construction method has a problem that it is impossible to prove the correctness of a non-existing data, which is equivalent to that whether account data of a status tree that does not form a certain block exists in the status tree of the block. For example, when the block height of the previous block chain is 100, and the account data of a certain account has changed only when the block height is 20, the correctness of the account data of the account can be verified only based on the status tree of the block height 20, but the correctness of the account data of the account cannot be verified based on the status tree of any block after the block height 20.

In order to solve the above problem, in the embodiment of the present invention, on the basis of storing the key-value key value pair, another group of key-value key value pairs is further added, where the key includes an account identifier and an account data identifier, the account data identifier at this time corresponds to a block height record, and the value is a block height record, and the block height record is used for recording the block height of a block where the account data in the account corresponding to the account identifier is located when the account data changes all the time.

For example, as in fig. 4, the current block height of the block chain is 60, 0x234_1 is the key stored persistently, 1 is the identification of the block height record, and 12-45-50 are the block height records of the record, it can be understood that account 0x234 is written at block height 12, and modified at block heights 45 and 50. Four key-value pairs as shown in table 1 are stored on the current block chain, wherein the first key-value pair is a block height record indicating the account 0x234, and the second to fourth key-value pairs are balance values indicating the account 0x234 when written or modified on the corresponding block height.

TABLE 1

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

By storing the key-value key value pair, the block height of the block where the account data corresponding to the account is located when the account data changes over time can be quickly determined, and the correctness of the data to be verified should be verified based on the state tree of which block is further determined, and a specific implementation manner can be described in detail below.

Based on the above description, fig. 5 exemplarily shows a flow of a method for generating a state tree of a block according to an embodiment of the present invention, where the flow may be performed by a device for generating a state tree of a block, and the device may be located in a block chain node, and may be a link point of the block.

In step 501, a block link point determines a first account and first account data of a block for any block in a block chain.

The first account is an account of which the account data changes after each transaction in the block is executed, and the first account data is the account data of which the account data changes after each transaction is executed.

In a specific implementation, the block link points determine accounts related to each transaction based on each transaction in the current block, and determine whether account data in the accounts related to each transaction changes, the account with changed account data is a first account, the changed account data is first account data, and one or more first account data may exist in one first account.

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

For another example, each transaction in the current block totally involves 100 accounts, and the number of accounts with changed account data is 98, then the number of the first accounts corresponding to the current block is 98, and each account of the 98 accounts corresponds to at least one changed account data. Here, one transaction or a plurality of transactions in the current block may cause the status data of a certain account not to change after the current block is executed.

At step 502, the block chain node builds a state tree of the block, which is composed of the first accounts and the first account data of the first accounts, and stores 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 building process, for any first account data of any first account, the identifier of the first account data and the block height of the block are used as key values, the first account data is used as value values of leaf nodes, and the state tree of the block is built based on the MPT mode.

In the embodiment of the present invention, the key value is directly stored persistently, instead of storing the hash of the key value persistently, and by this way, it can be ensured that the account data under the same account has the same compressed prefix, that is, the account id or the account address, as shown in fig. 4, the keys of all the account data of 0x234 have the same prefix, that is, 0x234, so that at least the keys of all the account data of 0x234 can be compressed by the common prefix of 0x 234. In the prior art, after hash calculation is performed on keys of all account data of 0x234, the number of common prefixes is reduced, and the level of forming the state tree is deep. Therefore, the embodiment of the invention can effectively utilize the advantages of the Patricia Tree, compress the hierarchy of the state Tree to the minimum, reduce the storage space and accelerate the construction and verification efficiency of the branch path.

Based on the above construction scheme of the state tree in the block chain node, an embodiment of the present invention further provides a method for verifying data on a chain, where the method is applicable to a system architecture as shown in fig. 6, and the system architecture may include a client and a block chain node. The client can be understood as a data user, and the block chain node can be understood as a data provider; a blockchain node is any blockchain node in the blockchain system that a client can access.

Fig. 7 is a flow of a method for verifying data on a chain according to an embodiment of the present invention, where the flow specifically includes:

in step 701, a client sends a data acquisition request to a block link node.

The data acquisition request includes an identification of the second account, an identification of the second account data, and the first block height, and the data acquisition request is used for indicating to acquire a value of the second account data of the second account on the first block height.

In step 702, the block link point determines a first block height record according to the identifier of the second account and the identifier of the first block height record of the second account.

After receiving a data acquisition request sent by a client, the blockchain node determines the first block high record according to the identifier of the second account and the identifier of the first block high record of the second account, for example, in table 1, if the identifier of the second account is 0x234 and the identifier of the first block high record of the second account is 1, the formed key is 0x234_1, and according to the persistently stored key-value key value pair, the value corresponding to the key being 0x234_1 is determined to be 12-45-50.

And step 703, determining the second account data by the block link point according to the identifier of the second account, the identifier of the second account data and the first block height.

The block chain node determines the second account data according to the identifier of the second account, the identifier of the second account data, and the first block height, as shown in table 1, if the first block height is 48, it is determined that the identifier of the second account is 0x234, and the identifier of the second account data is balance, the formed key is 0x234_ balance _45, and according to the persistently stored key-value pair, it is determined that the value corresponding to the key is 0x234_ balance _45 is 300.

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

In step 705, the blockchain node obtains a second branch path for verifying the second account data from the state tree of the second block.

In the embodiment of the present invention, the status tree of a certain block is constructed and only used for verifying the existence of the account data corresponding to the status tree of the block, so to verify the existence of the second account data, it is necessary to first determine the second block corresponding to the status tree where the second account data is located, and then determine the second branch path for verifying the second account data according to the status tree of the second block.

When determining the second block corresponding to the state tree in which the second account data is located, it is necessary to determine the block height record recorded when the account data of the second account is modified over time, that is, it is necessary to determine the first block height record, after determining the first block height record, a block corresponding to a highest block height among all block heights in the first block height record that are lower than the first block height may be used as the second block, the second block is used to record the account data of the second account that was modified last time before the first block height, and then a 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 high record, it is also necessary to determine a first block corresponding to the state tree where the first block high record is located, and then determine a first branch path for verifying the first block high record according to the state tree of the first block. Specifically, the first block may be a block corresponding to the highest block height in the first block height record.

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

In step 706, the block link point sends the first block height 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 height 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 client locally stores the block head of each block in the block chain, and is used for verifying the first block head record and the second account data according to the information in the corresponding block head after receiving the first block head record, the first branch path, the second account data and the second branch path sent by the block chain node.

In one implementation, the client may periodically remove the block link point to obtain the block header of the latest block, and in another implementation, the client may remove the block link node to obtain the latest block when the client needs to verify the received data. The former can be specifically accomplished by client and block chain node interaction as shown in fig. 8.

Step 801, a client sends a query request to a block link node;

step 802, a block chain node sends the current block height of a block chain to a client;

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

step 804, the client sends a block head acquisition request to the block link points;

step 805, determining a block head to be acquired by the client by using the block link points;

step 806, the block chain node sends the block head to be acquired 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 steps 801 to 807, a client sends an inquiry request to a block link point, after receiving the inquiry request, the block link point feeds back a current block height on a current block chain to the client, and the client receives an inquiry result including the current block height and is used for judging whether a block head needs to be synchronized to the block link point according to the inquiry result.

For example, if the current block height of the block chain node is 100, and the highest block height of the block header locally stored at the client is 98, the client determines that the block headers of the 99 th and 100 th blocks need to be acquired from the block chain node, and the client sends a block header acquisition request to the block chain node, where the block header acquisition request includes the block heights of the block headers to be acquired as 99 and 100.

In the implementation manner, the client regularly removes the block head of the latest block from the block link point, so that the block head information of the block for verification is locally stored when the account data needs to be verified.

As can be seen from the above, the client may determine 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 locally stored first block. Here, the first chunk stored locally by the client is also the chunk corresponding to the highest chunk height in the first chunk height record acquired by the client from the chunk chain node.

In the specific verification process, the client determines a first root hash according to the first block height record and the data of the leaf node and the branch node in the first branch path, and if the client determines that the first root hash is equal to the root hash of the state tree in the block head of the first block stored locally, the client determines that the first block height record is correct.

In step 708, after determining that the first block height record is correct, the client verifies whether the second account data is correct according to the second branch path and the root hash of the state tree in the block header of the locally stored second block.

The client firstly judges whether the first block height record is correct, and if so, the correctness of the second account data can be verified further according to a second branch path and the root hash of a state tree in a block head of a locally stored second block, wherein the block head of the locally stored second block of the client is obtained from a block chain node, the second block is a block corresponding to the second block height on the block chain, and the second block height is the highest block height in all block heights lower than the first block height in the first block height record.

In a specific verification process, the client may determine the second root hash according to the second account data and the data of the leaf node and the branch node in the second branch path, and if the client determines that 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 determines that the second account data is correct.

It should be noted that, although the client side obtains the first block height record and the second account data first, and verifies the first block height record based on the first block and verifies the second account data based on the second block, the client side may also obtain the first block height record first, and verify the first block height record based on the first block, and then obtain the second account data after the first block height record passes verification, and verify the second account data based on the second block in the embodiment of the present invention.

It should be noted that, since the client verifies the first chunk-high record based on the root hash of the state tree of the chunk header of the first chunk stored locally and verifies the second account data based on the root hash of the state tree of the chunk header of the second chunk stored locally, the client first needs to determine that the chunk header information stored locally is correct.

In order to prove the correctness of information in the block header, in the specific implementation, a signature list of a link node for the block header is added in the block header, after the client acquires the block header, the correctness of the block header is verified according to the signature list in the block header, specifically, before the client stores the received block header locally, the client acquires N pieces of signature information in the received block header, verifies the N pieces of signature information according to a local common identification node list, and if the N pieces of signature information pass the verification, the correctness of the received block header is determined. Here, the common node list is a list of common nodes determined by the client according to a block header in a created block of the block chain to a block header immediately before the received block header, and if the current block header acquired by the client is a block header of a 100 th block, the client needs to verify the signature information of the current block header according to the common node list determined by the block headers of the 0 th block (created block) to the 99 th block.

To explain, the common nodes in the common node list are determined in the creation block of the block chain, and may be changed in the subsequent block transaction, for example, A, B, C, D is determined in the creation block; when the number of the blocks is from 0 to 49, the common nodes in the common node list in the block head are not changed; in the 50 th block, adding a consensus node E to the consensus node list after the transaction in the block is executed, wherein A, B, C, D, E are consensus nodes in the consensus node list; the common nodes in the common node list are not changed from the 50 th block to the 99 th block; therefore, when verifying N signature messages in the 100 th chunk header, the client may verify the N signature messages according to the consensus node list determined by the chunk headers of the 0 th chunk to the 99 th chunk.

In the above embodiment, although the consensus node list is determined according to the block headers of the 0 th block to the 99 th block, when verifying the signature information in the block header of the 100 th block, it is sufficient to directly verify the consensus node list in the block header of the 99 th block by using the consensus node list in the block header of the 99 th block, because the block header of the 99 th block has been verified by the consensus node list in the block header of the 98 th block, the block header of the 98 th block has been verified by the consensus node list in the block header of the 97 th block, and so on, the block header of the 2 nd block has been verified by the consensus node list in the block header of the 1 st block, and the block header of the 1 st block has been verified by the consensus node list in the block header of the 0 th block.

In addition, if the common node in the common node list changes after the transaction of the current block is executed, it is equivalent to a certain contract data change, and it is necessary to verify the correctness of the contract data by using the state tree root hash of the block header of the current block, and to verify the signature information in the block header of the current block by using the common node list of the block header of the previous block, which is equivalent to verify the correctness of the state tree root hash in the block header of the current block by using the common node list of the block header of the previous block. Still by way of example, if a consensus node E is added to the consensus node list after the transaction in the 50 th block is executed, the contract data of the state tree corresponding to the 50 th block changes, and if some contract data (representing the consensus node E) is added, it is necessary to verify the existence of the added contract data by using the root hash of the state tree in the 50 th block, and verify the block header information of the 50 th block by using the consensus node list of the 49 th block, that is, verify the root hash of the state tree in the block header of the 50 th block.

In the specific verification process, the client determines N consensus nodes corresponding to the N signature information, and determines M consensus nodes in a consensus node list among the N consensus nodes, and if M meets a preset condition, determines that the N signature information passes verification. M accords with the preset condition, which means that the number of M accords with the preset threshold value, and the preset threshold value can take different values under the condition of different consensus algorithms. In one implementation, a PBFT (physical Byzantine Fault Tolerance) consensus algorithm is adopted, the preset threshold is f +1, and when the number of consensus nodes is greater than or equal to f +1, the block header information of the block passes verification, where f is (N-1)/3. In another implementation, a POW (Proof of Work) consensus algorithm is used, the preset threshold is N/2+1, and when the number of consensus nodes is greater than or equal to N/2+1, the block header information representing the block passes verification, where N is the number of consensus nodes in the consensus list.

In addition, the client needs to verify the correctness of the created block information, and when the client verifies that the created block information of a specific number of the common nodes on the block chain is consistent, the created block is approved. The specific number here may be the above-mentioned preset threshold.

As can be seen from the above, when the client verifies certain account data, the verification flow is creating block → consensus node → block header information → status tree root hash → account data, that is, creating block verifies consensus node, consensus node verifies block header information, block header information verifies status tree root hash, and status tree root hash verifies account data. Moreover, when the state tree is constructed, based on the one-way property of hash calculation, once the leaf node (account data) is modified, the root hash of the state tree is changed, that is, the non-modification property of the account data is further ensured. In addition, the information of the related verification points is provided by the nodes on the chain, and for the alliance chain with the admission concept, the nodes on the chain need to be authenticated before providing the information for the client, so that the accuracy of data verification is further guaranteed.

To better explain the embodiments of the present invention, a complete on-chain data validation example is provided below in conjunction with table 1, as follows:

the client requests to acquire balance of an account 0x234 on a block with a block height of 48 from a block link point, the block link point determines a first block height record 12-45-50 according to 0x234_1, and the block link point determines a first branch path for verifying the first block height record 12-45-50 according to a state tree of the first block with the block height of 50; and the block chain node determines that the block height which is smaller than the block height 48 and is the largest block height is 45 in the first block height record according to the first block height records 12-45-50 and the block height 48, the block chain node determines that the balance is 300 according to 0x234_ balance _45, and determines a second branch path for verifying the balance 300 according to the state tree of a second block with the block height of 45. The block link point sends the first block height record 12-45-50, the first branch path, the balance 300 and the second branch path to the client side, the client side verifies the correctness of the first block height record 12-45-50 by combining the first branch path according to the block head of the first block of the block height 50 stored locally, the balance is determined to be modified at the 45 block position based on the verified first block height record 12-45-50, and the block head of the second block of the block height 45 stored locally is used to verify the correctness of the balance 300 by combining the verification of the second branch path. In conjunction with the above process, the client completes the process of querying and verifying balance 300 for account 0x234 on the block of block height 48.

It should be noted that the client in fig. 6 may also be a block link point of a different alliance chain from the block link point, as in fig. 9, a first block link node and a second block link node may be included; the first blockchain node can be understood as a data user, and the second blockchain node can be understood as a data provider; the first and second block link nodes belong to different federation chains.

Based on the same inventive concept, fig. 10 exemplarily shows a structure of an apparatus for generating a state tree of a block, which may perform a flow of a method for generating a state tree of a block according to an embodiment of the present invention.

The device includes:

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

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

Optionally, the constructing unit 1002 is specifically configured to:

Optionally, the apparatus further comprises a processing unit 1003;

the processing unit 1003 is configured to:

Based on the same inventive concept, fig. 11 exemplarily shows a structure of an apparatus for on-chain data verification according to an embodiment of the present invention, and the apparatus can perform a flow of a method for on-chain data verification.

The device includes:

a transceiving unit 1101 configured to send a data acquisition request to a block link point; the data acquisition request comprises an identifier of a second account, an identifier of second account data and a first block height;

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

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

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

Optionally, the verification unit 1102 is specifically configured to:

Optionally, the apparatus further comprises a synchronization unit 1103;

the synchronization unit 1103 is configured to:

sending a query request to the block nodes;

Optionally, before the locally storing the received tile header, the synchronization unit 1103 is further configured to:

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

Optionally, the synchronization unit 1103 is specifically configured to:

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

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

a memory for storing program instructions;

Based on the same inventive concept, an embodiment of the present invention further provides a computer-readable non-volatile storage medium, which includes computer-readable instructions, and when the computer reads and executes the computer-readable instructions, the computer is caused to execute the method for generating the state tree of the block.

a memory for storing program instructions;

Based on the same inventive concept, the embodiment of the present invention further provides a computer-readable non-volatile storage medium, which includes computer-readable instructions, and when the computer reads and executes the computer-readable instructions, the computer is enabled to execute the above method for verifying the data on the chain.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

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

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

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

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

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

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

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

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

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

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

sending a query request to the block nodes;

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

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

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

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

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

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

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

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

the processing unit is configured to:

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

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

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

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

the synchronization unit is configured to:

sending a query request to the block nodes;

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

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

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

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

21. A computing device, comprising:

a memory for storing program instructions;

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

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

23. A computing device, comprising:

a memory for storing program instructions;

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

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