CN111177225A

CN111177225A - Account state existence proving method and device and state inquiring method and device

Info

Publication number: CN111177225A
Application number: CN202010002574.8A
Authority: CN
Inventors: 林鹏; 陆钟豪; 陈锐
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-01-02
Filing date: 2020-01-02
Publication date: 2020-05-19
Anticipated expiration: 2040-01-02
Also published as: CN111177225B; WO2021135756A1

Abstract

The disclosure relates to an account state existence proving method and device and a state inquiring method and device. The account state existence proving method comprises the following steps: receiving account status data of accounts to be certified on a target block from block link points; and performing presence attestation on the account status of the account to be attested based on the received account status data. The account state data comprises node information of each node on an account state query path in the state tree, the nodes comprise non-leaf nodes and leaf nodes, the node information of the non-leaf nodes comprises the node data of the node and hash value indication information of a next node of the node, the node information of the leaf nodes comprises the node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information of the account to be proved.

Description

Account state existence proving method and device and state inquiring method and device

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to an account status existence proving method and apparatus and a status querying method and apparatus.

Background

In blockchains, the latest global account State is called world State. World states consist of the state of individual accounts. The status of each account includes information such as account address (i.e., account number) balance. The states are typically stored on the blocks in a state tree structure, which stores world states in a tree data structure. The client may request proof of account status presence under a certain tile from tile chain nodes. Presence attestation refers to verifying whether an account number exists on a block.

Disclosure of Invention

In view of the above, the present disclosure provides an account status existence proving method and apparatus, and a status querying method and apparatus. By using the method and the device, the existence certification can be realized without depending on the decoding operation of each node on the query path when the account existence certification is carried out, and the method and the device can be suitable for state trees with various structures and have strong compatibility.

According to one aspect of the present disclosure, there is provided a method of presence attestation of account status on a target tile, comprising: receiving account status data of an account to be certified on a target block from a block node, the account status data being queried by the block node from a status tree of the target block in response to an account status query request sent by a client; and performing presence attestation on the account status of the account to be attested based on the received account status data. The account state data comprises node information of each node on an account state query path in the state tree, the nodes comprise non-leaf nodes and leaf nodes, the node information of the non-leaf nodes comprises the node data of the node and hash value indication information of a next node of the node, the node information of the leaf nodes comprises the node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information of the account to be proved.

Optionally, in one example, performing presence attestation on account status of the account to be attested based on the received account status data may include: determining whether a root node in the query path is correct based on the state root stored in the target block and node data of the root node in the query path; when the root node is determined to be correct, determining whether the query path is correct or not based on the node information of each node; and when the query path is determined to be correct, determining the existence of the account state of the account to be proved based on account information in the state entity indicated by the state entity indication information of the leaf node and account information of the account to be proved at the client.

Optionally, in an example, before determining the existence of the account status of the account to be certified based on the account information in the status entity indicated by the status entity indication information of the leaf node and the account information of the account to be certified at the client, performing the existence certification of the account status of the account to be certified based on the received account status data may further include: and when the query path is determined to be correct, decoding the state entity indicated by the state entity indication information to obtain account information in the state entity.

Optionally, in an example, the account status data may further include a status root of the target block, and determining whether the root node of the query path is correct based on the status root stored in the target block and the node data of the root node in the query path may include: acquiring a state root of the target block from a block chain; determining whether the state root in the state account data is correct or not based on the state root acquired from the block chain; and when the state root in the state account number data is determined to be correct, determining whether the root node is correct or not based on the state root in the account state data and the node data of the root node.

Optionally, in an example, determining whether the query path is correct based on the node information of each node may include: for each query link in the query path, determining whether the query link is correct or not based on hash indication information for a next node in node information of a starting node in the query link and node data in the node information of the next node, wherein each query link comprises two adjacent nodes; and determining that the query path is correct when all query links in the query path are determined to be correct.

Optionally, in an example, for each query link in the query path, determining whether the query link is correct based on the hash indication information for the next node in the node information of the start node in the query link and the node data in the node information of the next node may include: acquiring a first hash value of a next node based on hash value indication information for the next node in the node information of the start node; performing hash processing on node data in the node information of the next node to obtain a second hash value of the next node; and determining that the query link is correct when the first hash value and the second hash value of the next node are equal.

Optionally, in an example, the hash value indication information of the next node may be a storage index of the first hash value of the next node in the node data of the start node.

Optionally, in an example, the account status data may further include a block number of the target block, and the status root of the target block may be obtained from the block chain based on the block number.

According to another aspect of the present disclosure, there is also provided a block chaining status query method, including: receiving a state query request of a client for the account state to be queried, wherein the state query request comprises a block number of a target block; responding to the state query request, and querying the account state to be queried from the state tree of the target block based on the block number to obtain account state data; and sending the account status data to the client. The account state data comprises node information of each node on an account state query path in the state tree, the nodes comprise non-leaf nodes and leaf nodes, the node information of the non-leaf nodes comprises the node data of the node and hash value indication information of a next node of the node, the node information of the leaf nodes comprises the node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information of the account to be proved.

Optionally, in an example, the status query data may further include a status root of the target block.

Optionally, in an example, the status query data may further include a block number of the target block.

According to another aspect of the present disclosure, there is also provided an apparatus for presence attestation of account status on a target block, comprising: a status data receiving unit configured to receive account status data of an account to be certified on a target block from a block chain node, the account status data being queried by the block chain node from a status tree of the target block in response to an account status query request sent by a client; and a presence attestation performing unit configured to perform presence attestation on the account status of the account to be attested based on the received account status data. The account state data comprises node information of each node on an account state query path in the state tree, the nodes comprise non-leaf nodes and leaf nodes, the node information of the non-leaf nodes comprises the node data of the node and hash value indication information of a next node of the node, the node information of the leaf nodes comprises the node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information of the account to be proved.

Optionally, in an example, the presence attestation performing unit includes: a root node verification module configured to determine whether a root node in the query path is correct based on a state root stored in the target tile and node data of the root node in the query path; a path verification module configured to determine whether the query path is correct based on node information of the respective nodes when the root node is determined to be correct; and the state verification module is configured to determine the existence of the account state of the account to be proved based on account information in the state entity indicated by the state entity indication information of the leaf node and account information of the account to be proved at the client when the query path is determined to be correct.

Optionally, in an example, the presence attestation performing may further include: and the state entity decoding module is configured to decode the state entity indicated by the state entity indication information to obtain the account information in the state entity before determining the existence of the account state of the account to be proved based on the account information in the state entity indicated by the state entity indication information of the leaf node and the account information of the account to be proved at the client.

Optionally, in an example, the account status data may further include a status root of the target block, and the root node verification module may include: the state root acquisition submodule is configured to acquire a state root of the target from a blockchain; the state root verification submodule is configured to determine whether a state root in the state account data is correct or not based on the state root acquired from the block chain; and a root node verification sub-module configured to determine whether the root node is correct based on the state root in the account state data and the node data of the root node when the state root in the state account number data is determined to be correct.

Optionally, in an example, the path verification module may include: a query link verification sub-module configured to determine, for each query link in the query path, whether the query link is correct based on hash indication information for a next node in node information of a start node in the query link and node data in the node information of the next node, where each query link includes two adjacent nodes; and a path verification sub-module configured to determine that the query path is correct when all query links in the query path are determined to be correct.

Optionally, in an example, the query link verification sub-module may include: a first hash value determination submodule configured to acquire a first hash value of a next node based on hash value indication information for the next node in the node information of the start node; a second hash value determination submodule configured to perform hash processing on node data in the node information of the next node to obtain a second hash value of the next node; and a link verification sub-module configured to determine that the query link is correct when the first hash value and the second hash value of the next node are equal.

According to another aspect of the present disclosure, there is also provided an account status query apparatus, including: the query request receiving unit is configured to receive a state query request of a client for the account state to be queried, wherein the state query request comprises a block number of a target block; a status query unit configured to query the account status to be queried from the status tree of the target block based on the block number in response to the status query request to obtain account status data; and a query data sending unit configured to send the account status data to the client. The account state data comprises node information of each node on an account state query path in the state tree, the nodes comprise non-leaf nodes and leaf nodes, the node information of the non-leaf nodes comprises the node data of the node and hash value indication information of a next node of the node, the node information of the leaf nodes comprises the node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information of the account to be proved.

According to another aspect of the present disclosure, there is also provided a computing device comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the account state presence attestation method as described above.

According to another aspect of the present disclosure, there is also provided a non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the account state presence attestation method as described above.

According to another aspect of the present disclosure, there is also provided a computing device comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the state query method as described above.

According to another aspect of the present disclosure, there is also provided a non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the state query method as described above.

By using the method and the device disclosed by the invention, the data returned by the block chain nodes comprise the node data of each node in the query path and the hash value indication information of the next node, the existence of the account state is proved based on the data, and each node in the query path does not need to be decoded, so that the efficiency can be improved. In addition, the existence proving scheme can be suitable for state trees with various structures, and therefore compatibility is strong.

By using the method and the device disclosed by the invention, when the verification results of the root node of the query path and the query path are correct, the existence of the account state is verified based on the account information in the state entity and the account information of the account to be proved at the client, and when the verification results of the root node or the query path are incorrect, the execution is not required to be continued, so that the efficiency of the existence certification can be realized.

By using the method and the device disclosed by the invention, the account state data comprises the state root of the target block, and the client can verify whether the root node is correct or not based on the received state root and the node data of the root node when verifying that the received state root is correct, thereby providing a redundant verification method.

By using the method and the device disclosed by the invention, the query link formed by every two adjacent nodes in the query path is verified, and the query path is determined to be correct when each link is verified to be correct, so that the efficiency and the accuracy of verifying the query path can be improved.

By using the method and the device disclosed by the invention, the hash value indication information of the next node in the node information is the storage index of the hash value of the next node in the node, so that the data transmission capacity can be reduced, and the resources consumed by data transmission can be saved.

By using the method and the device disclosed by the invention, the client can acquire the state root of the target block from the block chain based on the received block number by enabling the state query data to comprise the block number of the target block, so that the client does not need to access a local storage space to acquire the block number of the target block when acquiring the state root of the target block from the block chain, and the local storage of the block number is not required.

Drawings

A further understanding of the nature and advantages of the present disclosure may be realized by reference to the following drawings. In the drawings, similar components or features may have the same reference numerals. The accompanying drawings, which are included to provide a further understanding of the embodiments of the disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the detailed description serve to explain the embodiments of the disclosure without limiting the embodiments of the disclosure. In the drawings:

FIG. 1 is a flow diagram of an example of an application of an account status presence attestation method and an account status inquiry method according to one embodiment of the present disclosure;

FIG. 2 is a schematic diagram illustrating query paths in a state tree;

FIG. 3 is a flow diagram of a presence attestation execution process in an account status presence attestation method, according to one embodiment of the present disclosure;

FIG. 4 is a flow diagram of a root node verification process in an account state presence attestation method, according to one embodiment of the present disclosure;

FIG. 5 is a flow diagram of a path verification process in an account status presence attestation method, according to one embodiment of the present disclosure;

FIG. 6 is a flow diagram of a query link verification process in an account status presence attestation method, according to one embodiment of the present disclosure;

FIG. 7 is a block diagram of an account status presence attestation apparatus, in accordance with one embodiment of the present disclosure;

fig. 8 is a block diagram showing the configuration of an example of a presence proving execution unit in the account status presence proving apparatus shown in fig. 7;

FIG. 9 is a block diagram of an example of a root node validation module shown in FIG. 8;

FIG. 10 is a block diagram of an example of the query path verification module shown in FIG. 8;

FIG. 11 is a block diagram of an example of the query link validation submodule shown in FIG. 10;

FIG. 12 is a block diagram of an account status query device according to one embodiment of the present disclosure;

FIG. 13 is a block diagram of a computing device for implementing an account status presence attestation method, in accordance with one embodiment of the present disclosure; and

FIG. 14 is a block diagram of a computing device for implementing an account status query method according to one embodiment of the present disclosure.

Detailed Description

The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

As used herein, the term "coupled" means either a direct mechanical, communication, or electrical connection between the two components, or an indirect mechanical, communication, or electrical connection through intermediate components. The term "electrically connected" means that electrical communication can be made between two components for data/information exchange. Likewise, the electrical connection may refer to a direct electrical connection between two components, or an indirect electrical connection through an intermediate component. The electrical connection may be achieved in a wired manner or a wireless manner.

An account status presence proving method and apparatus and an account status inquiring method and apparatus of the present disclosure will now be described with reference to the accompanying drawings.

In the present disclosure, a client may be an SPV node in a blockchain system, a blockchain node refers to a full-scale blockchain node. The SPV node does not download all the blockchain data when performing transaction verification, but only downloads the block headers of each block in the blockchain, and the blockchain composed of the block headers does not contain specific transaction data. The block header of each block includes the state root of the block. The state root refers to the hash value of the root node of the state tree on each chunk. The SPV node performs transaction verification on the unverified transaction associated with the node, which is SPV verification (simple transaction payment verification). A full blockchain node is a node that owns not only the block header but also all the transaction data of the blockchain.

When a transaction related to the SPV node occurs, the SPV node sends a status query request to the full volume blockchain node to query the account status related to the transaction to be verified. And the full-volume block chain node responds to the state query request and returns a query result aiming at the corresponding account state to the SPV node. The SPV node may perform SPV verification based on the received query results.

SPV verification is generally divided into two processes, one of which is a presence attestation process and the other of which is a state correctness attestation. The following implementations of the present disclosure are applicable to the presence attestation process in SPV verification. Presence attestation refers to attestation that the transaction to be authenticated is present on the corresponding block. The process of verifying a transaction corresponds to the process of verifying the status of an account associated with the transaction.

In addition to performing SPV verification on a transaction to be verified, the present disclosure may also be applicable to performing presence attestation on a queried account status when a client queries the account status associated with the client. When a client queries for relevant account status, presence attestation of the account status is also required.

In this specification, the term "node" refers to each data node in the state tree.

Fig. 1 is a flowchart of an application example of an account status presence proving method and an account status inquiring method according to one embodiment of the present disclosure. In this example, the account status presence attestation method is performed by the client and the account status inquiry method is performed by the block link point.

As shown in fig. 1, at block 120, the client sends a status query request to the block chaining point, the status query request including the block number of the target block. When the client wants to query the corresponding account status on a block, the block is the target block. The queried account is the account to be certified. For example, the account to be certified may be an account to which the transaction to be verified corresponds.

After the block chain node receives the status query request, at block 140, the account status to be queried is queried from the status tree of the target block based on the block number in the status query request to obtain account status data.

The account status data includes node information for each node on the account status query path in the status tree, the nodes including non-leaf nodes and leaf nodes. The node information of the non-leaf node includes node data of the node and hash value indication information of a node next to the node. The node information of the leaf node comprises node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information (namely an account address) of the account to be proved. The state entity may also include information such as account Balance (Balance), Recovery Key (Recovery Key), random number (Nonce), and the like.

Fig. 2 is a schematic diagram for explaining a query path in a state tree. Fig. 2 illustrates the structure of the state tree by taking the MPT tree as an example. As shown in fig. 2, the root node is the topmost node (node a) in the state tree, and the leaf nodes are the bottommost nodes (nodes D1 to D8) in the state tree. In the present disclosure, the nodes between the root node and the leaf nodes are referred to as intermediate nodes (nodes B1-B2, C1-C4). The MPT tree on each tile stores the world state (i.e., all account states) of the tile chain until the tile is generated, with the respective account states being stored in state entities in the leaf nodes.

If the account status of the account to be certified is stored at leaf node D1, the query path for that account status is A-B1-C1-D1.

The hash value indication information of the next node may be a hash value of the next node. In another example, the hash indication information of the next node may be a storage index of the hash value of the next node in the node. In the state tree, for each node, the node data of the node includes the hash value of the node next to the node. Taking FIG. 2 as an example, the hash values for nodes B1 and B2 are stored in the node data for node A, and the hash values for nodes C1 and C2 are stored in the node data for node B1. In this example, in the query path A-B1-C1-D1, the node information for node A may include the node data for node A, the start index and the end index of the hash value for node B1 in the node data for node A. Thus, the hash value of node B1 may be extracted from the node data of node a based on the start index and the end index.

The hash value occupies a large data space, and the data space occupied by the storage index is obviously smaller than the hash value, so that when the prompt information of the hash value is the storage index, the resources occupied by data transmission can be obviously reduced.

As an example, the field of the account status data may be StateProof < State _ Node [ ] >, which refers to a set of Node information for each Node on the query path. For query path A-B1-C1-D1, State _ Node [ ] is the Node information that includes State _ Node [0] (Node information for Node A), State _ Node [1] (Node information for Node B1), State _ Node [2] (Node information for Node C1), State _ Node [3] (Node D1). The node information field of each non-leaf node (A-C1) may be StateNode < data, next _ key _ begin _ index, next _ key _ end _ index >, data being the node data of the node, next _ key _ begin _ index being the start index of the hash value of the node next to the node in data, and next _ key _ end _ index being the end index of the hash value of the node next to the node in data. The field between the start index and the end index in the data is the hash value of the next node. The "next node" of a node refers to the node next to the node in the corresponding query path, e.g., the node next to node B1 is node C1 and the node next to node C1 is node D1.

In addition, the status entity indication information in the node information of the leaf node D1 may be a storage index of the status entity in the node information of the leaf node, or may be the status entity itself. When the status entity indication information is a storage index, the node information field of the leaf node D1 may be stateenode < data, begin _ index, end _ index >, data being the node data of the leaf node D1, begin _ index being the start index of the status entity in the data of the node D1, and end _ index being the end index of the status entity in the data of the node D1. The field between the start index and the end index is a state entity.

When the corresponding account status is queried, the block link point sends the queried account status data to the client at block 160.

After receiving the account status data sent by the blockchain node, the client performs presence attestation on the account status of the account to be attested at block 180 based on the received account status data.

Next, the presence proving execution process is explained with reference to fig. 3 to 6.

Fig. 3 is a flow diagram of a presence attestation execution process in an account status presence attestation method, according to one embodiment of the present disclosure.

As shown in FIG. 3, at blocks 302 and 304, a determination is made as to whether the root node in the query path is correct based on the state root stored in the target tile and the node data of the root node in the query path.

The client may locally store the account status on which block it wants to query, and then may obtain the status root of the corresponding block from the downloaded blockhead chain based on the block number of the target block stored locally. In one example, the account status data returned to the client by the chunk link point may include the chunk number of the target chunk. At this time, the fields of the account status data may be StateProof < block _ NUM, state _ node [ ] >, block _ NUM being the block number of the target block. In this example, the status root of the target block may be queried from the chain of block headers based on the block number in the account status data. Thus, the client does not need to access the local storage space or perform other operations to obtain the block number.

After the state root of the target block is obtained, hash operation may be performed on the node data of the root node to obtain a hash value of the root node. The algorithm of the hash operation employed in the present disclosure is consistent with the algorithm used when generating the state tree on the corresponding blockchain. For example, if the SHA256 algorithm is used in generating the state tree, then the SHA256 algorithm is also used in the presence attestation process.

