CN115795563A - State data checking method and device - Google Patents
State data checking method and device Download PDFInfo
- Publication number
- CN115795563A CN115795563A CN202211528784.6A CN202211528784A CN115795563A CN 115795563 A CN115795563 A CN 115795563A CN 202211528784 A CN202211528784 A CN 202211528784A CN 115795563 A CN115795563 A CN 115795563A
- Authority
- CN
- China
- Prior art keywords
- target
- state
- account
- leaf node
- data
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
One or more embodiments of the present specification provide a method and an apparatus for verifying status data. The method is applied to a block chain system and can comprise the following steps: searching a target leaf node corresponding to the state data to be checked in a state tree corresponding to the target block; each leaf node in the state tree is in one-to-one correspondence with each increment account subjected to state data updating based on the target block; the arrangement sequence of each leaf node in the state tree accords with an account sorting rule set for a global account; and under the condition that the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to a root node of the state tree, so as to generate an absence certification for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of block chaining technology, and in particular, to a method and an apparatus for checking status data.
Background
The block chain technology (also called as distributed account book technology) is a decentralized distributed database technology, has the characteristics of decentralization, openness and transparency, no tampering, trustiness and the like, and is suitable for application scenes with high requirements on data reliability.
In view of the above advantages of the blockchain technology, in order to ensure the security of data, a large amount of data is stored in the blockchain system, so as to prevent the data from being tampered.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for checking status data.
To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
according to a first aspect of one or more embodiments of the present specification, there is provided a status data checking method applied to a blockchain system, including:
searching a target leaf node corresponding to the state data to be checked in a state tree corresponding to the target block; each leaf node in the state tree corresponds to each increment account one by one, and each increment account is an account of which the state data is updated based on the target block in the global account; the arrangement sequence of each leaf node in the state tree accords with an account sorting rule set for the global account, and each leaf node is respectively maintained with increment state data obtained by updating the state data of a corresponding increment account;
and under the condition that the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to a root node of the state tree, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
According to a second aspect of one or more embodiments of the present specification, there is provided a status data evidence storing method applied to a blockchain system, including:
under the condition that the state data updating operation of a part of accounts in a global account is completed based on a target block, taking the part of accounts as increment accounts corresponding to the target block, and sequencing the increment accounts according to an account sequencing rule set for the global account;
constructing a state tree corresponding to the target block based on the sorted increment accounts so that the arrangement sequence of leaf nodes corresponding to each increment account in the state tree conforms to the account sorting rule;
and storing the incremental state data obtained by the state data updating operation to the leaf node corresponding to the incremental account.
According to a third aspect of one or more embodiments of the present specification, there is provided a status data checking method, applied to a client, including:
receiving an absence certification returned by a block chain system and used for proving that state data to be verified is not recorded in a state tree of a target block, and node data recorded on a path from an auxiliary leaf node to a root node, wherein the node data is acquired in the process of searching a target leaf node corresponding to the state data to be verified in the state tree; each leaf node of the target block corresponds to each increment account in a one-to-one manner, each increment account is an account of which the status data is updated based on the target block in the global accounts, the arrangement sequence of each leaf node in the status tree conforms to an account sorting rule set for the global accounts, and each leaf node is respectively maintained with increment status data obtained by updating the status data of the corresponding increment account;
and verifying the non-existence certification based on the node data recorded on the path, and determining that the state data to be verified is not recorded in the state tree corresponding to the target block under the condition that the verification is passed.
According to a fourth aspect of one or more embodiments of the present specification, there is provided a status data checking device applied to a blockchain system, including:
the searching unit is used for searching a target leaf node corresponding to the state data to be checked in the state tree corresponding to the target block; each leaf node in the state tree corresponds to each increment account in a one-to-one mode, and each increment account is an account of which the state data is updated based on the target block in the global account; the arrangement sequence of each leaf node in the state tree accords with an account sorting rule set for the global account, and each leaf node is respectively maintained with increment state data obtained by updating the state data of a corresponding increment account;
and the generating unit is used for determining auxiliary leaf nodes which are adjacent to the target leaf node after being sorted according to the account sorting rule in all the leaf nodes of the state tree under the condition that the target leaf node is not found, and determining a path from the auxiliary leaf node to a root node of the state tree, so as to generate an absence certification for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
According to a fifth aspect of one or more embodiments of the present specification, there is provided a status data evidence storing device applied to a blockchain system, including:
the sorting unit is used for taking the partial accounts as increment accounts corresponding to the target block under the condition that the state data updating operation of the partial accounts in the global account is completed based on the target block, and sorting the increment accounts according to an account sorting rule set for the global account;
the building unit is used for building a state tree corresponding to the target block based on the sorted increment accounts so as to enable the arrangement sequence of leaf nodes corresponding to each increment account in the state tree to accord with the account sorting rule;
and the evidence storing unit is used for storing the incremental state data obtained by the state data updating operation to the leaf node corresponding to the incremental account.
According to a sixth aspect of one or more embodiments of the present specification, there is provided a status data checking apparatus, applied to a client, including:
the receiving unit is used for receiving an absence proof which is returned by the block chain system and is used for proving that the state data to be verified is not recorded in a state tree of a target block, and node data which is recorded on a path from an auxiliary leaf node to a root node and is acquired in the process of searching a target leaf node corresponding to the state data to be verified in the state tree; each leaf node of the target block corresponds to each increment account in a one-to-one manner, each increment account is an account of which the status data is updated based on the target block in the global accounts, the arrangement sequence of each leaf node in the status tree conforms to an account sorting rule set for the global accounts, and each leaf node is respectively maintained with increment status data obtained by updating the status data of the corresponding increment account;
and the checking unit is used for checking the non-existence certification based on the node data recorded on the path and determining that the state data to be checked is not recorded in the state tree corresponding to the target block under the condition that the check is passed.
According to a seventh aspect of one or more embodiments of the present specification, there is provided an electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method according to any one of the first, second and third aspects by executing the executable instructions.
According to an eighth aspect of one or more embodiments of the present specification, a computer-readable storage medium is presented, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the method according to any one of the first, second and third aspects.
Drawings
Fig. 1 is a flowchart of a status data evidence storing method according to an exemplary embodiment.
FIG. 2 is a flowchart of a method for verifying status data according to an exemplary embodiment.
FIG. 3 is a flow chart of another method for verifying state data in accordance with an illustrative embodiment.
FIG. 4 is a flowchart of a method for constructing a Mercker tree in accordance with an illustrative embodiment.
FIG. 5 is a diagram of a constructed Mercker tree, according to an exemplary embodiment.
FIG. 6 is a diagram of another constructed Merck tree that is provided in an exemplary embodiment.
FIG. 7 is a block diagram of a constructed Merck tree of blocks according to an exemplary embodiment.
FIG. 8 is a flowchart of a state data lookup method provided by an exemplary embodiment.
FIG. 9 is a schematic diagram of a path between an auxiliary leaf child node and a root node, provided by an exemplary embodiment.
FIG. 10 is a diagram of a Merck tree maintained in a block chain system, according to an exemplary embodiment.
FIG. 11 is a schematic diagram of a path between a target leaf node and a root node in accordance with an illustrative embodiment.
Fig. 12 is a schematic structural diagram of an apparatus provided in an exemplary embodiment.
Fig. 13 is a block diagram of a status data checking apparatus according to an exemplary embodiment.
Fig. 14 is a block diagram of a status data evidence storage device according to an exemplary embodiment.
FIG. 15 is a block diagram of another state data checking device provided by an exemplary embodiment.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims that follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
In view of the characteristics of the blockchain technology such as decentralization and non-tampering, more and more users choose to store data in the blockchain system to ensure the security of the data. The data maintained in the blockchain system may include blockdata and status data, where the blockdata refers to: packaging the transaction data into blocks; the state data is multi-finger: data for recording transaction execution results, which are continuously updated along with the transaction execution, is usually recorded in the state tree of the corresponding block.
Since the state data is continuously updated along with the transaction, if the blockchain system needs to search for the target state data, it is necessary to prove that the searched data is the latest version of the target state data, i.e., it is necessary to perform version certification. In the actual searching process, the block chain system needs to search the state trees of a plurality of blocks until the target state data is found in the specific state tree of a specific block, and in order to prove that the found target state data is the latest version, the block chain system needs to prove that: no target state data is found in the other looked up state trees except the specific state tree, i.e. no proof corresponding to the other looked up state trees needs to be generated. It should be understood that, since the state tree of the newly generated block is preferentially searched by the blockchain system in the process of searching the target state data, the target state data searched in the specific state tree can be proved to be the latest version only by proving that the target state data is not searched in other searched state trees.
In the related art, there are various ways to generate a non-existence proof for proving that the target state data is not found in a particular state tree. For example, the related art may construct the state tree of each block by using the mercker tree or the MPT tree, so that when no target state data is found in the mercker tree or the MPT tree of a certain block, the absence certificate corresponding to the mercker tree or the MPT tree may be generated. Specifically, the related art needs to recalculate the root hash based on hash values of all nodes recorded in the mercker tree or MPT and compare the root hash with the root hash recorded in the root node. If the comparison result shows that the two are consistent, the data in the Merckel tree or the MPT tree is proved to be complete and not to be tampered, and further, the search result of the target state data which is not searched is proved to be reliable.
It is easy to see that, in the related art, the absence proof for proving that the target state data is not recorded in the state tree can be generated only by acquiring the node data of all nodes in the state tree, so that when the absence proof is generated, the related art has a large data calling amount, a high calculation cost, and occupies a large number of block chain processing resources.
In addition, for a user searching for state data, the user may not completely trust the non-existent certification provided by the blockchain system, wherein when the user does not trust the non-existent certification, the user needs to check the non-existent certification on the client side, and in order to meet the checking requirement of the user, the blockchain system needs to return all node data of the entire state tree to the client. In this case, the related art also has a problem of occupying a large bandwidth.
Therefore, the present specification provides a state data verification method, which can generate an absence certification for certifying that target state data is not recorded in a state tree only by acquiring node data of a part of nodes in the state tree, thereby avoiding a problem that a related art needs to acquire node data of all nodes in the entire state tree to generate the absence certification, which results in occupation of more block chain processing resources.
Before introducing the state data checking method, since the way of constructing the state tree in the present specification is different from the related art to some extent, how to construct the state tree in the present specification is first described to introduce the state data of the account.
Fig. 1 is a flowchart illustrating a status data evidence storing method according to an exemplary embodiment of the present disclosure. The method is applied to a block chain system, as shown in fig. 1, and may include the following steps:
and 102, under the condition that the status data updating operation of a part of accounts in the global account is completed based on the target block, taking the part of accounts as increment accounts corresponding to the target block, and sequencing the increment accounts according to an account sequencing rule set for the global account.
It is noted that, whether the status trees of the blocks are constructed by the merkel tree or the MPT tree, the related art maintains the status data of the full account in the status tree of each block. In other words, the status tree of each block maintains the status data of all registered accounts in the blockchain system. It is particularly emphasized that although in the case of constructing the state tree from MPT trees, the MPT trees of the other blocks than the created block appear to be in the form of not recording the state data of the full account, the state data of the full account is recorded by referencing the MPT tree of the previous block.
It should also be noted that, in the related art, when all the state data of the full-size account is recorded through the merkel tree or the MPT tree, the plurality of leaf nodes corresponding to the respective accounts are unordered. The concrete expression is as follows: for example, the position of the account a in the status tree 1 'of the block1 may be the first position from left to right, but the position of the account a in the status tree 2' of the block 2 may be the fourth position from left to right.
It is because the related art constructs the state tree in the above manner, so that when the proof of absence needs to be generated, all the node data recorded in the corresponding state tree needs to be acquired.
In view of this, when building a status tree for a block, the present specification does not record status data of all accounts, but only records updated status data of accounts updated based on the status data of the block. In this specification, a block for which a status tree needs to be built is referred to as a target block, an account for which status data update occurs based on the target block is referred to as an incremental account, and updated status data obtained by a status data update operation is referred to as incremental status data. In other words, in the present specification, only the incremental status data of the incremental account is recorded in the status tree constructed for the target block.
In addition to recording only incremental status data in the status tree, the present specification also sets account sorting rules for the full account in advance. Therefore, after the incremental accounts are determined, the present specification may preferentially sort the incremental accounts based on the account sorting rule, and construct a state tree based on the sorted incremental accounts, so that the arrangement order of the leaf nodes in the state tree conforms to the account sorting rule. On the basis, each increment state data can be stored into the leaf node corresponding to the increment account. It should be noted that the account sorting rule used in this specification may be set by a person skilled in the art according to actual needs, for example, the sorting may be performed according to the account number of the account, or the sorting may be performed according to the alphabetical order of the account address, which is not limited in this specification.
After the state tree is constructed according to the technical solution of the present specification, when the state data to be verified is not recorded in the state tree of the target block, an absence certification for certifying that the state data is not recorded in the state tree may be generated. In this specification, the status data that needs to be verified may be referred to as the status data to be verified.
In this specification, a target leaf node corresponding to state data to be verified may be preferentially searched in a state tree of a target block, if the target leaf node is not found, an auxiliary leaf node that is adjacent to the target leaf node after being sorted according to an account sorting rule is determined from all leaf nodes of the state tree, and a path from the auxiliary leaf node to a root node is determined, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to node data recorded on the path.
It should be understood that, because the state tree in this specification only records incremental state data, and the arrangement order of each leaf node is consistent with the order of the incremental accounts after being sorted according to the account sorting rule, it is only necessary to obtain node data recorded on a path from an auxiliary leaf node adjacent to a target leaf node to a root node, and it can be determined whether each auxiliary leaf node is directly adjacent in the state tree, and if the auxiliary leaf node is directly adjacent, it is verified that the state data to be verified is not stored in the state tree. Therefore, according to the technical scheme of the specification, the non-existence proof of the state tree in which the state data to be verified is not stored in the target block can be generated only by acquiring the node data recorded on the path from the auxiliary leaf node adjacent to the target leaf node to the root node, and the problem that the non-existence proof can be generated only by acquiring all the node data in the whole state tree in the related art, so that more block chain processing resources are occupied is solved.
In this specification, the node data recorded in each node in the state tree may be a hash value. On the basis, after the path from the auxiliary leaf node to the root node is determined, the hash value of the auxiliary leaf node and the hash values of the brother nodes of all the intermediate nodes on the path can be obtained, and the root hash of the state tree is calculated according to the root hash calculation rule of the state tree. After the root hash is obtained through calculation, the root hash can be compared with the root hash recorded in the root node, and if the comparison result shows that the root hash obtained through calculation is consistent with the root hash recorded in the root node, an absence proof used for proving that the state data to be verified is not recorded in the state tree can be generated based on the comparison result.
The node data in the state tree may be the account itself, in addition to the hash value. For example, the account addresses of the corresponding accounts may be recorded in leaf nodes, and hash values may be recorded in intermediate nodes, and the hash value of each intermediate node may be a hash value calculated after merging of the subordinate at least one child node, for example, for a parent node of two adjacent leaf nodes, the recorded node data may be "a hash value calculated after merging the account addresses recorded by two leaf nodes".
Of course, the above examples are only illustrative, and the node data recorded in the state tree may be determined by those skilled in the art according to actual needs, and the description is not limited thereto.
And 104, constructing a state tree corresponding to the target block based on the sorted increment accounts so that the arrangement sequence of leaf nodes corresponding to the increment accounts in the state tree conforms to the account sorting rule.
In this specification, after the state tree of the target block is constructed in the above manner, in a case where the state data to be verified is not found in the state tree, an absence certification for certifying that the state data to be verified is not stored in the state tree of the target block may be generated.
In an embodiment, when it is required to check whether the state data to be checked is recorded in the state tree of the target block, the target leaf node corresponding to the state data to be checked may be directly searched in the state tree.
When the target leaf node is not found, preferentially determining auxiliary leaf nodes adjacent to the target leaf node in all leaf nodes of the state tree after sorting according to an account sorting rule as described above, and determining a path from the auxiliary leaf node to a root node of the state tree, so as to generate an absence certificate for proving that the state data to be verified is not recorded in the state tree according to node data recorded on the path; and under the condition that the target leaf node is found, determining a path from the target leaf node to the root node, and generating an existence certification for certifying that the state data to be verified is recorded in the state tree according to the node data recorded on the path.
In another embodiment, in building the status tree for the target block, in addition to building the status tree corresponding to the target block according to the sorted delta accounts, a bloom filter may be generated based on the sorted delta accounts. The bloom filter may be used to check whether a target account corresponding to the state data to be checked is an incremental account corresponding to a leaf node in the state tree, that is, to check whether a target leaf node corresponding to the state data to be checked exists in the state tree. It should be noted that, after sorting the incremental accounts, the present specification may use any existing method to generate a bloom filter corresponding to the target block, which is not limited in this embodiment.
In this embodiment, when it is required to check whether the to-be-checked state data is recorded in the state tree of the target block, the bloom filter may be invoked preferentially, and the target account corresponding to the to-be-checked state data is input into the bloom filter to obtain an initial checking result. And when the initial verification result shows that the leaf node corresponding to the target account exists in the state tree, executing the operation of searching the target leaf node in the state tree.
It should be emphasized that the bloom filter is prone to misjudgment, that is, when the initial check result indicates that a leaf node corresponding to the target account exists in the state tree, the leaf node does not actually exist, which is also called a false positive problem of the bloom filter. Therefore, when the initial verification result indicates that the leaf node corresponding to the target account does not exist in the state tree, an absence proof for proving that the state data to be verified is not recorded in the state tree can be directly generated based on the initial verification result; and when the initial verification result shows that the leaf node corresponding to the target account exists in the state tree, secondarily verifying whether the leaf node corresponding to the target account exists in the state tree or not based on the state tree.
In the process of the secondary verification, as described above, the target leaf node corresponding to the state data to be verified is preferentially searched in the state tree. If the target leaf node is found, determining a path from the target leaf node to a root node in the state tree, and generating a presence certificate for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path; if the target leaf node is not found, the auxiliary leaf nodes adjacent to the target leaf node after being sorted according to the account sorting rule in all the leaf nodes of the state tree can be determined, and a path from the auxiliary leaf node to the root node is determined, so that an absence certificate for proving that the state data to be verified is not recorded in the state tree is generated according to the node data recorded on the path.
In other words, in the case that the bloom filter is created based on the sorted delta accounts, before searching for the target leaf node corresponding to the status data to be checked, it may be prioritized to preliminarily check whether the target leaf node exists in the status tree of the target block based on the bloom filter. Under the condition that the initial check result shows that the data does not exist, the non-existence proof can be directly generated based on the initial check result without additionally generating the non-existence proof based on the node data in the state tree; and in the case that the initial check result indicates that the result exists, because the bloom filter has a false positive problem, the bloom filter needs to directly search a target leaf node in the state tree, wherein if the target leaf node is not found, the absence proof can be generated based on the auxiliary leaf node, and if the target leaf node is found, the presence proof can be generated based on the found target leaf node. It should be appreciated that the manner in which the absence attestation is generated based on the bloom filter occupies less processing resources than the manner in which the absence attestation is generated based on the auxiliary leaf nodes, and thus, by introducing the bloom filter, the processing resources consumed to generate the absence attestation may be reduced.
And 106, storing the incremental state data obtained through the state data updating operation into the leaf node corresponding to the incremental account.
In this specification, when the block chain system does not find the target leaf node in the state tree corresponding to the target block, the target leaf node may also be found in the state trees of other blocks maintained by the block chain system. For example, the generated history state trees may be searched in the order of generation of the blocks until the target leaf node is found. And if the target leaf node is found in the process of searching the target leaf node in each historical state tree, generating a presence certificate for proving that the state data to be verified is recorded in the historical state tree, otherwise, generating a non-presence certificate for proving that the state data to be verified is not recorded in the historical state tree.
In this specification, various data may be used as the data to be checked according to actual situations, for example, when the blockchain system receives an extraction request for target state data, the target state data may be used as the state data to be checked to search for a target leaf node corresponding to the target state data in a state tree corresponding to each block. When the target leaf node is found, the block chain system can return the incremental state data recorded in the target leaf node, the absence certificate and the presence certificate generated in the finding process to the initiator of the extraction request, so that the initiator determines whether the received incremental state data is the latest version of the target state data based on the received absence certificate and the received presence certificate.
In practical applications, an initiator of the extraction request may compare a creation time of the state tree corresponding to the existence certification with a creation time of the state tree corresponding to each of the nonexistence certifications, and determine that the incremental state data is the latest version of the target state data if the creation time of the state tree corresponding to the existence certification is earlier than all the state trees corresponding to the nonexistence certifications.
In this specification, when the blockchain system finds a target leaf node, in addition to returning the recorded incremental state data and the absence certification and the presence certification generated in the finding process to the initiator of the extraction request, the blockchain system may also return node data used for generating the absence certification and the presence certification to the initiator, so that the initiator checks the reliability of the absence certification and the presence certification. For example, if the blockchain system generates an absence certification for certifying that the target state data is not recorded in the state tree of the target block, the node data recorded on the path from the auxiliary leaf node to the root node may be returned to the initiator of the extraction request, and the initiator may regenerate the absence certification corresponding to the target block according to the generation method of the absence certification to compare with the absence certification returned by the blockchain system, thereby achieving the purpose of verifying the absence certification. Similarly, if the blockchain system generates the existence proof for proving that the target state data is recorded in the state tree of a certain block, the node data recorded on the path from the target leaf node to the root node may be returned to the initiator of the extraction request, and the initiator regenerates the existence proof corresponding to the block according to the generation method of the existence proof to compare with the existence proof returned by the blockchain system, thereby achieving the purpose of verifying the existence proof.
It should be noted that the blockchain system in the present specification can be deployed based on a conventional architecture of the blockchain technology, that is, all nodes in the blockchain system are formed by deploying blockchain codes on corresponding physical devices, and in most cases, each node corresponds to one physical device; the Blockchain system in the present specification may also be deployed based on a BaaS (block chain as a Service) architecture in a Blockchain technology, that is, all nodes in the Blockchain system are formed by deploying Blockchain codes on a virtual machine implemented in a cloud through a cloud Service, and the Blockchain nodes do not need to correspond to corresponding physical devices one to one.
According to the technical scheme, before the state tree of the target block is created, the block chain system in the present specification preferentially determines the incremental accounts updated based on the target block from among the global accounts, and ranks the determined incremental accounts according to the account ranking rule set for the global accounts. Further, the block chain system can create a state tree of the target block based on the sorted increment accounts, so that the arrangement sequence of each leaf node corresponding to each increment account in the state tree one to one is consistent with the arrangement sequence of the increment accounts. On the basis, each updated incremental state data can be recorded in the leaf node of the incremental account to which the incremental state data belongs.
It should be understood that, because the arrangement order of the leaf nodes corresponding to the incremental accounts in the created state tree in one-to-one correspondence to each incremental account conforms to the account sorting rule set for the global account, when the target leaf node corresponding to the state data to be verified is not found in the state tree of the target block, only the auxiliary leaf node adjacent to the target leaf node after being sorted according to the account sorting rule in the state tree needs to be determined, and an absence certificate for proving that the state data to be verified is not recorded in the state tree can be generated based on the node data on the path from the auxiliary leaf node to the root node, thereby avoiding the problem that the node data of the whole state tree needs to be acquired in the related art, and the absence certificate for proving that the state data to be verified is not recorded in the state tree of the target block can be generated, which results in more block chain processing resources being occupied.
It is worth emphasizing that the status tree corresponding to each block created by the present specification records only incremental status data generated based on the corresponding block; or, only leaf nodes corresponding to the incremental accounts corresponding to the respective tiles are included. The state tree corresponding to each block created by the related art records the full-volume state data corresponding to the full-volume account in the block chain system, including all leaf nodes corresponding to the full-volume account. Therefore, the size of the state tree created by the present specification is inherently smaller than the state tree created by the related art. Therefore, as the specification only needs to acquire the node data on the path between the auxiliary leaf node and the root node during verification, and the related technology needs to acquire the node data of the whole state tree, the node data actually used for generating the certificate-free of the specification is far less than that of the related technology, and correspondingly, the block chain processing resources called when the specification generates the certificate-free of the specification are far less than that of the related technology.
Indeed, just because the specification creates a state tree based only on the incremental accounts corresponding to the tiles, the specification only needs to obtain node data on the path between the auxiliary leaf node and the root node when generating the absence certification corresponding to the respective tile. The reason is that when the state tree only contains the leaf nodes corresponding to the incremental account, whether the auxiliary leaf nodes are directly adjacent can be proved only according to the node data on the path, if the auxiliary leaf nodes are directly adjacent, the target leaf nodes are inevitably not recorded in the state tree, and the non-existence proof is generated. If the state tree is created based on the full account in the related art, each created state tree includes leaf nodes corresponding to all accounts, a target leaf node is bound to exist in any state tree, and the situation that the target leaf node is not included does not exist at all. As can be seen, based on the state tree created by the related art, it is apparently impossible to generate the absence certification based on only the node data on a single path as in the present specification.
After the status data is stored based on the status data storage method, the status data can be verified based on the created status tree. Therefore, the specification also discloses a state data checking method. In this method, most of the operations, for example, how to generate the non-existence proof, how to search for the target leaf node, and the like, are described in the above-described status data evidence storing method, and therefore, detailed description is not repeated in the following, and related contents can refer to the above description.
Fig. 2 is a flowchart illustrating a status data checking method according to an exemplary embodiment of the present disclosure. The method is applied to a block chain system, as shown in fig. 2, and may include the following steps:
As described above, in the present specification, when building a status tree for a block, status data of all accounts is not recorded any more, but only updated status data of accounts whose status data is updated based on the block is recorded. In other words, the status tree constructed for the target block in the present specification records only the incremental status data of the incremental account. After the incremental accounts are determined, the incremental accounts may be preferentially sorted based on the account sorting rule set for the full-size account, and a state tree is constructed based on the sorted incremental accounts, so that the arrangement order of each leaf node in the state tree conforms to the account sorting rule. On the basis, each increment state data can be stored and verified to the leaf node corresponding to the increment account.
As described above, after the state tree is constructed according to the technical solution of the present specification, when the state tree in which the state data to be verified is not recorded in the target block, the absence certification for certifying that the state data is not recorded in the state tree is generated.
As described above, the target leaf node corresponding to the state data to be verified may be preferentially searched in the state tree of the target block, and if the target leaf node is not found, the auxiliary leaf node adjacent to the target leaf node after being sorted according to the account sorting rule in all the leaf nodes of the state tree is determined, and a path from the auxiliary leaf node to the root node is determined, so as to generate an absence certification for certifying that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
As described above, the node data recorded in each node in the state tree may be a hash value. On the basis, after the path from the auxiliary leaf node to the root node is determined, the hash value of the auxiliary leaf node and the hash values of the brother nodes of all the intermediate nodes on the path can be obtained, and the root hash of the state tree is calculated according to the root hash calculation rule of the state tree. After the root hash is obtained through calculation, the root hash may be compared with the root hash recorded in the root node, and if the comparison result indicates that the root hash obtained through calculation is consistent with the root hash recorded in the root node, an absence proof for proving that the state data to be verified is not recorded in the state tree may be generated based on the comparison result.
As described above, in contrast to the target leaf node not being found, in the case that the target leaf node is found, the present specification may also generate the existence certification of the state tree for certifying that the state data to be verified is recorded in the target block. For example, a path from a target leaf node to a root node may be preferentially determined, and the proof of existence may be generated based on node data recorded on the path
As described above, the present specification may directly search a target leaf node corresponding to state data to be verified in a state tree of a target block to be verified when the state data to be verified is recorded in the state tree, and generate an absence certificate corresponding to the target block based on the foregoing manner when the target leaf node is not found.
As described above, in the case where a bloom filter generated based on each incremental account sorted according to the account sorting rule is maintained in the blockchain system, the present specification may preliminarily determine whether or not a leaf node corresponding to a target account exists in the status tree of a target block based on the bloom filter. Specifically, a target account corresponding to the state data to be verified may be input to a bloom filter to obtain an initial verification result, and if the initial verification result indicates that there is no leaf node corresponding to the target account in the state tree, an absence certification for certifying that the state data to be verified is not recorded in the state tree may be directly generated based on the initial verification result; on the contrary, if the initial verification result indicates that the leaf node corresponding to the target account exists in the state tree, the operation of searching the target leaf node in the state tree can be performed, and the absence certificate is generated based on the above manner under the condition that the target leaf node is not found, while the presence certificate is generated under the condition that the target leaf node is found.
As described above, when receiving an extraction request for target state data, the blockchain system may use the target state data as state data to be checked to search for a target leaf node corresponding to the target state data in a state tree corresponding to each block. When the target leaf node is not found in the state tree of the target block, the historical state trees corresponding to the generated historical blocks can be further searched according to the block generation sequence until the target leaf node is found; in the process of searching the target leaf node in each historical state tree, if the target leaf node is searched, a proof for proving that the target state data is recorded in the historical state tree can be generated, otherwise, an absence proof for proving that the target state data is not recorded in the historical state tree is generated.
As described above, in the case that the target leaf node is found, the blockchain system may return the incremental state data recorded in the target leaf node and the absence certificate and the presence certificate generated in the finding process to the initiator of the extraction request, so that the initiator determines that the received incremental state data is the latest version of the target state data based on the received absence certificate and the received presence certificate. In practical application, the initiator of the extraction request may compare the creation time of the state tree corresponding to the existence certification with the creation time of the state trees corresponding to the respective nonexistence certifications, and may determine that the incremental state data is the latest version of the target state data if the creation time of the state tree corresponding to the existence certification is earlier than the creation time of the state trees corresponding to all the nonexistence certifications.
As described above, the data verification method proposed in this specification can be applied to a blockchain system, which can be deployed based on a conventional architecture of blockchain technology, that is, all nodes in the blockchain system are formed by deploying blockchain codes on corresponding physical devices, and in most cases, each node corresponds to one physical device; the block chain system can also be deployed based on a BaaS (block chain as a Service) architecture in a block chain technology, that is, all nodes in the block chain system are formed by deploying block chain codes on a virtual machine implemented by a cloud through a cloud Service, and block chain nodes do not need to correspond to corresponding physical devices one by one.
According to the technical scheme, the block chain system in the specification constructs the state tree based on the sorted increment accounts, so that when the specification verifies the state data to be verified, on the basis of determining the auxiliary leaf node adjacent to the target leaf node to which the state data to be verified belongs, node data on a path between the auxiliary leaf node and the root node can be directly based on, and an absence proof for proving that the state data to be verified is not recorded in the state tree is generated, and the problem that more block chain processing resources are occupied due to the fact that the absence proof is generated based on the node data of the whole state tree in the related technology is solved.
As described above, since the blockchain system in the present specification can also return the basis for generating the non-existence certification to the initiator of the fetch request to be checked by the initiator itself. Therefore, the present specification also provides a data verification method applied to the client. Most operation modes of the method, for example, how to check that there is no proof and how to check the version, are introduced in the above-described status data proof method, and therefore, detailed descriptions are omitted hereinafter, and related contents can be referred to the above descriptions.
Fig. 3 is a flowchart illustrating another status data checking method according to an exemplary embodiment of the present disclosure. The method is applied to the client, and as shown in fig. 3, may include the following steps:
In this specification, after generating the absence certification for certifying that the state data to be verified is not recorded in the state tree of the target block, the blockchain system may return the basis for generating the absence certification to the client, so that the client checks whether the absence certification is reliable. For example, the node data recorded on the path from the auxiliary leaf node to the root node, which is acquired in the process of searching the target leaf node corresponding to the state data to be verified in the state tree of the target block, may be returned to the client, so that the client may verify the received absence certification based on the node data on the path, and only when the verification is passed, it is determined that the absence certification is reliable, that is, it is determined that the state data to be verified is not actually recorded in the state tree of the target block.
As described above, when the blockchain system generates the absence certification by calculating the root hash, the absence certification may be checked by recalculating the root hash. For example, the client may recalculate the root hash of the state tree according to the root hash calculation rule based on the hash value of the auxiliary leaf node included in the received node data and the hash values of the sibling nodes of all intermediate nodes on the path, where the root hash of the state tree is determined to be passed when the calculated root hash is consistent with the root hash recorded in the state tree included in the node data.
As described above, the blockchain system may use the target status data included in the received extraction request as the status data to be checked, and then, in the data checking method, the device used by the initiator of the extraction request may be used as the client.
In other words, the client may initiate an extraction request for the target state data to the blockchain system to cause the blockchain system to look up the target state data from the state tree corresponding to each of the blocks. When the block chain system searches for target state data in the state tree corresponding to any block, the block chain system may use the block as a target block and the target state data as state data to be checked to generate a presence certificate for proving that the target state data is recorded in the state tree corresponding to the block or an absence certificate for proving that the target state data is not recorded in the state tree corresponding to the block.
And under the condition that the block chain system finds the target state data, the found incremental state data recorded in the target leaf nodes and the absence certificate and the presence certificate generated based on each found state tree in the finding process can be returned to the client, so that the client verifies whether the incremental state data is the latest version of the target state data based on the received absence certificate and the presence certificate.
As described above, after receiving the absence certification and the presence certification, the client may compare the creation time of the state tree corresponding to the presence certification with the creation time of the state trees corresponding to the respective absence certifications, and determine that the received incremental state data is the latest version of the target state data if the creation time of the state tree corresponding to the presence certification is earlier than the state trees corresponding to all the absence certifications.
As can be seen from the foregoing technical solutions, the blockchain system in this specification may return, to the client, the basis for generating the non-existence certification, that is, "the node data on the path from the auxiliary leaf node adjacent to the target leaf node to the root node, which is determined from the state tree. On this basis, the client can verify the reliability of the received non-existence certification according to the received basis.
Further, after finding the incremental state data recorded in the target leaf node, the block chain system may return both the presence certificate and the absence certificate generated in the process of finding the target leaf node to the client. On the basis, the client can verify whether the received incremental state data is the latest version of the target state data based on the received non-existence proof and the existence proof so as to achieve the purpose of version verification.
The technical solution of the present specification will be described below by taking an example of constructing a state tree in the form of a block of a merkel tree.
Fig. 4 is a flowchart of a method for building a merck tree according to an exemplary embodiment of the present disclosure. As shown in fig. 4, the method may include the steps of:
and step 401, generating a new block.
At step 402, a delta account that is updated based on the status of the transaction occurrence in the block is determined.
In this embodiment, an example of "building a merck tree directly for a newly generated block in the case of block generation" is described.
In this embodiment, once a new block is generated in the block chain system, the incremental accounts in which the status update occurs and the incremental status data corresponding to each incremental account can be determined, and on this basis, the corresponding relationship between the incremental accounts and the incremental status data can be established to construct the mercker tree of the block.
For example, assume that a full account currently maintained in the blockchain system includes: accounts 1 to 10, and the newly created blocks include transactions a, b, c, and d, where transaction a is used to update the status Data of account 1, transaction b is used to update the status Data of account 4, transaction c is used to update the status Data of account 5, and transaction d is used to update the status Data of account 7, then accounts 1, 4, 5, and 7 may be determined as the incremental account corresponding to the newly created block, and Data1 updated via transaction a may be used as the incremental status Data corresponding to account 1, data4 updated via transaction b may be used as the incremental status Data corresponding to account 4, data5 updated via transaction c may be used as the incremental status Data corresponding to account 5, and Data7 updated via transaction d may be used as the incremental status Data corresponding to account 7. At this time, the correspondence relationship between the incremental account and the incremental status data may be as shown in table 1 below:
| |
Account 4 | Account 5 | |
| Data1 | Data4 | Data5 | Data7 |
TABLE 1
And step 403, sorting the determined incremental accounts according to the account sorting rule.
For the above example, it is assumed that the account sorting rule is sorting according to the alphabetical order of the account addresses, the block chain system records each account directly, and if the account address of account 1 is dajgdjfallkg, the account address of account 4 is qjiognakgag, the account address of account 5 is ajdsaiogng, the account address of account 7 is bgasgdfgio, and the block chain system records the account addresses in the form of Key-Value, then the Key-Value relationship obtained by sorting based on the alphabetical order may be as shown in table 2 below:
TABLE 2
For convenience, as shown in table 2 above, the Address of account 1 is hereinafter referred to as Address1, the Address of account 4 is hereinafter referred to as Address4, the Address of account 5 is hereinafter referred to as Address5, and the Address of account 7 is hereinafter referred to as Address7.
At step 404, a bloom filter is constructed based on the sorted incremental accounts.
Taking the above example into account, after sorting to obtain the relationship between the incremental account address and the incremental status data as shown in table 2 above, a bloom filter may be constructed based on the sorted account addresses.
And step 405, constructing a Merck tree by taking the sorted incremental accounts as leaf nodes.
Taking the above example as a support, in addition to building the bloom filter, the blockchain system also builds a merkel tree using the sorted incremental account addresses as leaf nodes.
In one case, the account address may be used as the node data for the corresponding leaf node. In this case, the account addresses of the two adjacent leaf nodes may be merged and then the Hash value may be calculated to serve as the node data of the parent node of the two leaf nodes, for example, as shown in fig. 5, since Address5 and Address7 are adjacent, two addresses ajdsaiogng and bgasgdfgio may be recorded in the two leftmost leaf nodes, respectively, and since the two addresses are merged to be "ajdsaiogngbgasgdfgio", the Hash value Hash57 of "ajdsaiogngbgasgdfgio" may be used as the Hash value of the parent node of the two leaf nodes. Correspondingly, all intermediate nodes can also calculate the node data of the parent node by combining the node data of the child nodes and then calculating the Hash value, for example, as shown in fig. 5, the Hash value can be further calculated after combining the Hash57 and the Hash71, and the node data of the parent node and the parent node is obtained as the Hash5771. And the like until the root hash is obtained by calculation.
In another case, the hash value of the account address may be used as the node data of the corresponding leaf node. In this case, hash values may be respectively calculated based on account addresses of two adjacent leaf child nodes, and the calculated Hash values are recorded in leaf nodes, on this basis, the Hash values of the two adjacent leaf child nodes may be merged and then the Hash values are calculated to serve as node data of a parent node of the two leaf child nodes, for example, as shown in fig. 6, since a leaf node corresponding to Address5 and a leaf node corresponding to Address7 are adjacent, then "Hash value Hash5" obtained by hashing ajsaiogng "and" Hash value Hash7 obtained by hashing bgasgdfgio "may be respectively recorded in the two leftmost leaf nodes, and on this basis, hash value 57 obtained by calculating after merging Hash5 and Hash7 may be used as a Hash value of a parent node of the two leaf child nodes. Similarly to the above case, all intermediate nodes may calculate node data of a parent node by merging node data of child nodes and then calculating a hash value, for example, as shown in fig. 6, the hash value 57 and the hash value 71 may be merged and then further calculated to obtain node data of both parent nodes as the hash value 5771. And the like until the root hash is obtained by calculation.
At step 406, the hash digest of the bloom filter and the chunk header of the root hash storage chunk of the merkel tree are hashed.
In this embodiment, after the bloom filter and the merkel tree are constructed, the hash digest of the bloom filter and the root hash of the merkel tree may be stored in the block header, so that when state data needs to be searched in the state tree of the newly generated block, the corresponding bloom filter may be directly found based on the hash digest in the block header, and the corresponding merkel tree may be found based on the root hash.
After constructing the merck trees for the respective blocks in the manner shown in fig. 4, if the hash value of the account address is used as the node data of the leaf node as shown in fig. 6, the merck trees corresponding to the plurality of blocks as shown in fig. 7 can be generated in the block chain system, so that after the block chain system receives the extraction request for the target state data, the retrieval can be performed in the respective merck trees.
The status data searching method in the present specification will be described by taking as an example "the newly generated Block in the Block chain structure shown in fig. 7 is Block1002 shown in fig. 6, and the Block chain structure further includes other blocks such as Block1000 and Block1001, and the status data extracted by the user request is the latest status data of account 2"
Fig. 8 is a flowchart illustrating a status data lookup method according to an exemplary embodiment of the present disclosure. As shown in fig. 8, the method may include the steps of:
In this embodiment, the example that the user needs to acquire the latest status data of the account 2 is taken as an example, and therefore, the account 2 may be regarded as the target account, the leaf node corresponding to the account 2 may be regarded as the target leaf node, and the latest status data of the account 2 may be regarded as the target status data. Then, the user can initiate an extraction request for the latest status data of account 2 to the blockchain system through the account Address of account 2 held by the user, i.e. Address2.
In this embodiment, after receiving the extraction request, the blockchain system may preferentially search the target leaf node in the merkel tree corresponding to the block generated later according to the generation order of the blocks.
The Block chain system accepts the above example, and generates Block1000 first, block1001 second, and Block1002 last. Thus, the target leaf node can be found in the merkel tree 1002", the merkel tree 1001", and the merkel tree 1000 "in sequence. Certainly, since the mercker tree 1000 "is not a founder block, when the target leaf node is not found in all of the three, the searching may be continued until the target leaf node is found.
In the present embodiment, since the hash digest of the bloom filter generated for the block and the root hash of the tacle tree generated for the block are recorded in the block header of the corresponding block in the previous embodiment, when the present embodiment needs to search for the target leaf node in a certain tacle tree, the hash digest of the bloom filter and the root hash of the tacle tree can be read from the block header of the corresponding block.
Taking the above example as an example, when the embodiment needs to search the target leaf node in the merkel tree 1002 ″, the hash digest of the bloom filter and the root hash of the merkel tree 1002 ″ can be read from the Block header of the Block1002. On this basis, the blockchain system may obtain the bloom filter 1002 'based on the read hash digest, so as to primarily determine whether the target leaf node is included in the merkel tree 1002 "through the bloom filter 1002'.
In step 803, a bloom filter 1002' is obtained from the hash digest.
In step 804, address2 contained in the extraction request is input to bloom filter 1002'.
Since the previous embodiment constructs the bloom filter 1002' based on the sorted account addresses, the present embodiment may use the account Address2 of the account 2 as an input of the bloom filter 1002' to output the determination result by the bloom filter 1002'.
Step 805, judging whether the Merck tree 1002 'contains Address2 according to the output result of the bloom filter 1002', if so, jumping to step 806, otherwise, jumping to step 808.
In this embodiment, if the output result of the bloom filter 1002 'indicates that the merkel tree 1002 "does not include Address2, it is determined that the merkel tree 1002" does not include the target leaf node, in this case, step 808 may be executed, and the absence proof may be generated based on the output result of the bloom filter 1002'.
It should be noted that when the output result of the bloom filter 1002' indicates that Address2 is contained in the merkel tree 1002", it does not mean that Address2 is necessarily contained in the merkel tree 1002", because the bloom filter has the problem of false positive. Therefore, it is necessary to directly look up Address2 in the merkel tree 1002 "to determine whether Address2 is really present in the merkel tree 1002". Of course, in this embodiment, the actually searched object may be a Hash value of Address2, that is, hash2.
In this embodiment, if the query result indicates that Address2 exists in the merkel tree 1002 ″, the query operation is stopped, and the Value in the searched target leaf node is returned to the initiator of the extraction request; if the query result indicates that Address2 does not exist in the merkel tree 1002", it is necessary to generate an absence certification for certifying that the state information of the account 2 is not recorded in the merkel tree 1002".
In step 807, the leaf node corresponding to Address2 is not found, and an absence certificate corresponding to the merkel tree 1002 ″ is generated.
However, as can be seen from fig. 7, the status Address of account 2 is not contained in the merkel tree 1002", and therefore, if the output result of the bloom filter 1002' indicates that the merkel tree 1002" contains Address2 but the target leaf node is not found in the merkel tree 1002", this is necessarily due to a false positive problem.
At this point, then the absence attestation may be generated based on the merkel tree 1002 "itself. As described above, the secondary leaf node adjacent to the target leaf node may be preferentially determined to generate the absence manifest based on the node data on the path between the secondary leaf node and the root node.
Taking the above example, suppose that Address2 is "bashdofilgd", the first letter is b, and is consistent with Address7 in the mercker tree 1002", but the second letter is a, and is earlier than the second letter" g "of Address7 in 26 alphabetical order, so according to the account sorting rule, the two account addresses adjacent to Address2 in the mercker tree 1002" are: address5 and Address7. In other words, the determined auxiliary leaf nodes are: a leaf node corresponding to Address5 and a leaf node corresponding to Address7.
Thus, it may be determined that the path between the secondary leaf node and the root node, which includes intermediate nodes 57 and 5771, may be as shown in FIG. 9. On the basis, hash values Hash5 and Hash7 of the auxiliary leaf nodes, hash value Hash71 of brother node 71 of intermediate node 57 and Hash value Hash7114 of brother node 7114 of intermediate node 5771 can be obtained. On the basis, the root Hash can be recalculated based on the Hash5, the Hash7, the Hash71 and the Hash7114.
Specifically, the Hash value Hash57' of the intermediate node 57 may be recalculated based on Hash5 and Hash7, the Hash5771' may be recalculated based on the calculated Hash57' and Hash71, and finally the root Hash 5771114 ' may be recalculated based on the calculated Hash5771' and Hash7114. Then, the recalculated root Hash 5771114 ' and the root Hash 5771114 recorded in the root node may be compared, and if the comparison result indicates that the root Hash 5771114 ' and the root Hash 5771114 ' are consistent, it is proved that the node data on the path shown in fig. 9 is consistent with the node data in the originally generated tacle tree, and it is indirectly proved that "the leaf node corresponding to Address5 is directly adjacent to the leaf node corresponding to Address 7", that is, it is proved that the leaf node corresponding to Address2 does not exist in the tacle tree 1002 ".
It can be seen that the root Hash recalculated based on Hash5, hash7, hash71, hash7114 can be used to generate the absence certificate corresponding to mercker tree 1002 ".
At step 808, an absence attestation is generated based on the output of bloom filter 1002'.
In the embodiment, the bloom filter has no false positive problem when the output result is no, that is, the output result indicates that the target state data does not exist in the merkel tree. Thus, in the above example, the absence attestation may be generated directly based on the output results of bloom filter 1002', without having to go through steps 806 and 807.
In the embodiment, as can be seen from fig. 7, address2 cannot be found in the mercke tree 1002 ″ corresponding to the block1002. Therefore, the search for Address2 in the Mercker tree 1001 "corresponding to block1001 may continue.
Similar to finding Address2 in mercker tree 1002", when finding Address2 in mercker tree 1001", bloom filter 1001' may also be obtained preferentially to determine whether Address2 is contained in mercker tree 1001 ". If the output result of the bloom filter 1001' indicates that Address2 is not included in the mercker tree 1001", then the absence certification corresponding to the mercker tree 1001" is generated directly based on the output result; if the output result of the bloom filter 1001' indicates that the merkel tree 1001 "contains Address2, address2 is directly searched for in the merkel tree 1001", and if the Address is not found, the absence proof is generated based on the node data of the merkel tree 1001 ".
Specifically, the operations in steps 809 to 816 are the same as the operations in steps 802 to 808, except that the range of search is changed from the merkel tree 1002 "to the merkel tree 1001", and therefore, the related contents can refer to the operations in steps 802 to 808, and are not described in detail in the related steps.
In step 810, a bloom filter 1001' is obtained from the hash digest.
In step 811, address2 included in the extraction request is input to bloom filter 1001'.
Step 812, judging whether the Merck tree 1001 'contains Address2 according to the output result of the bloom filter 1001', if so, jumping to step 813, otherwise, jumping to step 816
Step 813 looks up Address2 in the Mercker tree 1001 ".
In step 814, the leaf node corresponding to Address2 is not found, and an absence certificate corresponding to the merkel tree 1001 "is generated.
At step 815, a proof of absence is generated based on the output of bloom filter 1001'.
As can be seen from FIG. 7, after Address2 has not been found in Merckel tree 1001', address2 can therefore be found in Merckel tree 1000' corresponding to block 1000.
In step 817, the bloom filter 1000' is obtained from the hash digest.
Step 819, determine whether the merkel tree 1000 "contains Address2 according to the output result of the bloom filter 1000', if yes, go to step 820, otherwise, go to step 823.
At step 820, address2 is looked up in Merckel tree 1000 ".
Step 821, finding the leaf node corresponding to Address2, and generating a presence certificate corresponding to the merkel tree 1000 ".
As can be seen from FIG. 7, address2 can be found in the Mercker tree 1000 ". Therefore, on one hand, the incremental state data recorded in Address2 can be extracted from the searched leaf node, and on the other hand, a path from the target node data corresponding to Address2 to the root node and the node data on the path can be determined, so as to generate the existence proof corresponding to the mercker tree 1000 ″ according to the node data.
Assuming that the merkel tree 1000 "is as shown in fig. 10, the path as shown in fig. 11 can be determined, and on this basis, the Hash value Hash21' of the intermediate node 21 can be recalculated based on Hash2 and Hash1, hash2114' can be recalculated based on calculated Hash21' and Hash14, and finally the root Hash21141448' can be recalculated based on calculated Hash2114' and Hash 1448. Then, the recalculated root Hash21141448' and the root Hash21141448 recorded in the root node may be compared, and if the comparison result indicates that the two Hash are consistent, it may be verified that the node data on the path shown in fig. 11 is consistent with the node data in the originally generated mercker tree, that is, it may be verified that a leaf node corresponding to Address2 exists in the mercker tree 1000 ″.
As can be seen from fig. 7, address2 can be found in the mercker tree 1000", and therefore, after the incremental state Data2 of Address2 is read from the mercker tree 1000", data2, the proof of existence corresponding to the mercker tree 1000", the proof of absence corresponding to the mercker tree 1001", and the proof of absence corresponding to the mercker tree 1002 "can all be returned to the initiator of the extraction request.
Of course, this embodiment may also return the block header information of the blocks 1000, 1001, and 1002 to the initiator, so that the initiator determines the generation time of each block according to the information recorded in each block header, and performs version certification on the received Data2 based on the determined generation time, and the received presence certification and absence certification.
Specifically, as can be seen from fig. 7, the generation sequence of the blocks 1000, 1001, and 1002 is "1000 → 1002 → 1003", and the initiator receives "the presence certificate corresponding to the mercker tree 1000", the absence certificate corresponding to the mercker tree 1001", and the absence certificate corresponding to the mercker tree 1002", which are sufficient to prove that the status Data of Address2 is not recorded in the mercker tree generated after the mercker tree 1000", and thus the obtained Data2 is the latest status Data of Address2.
Of course, it should be noted that the present embodiment may also return the data of the nodes used for generating the absence proof and the presence proof to the initiator of the extraction request as shown in fig. 9 and 11, so that the root node of the corresponding merck tree is recalculated by the initiator, and the reliabilities of the absence proof and the presence proof are checked. The calculation method is consistent with the generation of the existence certification and the non-existence certification, and reference may be made to the description of the above steps, which is not described in detail in this step.
As can be seen from the foregoing technical solutions, in the embodiment, when looking up Address2 in the tacle tree of each block, a preliminary determination is preferentially performed based on the bloom filter of the corresponding block, wherein when the preliminary determination indicates that the corresponding tacle tree does not include Address2, the Address2 can be directly and continuously looked up in the tacle tree of the next block. Compared with the method of directly searching in the merkel tree, the method has the advantages that the bloom filter occupies lower processing resources and has higher operation efficiency, so that the acquisition efficiency of the target state data is improved and the occupation of the processing resources is reduced by means of pre-establishing the bloom filter.
In addition, in this embodiment, when the preliminary judgment obtained by the bloom filter indicates that the corresponding tacle tree includes Address2, but Address2 is not found in the corresponding tacle tree, the path as shown in fig. 9 and the node data included in the path may be determined. It should be understood that, for the sake of convenience of understanding, the merkel tree 1002 ″ shown in fig. 7 containing a small amount of node data is used as an example of the present embodiment, so that the node data on the path shown in fig. 9 is different from the node data contained in the merkel tree 1002 ″ shown in fig. 7 by only a small amount of node data, but in the merkel tree actually generated for each block by the block chain system, a large amount of leaf nodes is usually contained, and the amount of the leaf nodes is far greater than that of the merkel tree 1002 ″ shown in fig. 9, and therefore, the node data on the path actually determined based on the above method is far greater than that of the merkel tree shown in fig. 7 and fig. 9. Therefore, by the technical scheme of the embodiment, the node data required by the generation of the non-existence certification can be greatly reduced, that is, the problem that when the related technology generates the non-existence certification, a large amount of block chain processing resources are occupied due to the fact that the node data of the whole merkel tree is required is solved.
FIG. 12 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 12, at the hardware level, the apparatus includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210, although other hardware required for services may be included. One or more embodiments of the present description can be implemented in software, such as by the processor 1202 reading corresponding computer programs from the non-volatile memory 1210 into the memory 1208 and then executing. Of course, besides the software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combination of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 13, the status data checking apparatus applied to the blockchain system can be applied to the device shown in fig. 12 to implement the technical solution of the present specification. Wherein, the state data checking device may include:
the searching unit 1301 searches a target leaf node corresponding to the state data to be checked in a state tree corresponding to the target block; each leaf node in the state tree corresponds to each increment account one by one, and each increment account is an account of which the state data is updated based on the target block in the global account; the arrangement sequence of each leaf node in the state tree accords with an account sorting rule set for the global account, and each leaf node is respectively maintained with increment state data obtained by updating the state data of a corresponding increment account;
the generating unit 1302 determines, when the target leaf node is not found, an auxiliary leaf node adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determines a path from the auxiliary leaf node to a root node of the state tree, so as to generate, according to node data recorded on the path, an absence certification for certifying that the state data to be verified is not recorded in the state tree.
Optionally, the generating unit 1302 is further configured to:
acquiring the hash value of the auxiliary leaf node and the hash values of brother nodes of all intermediate nodes on the path, and calculating the root hash of the state tree according to the root hash calculation rule of the state tree;
and comparing the calculated root hash with the root hash recorded in the root node, and generating an absence proof for proving that the state data to be verified is not recorded in the state tree based on the comparison result when the comparison result shows that the root hash and the root hash are consistent.
Optionally, a bloom filter generated based on each increment account sorted according to the account sorting rule is maintained in the block chain system; the method further comprises the following steps:
the input unit 1303 is used for inputting the target account corresponding to the state data to be verified into the bloom filter to obtain an initial verification result;
and searching the target leaf node in the state tree, and executing the operation when the initial verification result shows that the leaf node corresponding to the target account exists in the state tree.
Optionally, the generating unit 1302 is further configured to:
and under the condition that the target leaf node is found, determining a path from the target leaf node to the root node, and generating a presence certificate for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path.
Optionally, the lookup unit 1301 is further configured to:
taking the target state data as the state data to be checked under the condition of receiving an extraction request aiming at the target state data;
under the condition that the target leaf node is not found in the state tree of the target block, searching the historical state trees corresponding to the generated historical blocks according to the block generation sequence until the target leaf node is found;
in the process of searching the target leaf node in each historical state tree, if the target leaf node is searched, generating a proof for proving that the target state data is recorded in the historical state tree, otherwise, generating an absence proof for proving that the target state data is not recorded in the historical state tree.
Optionally, the method further includes:
a returning unit 1304, configured to, in a case that the target leaf node is found, return the incremental state data maintained in the target leaf node, and the absence proof and the presence proof generated in the finding process to the initiator of the extraction request, so that the initiator determines, based on the received absence proof and the received presence proof, that the received incremental state data is the latest version of the target state data.
Referring to fig. 14, the status data verification apparatus applied to the blockchain system can be applied to the device shown in fig. 12 to implement the technical solution of the present specification. Wherein, this state data deposit evidence device can include:
a sorting unit 1401, configured to, when a status data update operation of a partial account in a global account is completed based on a target block, take the partial account as an incremental account corresponding to the target block, and sort the incremental account according to an account sorting rule set for the global account;
a constructing unit 1402, configured to construct a state tree corresponding to the target block based on the sorted incremental accounts, so that an arrangement order of leaf nodes corresponding to each incremental account in the state tree conforms to the account sorting rule;
the evidence storing unit 1403 stores the incremental status data obtained through the status data updating operation to the leaf node corresponding to the incremental account to which the incremental status data belongs.
Optionally, the method further includes:
a generating unit 1404, configured to generate a bloom filter based on the sorted incremental accounts, where the bloom filter is used to check whether a target account corresponding to the state data to be checked is an incremental account corresponding to a leaf node in the state tree.
Optionally, the method further includes:
a verification unit 1405, which inputs a target account corresponding to the status data to be verified into the bloom filter to obtain an initial verification result; under the condition that the initial verification result shows that leaf nodes corresponding to the target account exist in the state tree, secondarily verifying whether leaf nodes corresponding to the target account exist in the state tree or not based on the state tree; and generating an absence certification for certifying that the state data to be verified is not recorded in the state tree based on the initial verification result under the condition that the initial verification result shows that the leaf node corresponding to the target account does not exist in the state tree.
Optionally, the check unit 1405 is further configured to:
searching a target leaf node recorded with the state data to be checked in the state tree;
if the target leaf node is found, determining a path from the target leaf node to a root node in the state tree, and generating a presence certificate for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path;
if the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to the root node, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
Optionally, the method further includes:
a searching unit 1406, configured to search a target leaf node in the state tree, where the state data to be checked is recorded; if the target leaf node is found, determining a path from the target leaf node to a root node in the state tree, and generating a presence certificate for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path; if the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to the root node, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
Optionally, the search unit 1406 is further configured to:
under the condition that the target leaf node is not found in the state tree corresponding to the target block, searching each generated historical state tree according to a generation sequence until the target leaf node is found;
in the process of searching the target leaf node in each historical state tree, if the target leaf node is searched, generating a presence certificate for proving that the state data to be verified is recorded in the historical state tree, otherwise, generating an absence certificate for proving that the state data to be verified is not recorded in the historical state tree.
Referring to fig. 15, the status data checking apparatus applied to the client may be applied to the device shown in fig. 12 to implement the technical solution of the present specification. Wherein, the status data checking device may include:
the receiving unit 1501 receives an absence certification returned by the block chain system and used for certifying that the state data to be verified is not recorded in the state tree of the target block, and node data recorded on a path from an auxiliary leaf node to a root node, acquired in a process of searching a target leaf node corresponding to the state data to be verified in the state tree; each leaf node of the target block corresponds to each increment account in a one-to-one manner, each increment account is an account of the global accounts, which is updated based on the target block, the arrangement sequence of each leaf node in the status tree conforms to an account sorting rule set for the global accounts, and each leaf node is respectively maintained with increment status data obtained by updating the status data of the corresponding increment account;
a checking unit 1502 checks the non-existence certification based on the node data recorded on the path, and determines that the state data to be checked is not recorded in the state tree corresponding to the target block if the check is passed.
Optionally, the check unit 1502 is further configured to:
calculating root hash of the state tree according to a root hash calculation rule based on hash values of auxiliary leaf nodes contained in the received node data and hash values of brother nodes of all intermediate nodes on the path;
and determining that the check is passed when the calculated root hash is consistent with a root hash recorded in the state tree and included in the node data.
Alternatively to this, the first and second parts may,
further comprising: an initiating unit 1503, which initiates an extraction request for target state data to a blockchain system, so that the blockchain system searches for the target state data from a state tree corresponding to each block; when the block chain system searches the target state data in the state tree corresponding to any block, taking the any block as the target block and the target state data as the state data to be checked so as to generate a proof of existence for proving that the target state data is recorded in the state tree corresponding to the any block or a proof of nonexistence for proving that the target state data is not recorded in the state tree corresponding to the any block;
the verification unit 1502 is also used to: receiving incremental state data returned by the block chain system under the condition of finding the target state data, generating an absence certificate and a presence certificate based on each found state tree in the finding process, and checking whether the incremental state data is the latest version of the target state data based on the received absence certificate and the received presence certificate.
Optionally, the check unit 1502 is further configured to:
and in the case that the creation time of the state tree corresponding to the existence certification is earlier than the creation time of the state trees corresponding to all the nonexistence certifications, determining the incremental state data to be the latest version of the target state data.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of other like elements in a process, method, article, or apparatus comprising the element.
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.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if," as used herein, may be interpreted as "at \8230; \8230when" or "when 8230; \823030when" or "in response to a determination," depending on the context.
The above description is intended only to be exemplary of the one or more embodiments of the present disclosure, and should not be taken as limiting the one or more embodiments of the present disclosure, as any modifications, equivalents, improvements, etc. that come within the spirit and scope of the one or more embodiments of the present disclosure are intended to be included within the scope of the one or more embodiments of the present disclosure.
Claims (21)
1. A state data checking method is applied to a block chain system and comprises the following steps:
searching a target leaf node corresponding to the state data to be checked in a state tree corresponding to the target block; each leaf node in the state tree corresponds to each increment account in a one-to-one mode, and each increment account is an account of which the state data is updated based on the target block in the global account; the arrangement sequence of each leaf node in the state tree accords with an account sorting rule set for the global account, and each leaf node is respectively maintained with increment state data obtained by updating the state data of a corresponding increment account;
and under the condition that the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to a root node of the state tree, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
2. The method according to claim 1, wherein the generating, according to the node data recorded on the path, an absence certification for certifying that the state data to be verified is not recorded in the state tree comprises:
acquiring the hash value of the auxiliary leaf node and the hash values of brother nodes of all intermediate nodes on the path, and calculating the root hash of the state tree according to the root hash calculation rule of the state tree;
and comparing the calculated root hash with the root hash recorded in the root node, and generating an absence proof for proving that the state data to be verified is not recorded in the state tree based on the comparison result under the condition that the comparison result shows that the root hash and the root hash are consistent.
3. The method of claim 1, wherein a bloom filter is maintained in the blockchain system that is generated based on each incremental account sorted according to the account sorting rule; the method further comprises the following steps:
inputting the target account corresponding to the state data to be verified into the bloom filter to obtain an initial verification result;
and searching the target leaf node in the state tree, and executing the operation when the initial verification result shows that the leaf node corresponding to the target account exists in the state tree.
4. The method of claim 1, further comprising:
and under the condition that the target leaf node is found, determining a path from the target leaf node to the root node, and generating a presence certificate for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path.
5. The method of claim 1, further comprising:
taking the target state data as the state data to be checked under the condition of receiving an extraction request aiming at the target state data;
under the condition that the target leaf node is not found in the state tree of the target block, searching a historical state tree corresponding to each generated historical block according to a block generation sequence until the target leaf node is found;
in the process of searching the target leaf node in each historical state tree, if the target leaf node is searched, generating a proof for proving that the target state data is recorded in the historical state tree, otherwise, generating an absence proof for proving that the target state data is not recorded in the historical state tree.
6. The method of claim 5, further comprising:
and under the condition that the target leaf node is found, returning the incremental state data recorded in the target leaf node, and the absence certification and the presence certification generated in the finding process to the initiator of the extraction request, and determining the received incremental state data to be the latest version of the target state data by the initiator based on the received absence certification and the received presence certification.
7. A status data evidence storing method is applied to a block chain system and comprises the following steps:
under the condition that the status data updating operation of a part of accounts in a global account is completed based on a target block, taking the part of accounts as increment accounts corresponding to the target block, and sequencing the increment accounts according to an account sequencing rule set for the global account;
constructing a state tree corresponding to the target block based on the sorted increment accounts so that the arrangement sequence of leaf nodes corresponding to each increment account in the state tree accords with the account sorting rule;
and storing the incremental state data obtained through the state data updating operation into the leaf node corresponding to the incremental account.
8. The method of claim 7, further comprising:
and generating a bloom filter based on the sorted increment accounts, wherein the bloom filter is used for verifying whether the target account corresponding to the state data to be verified is the increment account corresponding to the leaf node in the state tree.
9. The method of claim 8, further comprising:
inputting the target account corresponding to the state data to be verified into the bloom filter to obtain an initial verification result;
under the condition that the initial verification result shows that leaf nodes corresponding to the target account exist in the state tree, secondarily verifying whether leaf nodes corresponding to the target account exist in the state tree or not based on the state tree;
and under the condition that the initial verification result shows that the leaf node corresponding to the target account does not exist in the state tree, generating an absence proof for proving that the state data to be verified is not recorded in the state tree based on the initial verification result.
10. The method of claim 9, the secondarily verifying whether a leaf node corresponding to the target account exists in the state tree based on the state tree, comprising:
searching a target leaf node recorded with the state data to be checked in the state tree;
if the target leaf node is found, determining a path from the target leaf node to a root node in the state tree, and generating a proof for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path;
if the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to the root node, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
11. The method of claim 7, further comprising:
searching a target leaf node recording state data to be checked in the state tree;
if the target leaf node is found, determining a path from the target leaf node to a root node in the state tree, and generating a presence certificate for proving that the state data to be verified is recorded in the state tree according to the node data recorded on the path;
if the target leaf node is not found, determining an auxiliary leaf node which is adjacent to the target leaf node after being sorted according to the account sorting rule in all leaf nodes of the state tree, and determining a path from the auxiliary leaf node to the root node, so as to generate an absence proof for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
12. The method of claim 10 or 11, further comprising:
searching each generated historical state tree according to a generation sequence under the condition that the target leaf node is not found in the state tree corresponding to the target block until the target leaf node is found;
in the process of searching the target leaf node in each historical state tree, if the target leaf node is searched, generating a presence certificate for proving that the state data to be verified is recorded in the historical state tree, otherwise, generating an absence certificate for proving that the state data to be verified is not recorded in the historical state tree.
13. A state data checking method is applied to a client and comprises the following steps:
receiving an absence certification returned by a block chain system and used for proving that state data to be verified is not recorded in a state tree of a target block, and node data recorded on a path from an auxiliary leaf node to a root node, wherein the node data is acquired in the process of searching a target leaf node corresponding to the state data to be verified in the state tree; each leaf node of the target block corresponds to each increment account in a one-to-one manner, each increment account is an account of which the status data is updated based on the target block in the global accounts, the arrangement sequence of each leaf node in the status tree conforms to an account sorting rule set for the global accounts, and each leaf node is respectively maintained with increment status data obtained by updating the status data of the corresponding increment account;
and verifying the non-existence certification based on the node data recorded on the path, and determining that the state data to be verified is not recorded in the state tree corresponding to the target block under the condition that the verification is passed.
14. The method of claim 13, the verifying the proof of absence based on node data recorded on the path, comprising:
calculating root hash of the state tree according to a root hash calculation rule based on hash values of auxiliary leaf nodes contained in the received node data and hash values of brother nodes of all intermediate nodes on the path;
and determining that the check is passed when the calculated root hash is consistent with a root hash recorded in the state tree and included in the node data.
15. The method of claim 13, further comprising:
initiating an extraction request aiming at target state data to a block chain system so that the block chain system searches the target state data from a state tree corresponding to each block; when the block chain system searches the target state data in the state tree corresponding to any block, taking the any block as the target block and the target state data as the state data to be checked so as to generate a proof of existence for proving that the target state data is recorded in the state tree corresponding to the any block or a proof of nonexistence for proving that the target state data is not recorded in the state tree corresponding to the any block;
receiving incremental state data returned by the block chain system under the condition that the target state data is found, generating an absence certificate and a presence certificate based on each found state tree in the finding process, and checking whether the incremental state data is the latest version of the target state data based on the received absence certificate and the received presence certificate.
16. The method of claim 15, the verifying whether the delta state data is a latest version of the target state data based on the received absence attestation and presence attestation, comprising:
and in the case that the creation time of the state tree corresponding to the existence certification is earlier than the creation time of the state trees corresponding to all the nonexistence certifications, determining the incremental state data to be the latest version of the target state data.
17. A state data checking device applied to a block chain system comprises:
the searching unit is used for searching a target leaf node corresponding to the state data to be checked in the state tree corresponding to the target block; each leaf node in the state tree corresponds to each increment account one by one, and each increment account is an account of which the state data is updated based on the target block in the global account; the arrangement sequence of each leaf node in the state tree accords with an account sorting rule set for the global account, and each leaf node is respectively maintained with increment state data obtained by updating the state data of a corresponding increment account;
and the generating unit is used for determining auxiliary leaf nodes which are adjacent to the target leaf node after being sorted according to the account sorting rule in all the leaf nodes of the state tree under the condition that the target leaf node is not found, and determining a path from the auxiliary leaf node to a root node of the state tree, so as to generate an absence certification for proving that the state data to be verified is not recorded in the state tree according to the node data recorded on the path.
18. A status data evidence storing device applied to a block chain system comprises:
the sorting unit is used for taking the partial accounts as increment accounts corresponding to the target block under the condition that the state data updating operation of the partial accounts in the global account is completed based on the target block, and sorting the increment accounts according to an account sorting rule set for the global account;
the building unit builds a state tree corresponding to the target block based on the sorted incremental accounts so that the arrangement sequence of leaf nodes corresponding to the incremental accounts in the state tree conforms to the account sorting rule;
and the evidence storing unit is used for storing the incremental state data obtained through the state data updating operation to the leaf node corresponding to the incremental account.
19. A state data checking device is applied to a client and comprises:
the receiving unit is used for receiving an absence proof which is returned by the block chain system and is used for proving that the state data to be verified is not recorded in a state tree of a target block, and node data which is recorded on a path from an auxiliary leaf node to a root node and is acquired in the process of searching a target leaf node corresponding to the state data to be verified in the state tree; each leaf node of the target block corresponds to each increment account in a one-to-one manner, each increment account is an account of which the status data is updated based on the target block in the global accounts, the arrangement sequence of each leaf node in the status tree conforms to an account sorting rule set for the global accounts, and each leaf node is respectively maintained with increment status data obtained by updating the status data of the corresponding increment account;
and the checking unit is used for checking the non-existence certification based on the node data recorded on the path and determining that the state data to be checked is not recorded in the state tree corresponding to the target block under the condition that the check is passed.
20. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1-16 by executing the executable instructions.
21. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 16.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211528784.6A CN115795563A (en) | 2022-11-30 | 2022-11-30 | State data checking method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211528784.6A CN115795563A (en) | 2022-11-30 | 2022-11-30 | State data checking method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115795563A true CN115795563A (en) | 2023-03-14 |
Family
ID=85444457
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211528784.6A Pending CN115795563A (en) | 2022-11-30 | 2022-11-30 | State data checking method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115795563A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117194739A (en) * | 2023-09-12 | 2023-12-08 | 北京云枢创新软件技术有限公司 | Method, electronic equipment and medium for searching hierarchical tree nodes based on hit state |
-
2022
- 2022-11-30 CN CN202211528784.6A patent/CN115795563A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117194739A (en) * | 2023-09-12 | 2023-12-08 | 北京云枢创新软件技术有限公司 | Method, electronic equipment and medium for searching hierarchical tree nodes based on hit state |
| CN117194739B (en) * | 2023-09-12 | 2024-04-19 | 北京云枢创新软件技术有限公司 | Method, electronic equipment and medium for searching hierarchical tree nodes based on hit state |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110602148B (en) | Method and device for generating state tree of block and verifying data on chain | |
| US10698885B2 (en) | Method and device for writing service data in block chain system | |
| CN110275884B (en) | Data storage method and node | |
| US11762839B2 (en) | Search method using data structure for supporting multiple search in blockchain-based IoT environment, and device according to method | |
| US11294875B2 (en) | Data storage on tree nodes | |
| EP3516539B1 (en) | Techniques for in-memory key range searches | |
| US20210109920A1 (en) | Method for Validating Transaction in Blockchain Network and Node for Configuring Same Network | |
| CN104408584A (en) | Analysis method and system for transaction relevance | |
| US11669301B2 (en) | Effectively fusing database tables | |
| CN110036381B (en) | In-memory data search technique | |
| US20160147867A1 (en) | Information matching apparatus, information matching method, and computer readable storage medium having stored information matching program | |
| US8271500B2 (en) | Minimal perfect hash functions using double hashing | |
| CN113220717B (en) | Block chain-based data verification method and device and electronic equipment | |
| US20230018381A1 (en) | Method for automatically identifying design changes in building information model | |
| CN115795563A (en) | State data checking method and device | |
| CN111930924A (en) | Data duplicate checking system and method based on bloom filter | |
| CN107256130A (en) | Data store optimization method and system based on Cuckoo Hash calculations | |
| CN115203746A (en) | Data account access authorization method and device | |
| CN115221559A (en) | Data account access authorization method and device | |
| CN106250440B (en) | Document management method and device | |
| CN115203747A (en) | Data account creation method and device | |
| CN115114289A (en) | Data query method and device and electronic equipment | |
| CN111858609A (en) | Fuzzy query method and device for block chain | |
| CN115577070B (en) | Financial data inquiry management system | |
| US20240152520A1 (en) | Data query and data storage methods and apparatuses for relation network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |