WO2021135756A1 - 账户状态存在性证明方法及装置和状态查询方法及装置 - Google Patents

账户状态存在性证明方法及装置和状态查询方法及装置 Download PDF

Info

Publication number
WO2021135756A1
WO2021135756A1 PCT/CN2020/132055 CN2020132055W WO2021135756A1 WO 2021135756 A1 WO2021135756 A1 WO 2021135756A1 CN 2020132055 W CN2020132055 W CN 2020132055W WO 2021135756 A1 WO2021135756 A1 WO 2021135756A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
account
state
query
information
Prior art date
Application number
PCT/CN2020/132055
Other languages
English (en)
French (fr)
Inventor
林鹏
陆钟豪
陈锐
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021135756A1 publication Critical patent/WO2021135756A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present disclosure relates to the field of blockchain technology, in particular, to a method and device for proving the existence of an account state and a method and device for querying the state.
  • the latest global account state is called the word state.
  • the world state consists of the state of each account.
  • the status of each account includes information such as account address (ie account) balance.
  • the state is usually stored on the block in a state tree structure, and the state tree stores the world state in a tree-like data structure.
  • the client can request a proof of the existence of the account status in a certain block from the blockchain node. Proof of existence refers to verifying whether an account exists on a certain block.
  • the present disclosure provides a method and device for proving the existence of an account status, and a method and device for querying status.
  • the existence proof can be realized without relying on the decoding operation of each node on the query path, and the method and device can be applied to state trees of various structures, with compatibility Stronger.
  • a method for proving the existence of an account status on a target block including: receiving account status data of an account to be proven on the target block from a blockchain node, the account The status data is queried from the status tree of the target block by the blockchain node in response to the account status query request sent by the client; and based on the received account status data, the to-be-proven The account status of the account executes the existence proof.
  • the account state data includes the node information of each node on the account state query path in the state tree, the node includes a non-leaf node and a leaf node, and the node information of the non-leaf node includes the node information
  • the node data and the hash value indication information of the next node of the node the node information of the leaf node includes the node data and state entity indication information of the node, the state entity indication information indicates the state entity, and the state entity includes the to-be-proven The account information of the account.
  • performing existence proof on the account state of the account to be proven based on the received account state data may include: based on the state root stored in the target block and the query path Determine whether the root node in the query path is correct; when the root node is determined to be correct, determine whether the query path is correct based on the node information of each node; and When the query path is determined to be correct, the account status of the account to be certified is determined 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 certified at the client Existence.
  • the account status of the account to be certified is determined 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 certified at the client.
  • performing existence proof on the account state of the account to be certified based on the received account state data may also include: when the query path is determined to be correct, the state entity indication information indicates The state entity is decoded to obtain the account information in the state entity.
  • 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, based on the start node in the query link The hash indication information for the next node in the node information and the node data in the node information of the next node to determine whether the query link is correct, and each query link includes two adjacent nodes; and When all the query links in the query path are determined to be correct, it is determined that the query path is correct.
  • the node data in the node information to determine whether the query link is correct may include: obtaining 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 starting node ; Perform hash processing on the node data in the node information of the next node to obtain the second hash value of the next node; and the first hash value and the second hash value of the next node When the values are equal, it is determined that the query link is correct.
  • 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.
  • the account state data may further include the block number of the target block, and the state root of the target block may be based on the block number from the block chain. Acquired.
  • a block chain status query method including: receiving a client's status query request for the account status to be queried, the status query request including the block number of the target block; The status query request is to query the account status to be queried from the status tree of the target block based on the block number to obtain account status data; and send the account status data to the client.
  • the account state data includes the node information of each node on the account state query path in the state tree, the node includes a non-leaf node and a leaf node, and the node information of the non-leaf node includes the node information
  • the node data and the hash value indication information of the next node of the node the node information of the leaf node includes the node data and state entity indication information of the node, the state entity indication information indicates the state entity, and the state entity includes the to-be-proven The account information of the account.
  • the state query data may further include the state root of the target block.
  • the status query data may further include the block number of the target block.
  • a device for proving the existence of an account status on a target block including: a status data receiving unit configured to receive the to-be-proven on the target block from a blockchain node The account status data of the account, the account status data is queried from the status tree of the target block by the blockchain node in response to the account status query request sent by the client; and the existence proof execution The unit is configured to perform existence certification on the account status of the account to be certified based on the received account status data.
  • the account state data includes the node information of each node on the account state query path in the state tree, the node includes a non-leaf node and a leaf node, and the node information of the non-leaf node includes the node information
  • the node data and the hash value indication information of the next node of the node the node information of the leaf node includes the node data and state entity indication information of the node, the state entity indication information indicates the state entity, and the state entity includes the to-be-proven The account information of the account.
  • the existence proof execution unit includes: a root node verification module configured to be based on the state root stored in the target block and the node data of the root node in the query path, Determine whether the root node in the query path is correct; a path verification module configured to determine whether the query path is correct based on the node information of each node when the root node is determined to be correct; and state verification Module, configured to, when the query path is determined to be correct, determine the account information 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 certified at the client The existence of the account status of the account to be proved.
  • the execution of the existence proof may further include: a state entity decoding module configured to account for the account information and the client in the state entity indicated by the state entity indication information of the leaf node Before determining the existence of the account status of the account to be certified, when the query path is determined to be correct, decode the status entity indicated by the status entity indication information to Obtain account information in the state entity.
  • a state entity decoding module configured to account for the account information and the client in the state entity indicated by the state entity indication information of the leaf node Before determining the existence of the account status of the account to be certified, when the query path is determined to be correct, decode the status entity indicated by the status entity indication information to Obtain account information in the state entity.
  • the account state data may further include the state root of the target block
  • the root node verification module may include: a state root obtaining submodule configured to obtain the state root from the blockchain. The state root of the target; the state root verification sub-module configured to determine whether the state root in the state account data is correct based on the state root obtained from the blockchain; and the root node verification sub-module configured to When the state root in the state account data is determined to be correct, it is determined whether the root node is correct based on the state root in the account state data and the node data of the root node.
  • the path verification module may include: a query link verification sub-module configured to, for each query link in the query path, based on the value of the start node in the query link The hash indication information for the next node in the node information and the node data in the node information of the next node are used to determine whether the query link is correct, and each query link includes two adjacent nodes; and a path The verification sub-module is configured to determine that the query path is correct when all query links in the query path are determined to be correct.
  • the query link verification submodule may include: a first hash value determination submodule configured to be based on the hash value for the next node in the node information of the starting node Indicating information, obtaining the first hash value of the next node; the second hash value determining sub-module is configured to hash the node data in the node information of the next node to obtain the The second hash value of the next node; and the 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.
  • an account status query device including: a query request receiving unit configured to receive a client's status query request for the account status to be queried, and the status query request includes the status of the target block Block number; a status query unit configured to, in response to the status query request, query the status of the account to be queried from the status tree of the target block based on the block number 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 includes the node information of each node on the account state query path in the state tree, the node includes a non-leaf node and a leaf node, and the node information of the non-leaf node includes the node information
  • the node data and the hash value indication information of the next node of the node the node information of the leaf node includes the node data and state entity indication information of the node, the state entity indication information indicates the state entity, and the state entity includes the to-be-proven The account information of the account.
  • a computing device including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one The processor executes the account state existence verification method as described above.
  • a non-transitory machine-readable storage medium which stores executable instructions that, when executed, cause the machine to execute the method for proving the existence of an account state as described above .
  • a computing device including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one The processor executes the state query method as described above.
  • a non-transitory machine-readable storage medium which stores executable instructions, which when executed cause the machine to execute the state query method as described above.
  • the data returned by the blockchain node includes the node data of each node in the query path and the hash value indication information of the next node. Based on these data, the existence of the account state is proved, and there is no need Each node of the query path is decoded, which can improve efficiency.
  • this kind of existence proof scheme can be applied to state trees of various structures, so the compatibility is strong.
  • the account status is verified based on the account information in the status entity and the account information of the account to be proven at the client
  • the verification result of the root node or the query path is incorrect, there is no need to continue execution, which can prove the efficiency of existence.
  • the client can verify that the received state root is correct, based on the received state root and node data of the root node To verify whether the root node is correct, thereby providing a redundant verification method.
  • the verification of the query path can be improved. Efficiency and accuracy.
  • 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, thereby reducing the capacity of data transmission and saving data transmission consumption. Resources.
  • the client can obtain the state root of the target block from the blockchain based on the received block number, so that the client When obtaining the state root of the target block from the blockchain, there is no need to access the local storage space to obtain the block number of the target block, and the block number may not be stored locally.
  • Fig. 1 is a flowchart of an application example of an account state existence proof method and an account state query method according to an embodiment of the present disclosure
  • Figure 2 is a schematic diagram for explaining the query path in the state tree
  • Fig. 3 is a flowchart of the existence proof execution process in the account state existence proof method according to an embodiment of the present disclosure
  • FIG. 4 is a flowchart of a root node verification process in a method for proving the existence of an account state according to an embodiment of the present disclosure
  • FIG. 5 is a flowchart of a path verification process in a method for proving the existence of an account state according to an embodiment of the present disclosure
  • Fig. 6 is a flowchart of a query link verification process in a method for proving the existence of an account state according to an embodiment of the present disclosure
  • Fig. 7 is a structural block diagram of an account state existence certification device according to an embodiment of the present disclosure.
  • FIG. 8 is a structural block diagram of an example of the existence proof execution unit in the account state existence proof device shown in FIG. 7;
  • FIG. 9 is a structural block diagram of an example of the root node verification module shown in FIG. 8;
  • FIG. 10 is a structural block diagram of an example of the query path verification module shown in FIG. 8;
  • FIG. 11 is a structural block diagram of an example of the query link verification submodule shown in FIG. 10;
  • Fig. 12 is a structural block diagram of an account status query device according to an embodiment of the present disclosure.
  • Fig. 13 is a structural block diagram of a computing device for implementing a method for proving the existence of an account state according to an embodiment of the present disclosure.
  • Fig. 14 is a structural block diagram of a computing device for implementing an account status query method according to an embodiment of the present disclosure.
  • the term “including” and its variations mean open terms, meaning “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”, etc. may refer to different or the same objects. Other definitions can be included below, whether explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.
  • connection refers to direct mechanical connection, communication or electrical connection between two components, or indirect mechanical connection, communication or electrical connection through intermediate components.
  • electrically connected refers to the possibility of electrical communication between two components for data/information exchange.
  • 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 can be implemented in a wired manner or a wireless manner.
  • the client may be an SPV node in a blockchain system
  • the blockchain node refers to a full blockchain node.
  • the SPV node does not download all the block chain data when performing transaction verification, but only downloads the block headers of each block in the block chain.
  • This block header chain composed of 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 block.
  • the SPV node performs transaction verification on the unverified transaction related to the node, and the transaction verification is SPV verification (simple transaction payment verification).
  • a full blockchain node refers to a node that not only owns the block header, but also owns all transaction data of the blockchain.
  • the SPV node When a transaction related to the SPV node occurs, the SPV node will send a status query request to all blockchain nodes to query the account status related to the transaction to be verified. In response to the status query request, all blockchain nodes return the query results for the corresponding account status to the SPV node. The SPV node can perform SPV verification based on the received query result.
  • SPV verification is usually divided into two processes, one of which is the existence proof process, and the other is the state correctness proof.
  • the following implementations of the present disclosure are applicable to the existence proof process in SPV verification.
  • Proof of existence refers to proof that the transaction to be verified exists on the corresponding block.
  • the process of verifying the transaction is equivalent to the process of verifying the status of the account related to the transaction.
  • the present disclosure can also be applied to the client to verify the existence of the inquired account state when the client inquires about the account state associated with the client.
  • the client queries the related account status it also needs to prove the existence of the account status.
  • node refers to each data node in the state tree.
  • Fig. 1 is a flowchart of an application example of an account state existence proof method and an account state query method according to an embodiment of the present disclosure.
  • the account state existence proof method is executed by the client
  • the account state query method is executed by the blockchain node.
  • the client sends a status query request to the blockchain node, and the status query request includes the block number of the target block.
  • the block is the target block.
  • the account to be queried is the account to be proved.
  • the account to be verified may be an account corresponding to the exchange to be verified.
  • the blockchain node After the blockchain node receives the status query request, in block 140, based on the block number in the status query request, query the status of the account to be queried from the status tree of the target block to obtain account status data.
  • the account status data includes the node information of each node on the account status query path in the status tree, and the nodes include non-leaf nodes and leaf nodes.
  • the node information of the non-leaf node includes the node data of the node and the hash value indication information of the next node of the node.
  • the node information of the leaf node includes the node data and status entity indication information of the node, the status entity indication information indicates the status entity, and the status entity includes account information (ie, account address) of the account to be certified.
  • the state entity may also include information such as account balance (Balance), recovery key (Recovery Key), and random number (Nonce).
  • Fig. 2 is a schematic diagram for explaining the query path in the state tree.
  • Figure 2 shows the structure of the state tree using the MPT tree as an example.
  • the root node refers to the top node (node A) in the state tree
  • the leaf node refers to the bottom node (nodes D1 to D8) in the state tree.
  • the nodes between the root node and the leaf nodes are called intermediate nodes (nodes B1 to B2, C1 to C4).
  • the MPT tree on each block stores the world state of the block chain (that is, all account states) when the block is generated, and each account state is stored in the state entity in the leaf node.
  • the query path for the account status is A-B1-C1-D1.
  • the hash value indication information of the next node may be the hash value of the next node.
  • the hash indication information of the next node may be the storage index of the hash value of the next node in the node.
  • the node data of the node includes the hash value of the next node of the node. Taking FIG. 2 as an example, the hash values of nodes B1 and B2 are stored in the node data of node A, and the hash values of nodes C1 and C2 are stored in the node data of node B1.
  • the node information of node A may include the node data of node A, the start index and the end index of the hash value of node B1 in the node data of node A .
  • the hash value of node B1 can be extracted from the node data of node A based on the start index and the end index.
  • the hash value itself occupies a large data space, and the data space occupied by the storage index is significantly smaller than the hash value. Therefore, when the hash value prompt information is the storage index, the resources occupied by data transmission can be significantly reduced.
  • the field of the account state data may be StateProof ⁇ state_node[]>, and State_Node[] refers to a collection of node information of each node on the query path.
  • State_Node[] includes State_Node[0] (node information of node A), State_Node[1] (node information of node B1), State_Node[2] (node information of node C1) ), State_Node[3] (node information of node D1).
  • the node information field of each non-leaf node can be StateNode ⁇ data, next_key_begin_index, next_key_end_index>, data is the node data of the node, next_key_begin_index is the beginning of the hash value of the next node of the node in data Start index, next_key_end_index is the end index of the hash value of the node's next node in data.
  • the field between the start index and the end index in data is the hash value of the next node.
  • the "next node" of a node refers to the next node of the node in the corresponding query path, for example, the next node of node B1 is node C1, and the next node of node C1 is node D1.
  • the state entity indication information in the node information of the leaf node D1 may be the storage index of the node information of the state entity in the leaf node, or may be the state entity itself.
  • the node information field of the leaf node D1 can be StateNode ⁇ data,begin_index,end_index>, data is the node data of the leaf node D1
  • begin_index is the start of the state entity in the data of the node D1 Index
  • the field between the start index and the end index is the state entity.
  • the blockchain node When the corresponding account status is queried, at block 160, the blockchain node sends the account status data obtained by the query to the client.
  • the client After the client receives the account status data sent by the blockchain node, in block 180, based on the received account status data, the account status of the account to be certified executes the existence proof.
  • Fig. 3 is a flowchart of an existence proof execution process in an account state existence proof method according to an embodiment of the present disclosure.
  • the client can store the account status on which block it wants to query locally, and then can obtain the status root of the corresponding block from the downloaded block header chain based on the block number of the target block stored locally.
  • the account status data returned by the blockchain node to the client may include the block number of the target block.
  • the field of the account state data can be StateProof ⁇ block_NUM, state_node[]>, and block_NUM is the block number of the target block.
  • the state root of the target block can be queried from the block header chain based on the block number in the account state data. Therefore, the client does not need to access the local storage space or perform other operations to obtain the block number.
  • the node data of the root node can be hashed to obtain the hash value of the root node.
  • the hash calculation algorithm used in this disclosure is consistent with the algorithm used when generating the state tree on the corresponding blockchain. For example, if the SHA256 algorithm is used when generating the state tree, the SHA256 algorithm is also used in the existence proof process.
  • the state entity indicated by the state entity indication information is decoded to obtain account information in the state entity.
  • the account information in the state entity is sometimes not the information itself, but the information after the information itself is encoded using a specific encoding method (such as RLP encoding). In this case, the state entity needs to be decoded. For example, when the state entity is encoded by RLP encoding, the corresponding decoding method can be used for decoding. After decoding, the information itself of the status information can be obtained, and then the account information can be obtained from it.
  • the decoding operation of block 310 may not be performed. Therefore, the operation of block 310 is not essential.
  • the account information in the status entity is consistent with the account information of the account to be certified at the client terminal (the account address is the same), it can be determined that the account status of the account to be certified is stored in the target block.
  • the account state data sent by the blockchain node to the client may also include the state root of the target block.
  • the field of the account state data can be StateProof ⁇ state_root, state_node[]> or StateProof ⁇ block_NUM, state_root, state_node[]>, where state_root is the state root of the target block.
  • the example shown in FIG. 4 can be used to verify the root node.
  • Fig. 4 is a flowchart of a root node verification process in a method for proving the existence of an account state according to an embodiment of the present disclosure.
  • the state root of the target block is obtained from the blockchain.
  • the state root of the target block can be obtained from the downloaded block header chain based on the block number of the target block.
  • block 404 and block 406 After obtaining the state root from the blockchain, in block 404 and block 406, based on the state root obtained from the blockchain, it is determined whether the state root in the account state data is correct. When the state root obtained from the blockchain is consistent with the state root in the account state data, it can be determined that the state root in the account state data is correct.
  • Fig. 5 is a flowchart of a path verification process in a method for proving the existence of an account state according to an embodiment of the present disclosure.
  • each query link in the query path based on the hash indication information for the next node and the node of the next node in the node information of the start node in the query link The node data in the information determines whether the query link is correct.
  • Each query link includes two adjacent nodes.
  • the query path A-B1-C1-D1 includes three query links A-B1, B1-C1, and C1-D1.
  • node A, node B1, and node C1 are the start nodes of each query link
  • node B1, node C1, and node D1 are the end nodes of each query link mentioned above, or can be called node A, node B1, and node C1.
  • the next node can be determined based on the node data of the hash value indication information for the node B1 and the node information of the node B1 in the node information of the node A.
  • FIG. 6 is a flowchart of a query link verification process in a method for proving the existence of an account state according to an embodiment of the present disclosure.
  • the first hash value of the next node is obtained based on the hash value indication information for the next node in the node information of the starting node in the query link. If the hash value indication information is the hash value itself, the first hash value of the next node can 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 obtained from the node data of the node A based on the storage index of the hash value of the node B1 in the node data of the node A. In block 604, the node data in the node information of the next node is hashed to obtain the second hash value of the next node.
  • the account status data sent by the blockchain node to the client includes the hash value indication information of the next node of the previous node
  • the client needs to verify whether the information is correct.
  • the hash value indication information for the next node in the previous node is consistent with the hash value of the node data of the next node, it can be determined that the query link can be connected.
  • each query link in the query path When each query link in the query path is correct, it indicates that each node in the query path can be connected to an adjacent node. At this time, at block 506, it is determined that the query path is correct. If there is an incorrect query link in the query path, then at block 508, it is determined that the query path is incorrect.
  • Fig. 7 is a structural block diagram of an account state existence proof device according to an embodiment of the present disclosure.
  • the account state existence certification device 700 includes a state data receiving unit 710 and an existence certification execution unit 720.
  • the status data receiving unit 710 is configured to receive the account status data of the account to be proven on the target block from the blockchain node, and the account status data is obtained by the blockchain node in response to the account status query request sent by the client. Query from the status tree of the target block.
  • the existence proof execution unit 720 is configured to execute the existence proof on the account state of the account to be certified based on the received account state data.
  • the account state data includes the node information of each node on the account state query path in the state tree.
  • the nodes include non-leaf nodes and leaf nodes.
  • the node information of the non-leaf nodes includes the node data of the node and the next node of the node.
  • the hash value indication information of the node, the node information of the leaf node includes the node data and state entity indication information of the node, the state entity indication information indicates the state entity, and the state entity includes the account information of the account to be certified.
  • FIG. 8 is a structural block diagram of an example of the existence proof execution unit 720 in the account state existence proof device 700 shown in FIG. 7.
  • the existence proof execution 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 block 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 the node information of each node.
  • the state entity decoding module 723 can decode the state entity indicated by the state entity indication information to obtain the account information in the state entity. If the information in the state entity is unencoded information itself, no decoding process is required. At this time, the state entity decoding module may not be included.
  • the state verification module 724 determines the account of the account to be certified 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 certified at the client. The existence of state. If there is no need to perform decoding, the state verification module 724 may be set to perform the account state existence determination process when the query path is determined to be correct.
  • Fig. 9 is a structural block diagram of an example of the root node verification module shown in Fig. 8.
  • the account state data also includes the state root of the target block.
  • the root node verification module 721 includes a state root obtaining sub-module 7211, a state root verification sub-module 7212, and a root node verification sub-module 7213.
  • the state root obtaining submodule 7211 is configured to obtain the state root of the target from the blockchain.
  • the account status data can also include the block number of the target block. At this time, the status root of the target block can be obtained from the blockchain based on the block number in the account status data.
  • the state root verification submodule 7212 is configured to determine whether the state root in the state account data is correct based on the state root obtained from the blockchain. When the state root in the account state data is determined to be correct, the root node verification submodule 7213 determines whether the root node is correct based on the state root in the account state data and the node data of the root node.
  • FIG. 10 is a structural block diagram of an example of the path verification module 722 shown in FIG. 8. As shown in FIG. 10, the path verification module 722 includes a query link verification sub-module 7221 and a path verification sub-module 7222.
  • the query link verification submodule 7221 is configured to, for each query link in the query path, based on the hash indication information for the next node and the node of the next node in the node information of the start node in the query link The node data in the information determines whether the query link is correct.
  • Each query link includes two adjacent nodes.
  • the path verification submodule 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 structural block diagram of an example of the query link verification submodule 7221 shown in FIG. 10. As shown in FIG. 11, the 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 determining 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 starting node.
  • the second hash value determining submodule 7224 is configured to perform hash processing on the node data in the node information of the next node to obtain the second hash value of the next node.
  • the link verification submodule 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 structural block diagram of an account status query device according to an embodiment of the present disclosure.
  • the status query device 1200 includes a query request receiving unit 1210, a status query unit 1220, and a query data sending unit 1230.
  • the query request receiving unit 1210 is configured to receive a client's status query request for the account status to be queried, and the status query request includes the block number of the 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 to obtain account status data.
  • the query data sending unit 1230 is configured to send account status data to the client. Among them, the specific content of the account status data can be referred to the description of the above embodiment.
  • the account status existence certification device and the account status query device of the present disclosure can be implemented by hardware, or can be implemented by software or a combination of hardware and software.
  • the details mentioned in the above description of the method embodiment are also applicable to the embodiment of the device of the present disclosure.
  • the various embodiments in this specification are described in a progressive manner, and the same or similar parts among the various embodiments are referred to each other.
  • the account status existence certification device and the account status query device of the present disclosure can be implemented by hardware, or can be implemented by software or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the memory into the memory through the processor of the device where it is located. In the present disclosure, the account state existence proof device and the account state query device can be implemented using computing devices, for example.
  • FIG. 13 is a structural block diagram of a computing device 1300 for implementing a method for proving the existence of an account state according to an embodiment of the present disclosure.
  • the computing device 1300 includes a processor 1310, a memory 1320, a memory 1330, a communication interface 1340, and an internal bus 1350.
  • the computing device 1300 may include at least one processor 1310 that executes at least one computer-readable instruction (ie, the aforementioned Elements implemented in software).
  • computer-executable instructions are stored in the memory 1320, which, when executed, cause at least one processor 1310 to: receive from the blockchain node the account status data of the account to be certified on the target block, the account status The data is queried from the status tree of the target block by the blockchain node in response to the account status query request sent by the client; and based on the received account status data, the account to be proven The account status of the implementation of the existence proof.
  • the computer-executable instructions stored in the memory 1320 when executed, cause at least one processor 1310 to perform various methods and devices for the account state existence verification method and device described above in conjunction with FIGS. 1-11 in the various embodiments of the present disclosure. Operation and function.
  • FIG. 14 is a structural block diagram of a computing device 1400 for implementing an account status query method according to an embodiment of the present disclosure.
  • the computing device 1400 includes a processor 1410, a memory 1420, a memory 1430, a communication interface 1440, and an internal bus 1450.
  • the computing device 1400 may include at least one processor 1410 that executes at least one computer-readable instruction (ie, the aforementioned Elements implemented in software).
  • computer-executable instructions are stored in the memory 1420, which when executed, cause at least one processor 1410 to: receive a client's status query request for the status of the account to be queried, the status query request including the status of the target block Block number; in response to the status query request, based on the block number, query the status of the account to be queried from the status tree of the target block to obtain account status data; and send to the client The account status data.
  • a program product such as a non-transitory machine-readable medium.
  • the non-transitory machine-readable medium may have instructions (that is, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to execute the account-oriented account described above in conjunction with FIGS. 1-11 in the various embodiments of the present disclosure.
  • Various operations and functions of the state existence proof method and device are described above in conjunction with FIGS. 1-11 in the various embodiments of the present disclosure.
  • a program product such as a non-transitory machine-readable medium.
  • the non-transitory machine-readable medium may have instructions (ie, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to execute the various embodiments of the present disclosure described above with reference to FIGS. 1-2 and 12 The various operations and functions of the method and device for querying account status.
  • a system or device equipped with a readable storage medium may be provided, and the software program code for realizing the function of any one of the above-mentioned embodiments is stored on the readable storage medium, and the computer or device of the system or device The processor reads and executes the instructions stored in the readable storage medium.
  • the program code itself read from the readable medium can realize the function of any one of the above embodiments, so the machine readable code and the readable storage medium storing the machine readable code constitute the present invention a part of.
  • Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, Volatile memory card and ROM.
  • the program code can be downloaded from a server computer or cloud via a communication network.
  • the device structure described in the foregoing embodiments may be a physical structure or a logical structure, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented by multiple physical entities. Some components in independent devices are implemented together.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Strategic Management (AREA)
  • Databases & Information Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Development Economics (AREA)
  • Computational Linguistics (AREA)
  • Marketing (AREA)
  • Fuzzy Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种账户状态存在性证明方法及装置和状态查询方法及装置，所述账户状态存在性证明方法包括：从区块链节点接收目标区块上的待证明账户的账户状态数据；以及基于所接收的账户状态数据，对所述待证明账户的账户状态执行存在性证明。其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。

Description

账户状态存在性证明方法及装置和状态查询方法及装置 技术领域
本公开涉及区块链技术领域，具体地，涉及账户状态存在性证明方法及装置和状态查询方法及装置。
背景技术
在区块链中，最新的全局账户状态被称为世界状态(Word State)。世界状态由各个账户的状态组成。各个账户的状态包括账户地址(即账号)余额等信息。状态通常以状态树结构存储在区块上，状态树以树状数据结构对世界状态进行存储。客户端可以向区块链节点请求在某个区块下的账户状态存在性证明。存在性证明是指对账号是否存在于某个区块上进行验证。
发明内容
鉴于上述，本公开提供了一种账户状态存在性证明方法及装置和状态查询方法及装置。利用该方法和装置，在进行账号存在性证明时，不依赖于对查询路径上各个节点的解码操作即可实现存在性证明，并且该方法和装置能够适用于各种结构的状态树，兼容性较强。
根据本公开的一个方面，提供了一种对目标区块上的账户状态进行存在性证明的方法，包括：从区块链节点接收目标区块上的待证明账户的账户状态数据，所述账户状态数据是由所述区块链节点响应于客户端所发送的账户状态查询请求而从所述目标区块的状态树中查询出的；以及基于所接收的账户状态数据，对所述待证明账户的账户状态执行存在性证明。其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
可选的，在一个示例中，基于所接收的账户状态数据来对所述待证明账户的账户状态执行存在性证明可以包括：基于所述目标区块中存储的状态根和所述查询路径中的根节点的节点数据，确定所述查询路径中的根节点是否正确；在所述根节点被确定为正 确时，基于所述各个节点的节点信息，确定所述查询路径是否正确；以及在所述查询路径被确定为正确时，基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性。
可选的，在一个示例中，在基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性之前，基于所接收的账户状态数据来对所述待证明账户的账户状态执行存在性证明还可以包括：在所述查询路径被确定为正确时，对所述状态实体指示信息所指示的状态实体进行解码，以得出所述状态实体中的账号信息。
可选的，在一个示例中，所述账户状态数据还可以包括所述目标区块的状态根，基于所述目标区块中存储的状态根和所述查询路径中的根节点的节点数据，确定所述查询路径的根节点是否正确可以包括：从区块链上获取所述目标区块的状态根；基于从所述区块链上获取的状态根，确定所述状态账号数据中的状态根是否正确；以及当所述状态账号数据中的状态根被确定为正确时，基于所述账户状态数据中的状态根和所述根节点的节点数据，确定所述根节点是否正确。
可选的，在一个示例中，基于所述各个节点的节点信息，确定所述查询路径是否正确可以包括：针对所述查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和所述下一节点的节点信息中的节点数据，确定该查询链路是否正确，每条查询链路包括相邻的两个节点；以及在所述查询路径中的所有查询链路被确定为是正确时，确定所述查询路径正确。
可选的，在一个示例中，针对所述查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和下一节点的节点信息中的节点数据，确定该查询链路是否正确可以包括：基于所述开始节点的节点信息中的针对下一节点的哈希值指示信息，获取所述下一节点的第一哈希值；对所述下一节点的节点信息中的节点数据进行哈希处理，以得到所述下一节点的第二哈希值；以及在所述下一节点的第一哈希值和第二哈希值相等时，确定该查询链路是正确的。
可选的，在一个示例中，所述下一节点的哈希值指示信息可以是所述下一节点的第一哈希值在所述开始节点的节点数据中的存储索引。
可选的，在一个示例中，所述账户状态数据还可以包括所述目标区块的区块编号，所述目标区块的状态根可以是基于所述区块编号从所述区块链上获取的。
根据本公开的另一方面，还提供一种区块链状态查询方法，包括：接收客户端针对待查询账户状态的状态查询请求，所述状态查询请求包括目标区块的区块编号；响应于所述状态查询请求，基于所述区块编号，从所述目标区块的状态树中查询所述待查询账户状态，以得到账户状态数据；以及向所述客户端发送所述账户状态数据。其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
可选的，在一个示例中，所述状态查询数据还可以包括所述目标区块的状态根。
可选的，在一个示例中，所述状态查询数据还可以包括所述目标区块的区块编号。
根据本公开的另一方面，还提供一种对目标区块上的账户状态进行存在性证明的装置，包括：状态数据接收单元，被配置为从区块链节点接收目标区块上的待证明账户的账户状态数据，所述账户状态数据是由所述区块链节点响应于客户端所发送的账户状态查询请求而从所述目标区块的状态树中查询出的；以及存在性证明执行单元，被配置为基于所接收的账户状态数据，对所述待证明账户的账户状态执行存在性证明。其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
可选的，在一个示例中，所述存在性证明执行单元包括：根节点验证模块，被配置为基于所述目标区块中存储的状态根和所述查询路径中的根节点的节点数据，确定所述查询路径中的根节点是否正确；路径验证模块，被配置为在所述根节点被确定为正确时，基于所述各个节点的节点信息，确定所述查询路径是否正确；以及状态验证模块，被配置为在所述查询路径被确定为正确时，基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性。
可选的，在一个示例中，所述存在性证明执行还可以包括：状态实体解码模块，被配置为在基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和 客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性之前，在所述查询路径被确定为正确时，对所述状态实体指示信息所指示的状态实体进行解码，以得出所述状态实体中的账号信息。
可选的，在一个示例中，所述账户状态数据还可以包括目标区块的状态根，所述根节点验证模块可以包括：状态根获取子模块，被配置为从区块链上获取所述目标的状态根；状态根验证子模块，被配置为基于从所述区块链上获取的状态根，确定所述状态账号数据中的状态根是否正确；以及根节点验证子模块，被配置为当所述状态账号数据中的状态根被确定为正确时，基于所述账户状态数据中的状态根和所述根节点的节点数据，确定所述根节点是否正确。
可选的，在一个示例中，所述路径验证模块可以包括：查询链路验证子模块，被配置为针对所述查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和所述下一节点的节点信息中的节点数据，确定该查询链路是否正确，每条查询链路包括相邻的两个节点；以及路径验证子模块，被配置为在所述查询路径中的所有查询链路被确定为是正确时，确定所述查询路径正确。
可选的，在一个示例中，所述查询链路验证子模块可以包括：第一哈希值确定子模块，被配置为基于所述开始节点的节点信息中的针对下一节点的哈希值指示信息，获取所述下一节点的第一哈希值；第二哈希值确定子模块，被配置为对所述下一节点的节点信息中的节点数据进行哈希处理，以得到所述下一节点的第二哈希值；以及链路验证子模块，被配置为在所述下一节点的第一哈希值和第二哈希值相等时，确定该查询链路是正确的。
根据本公开的另一方面，还提供一种账户状态查询装置，包括：查询请求接收单元，被配置为接收客户端针对待查询账户状态的状态查询请求，所述状态查询请求包括目标区块的区块编号；状态查询单元，被配置为响应于所述状态查询请求，基于所述区块编号，从所述目标区块的状态树中查询所述待查询账户状态，以得到账户状态数据；以及查询数据发送单元，被配置为向所述客户端发送所述账户状态数据。其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
根据本公开的另一方面，还提供一种计算设备，包括：至少一个处理器；以及存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的账户状态存在性证明方法。
根据本公开的另一方面，还提供一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的账户状态存在性证明方法。
根据本公开的另一方面，还提供一种计算设备，包括：至少一个处理器；以及存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的状态查询方法。
根据本公开的另一方面，还提供一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的状态查询方法。
利用本公开的方法及装置，区块链节点返回的数据中包括在查询路径中各个节点的节点数据和下一节点的哈希值指示信息，基于这些数据对账户状态进行存在性证明，不需要对查询路径的每个节点均进行解码，因而能够提高效率。此外，此种存在性证明方案能够适用于各种结构的状态树，因而兼容性强。
利用本公开的方法及装置，通过在查询路径的根节点和查询路径的验证结果为正确时，基于状态实体中的账号信息和客户端处的待证明账户的账号信息，来验证账户状态的存在性，当根节点或查询路径的验证结果为不正确时不需要继续执行，能够存在性证明的效率。
利用本公开的方法及装置，通过使账户状态数据中包括目标区块的状态根，客户端可以在验证所接收到的状态根为正确时，基于所接收到的状态根和根节点的节点数据来验证根节点是否正确，从而提供了一种冗余的验证方法。
利用本公开的方法及装置，通过对查询路径中的每相邻两个节点组成的查询链路进行验证，并在每条链路均验证正确时确定查询路径正确，能够提高对查询路径进行验证的效率和准确性。
利用本公开的方法及装置，节点信息中的下一节点的哈希值指示信息为下一节点的哈希值在该节点中的存储索引，从而能够减少数据传输的容量，节省数据传输消耗的资源。
利用本公开的方法及装置，通过使状态查询数据中包括目标区块的区块编号，客户端可以基于所接收到的区块编号从区块链上获取目标区块的状态根，从而客户端在从 区块链上获取目标区块的状态根时不需要访问本地存储空间以获取目标区块的区块编号，本地也可以不存储该区块编号。
附图说明
通过参照下面的附图，可以实现对于本公开内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。附图是用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开的实施例，但并不构成对本公开的实施例的限制。在附图中：
图1是根据本公开的一个实施例的账户状态存在性证明方法和账户状态查询方法的应用示例的流程图；
图2是用于说明在状态树中的查询路径的示意图；
图3是根据本公开的一个实施例的账户状态存在性证明方法中的存在性证明执行过程的流程图；
图4是根据本公开的一个实施例的账户状态存在性证明方法中的根节点验证过程的流程图；
图5是根据本公开的一个实施例的账户状态存在性证明方法中的路径验证过程的流程图；
图6是根据本公开的一个实施例的账户状态存在性证明方法中的查询链路验证过程的流程图；
图7是根据本公开的一个实施例的账户状态存在性证明装置的结构框图；
图8是图7所示的账户状态存在性证明装置中的存在性证明执行单元的一个示例的结构框图；
图9是图8所示的根节点验证模块的一个示例的结构框图；
图10是图8所示的查询路径验证模块的一个示例的结构框图；
图11是图10所示的查询链路验证子模块的一个示例的结构框图；
图12是根据本公开一个实施例的账户状态查询装置的结构框图；
图13是根据本公开的一个实施例的用于实现账户状态存在性证明方法的计算设备 的结构框图；以及
图14是根据本公开的一个实施例的用于实现账户状态查询方法的计算设备的结构框图。
具体实施方式
以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本公开内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
在本文中，术语“相连”是指两个组件之间直接机械连接、连通或电连接，或者通过中间组件来间接机械连接、连通或电连接。术语“电连接”是指两个组件之间可以进行电通信以进行数据/信息交换。同样，所述电连接可以指两个组件之间直接电连接，或者通过中间组件来间接电连接。所述电连接可以采用有线方式或无线方式来实现。
现在结合附图来描述本公开的账户状态存在性证明方法及装置和账户状态查询方法及装置。
在本公开中，客户端可以是区块链系统中的SPV节点，区块链节点是指全量区块链节点。SPV节点在进行交易验证时并不会下载全部的区块链数据，而只是下载区块链中各个区块的块头，这条由块头组成的块头链不包含具体的交易数据。各个区块的块头包括该区块的状态根。状态根是指在每个区块上的状态树的根节点的哈希值。SPV节点对与该节点相关的未验证交易进行交易验证，该交易验证为SPV验证(简单交易支付验证)。全量区块链节点是指不仅拥有块头，并且拥有区块链的全部交易数据的节点。
当发生了一笔与该SPV节点相关的交易时，SPV节点会向全量区块链节点发送状态查询请求，以查询与待验证交易相关的账户状态。全量区块链节点响应于状态查询请求，将针对相应账户状态的查询结果返回给SPV节点。SPV节点可以基于所接收到的查询结果进行SPV验证。
SPV验证通常分为两个过程，其中一个过程是存在性证明过程，另一过程为状态正确性证明。本公开的以下实施适用于SPV验证中的存在性证明过程。存在性证明是指对待验证交易存在于相应区块上进行证明。对交易进行验证的过程，相当于对与交易相关的账户状态进行验证的过程。
除了对待验证交易执行SPV验证以外，本公开还可以适用于客户端查询与该客户端关联的账户状态时，对所查询到的账户状态进行存在性证明。当客户端查询相关账户状态时，也需要对账户状态进行存在性证明。
在本说明书中，术语“节点”是指状态树中的各个数据节点。
图1是根据本公开的一个实施例的账户状态存在性证明方法和账户状态查询方法的应用示例的流程图。在该示例中，账户状态存在性证明方法由客户端执行，账户状态查询方法由区块链节点执行。
如图1所示，在块120，客户端向区块链节点发送状态查询请求，状态查询请求包括目标区块的区块编号。当客户端想要查询某一区块上的相应账户状态时，该区块即目标区块。该被查询的账户即待证明账户。例如，待证明账户可以是待验证交易所对应的账户。
区块链节点在接收到状态查询请求后，在块140，基于状态查询请求中的区块编号，从目标区块的状态树中查询待查询账户状态，以得到账户状态数据。
账户状态数据包括在状态树中的账户状态查询路径上的各个节点的节点信息，节点包括非叶子节点和叶子节点。非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息。叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，状态实体包括待证明账户的账号信息(即账户地址)。状态实体还可以包括账户余额(Balance)、恢复密钥(Recovery Key)、随机数(Nonce)等信息。
图2是用于说明在状态树中的查询路径的示意图。图2以MPT树为例示出了状态树的结构。如图2所示，根节点是指在状态树中最顶端的节点(节点A)，叶子节点是 指在状态树的最底端的节点(节点D1～D8)。在本公开中，根节点和叶子节点之间的节点被称为中间节点(节点B1～B2、C1～C4)。每个区块上的MPT树存储有到该区块被生成时区块链的世界状态(即所有账户状态)，其中各个账户状态被存储于叶子节点中的状态实体中。
如果待证明账户的账户状态存储于叶子节点D1，则针对该账户状态的查询路径为A-B1-C1-D1。
下一节点的哈希值指示信息可以是下一节点的哈希值。在另一示例中，下一节点的哈希指示信息可以是下一节点的哈希值在该节点中的存储索引。在状态树中，对于各个节点，该节点的节点数据中包括该节点的下一节点的哈希值。以图2为例，节点B1和B2的哈希值存储在节点A的节点数据中、节点C1和C2的哈希值存储在节点B1的节点数据中。在该示例中，在查询路径A-B1-C1-D1中，节点A的节点信息可以包括节点A的节点数据、节点B1的哈希值在节点A的节点数据中的起始索引和终止索引。由此，可以基于起始索引和终止索引来从节点A的节点数据中提取出节点B1的哈希值。
哈希值本身占用数据空间较大，而存储索引所占用的数据空间明显小于哈希值，因而当哈希值提示信息为存储索引时，能够明显降低数据传输占用的资源。
作为示例，账户状态数据的字段可以是StateProof<state_node[]>，State_Node[]是指查询路径上的各个节点的节点信息所组成的集合。对于查询路径A-B1-C1-D1，State_Node[]为包括State_Node[0](节点A的节点信息)、State_Node[1](节点B1的节点信息)、State_Node[2](节点C1的节点信息)、State_Node[3](节点D1的节点信息)。每个非叶子节点(A～C1)的节点信息字段可以为StateNode<data,next_key_begin_index,next_key_end_index>，data为该节点的节点数据，next_key_begin_index为该节点的下一节点的哈希值在data中的起始索引，next_key_end_index为该节点的下一节点的哈希值在data中的终止索引。在data中起始索引和终止索引之间的字段为下一节点的哈希值。某节点的“下一节点”是指在相应查询路径中该节点的下一个节点，例如节点B1的下一节点是节点C1，节点C1的下一节点是节点D1。
此外，叶子节点D1的节点信息中的状态实体指示信息可以是状态实体在叶子节点的节点信息的存储索引，也可以是状态实体本身。当状态实体指示信息为存储索引时，叶子节点D1的节点信息字段可以为StateNode<data,begin_index,end_index>，data为叶子节点D1的节点数据，begin_index为状态实体在节点D1的data中的起始索引， end_index状态实体在节点D1的data中的终止索引。该起始索引和终止索引之间的字段为状态实体。
在查询到相应账户状态时，在块160，区块链节点将查询得到的账户状态数据发送给客户端。
客户端在接收到区块链节点发送的账户状态数据之后，在块180，基于所接收的账户状态数据，对待证明账户的账户状态执行存在性证明。
接下来，参考图3至图6对存在性证明执行过程进行说明。
图3是根据本公开的一个实施例的账户状态存在性证明方法中的存在性证明执行过程的流程图。
如图3所示，在块302和块304，基于目标区块中存储的状态根和查询路径中的根节点的节点数据，确定查询路径中的根节点是否正确。
客户端可以在本地存储想要查询哪个区块上的账户状态，然后可以基于本地存储的目标区块的区块编号，从已下载的块头链上获取相应区块的状态根。在一个示例中，区块链节点返回给客户端的账户状态数据可以包括目标区块的区块编号。此时，账户状态数据的字段可以为StateProof<block_NUM，state_node[]>，block_NUM为目标区块的区块编号。在该示例中，可以基于账户状态数据中的区块编号来从块头链上查询得到目标区块的状态根。由此，客户端不需要访问本地存储空间或进行其它操作以获取区块编号。
在获取到目标区块的状态根之后，可以对根节点的节点数据做哈希运算，以得到根节点的哈希值。在本公开中采用的哈希运算的算法与相应区块链上生成状态树时所使用的算法一致。例如，如果在生成状态树时使用的是SHA256算法，则在存在性证明过程中使用的也是SHA256算法。
然后，可以比较运算得到的根节点的哈希值是否与从区块链上获取的目标区块的状态根一致，如果一致则表明根节点是正确的。如果比较结果为不一致，则表明查询路径的根节点不正确。
在根节点被确定为正确时，在块306和块308基于各个节点的节点信息，确定查询路径是否正确。当根节点和查询路径均为正确时，可以确定针对待查询账户状态的查询路径是存在的。对查询路径进行验证的示例将在后述参考图5进行说明。
在查询路径被确定为正确时，在块310，在查询路径被确定为正确时，对状态实体指示信息所指示的状态实体进行解码，以得出状态实体中的账号信息。状态实体中的账号信息有时不是信息本身，而是采用特定编码方法(例如RLP编码)对信息本身进行编码后的信息。在该情形下，需要对状态实体进行解码，例如当状态实体用RLP编码进行编码时，可以用对应的解码方法进行解码。解码后即可得到状态信息的信息本身，进而可从中获取账号信息。
如果状态实体未经编码时，也可以不执行块310的解码操作。因此，块310的操作是不是必不可少的。
接下来，在块312，基于叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定待证明账户的账户状态的存在性。
如果状态实体中的账号信息与客户端处的待证明账户的账号信息一致(账号地址一致)，则可确定待证明账户的账户状态存在目标区块中。
如果根节点的验证结果为不正确、或查询路径的验证结果不正确、或状态实体中的账号信息与客户端处存在的账号信息不一致，则表明待证明账户状态不存在于目标区块上。
在一个示例中，区块链节点向客户端发送的账户状态数据还可以包括目标区块的状态根。此时，账户状态数据的字段可以为StateProof<state_root，state_node[]>或StateProof<block_NUM，state_root，state_node[]>，state_root为目标区块的状态根。在该示例中，可以采用如图4所示的示例来验证根节点。图4是根据本公开的一个实施例的账户状态存在性证明方法中的根节点验证过程的流程图。
如图4所示，在块402中，从区块链上获取目标区块的状态根。如前所述，可以基于目标区块的区块编号从所下载的块头链上查询得到目标区块的状态根。
在从区块链上获取状态根之后，在块404和块406，基于从区块链上获取的状态根，确定账户状态数据中的状态根是否正确。当从区块链上获取的状态根与账户状态数据中的状态根一致时，可以确定账户状态数据中的状态根是正确的。
当账户状态数据中的状态根为正确时，在块408，基于账户状态数据中的状态根和根节点的节点数据，确定根节点是否正确。如果账户状态数据中的状态根不正确，则表明账户状态不存在。此时可以不必继续执行后续操作。
图5是根据本公开的一个实施例的账户状态存在性证明方法中的路径验证过程的 流程图。
如图5所示，在块502，针对查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和下一节点的节点信息中的节点数据，确定该查询链路是否正确。每条查询链路包括相邻的两个节点。
如图2所示，在查询路径A-B1-C1-D1中，包括A-B1、B1-C1、C1-D1三个查询链路。其中节点A、节点B1、节点C1分别是各个查询链路的开始节点，节点B1、节点C1、节点D1分别是上述各个查询链路的结束节点，或可称为节点A、节点B1、节点C1的下一节点。作为示例，对于查询链路A-B1，可以基于节点A的节点信息中针对节点B1的哈希值指示信息和节点B1的节点信息的节点数据来确定查询链路A-B1是否正确。
可以使用如图6所示的示例来确定各个查询链路是否正确。图6是根据本公开的一个实施例的账户状态存在性证明方法中的查询链路验证过程的流程图。
如图6所示，在块602，基于查询链路中开始节点的节点信息中的针对下一节点的哈希值指示信息，获取下一节点的第一哈希值。如果哈希值指示信息是哈希值本身，则可以从账户状态数据中读取下一节点的第一哈希值。如果哈希值指示信息是存储索引，则可以基于节点B1的哈希值在节点A的节点数据中的存储索引，来从节点A的节点数据中获取节点B1的第一哈希值。在块604，对下一节点的节点信息中的节点数据进行哈希处理，以得到所述下一节点的第二哈希值。然后，在块606，确定第一哈希值是否与第二哈希值相等。在下一节点的第一哈希值和第二哈希值相等时，在块608，确定该查询链路是正确的。否则，在块610，确定该查询链路不正确。
区块链节点发送给客户端的账户状态数据中虽然包括了在前节点的下一节点的哈希值指示信息，但该信息是否正确，需要客户端来进行验证。当在前节点中的针对下一节点的哈希值指示信息与其下一节点的节点数据的哈希值一致时，可以确定该查询链路是之间是能够连接上的。
在对单条查询链路进行验证后，在块504，判断查询路径中的每条查询链路是否均正确。
当查询路径中的每条查询链路均正确时，则表明查询路径中的每个节点均能够与相邻节点连接。此时，在块506，确定查询路径是正确的。如果查询路径中存在不正确的查询链路，则在块508，确定查询路径不正确。
在一个示例中，可以从根节点所在的查询链路开始，依次验证各个查询链路是否正确，也可以并行验证各个查询链路。此外，还可以在确定出其中一条查询链路不正确时，不再继续验证其它查询链路。此时，可以确定查询路径是不正确的。
图7是根据本公开的一个实施例的账户状态存在性证明装置的结构框图。如图7所示，账户状态存在性证明装置700包括状态数据接收单元710和存在性证明执行单元720。
状态数据接收单元710配置为从区块链节点接收目标区块上的待证明账户的账户状态数据，账户状态数据是由所述区块链节点响应于客户端所发送的账户状态查询请求而从目标区块的状态树中查询出的。存在性证明执行单元720被配置为基于所接收的账户状态数据，对待证明账户的账户状态执行存在性证明。
账户状态数据包括在状态树中的账户状态查询路径上的各个节点的节点信息，节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，状态实体包括待证明账户的账户信息。
图8是图7所示的账户状态存在性证明装置700中的存在性证明执行单元720的一个示例的结构框图。存在性证明执行单元720包括根节点验证模块721、路径验证模块722、状态实体解码模块732和状态验证模块724。
根节点验证模块721被配置为基于目标区块中存储的状态根和查询路径中的根节点的节点数据，确定查询路径中的根节点是否正确。在根节点被确定为正确时，路径验证模块722基于各个节点的节点信息，确定查询路径是否正确。
如果状态实体是被编码后的信息，则在查询路径被确定为正确时，状态实体解码模块723可以对状态实体指示信息所指示的状态实体进行解码，以得出状态实体中的账号信息。如果状态实体中的信息是未编码的信息本身，则不需要解码过程。此时可以不包括状态实体解码模块。
在获取到状态实体中的账号信息时，状态验证模块724基于叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定待证明账户的账户状态的存在性。如果不需要执行解码，则状态验证模块724可以被置为在查询路径被确定为正确时，执行账户状态存在性确定过程。
图9是图8所示的根节点验证模块的一个示例的结构框图。在该示例中，账户状态数据还包括目标区块的状态根。如图9所示，根节点验证模块721包括状态根获取子模块7211、状态根验证子模块7212和根节点验证子模块7213。
状态根获取子模块7211被配置为从区块链上获取目标的状态根。账户状态数据中还可以包括目标区块的区块编号，此时可以基于账户状态数据中的区块编号从区块链上获取目标区块的状态根。状态根验证子模块7212被配置为基于从区块链上获取的状态根，确定状态账号数据中的状态根是否正确。当账户状态数据中的状态根被确定为正确时，根节点验证子模块7213基于账户状态数据中的状态根和根节点的节点数据，确定根节点是否正确。
图10是图8所示的路径验证模块722的一个示例的结构框图。如图10所示，路径验证模块722包括查询链路验证子模块7221和路径验证子模块7222。
查询链路验证子模块7221被配置为针对查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和下一节点的节点信息中的节点数据，确定该查询链路是否正确，每条查询链路包括相邻的两个节点。路径验证子模块7222被配置为在查询路径中的所有查询链路被确定为是正确时，确定查询路径正确。
图11是图10所示的查询链路验证子模块7221的一个示例的结构框图。如图11所示，查询链路验证子模块7221包括第一哈希值确定子模块7223、第二哈希值确定子模块7224和链路验证子模块7225。
第一哈希值确定子模块7223被配置为基于开始节点的节点信息中的针对下一节点的哈希值指示信息，获取下一节点的第一哈希值。第二哈希值确定子模块7224被配置为对下一节点的节点信息中的节点数据进行哈希处理，以得到下一节点的第二哈希值。链路验证子模块7225被配置为在下一节点的第一哈希值和第二哈希值相等时，确定该查询链路是正确的。
图12是根据本公开一个实施例的账户状态查询装置的结构框图。如图12所示，状态查询装置1200包括查询请求接收单元1210、状态查询单元1220和查询数据发送单元1230。
查询请求接收单元1210被配置为接收客户端针对待查询账户状态的状态查询请求，状态查询请求包括目标区块的区块编号。状态查询单元1220被配置为响应于状态查询 请求，基于区块编号，从目标区块的状态树中查询待查询账户状态，以得到账户状态数据。查询数据发送单元1230被配置为向客户端发送账户状态数据。其中，账户状态数据的具体内容可以参见如上实施例的描述。
以上参照图1到图12，对根据本公开的账户状态存在性证明方法及装置和账户状态查询方法及装置的实施例进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本公开的装置的实施例。
本公开的账户状态存在性证明装置和账户状态查询装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。在以上对方法实施例的描述中所提及的细节，同样适用于本公开的装置的实施例。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见。
本公开的账户状态存在性证明装置和账户状态查询装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将存储器中对应的计算机程序指令读取到内存中运行形成的。在本公开中，账户状态存在性证明装置和账户状态查询装置例如可以利用计算设备实现。
图13是根据本公开的一个实施例的用于实现账户状态存在性证明方法的计算设备1300的结构框图。如图13所示，计算设备1300包括处理器1310、存储器1320、内存1330、通信接口1340和内部总线1350。根据一个实施例，计算设备1300可以包括至少一个处理器1310，该至少一个处理器1310执行在计算机可读存储介质(即，存储器1320)中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器1320中存储计算机可执行指令，其当执行时使得至少一个处理器1310：从区块链节点接收目标区块上的待证明账户的账户状态数据，所述账户状态数据是由所述区块链节点响应于客户端所发送的账户状态查询请求而从所述目标区块的状态树中查询出的；以及基于所接收的账户状态数据，对所述待证明账户的账户状态执行存在性证明。
应该理解，在存储器1320中存储的计算机可执行指令当执行时使得至少一个处理器1310进行本公开的各个实施例中以上结合图1-11描述的针对账户状态存在性证明方法及装置的各种操作和功能。
图14是根据本公开的一个实施例的用于实现账户状态查询方法的计算设备1400 的结构框图。如图14所示，计算设备1400包括处理器1410、存储器1420、内存1430、通信接口1440和内部总线1450。根据一个实施例，计算设备1400可以包括至少一个处理器1410，该至少一个处理器1410执行在计算机可读存储介质(即，存储器1420)中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器1420中存储计算机可执行指令，其当执行时使得至少一个处理器1410：接收客户端针对待查询账户状态的状态查询请求，所述状态查询请求包括目标区块的区块编号；响应于所述状态查询请求，基于所述区块编号，从所述目标区块的状态树中查询所述待查询账户状态，以得到账户状态数据；以及向所述客户端发送所述账户状态数据。
应该理解，在存储器1420中存储的计算机可执行指令当执行时使得至少一个处理器1410进行本公开的各个实施例中以上结合图1-2和图12描述的针对账户状态查询方法和装置的各种操作和功能。
根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本公开的各个实施例中以上结合图1-11描述的针对账户状态存在性证明方法及装置的各种操作和功能。
根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本公开的各个实施例中以上结合图1-2和图12描述的针对账户状态查询方法和装置的各种操作和功能。
具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。
可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
以上结合附图详细描述了本公开的实施例的可选实施方式，但是，本公开的实施例并不限于上述实施方式中的具体细节，在本公开的实施例的技术构思范围内，可以对本公开的实施例的技术方案进行多种简单变型，这些简单变型均属于本公开的实施例的保护范围。
本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (22)

  1. 一种对目标区块上的账户状态进行存在性证明的方法，包括：
    从区块链节点接收目标区块上的待证明账户的账户状态数据，所述账户状态数据是由所述区块链节点响应于客户端所发送的账户状态查询请求而从所述目标区块的状态树中查询出的；以及
    基于所接收的账户状态数据，对所述待证明账户的账户状态执行存在性证明，
    其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
  2. 如权利要求1所述的方法，其中，基于所接收的账户状态数据来对所述待证明账户的账户状态执行存在性证明包括：
    基于所述目标区块中存储的状态根和所述查询路径中的根节点的节点数据，确定所述查询路径中的根节点是否正确；
    在所述根节点被确定为正确时，基于所述各个节点的节点信息，确定所述查询路径是否正确；以及
    在所述查询路径被确定为正确时，基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性。
  3. 如权利要求2所述的方法，其中，在基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性之前，基于所接收的账户状态数据来对所述待证明账户的账户状态执行存在性证明还包括：
    在所述查询路径被确定为正确时，对所述状态实体指示信息所指示的状态实体进行解码，以得出所述状态实体中的账号信息。
  4. 如权利要求2所述的方法，其中，所述账户状态数据还包括所述目标区块的状态根，基于所述目标区块中存储的状态根和所述查询路径中的根节点的节点数据，确定所述查询路径的根节点是否正确包括：
    从区块链上获取所述目标区块的状态根；
    基于从所述区块链上获取的状态根，确定所述状态账号数据中的状态根是否正确； 以及
    当所述状态账号数据中的状态根被确定为正确时，基于所述账户状态数据中的状态根和所述根节点的节点数据，确定所述根节点是否正确。
  5. 如权利要求2-4中任一项所述的方法，其中，基于所述各个节点的节点信息，确定所述查询路径是否正确包括：
    针对所述查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和所述下一节点的节点信息中的节点数据，确定该查询链路是否正确，每条查询链路包括相邻的两个节点；以及
    在所述查询路径中的所有查询链路被确定为是正确时，确定所述查询路径正确。
  6. 如权利要求5所述的方法，其中，针对所述查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和所述下一节点的节点信息中的节点数据，确定该查询链路是否正确包括：
    基于所述开始节点的节点信息中的针对下一节点的哈希值指示信息，获取所述下一节点的第一哈希值；
    对所述下一节点的节点信息中的节点数据进行哈希处理，以得到所述下一节点的第二哈希值；以及
    在所述下一节点的第一哈希值和第二哈希值相等时，确定该查询链路是正确的。
  7. 如权利要求2-4中任一项所述的方法，其中，所述下一节点的哈希值指示信息是所述下一节点的第一哈希值在所述开始节点的节点数据中的存储索引。
  8. 如权利要求2-4中任一项所述的方法，其中，所述账户状态数据还包括所述目标区块的区块编号，所述目标区块的状态根是基于所述区块编号从所述区块链上获取的。
  9. 一种账户状态查询方法，包括：
    接收客户端针对待查询账户状态的状态查询请求，所述状态查询请求包括目标区块的区块编号；
    响应于所述状态查询请求，基于所述区块编号，从所述目标区块的状态树中查询所述待查询账户状态，以得到账户状态数据；以及
    向所述客户端发送所述账户状态数据，
    其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实 体包括待证明账户的账户信息。
  10. 如权利要求9所述的方法，其中，所述状态查询数据还包括所述目标区块的状态根。
  11. 如权利要求9或10所述的方法，其中，所述状态查询数据还包括所述目标区块的区块编号。
  12. 一种对目标区块上的账户状态进行存在性证明的装置，包括：
    状态数据接收单元，被配置为从区块链节点接收目标区块上的待证明账户的账户状态数据，所述账户状态数据是由所述区块链节点响应于客户端所发送的账户状态查询请求而从所述目标区块的状态树中查询出的；以及
    存在性证明执行单元，被配置为基于所接收的账户状态数据，对所述待证明账户的账户状态执行存在性证明，
    其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
  13. 如权利要求12所述的装置，其中，所述存在性证明执行单元包括：
    根节点验证模块，被配置为基于所述目标区块中存储的状态根和所述查询路径中的根节点的节点数据，确定所述查询路径中的根节点是否正确；
    路径验证模块，被配置为在所述根节点被确定为正确时，基于所述各个节点的节点信息，确定所述查询路径是否正确；以及
    状态验证模块，被配置为在所述查询路径被确定为正确时，基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性。
  14. 如权利要求13所述的装置，其中，所述存在性证明执行还包括：
    状态实体解码模块，被配置为在基于所述叶子节点的状态实体指示信息所指示的状态实体中的账号信息和客户端处的待证明账户的账号信息，确定所述待证明账户的账户状态的存在性之前，在所述查询路径被确定为正确时，对所述状态实体指示信息所指示的状态实体进行解码，以得出所述状态实体中的账号信息。
  15. 如权利要求13所述的装置，其中，所述账户状态数据还包括目标区块的状态根，所述根节点验证模块包括：
    状态根获取子模块，被配置为从区块链上获取所述目标的状态根；
    状态根验证子模块，被配置为基于从所述区块链上获取的状态根，确定所述状态账号数据中的状态根是否正确；以及
    根节点验证子模块，被配置为当所述状态账号数据中的状态根被确定为正确时，基于所述账户状态数据中的状态根和所述根节点的节点数据，确定所述根节点是否正确。
  16. 如权利要求13-15中任一项所述的装置，其中，所述路径验证模块包括：
    查询链路验证子模块，被配置为针对所述查询路径中的每条查询链路，基于该查询链路中的开始节点的节点信息中的针对下一节点的哈希指示信息和所述下一节点的节点信息中的节点数据，确定该查询链路是否正确，每条查询链路包括相邻的两个节点；以及
    路径验证子模块，被配置为在所述查询路径中的所有查询链路被确定为是正确时，确定所述查询路径正确。
  17. 如权利要求16所述的装置，其中，所述查询链路验证子模块包括：
    第一哈希值确定子模块，被配置为基于所述开始节点的节点信息中的针对下一节点的哈希值指示信息，获取所述下一节点的第一哈希值；
    第二哈希值确定子模块，被配置为对所述下一节点的节点信息中的节点数据进行哈希处理，以得到所述下一节点的第二哈希值；以及
    链路验证子模块，被配置为在所述下一节点的第一哈希值和第二哈希值相等时，确定该查询链路是正确的。
  18. 一种账户状态查询装置，包括：
    查询请求接收单元，被配置为接收客户端针对待查询账户状态的状态查询请求，所述状态查询请求包括目标区块的区块编号；
    状态查询单元，被配置为响应于所述状态查询请求，基于所述区块编号，从所述目标区块的状态树中查询所述待查询账户状态，以得到账户状态数据；以及
    查询数据发送单元，被配置为向所述客户端发送所述账户状态数据，
    其中，所述账户状态数据包括在所述状态树中的账户状态查询路径上的各个节点的节点信息，所述节点包括非叶子节点和叶子节点，所述非叶子节点的节点信息包括该节点的节点数据以及该节点的下一节点的哈希值指示信息，所述叶子节点的节点信息包括该节点的节点数据和状态实体指示信息，状态实体指示信息指示状态实体，所述状态实体包括待证明账户的账户信息。
  19. 一种计算设备，包括：
    至少一个处理器；以及
    存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1到8中任一所述的方法。
  20. 一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到8中任一所述的方法。
  21. 一种计算设备，包括：
    至少一个处理器；以及
    存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求9到11中任一所述的方法。
  22. 一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求9到11中任一所述的方法。
PCT/CN2020/132055 2020-01-02 2020-11-27 账户状态存在性证明方法及装置和状态查询方法及装置 WO2021135756A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010002574.8 2020-01-02
CN202010002574.8A CN111177225B (zh) 2020-01-02 2020-01-02 账户状态存在性证明方法及装置和状态查询方法及装置

Publications (1)

Publication Number Publication Date
WO2021135756A1 true WO2021135756A1 (zh) 2021-07-08

Family

ID=70649216

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/132055 WO2021135756A1 (zh) 2020-01-02 2020-11-27 账户状态存在性证明方法及装置和状态查询方法及装置

Country Status (2)

Country Link
CN (1) CN111177225B (zh)
WO (1) WO2021135756A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111177225B (zh) * 2020-01-02 2023-05-23 支付宝(杭州)信息技术有限公司 账户状态存在性证明方法及装置和状态查询方法及装置
CN111984322B (zh) * 2020-09-07 2023-03-24 北京航天数据股份有限公司 一种控制指令传输方法及装置
CN113505138B (zh) * 2021-09-06 2021-12-21 支付宝(杭州)信息技术有限公司 区块链系统中状态证明及执行区块的方法及装置
CN114691686B (zh) * 2021-12-30 2023-03-24 北京连琪科技有限公司 生成区块状态承诺的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109885615A (zh) * 2019-01-24 2019-06-14 华东师范大学 一种基于索引的面向区块链轻客户端的范围查询可验证查询方法
CN110060064A (zh) * 2019-04-26 2019-07-26 深圳市网心科技有限公司 一种交易信息验证方法及相关装置
US20190363875A1 (en) * 2017-07-28 2019-11-28 Upheaval LLC Blockchain content reconstitution facilitation systems and methods
CN110602148A (zh) * 2019-10-10 2019-12-20 深圳前海微众银行股份有限公司 一种区块的状态树的生成和链上数据验证的方法及装置
CN111177225A (zh) * 2020-01-02 2020-05-19 支付宝(杭州)信息技术有限公司 账户状态存在性证明方法及装置和状态查询方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2524968A (en) * 2014-04-07 2015-10-14 Mastercard International Inc Method and system for facilitating a transaction
EP4254220A3 (en) * 2016-02-12 2023-11-29 Royal Bank Of Canada Methods and systems for digital reward processing
WO2017148527A1 (en) * 2016-03-03 2017-09-08 Nec Europe Ltd. Method for managing data in a network of nodes
CN108009810A (zh) * 2017-12-27 2018-05-08 光载无限（北京）科技有限公司 一种可信数字资产交易方法
US11487749B2 (en) * 2018-05-30 2022-11-01 Aenco Technologies Limited Method and system for verifying and maintaining integrity of data transactions using distributed ledger
CN109255010A (zh) * 2018-09-05 2019-01-22 明涛（保定）信息技术服务有限公司 一种区块链专利整理流程
CN109858281B (zh) * 2019-02-01 2020-09-18 杭州云象网络技术有限公司 一种基于零知识证明的区块链账户模型隐私保护方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190363875A1 (en) * 2017-07-28 2019-11-28 Upheaval LLC Blockchain content reconstitution facilitation systems and methods
CN109885615A (zh) * 2019-01-24 2019-06-14 华东师范大学 一种基于索引的面向区块链轻客户端的范围查询可验证查询方法
CN110060064A (zh) * 2019-04-26 2019-07-26 深圳市网心科技有限公司 一种交易信息验证方法及相关装置
CN110602148A (zh) * 2019-10-10 2019-12-20 深圳前海微众银行股份有限公司 一种区块的状态树的生成和链上数据验证的方法及装置
CN111177225A (zh) * 2020-01-02 2020-05-19 支付宝(杭州)信息技术有限公司 账户状态存在性证明方法及装置和状态查询方法及装置

Also Published As

Publication number Publication date
CN111177225B (zh) 2023-05-23
CN111177225A (zh) 2020-05-19

Similar Documents

Publication Publication Date Title
WO2021135756A1 (zh) 账户状态存在性证明方法及装置和状态查询方法及装置
CN113329031B (zh) 一种区块的状态树的生成方法及装置
EP3678346B1 (en) Blockchain smart contract verification method and apparatus, and storage medium
TWI737165B (zh) 跨鏈發送資源的方法和裝置
TWI733328B (zh) 跨鏈發送可認證訊息的方法和裝置
US10372942B1 (en) Method and server for providing notary service for file and verifying file recorded by notary service
US10924281B2 (en) Method and apparatus for inter-blockchain transmission of authenticable message
CN111047449B (zh) 在区块链中执行交易的方法及装置
CN110730225A (zh) 基于区块链的物联网的数据处理方法、物联网及存储介质
CN108572986B (zh) 一种数据更新的方法及节点设备
WO2014094441A1 (zh) 病毒检测方法及设备
CN112286963B (zh) 一种区块链终端数据可信查询系统及其实现方法
US20230177505A1 (en) Transaction Verification Method and Apparatus
EP3633519A1 (en) Method for storing objects, and object store gateway
CN112988819B (zh) 区块链交易执行方法、区块链节点及控制装置
WO2020258849A1 (zh) 一种跨链发送可认证消息的方法和装置
CN111309809A (zh) 一种区块头保存方法及其设备
CN116977067A (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质
CN112988818B (zh) 区块链交易执行方法、区块链节点及控制装置
CN112884588B (zh) 区块链交易执行方法、区块链节点及控制装置
CN111339089B (zh) 一种应用于区块链的数据存储与获取方法及装置
CN110377584A (zh) 一种基于元数据的数据结构版本兼容的存取方法及装置
CN109885259B (zh) 基于有向无环图的轻量级容量证明方法及存储介质
CN115082068B (zh) 支持聚合的最小默克尔证明生成及区块链交易验证方法
CN111178885B (zh) 基于区块链的数据处理方法、装置、数据处理设备及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20908945

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20908945

Country of ref document: EP

Kind code of ref document: A1