Then, whether the hash value of the root node obtained by the operation is consistent with the state root of the target block acquired from the block chain or not can be compared, and if so, the root node is correct. If the comparison result is inconsistent, the root node of the query path is incorrect.

When the root node is determined to be correct, it is determined whether the query path is correct based on node information of the respective nodes at

blocks

306 and 308. When both the root node and the query path are correct, it may be determined that a query path exists for the account status to be queried. An example of validating the query path will be described later with reference to fig. 5.

When the query path is determined to be correct, at block 310, the status entity indicated by the status entity indication information is decoded to derive account information in the status entity when the query path is determined to be correct. Sometimes, the account information in the status entity is not the information itself, but the information itself is encoded by a specific encoding method (e.g. RLP encoding). In this case, the state entity needs to be decoded, for example, when the state entity is encoded with RLP encoding, it can be decoded with a corresponding decoding method. After decoding, the information of the state information can be obtained, and then the account information can be obtained.

The decoding operation of block 310 may not be performed if the state entity is not encoded. Thus, the operation of block 310 is not essential.

Next, at block 312, the existence of the account status of the account to be certified is determined based on the account information in the status entity indicated by the status entity indication information of the leaf node and the account information of the account to be certified at the client.

If the account number information in the status entity is consistent with the account number information (account number address) of the account to be certified at the client, it can be determined that the account status of the account to be certified is present in the target block.

And if the verification result of the root node is incorrect, or the verification result of the query path is incorrect, or the account number information in the state entity is inconsistent with the account number information existing at the client, indicating that the account state to be proved does not exist on the target block.

In one example, the account status data sent by the tile chain node to the client may also include the status root of the target tile. At this time, the field of the account status data may be stateprof < state _ root, state _ node [ ] > or stateprof < block _ NUM, state _ root, state _ node [ ] >, and state _ root is the status root of the target block. In this example, the example shown in FIG. 4 may be employed to verify the root node. Fig. 4 is a flow diagram of a root node verification process in an account state presence attestation method, according to one embodiment of the present disclosure.

As shown in fig. 4, in block 402, a status root of a target block is obtained from a blockchain. As described above, the status root of the target block can be queried from the downloaded block header chain based on the block number of the target block.

After obtaining the state root from the blockchain, at blocks 404 and 406, a determination is made as to whether the state root in the state account data is correct based on the state root obtained from the blockchain. When the status root obtained from the blockchain is consistent with the status root in the account status data, the status root in the account status data can be determined to be correct.

When the state root in the account state data is correct, at block 408, a determination is made as to whether the root node is correct based on the state root in the account state data and the node data of the root node. If the status root in the account status data is incorrect, it indicates that the account status does not exist. At which point it may not be necessary to continue with the subsequent operations.

Fig. 5 is a flow diagram of a path verification process in an account status presence attestation method, according to one embodiment of the present disclosure.

As shown in fig. 5, at block 502, for each query link in the query path, it is determined whether the query link is correct based on the hash indication information for the next node in the node information of the start node in the query link and the node data in the node information of the next node. Each query link includes two nodes that are adjacent.

As shown in FIG. 2, the query path A-B1-C1-D1 comprises three query links A-B1, B1-C1 and C1-D1. Node a, node B1, and node C1 are the starting nodes of the respective query links, and node B1, node C1, and node D1 are the ending nodes of the respective query links, or the next nodes that can be referred to as node a, node B1, and node C1, respectively. As an example, for the query link a-B1, whether the query link a-B1 is correct may be determined based on node data of the node information of node a for the hash value indication information of node B1 and the node information of node B1.

The examples shown in fig. 6 may be used to determine whether the respective query links are correct. Fig. 6 is a flow diagram of a query link verification process in an account status presence attestation method, according to one embodiment of the present disclosure.

As shown in fig. 6, at block 602, a first hash value of a next node is obtained based on hash value indication information for the next node in node information of a start node in a query link. If the hash value indication information is the hash value itself, the first hash value of the next node may be read from the account status data. If the hash value indication information is a storage index, the first hash value of the node B1 may be acquired from the node A's node data based on the storage index of the hash value of the node B1 in the node A's node data. At block 604, the node data in the node information of the next node is hashed to obtain a second hash value of the next node. Then, at block 606, a determination is made whether the first hash value is equal to the second hash value. When the first hash value and the second hash value of the next node are equal, at block 608, it is determined that the query link is correct. Otherwise, at block 610, it is determined that the query link is incorrect.

Although the account status data sent by the block nodes to the client includes the hash value indication information of the node next to the previous node, the client is required to verify whether the information is correct. When the hash value indication information for the next node in the previous node coincides with the hash value of the node data of its next node, it may be determined that the query link is connectible therebetween.

After a single query link is verified, at block 504, it is determined whether each query link in the query path is correct.

When each query link in the query path is correct, it indicates that each node in the query path can be connected with an adjacent node. At this point, at block 506, the query path is determined to be correct. If an incorrect query link exists in the query path, at block 508, it is determined that the query path is incorrect.

In one example, whether each query link is correct or not may be verified sequentially from the query link where the root node is located, or each query link may be verified in parallel. In addition, when one of the query links is determined to be incorrect, the other query links are not continuously verified. At this point, it may be determined that the query path is incorrect.

Fig. 7 is a block diagram of an account status presence attestation apparatus, in accordance with one embodiment of the present disclosure. As shown in fig. 7, the account status presence proving apparatus 700 includes a status data receiving unit 710 and a presence proving executing unit 720.

The status data receiving unit 710 is configured to receive account status data of accounts to be certified on the target block from the block chain node, the account status data being queried by the block chain node from the status tree of the target block in response to an account status query request sent by the client. The presence attestation performing unit 720 is configured to perform presence attestation of the account status of the account to be attested, based on the received account status data.

The account state data comprises node information of each node on an account state query path in the state tree, the nodes comprise non-leaf nodes and leaf nodes, the node information of the non-leaf nodes comprises the node data of the node and hash value indication information of a next node of the node, the node information of the leaf nodes comprises the node data of the node and state entity indication information, the state entity indication information indicates a state entity, and the state entity comprises account information of the account to be proved.

Fig. 8 is a block diagram showing an example of the presence proving execution unit 720 in the account status presence proving apparatus 700 shown in fig. 7. The presence attestation performing unit 720 includes a root node verification module 721, a path verification module 722, a state entity decoding module 732, and a state verification module 724.

The root node verification module 721 is configured to determine whether the root node in the query path is correct based on the state root stored in the target tile and the node data of the root node in the query path. When the root node is determined to be correct, the path verification module 722 determines whether the query path is correct based on node information of the respective nodes.

If the status entity is encoded information, the status entity decoding module 723 may decode the status entity indicated by the status entity indication information to obtain account information in the status entity when the query path is determined to be correct. If the information in the state entity is the unencoded information itself, no decoding process is required. The state entity decoding module may not be included at this time.

When the account information in the state entity is acquired, the state verification module 724 determines the existence of the account state of the account to be proved based on the account information in the state entity indicated by the state entity indication information of the leaf node and the account information of the account to be proved at the client. If no decoding needs to be performed, the status verification module 724 may be configured to perform an account status presence determination procedure when the query path is determined to be correct.

Fig. 9 is a block diagram of an example of a root node verification module shown in fig. 8. In this example, the account status data also includes a status root for the target tile. As shown in fig. 9, the root node verification module 721 includes a status root acquisition submodule 7211, a status root verification submodule 7212, and a root node verification submodule 7213.

The status root retrieving submodule 7211 is configured to retrieve a status root of a target from the blockchain. The account status data may further include a block number of the target block, and at this time, the status root of the target block may be acquired from the block chain based on the block number in the account status data. Status root validation submodule 7212 is configured to determine whether the status root in the status account data is correct based on the status root obtained from the blockchain. When the status root in the account status data is determined to be correct, the root node verification sub-module 7213 determines whether the root node is correct based on the status root in the account status data and the node data of the root node.

Fig. 10 is a block diagram of an example of the path verification module 722 shown in fig. 8. As shown in fig. 10, path verification module 722 includes a query link verification sub-module 7221 and a path verification sub-module 7222.

The query link verification sub-module 7221 is configured to determine, for each query link in the query path, whether the query link is correct based on the hash indication information for the next node in the node information of the start node in the query link and the node data in the node information of the next node, each query link including two adjacent nodes. The path verification sub-module 7222 is configured to determine that the query path is correct when all query links in the query path are determined to be correct.

Fig. 11 is a block diagram showing an example of the query link verification sub-module 7221 shown in fig. 10. As shown in fig. 11, query link verification submodule 7221 includes a first hash value determination submodule 7223, a second hash value determination submodule 7224, and a link verification submodule 7225.

The first hash value determination submodule 7223 is configured to obtain the first hash value of the next node based on the hash value indication information for the next node in the node information of the start node. The second hash value determination submodule 7224 is configured to hash the node data in the node information of the next node to obtain a second hash value of the next node. Link verification sub-module 7225 is configured to determine that the query link is correct when the first hash value and the second hash value of the next node are equal.

Fig. 12 is a block diagram of an account status inquiry apparatus according to an embodiment of the present disclosure. As shown in fig. 12, the status query apparatus 1200 includes a query request receiving unit 1210, a status query unit 1220, and a query data transmitting unit 1230.

The query request receiving unit 1210 is configured to receive a status query request of a client for a status of an account to be queried, where the status query request includes a block number of a target block. The status query unit 1220 is configured to query the status of the account to be queried from the status tree of the target block based on the block number in response to the status query request, so as to obtain the account status data. The query data transmitting unit 1230 is configured to transmit the account status data to the client. The specific content of the account status data may be referred to the description of the above embodiment.

Embodiments of an account status presence proving method and apparatus and an account status inquiring method and apparatus according to the present disclosure are described above with reference to fig. 1 to 12. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the apparatus of the present disclosure.

The account status existence proving apparatus and the account status inquiring apparatus of the present disclosure may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the apparatus of the present disclosure. The various embodiments in this specification are described in a progressive manner, with like reference to each other.

The account status existence proving apparatus and the account status inquiring apparatus of the present disclosure may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The software implementation is taken as an example, and is formed by reading corresponding computer program instructions in the storage into the memory for operation through the processor of the device where the software implementation is located as a logical means. In the present disclosure, the account status presence proving apparatus and the account status inquiring apparatus may be implemented by a computing device, for example.

Fig. 13 is a block diagram of a computing device 1300 for implementing an account status presence attestation method, according to one embodiment of the present disclosure. As shown in fig. 13, computing device 1300 includes a processor 1310, a memory 1320, a memory 1330, a communication interface 1340, and an internal bus 1350. According to one embodiment, the computing device 1300 may include at least one processor 1310 that executes at least one computer-readable instruction (i.e., the elements described above as being implemented in software) stored or encoded in a computer-readable storage medium (i.e., memory 1320).

In one embodiment, computer-executable instructions are stored in the memory 1320 that, when executed, cause the at least one processor 1310 to: receiving account status data of an account to be certified on a target block from a block node, the account status data being queried by the block node from a status tree of the target block in response to an account status query request sent by a client; and performing presence attestation on the account status of the account to be attested based on the received account status data.

It should be appreciated that the computer-executable instructions stored in the memory 1320, when executed, cause the at least one processor 1310 to perform the various operations and functions of the account status presence attestation method and apparatus described above in connection with fig. 1-11 in the various embodiments of the present disclosure.

FIG. 14 is a block diagram of a computing device 1400 for implementing an account status query method, according to one embodiment of the present disclosure. As shown in fig. 14, computing device 1400 includes a processor 1410, storage 1420, memory 1430, a communication interface 1440, and an internal bus 1450. According to one embodiment, computing device 1400 may include at least one processor 1410, the at least one processor 1410 executing at least one computer-readable instruction (i.e., an element described above as being implemented in software) stored or encoded in a computer-readable storage medium (i.e., memory 1420).

In one embodiment, computer-executable instructions are stored in the memory 1420 that, when executed, cause the at least one processor 1410 to: receiving a state query request of a client for the account state to be queried, wherein the state query request comprises a block number of a target block; responding to the state query request, and querying the account state to be queried from the state tree of the target block based on the block number to obtain account state data; and sending the account status data to the client.

It should be understood that the computer-executable instructions stored in the memory 1420, when executed, cause the at least one processor 1410 to perform the various operations and functions of the account status query method and apparatus described above in connection with fig. 1-2 and 12 in the various embodiments of the present disclosure.

According to one embodiment, a program product, such as a non-transitory machine-readable medium, is provided. A non-transitory machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions of the account status presence attestation method and apparatus described above in connection with fig. 1-11 in the various embodiments of the present disclosure.

According to one embodiment, a program product, such as a non-transitory machine-readable medium, is provided. A non-transitory machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions of the account status query method and apparatus described above in connection with fig. 1-2 and 12 in various embodiments of the present disclosure.

Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present invention.

Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.

Alternative embodiments of the present disclosure are described in detail with reference to the drawings, however, the embodiments of the present disclosure are not limited to the specific details in the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical concept of the embodiments of the present disclosure, and the simple modifications all belong to the protective scope of the embodiments of the present disclosure.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of presence attestation of account status on a target block, comprising:

receiving account status data of an account to be certified on a target block from a block node, the account status data being queried by the block node from a status tree of the target block in response to an account status query request sent by a client; and

performing presence attestation on account status of the account to be attested based on the received account status data,

2. The method of claim 1, wherein performing presence attestation on account status of the account to be attested based on the received account status data comprises:

determining whether a root node in the query path is correct based on the state root stored in the target block and node data of the root node in the query path;

when the root node is determined to be correct, determining whether the query path is correct or not based on the node information of each node; and

when the inquiry path is determined to be correct, determining the existence of the account state of the account to be proved based on account information in the state entity indicated by the state entity indication information of the leaf node and account information of the account to be proved at the client.

3. The method of claim 2, wherein performing presence attestation on account status of the account to be attested based on the received account status data prior to determining presence of account status of the account to be attested based on account information in a status entity indicated by status entity indication information of the leaf node and account information of the account to be attested at a client further comprises:

and when the query path is determined to be correct, decoding the state entity indicated by the state entity indication information to obtain account information in the state entity.

4. The method of claim 2, wherein the account status data further comprises a status root of the target tile, and determining whether the root node of the query path is correct based on the status root stored in the target tile and node data of the root node in the query path comprises:

acquiring a state root of the target block from a block chain;

determining whether the state root in the state account data is correct or not based on the state root acquired from the block chain; and

when the state root in the state account number data is determined to be correct, determining whether the root node is correct or not based on the state root in the account state data and the node data of the root node.

5. The method of any of claims 2-4, wherein determining whether the query path is correct based on the node information of the respective nodes comprises:

for each query link in the query path, determining whether the query link is correct or not based on hash indication information for a next node in node information of a starting node in the query link and node data in the node information of the next node, wherein each query link comprises two adjacent nodes; and

determining that the query path is correct when all query links in the query path are determined to be correct.

6. The method of claim 5, wherein determining, for each query link in the query path, whether the query link is correct based on the hash indication information for the next node in the node information of the starting node in the query link and the node data in the node information of the next node comprises:

acquiring a first hash value of a next node based on hash value indication information for the next node in the node information of the start node;

performing hash processing on node data in the node information of the next node to obtain a second hash value of the next node; and

and when the first hash value and the second hash value of the next node are equal, determining that the query link is correct.

7. The method according to any of claims 2-4, wherein the hash value indication information of the next node is a storage index of the first hash value of the next node in the node data of the start node.

8. The method of any of claims 2-4, wherein the account status data further comprises a block number of the target block, the status root of the target block being obtained from the chain of blocks based on the block number.

9. An account status query method, comprising:

receiving a state query request of a client for the account state to be queried, wherein the state query request comprises a block number of a target block;

responding to the state query request, and querying the account state to be queried from the state tree of the target block based on the block number to obtain account state data; and

sending the account status data to the client,

10. The method of claim 9, wherein the status query data further comprises a status root of the target chunk.

11. The method of claim 9 or 10, wherein the status query data further comprises a block number of the target block.

12. An apparatus for presence attestation of account status on a target block, comprising:

a status data receiving unit configured to receive account status data of an account to be certified on a target block from a block chain node, the account status data being queried by the block chain node from a status tree of the target block in response to an account status query request sent by a client; and

a presence attestation performing unit configured to perform presence attestation on an account status of the account to be attested based on the received account status data,

13. The apparatus of claim 12, wherein the presence attestation performing unit comprises:

a root node verification module configured to determine whether a root node in the query path is correct based on a state root stored in the target tile and node data of the root node in the query path;

a path verification module configured to determine whether the query path is correct based on node information of the respective nodes when the root node is determined to be correct; and

a state verification module configured to determine, when the query path is determined to be correct, existence of an account state of the account to be proved based on account information in the state entity indicated by the state entity indication information of the leaf node and account information of the account to be proved at the client.

14. The apparatus of claim 13, wherein the presence attestation execution further comprises:

and the state entity decoding module is configured to decode the state entity indicated by the state entity indication information to obtain the account information in the state entity before determining the existence of the account state of the account to be proved based on the account information in the state entity indicated by the state entity indication information of the leaf node and the account information of the account to be proved at the client.

15. The apparatus of claim 13, wherein the account status data further comprises a status root of a target tile, the root node verification module comprising:

the state root acquisition submodule is configured to acquire a state root of the target from a blockchain;

the state root verification submodule is configured to determine whether a state root in the state account data is correct or not based on the state root acquired from the block chain; and

a root node verification sub-module configured to determine whether the root node is correct based on the state root in the account state data and the node data of the root node when the state root in the state account number data is determined to be correct.

16. The apparatus of any of claims 13-15, wherein the path verification module comprises:

a query link verification sub-module configured to determine, for each query link in the query path, whether the query link is correct based on hash indication information for a next node in node information of a start node in the query link and node data in the node information of the next node, where each query link includes two adjacent nodes; and

a path verification sub-module configured to determine that the query path is correct when all query links in the query path are determined to be correct.

17. The apparatus of claim 16, wherein the query link validation submodule comprises:

a first hash value determination submodule configured to acquire a first hash value of a next node based on hash value indication information for the next node in the node information of the start node;

a second hash value determination submodule configured to perform hash processing on node data in the node information of the next node to obtain a second hash value of the next node; and

a link verification sub-module configured to determine that the query link is correct when the first hash value and the second hash value of the next node are equal.

18. An account status inquiry apparatus comprising:

the query request receiving unit is configured to receive a state query request of a client for the account state to be queried, wherein the state query request comprises a block number of a target block;

a status query unit configured to query the account status to be queried from the status tree of the target block based on the block number in response to the status query request to obtain account status data; and

a query data transmitting unit configured to transmit the account status data to the client,

19. A computing device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 8.

20. A non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method of any of claims 1-8.

21. A computing device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 9 to 11.

22. A non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method of any of claims 9-11.