A data verification method, device, computer equipment and storage medium

Abstract

The present disclosure provides a data verification method and device, computer equipment and a storage medium, wherein the method comprises: obtaining transaction receipt information of a target transaction completed by a current processing of a distributed ledger server; the transaction receipt information comprises a transaction serial number of the target transaction and a to-be-verified root set digest of a to-be-verified node; the to-be-verified root set digest comprises first digest information of at least one verification node used for verifying the to-be-verified node; in a case where a trust anchor point value of a reconstructed verification digest set is less than the transaction serial number, determining a target verification root set digest corresponding to the target transaction according to the reconstructed verification digest set and transaction data of each completed transaction downloaded from the distributed ledger server; the target verification root set digest comprises second digest information of each target node; in a case where the first digest information of the verification node is consistent with the second digest information of the target node, determining that the to-be-verified root set digest is verified, and updating the trust anchor point value to the transaction serial number.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and more specifically, to a data verification method, apparatus, computer equipment, and storage medium. Background Technology

[0002] A blockchain database, also known as a ledger database or trusted ledger database, is a database where a ledger server manages various transaction data from clients. The data stored in a blockchain database has decentralized characteristics. A ledger server can use a Merkle tree structure to store various transaction data in the blockchain database. Similarly, when a client needs to insert new transaction data, the ledger server will also use a Merkle tree structure to store the new transaction data.

[0003] However, when the ledger server is not trusted by the client, for example, when the client needs to prove whether the ledger server has modified transaction data, how to quickly and effectively verify transaction data in the blockchain database by the client becomes a problem worthy of attention. Summary of the Invention

[0004] This disclosure provides at least one data verification method, apparatus, computer device, and storage medium.

[0005] In a first aspect, embodiments of this disclosure provide a data verification method, including:

[0006] Obtain transaction receipt information for the currently completed target transaction sent by the ledger server; the transaction receipt information includes the transaction sequence number of the target transaction and a root set summary of the node to be verified that matches the target transaction; the root set summary includes first summary information of at least one verification node used to verify the node to be verified, and the root set summary is determined by the ledger server based on the transaction data of the target transaction.

[0007] If the trust anchor value of the currently constructed reconstructed verification digest set is less than the transaction sequence number, the target verification root set digest corresponding to the target transaction is determined based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server; the target verification root set digest includes the second digest information of each target node corresponding to the target transaction;

[0008] If the first digest information of the verification node is consistent with the second digest information of the target node, it is determined that the root set digest to be verified has passed the verification, and the trust anchor value is updated to the transaction sequence number.

[0009] In one possible implementation, if the root set summary of the node to be verified does not include a verification node at the same level as the node to be verified, the root set summary of the node to be verified shall at least include the first summary information of the node to be verified.

[0010] In one possible implementation, the method further includes:

[0011] If the trust anchor value is not less than the transaction sequence number, find the generated verification root set digest of the constructed target node that matches the transaction sequence number from the reconstructed verification digest set;

[0012] If the generated root set digest and the root set digest to be verified are consistent, the root set digest to be verified is determined to be verified successfully; the successful verification of the root set digest to be verified is used to indicate that the transaction receipt information sent by the ledger server meets the preset requirements.

[0013] In one possible implementation, the completed transaction with the highest transaction sequence number is the target transaction; the transaction data includes the original data of the completed transaction and a first summary information calculated by the ledger server based on the original data;

[0014] The step of determining the target verification root set digest corresponding to the target transaction based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server includes:

[0015] Based on the trust anchor value of the reconstructed verification summary set and the transaction sequence number of each completed transaction, each transaction data to be constructed with a transaction sequence number greater than the trust anchor value is selected from the transaction data of each completed transaction.

[0016] For each of the transaction data to be constructed, a hash algorithm is used to perform hash calculation on the original data in the transaction data to be constructed, and to determine the second digest information of the target node corresponding to the transaction data to be constructed.

[0017] If the first summary information corresponding to each of the transaction data to be constructed is consistent with the second summary information of the transaction data to be constructed, the target verification root set summary corresponding to the target transaction is determined based on each of the transaction data to be constructed and the reconstruction verification set summary.

[0018] In one possible implementation, determining the target verification root set digest corresponding to the target transaction based on each of the transaction data to be constructed and the reconstruction verification set digest includes:

[0019] Target construction data is selected from the transaction data to be constructed in ascending order of the transaction sequence number of each transaction data to be constructed;

[0020] Based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstruction verification digest set, the target verification root set digest of the target constructed data is determined, and the trust anchor value of the reconstruction verification set is updated to the transaction sequence number of the target constructed data.

[0021] Return to the step of filtering out target construction data from the transaction data to be constructed in ascending order of the transaction number of each transaction data to be constructed, until the target verification root set digest corresponding to the target transaction is determined.

[0022] In one possible implementation, determining the target verification root set digest of the target constructed data based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set includes:

[0023] When the transaction sequence number of the target constructed data is odd, the target verification root set digest of the target constructed data is determined based on the target constructed verification root set digest of the constructed data whose transaction sequence number matches the trust anchor value in the reconstruction verification digest set, and the second digest information of the target constructed data.

[0024] In one possible implementation, determining the target verification root set digest of the target constructed data based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set includes:

[0025] When the transaction sequence number of the target construction data is even, the target node and its second summary information are generated based on the second summary information of the leaf nodes in the target already constructed verification root set summary and the second summary information of the target construction data; the leaf node is the target node corresponding to the transaction data to be constructed.

[0026] Determine whether there exists a constructed target node in the target's constructed verification root set digest that has the same node level as the target node in the previous level;

[0027] If so, then based on the second summary information of the already constructed target node and the second summary information of the target node at the next higher level, generate the second summary information of the target node at the next higher level and the target node at the next higher level;

[0028] Return to determine whether there is a built target node in the target's built verification root set digest that has the same node level as the target node in the previous level, until there is no built target node with the same node level as the target node. Based on the second digest information of the latest generated target node, determine the target verification root set digest of the target construction data.

[0029] In one possible implementation, the method further includes:

[0030] If the first digest information is inconsistent with the second digest information, an exception message indicating that the digest verification of the root set to be verified has failed is generated.

[0031] Secondly, embodiments of this disclosure also provide a data verification apparatus, comprising:

[0032] The acquisition module is used to acquire transaction receipt information of a target transaction that has been processed and completed, sent by the ledger server. The transaction receipt information includes the transaction sequence number of the target transaction and a root set summary of the node to be verified that matches the target transaction. The root set summary includes first summary information of at least one verification node used to verify the node to be verified. The root set summary is determined by the ledger server based on the transaction data of the target transaction.

[0033] The first verification module is used to determine the target verification root set summary corresponding to the target transaction based on the reconstructed verification summary set and the transaction data of each completed transaction downloaded from the ledger server, when the trust anchor value of the currently constructed reconstructed verification summary set is less than the transaction sequence number; the target verification root set summary includes the second summary information of each target node corresponding to the target transaction;

[0034] The second verification module is used to determine that the root set digest to be verified has passed verification when the first digest information of the verification node is consistent with the second digest information of the target node, and to update the trust anchor value to the transaction sequence number.

[0035] In one possible implementation, if the root set summary of the node to be verified does not include a verification node at the same level as the node to be verified, the root set summary of the node to be verified shall at least include the first summary information of the node to be verified.

[0036] In one possible implementation, the second verification module is further configured to:

[0037] If the trust anchor value is not less than the transaction sequence number, find the generated verification root set digest of the constructed target node that matches the transaction sequence number from the reconstructed verification digest set;

[0038] If the generated root set digest and the root set digest to be verified are consistent, the root set digest to be verified is determined to be verified successfully; the successful verification of the root set digest to be verified is used to indicate that the transaction receipt information sent by the ledger server meets the preset requirements.

[0039] In one possible implementation, the completed transaction with the highest transaction sequence number is the target transaction; the transaction data includes the original data of the completed transaction and a first summary information calculated by the ledger server based on the original data;

[0040] The first verification module, when determining the target verification root set digest corresponding to the target transaction based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server, is configured to:

[0041] Based on the trust anchor value of the reconstructed verification summary set and the transaction sequence number of each completed transaction, each transaction data to be constructed with a transaction sequence number greater than the trust anchor value is selected from the transaction data of each completed transaction.

[0042] For each of the transaction data to be constructed, a hash algorithm is used to perform hash calculation on the original data in the transaction data to be constructed, and to determine the second digest information of the target node corresponding to the transaction data to be constructed.

[0043] If the first summary information corresponding to each of the transaction data to be constructed is consistent with the second summary information of the transaction data to be constructed, the target verification root set summary corresponding to the target transaction is determined based on each of the transaction data to be constructed and the reconstruction verification set summary.

[0044] In one possible implementation, the first verification module, when determining the target verification root set summary corresponding to the target transaction based on each of the transaction data to be constructed and the reconstruction verification set summary, is configured to:

[0045] Target construction data is selected from the transaction data to be constructed in ascending order of the transaction sequence number of each transaction data to be constructed;

[0046] Based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstruction verification digest set, the target verification root set digest of the target constructed data is determined, and the trust anchor value of the reconstruction verification set is updated to the transaction sequence number of the target constructed data.

[0047] Return to the step of filtering out target construction data from the transaction data to be constructed in ascending order of the transaction number of each transaction data to be constructed, until the target verification root set digest corresponding to the target transaction is determined.

[0048] In one possible implementation, the first verification module, when determining the target verification root set digest of the target constructed data based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set, is configured to:

[0049] When the transaction sequence number of the target constructed data is odd, the target verification root set digest of the target constructed data is determined based on the target constructed verification root set digest of the constructed data whose transaction sequence number matches the trust anchor value in the reconstruction verification digest set, and the second digest information of the target constructed data.

[0050] In one possible implementation, the first verification module, when determining the target verification root set digest of the target constructed data based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set, is configured to:

[0051] When the transaction sequence number of the target construction data is even, the target node and its second summary information are generated based on the second summary information of the leaf nodes in the target already constructed verification root set summary and the second summary information of the target construction data; the leaf node is the target node corresponding to the transaction data to be constructed.

[0052] Determine whether there exists a constructed target node in the target's constructed verification root set digest that has the same node level as the target node in the previous level;

[0053] If so, then based on the second summary information of the already constructed target node and the second summary information of the target node at the next higher level, generate the second summary information of the target node at the next higher level and the target node at the next higher level;

[0054] Return to determine whether there is a built target node in the target's built verification root set digest that has the same node level as the target node in the previous level, until there is no built target node with the same node level as the target node. Based on the second digest information of the latest generated target node, determine the target verification root set digest of the target construction data.

[0055] In one possible implementation, the second verification module is further configured to:

[0056] If the first digest information is inconsistent with the second digest information, an exception message indicating that the digest verification of the root set to be verified has failed is generated.

[0057] Thirdly, an optional implementation of this disclosure also provides a computer device, a processor, and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is configured to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the steps of the first aspect above, or any possible implementation of the first aspect, are performed.

[0058] Fourthly, an optional implementation of this disclosure also provides a computer-readable storage medium storing a computer program that, when run, performs the steps of the first aspect or any possible implementation of the first aspect.

[0059] For a description of the effects of the aforementioned data verification device, computer equipment, and computer-readable storage medium, please refer to the description of the aforementioned data verification method; it will not be repeated here.

[0060] The data verification method, apparatus, computer equipment, and storage medium provided in this disclosure, when the ledger server is not trusted, allow the client to reconstruct the target verification root set digest corresponding to the target transaction by downloading transaction data of each completed transaction from the ledger server and reconstructing a set of verification digests. This enables automatic verification of the root set digest to be verified in the transaction receipt information sent by the ledger server based on the reconstructed target verification root set digest, even when the trust anchor value corresponding to the reconstructed verification digest set is less than the transaction sequence number of the target transaction to be verified. This determines whether the root set digest to be verified generated by the ledger server is correct, i.e., whether the ledger server has altered the transaction data. By having the client actively generate a set of reconstructed verification digests to verify the transaction data of the ledger server, the existence and accuracy of each transaction data point can be accurately determined.

[0061] Furthermore, the data verification method, apparatus, computer equipment, and storage medium provided in this disclosure can also, when the trust anchor value is not less than the transaction sequence number, directly search for the generated verification root set digest of the constructed target node that matches the transaction sequence number from the reconstructed verification digest set, and then use the generated verification root set digest to verify the root set digest to be verified. This realizes the direct conversion of transaction data verification into a search and matching detection method. Compared with the prior art, which requires the construction of a Merkle set for each verification before verification, this method omits the step of reconstructing the verification root set digest, thereby improving the efficiency and convenience of transaction data verification.

[0062] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0063] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0064] Figure 1 A flowchart of a data verification method provided by an embodiment of this disclosure is shown;

[0065] Figure 2 A schematic diagram of a node to be verified provided in an embodiment of this disclosure is shown;

[0066] Figure 3 This illustration shows transaction receipt information for three target transactions provided in an embodiment of this disclosure;

[0067] Figure 4 This disclosure illustrates a prior art transaction verification method provided by an embodiment of the present invention.

[0068] Figure 5 A schematic diagram of a data verification apparatus provided in an embodiment of this disclosure is shown;

[0069] Figure 6 A schematic diagram of the structure of a computer device provided in an embodiment of this disclosure is shown. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown herein can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0071] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0072] In this article, "multiple or several" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0073] Research has revealed that in blockchain technology, transaction data from clients is typically stored in the blockchain database by a ledger server using a Merkle tree structure. Each time a client inserts a transaction, the ledger server needs to update the Merkle tree to store the newly inserted transaction and obtain its corresponding summary information. However, data stored in a blockchain database often needs to be decentralized and immutable. If the ledger server is not trusted by the client, the existence and authenticity of the transaction data stored on it will be questioned. Therefore, how to verify the existence and authenticity of transaction data stored on the ledger server by the client becomes a crucial issue that requires consideration and attention.

[0074] Based on the above research, this disclosure provides a data verification method, apparatus, computer equipment, and storage medium. When the ledger server is not trusted, the client reconstructs the target verification root set summary corresponding to the target transaction by downloading transaction data of each completed transaction from the ledger server and reconstructing a set of verification digests. This allows for automatic verification of the root set summary to be verified in the transaction receipt information sent by the ledger server, based on the reconstructed target verification root set summary, even when the trust anchor value corresponding to the reconstructed verification digest set is less than the transaction sequence number of the target transaction to be verified. This determines whether the root set summary to be verified generated by the ledger server is correct, i.e., whether the ledger server has altered the transaction data. By having the client actively generate a set of reconstructed verification digests to verify the transaction data of the ledger server, the existence and accuracy of each transaction data can be accurately determined.

[0075] The shortcomings of the above solutions are the result of the inventor's practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below should be considered as the inventor's contribution to this disclosure.

[0076] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0077] To facilitate understanding of this embodiment, a data verification method disclosed in this disclosure will first be described in detail. The execution subject of the data verification method provided in this disclosure is generally a terminal device or other processing device with certain computing power. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, personal digital assistant device (PDA), handheld device, computer device, etc. In some possible implementations, the data verification method can be implemented by the processor calling computer-readable instructions stored in the memory.

[0078] The data verification method provided in this disclosure embodiment will be described below using the client as the executing entity as an example.

[0079] like Figure 1 The flowchart shown is a data verification method provided in an embodiment of this disclosure, which may include the following steps:

[0080] S101: Obtain the transaction receipt information of the target transaction that has been processed and is currently completed, sent by the ledger server; the transaction receipt information includes the transaction sequence number of the target transaction and the root set summary of the node to be verified that matches the target transaction; the root set summary of the node to be verified includes the first summary information of at least one verification node used to verify the node to be verified, and the root set summary of the node to be verified is determined by the ledger server based on the transaction data of the target transaction.

[0081] Here, the Ledger Server manages transaction data for transactions initiated by various clients, and each client can be any Ledger Client. A client-initiated transaction is also known as a journal entry, which involves inserting new transaction data. Transaction data is the complete data corresponding to a single transaction, and may include information such as transaction amount, transaction counterparty, and transaction method.

[0082] Transaction data can be stored in a block-like database by a ledger server. Each transaction can have a transaction sequence number, which can be determined in an auto-incrementing order. Each transaction corresponds to a node to be verified. Each node to be verified has a journal sequence number (JSN), which can specifically be the transaction sequence number of the transaction corresponding to that node. Each node to be verified can also have a first digest. Each node to be verified can also have a root set digest generated by the ledger server based on the transaction data using a Merkle tree method. The root set digest can include the first digest information of at least one verifying node used to verify the node to be verified. The root set digest can be called a Merkle root set digest. The first digest information corresponding to the verifying node can be used to determine the existence and authenticity of the transaction data corresponding to the node to be verified. The root set digest can be determined by the ledger server based on the root set digests of the transaction data of each completed transaction. The first digest information can be determined by the ledger server after hashing the transaction data. The first digest information included in the root set digest to be verified can be represented by a journal digest.

[0083] like Figure 2 The diagram shown is a schematic of a node to be verified provided in this disclosure example, wherein... Figure 2 The binary tree shown includes 8 nodes to be verified (i.e., leaf nodes) and 7 verification nodes. Leaf nodes can also be used as verification nodes. Different verification nodes can be at different levels. The nodes to be verified at the lowest level are called leaf nodes. Each leaf node corresponds to a transaction. The first digest information of a leaf node can be obtained by hashing the transaction data of the transaction corresponding to that leaf node using the ledger server. The node number corresponding to a leaf node is the transaction number corresponding to that leaf node. The first digest information of each verification node other than the leaf nodes can be obtained by merging the first digest information of the two child nodes corresponding to that verification node. For example, for verification node 1, the first digest information of verification node 1 can be obtained by merging the first digest information of leaf node 1 and leaf node 2.

[0084] For example, in Figure 2In this Merkle tree, the verification node of leaf node 1 is leaf node 1 itself, and the root set digest to be verified of leaf node 1 can include leaf node 1 and its first digest information. When the transaction initiated by the client corresponds to leaf node 2, the ledger server can first generate leaf node 2 and its first digest information based on the transaction data sent by the client. Then, following the Merkle tree generation method, based on the first digest information of leaf node 2 and leaf node 1, it can generate the parent node (i.e., verification node 1) at the next higher level and its corresponding first digest information. At the same time, the verification node of leaf node 2 is verification node 1, and the root set digest to be verified of leaf node 2 can include verification node 1, which does not belong to the same level as leaf node 2, and its first digest information.

[0085] When the transaction initiated by the client (also known as the newly inserted transaction) is the transaction corresponding to leaf node 3, the ledger server can first generate leaf node 3 and its first summary information based on the transaction data of the transaction. At this time, the verification node of leaf node 3 can be verification node 1 and leaf node 3. The root set summary to be verified of leaf node 3 can include verification node 1 and its first summary information that does not belong to the same level as leaf node 3, as well as the first summary information of leaf node 3 and itself.

[0086] When the transaction initiated by the client corresponds to leaf node 4, the ledger server can first generate leaf node 4 and its first digest information based on the transaction data. Then, based on the first digest information corresponding to leaf node 3 and leaf node 4 respectively, it can generate the parent node (i.e., verification node 2) at the next higher level and its corresponding first digest information. Here, since the root set digest to be verified corresponding to leaf node 3 includes node 1 to be verified at the same level as verification node 2, after obtaining verification node 2, the ledger server can generate the parent node (i.e., verification node 3) at the next higher level and its corresponding first digest information based on the first digest information corresponding to verification node 1 and verification node 2 respectively. At this time, the root set digest to be verified of leaf node 4 can include verification node 3 and its first digest information.

[0087] When the transaction initiated by the client is the transaction corresponding to leaf node 5, the ledger server can first generate leaf node 5 and its first summary information based on the transaction data of the transaction. At this time, the verification node of leaf node 5 can be verification node 3 and leaf node 3. The root set summary to be verified of leaf node 5 can include verification node 3 and its first summary information that does not belong to the same level as leaf node 5, as well as the first summary information of leaf node 5 and itself.

[0088] When the transaction initiated by the client corresponds to leaf node 6, the ledger server can first generate leaf node 6 and its first digest information based on the transaction data. Then, based on the first digest information corresponding to leaf node 5 and leaf node 6 respectively, it can generate the parent node (i.e., verification node 4) at the next higher level and its corresponding first digest information. Here, since the verification nodes in the root set digest to be verified corresponding to leaf node 5 are verification node 3 and leaf node 5, which does not include verification nodes at the same level as verification node 4, it can be determined that the verification nodes of leaf node 6 can be verification node 3 and verification node 4. The root set digest to be verified of leaf node 6 can include verification node 3 and verification node 4 and their corresponding first digest information.

[0089] When the transaction initiated by the client corresponds to leaf node 7, the ledger server can first generate leaf node 7 and its first summary information based on the transaction data of the transaction. At this time, since the root set summary to be verified of leaf node 6 does not include the verification node at the same level as leaf node 7, the verification nodes of leaf node 7 can be determined to be verification node 3, verification node 4 and leaf node 7. The root set summary to be verified of leaf node 7 can include verification node 3 and verification node 4 and their corresponding first summary information, as well as leaf node 7 and its corresponding first summary information.

[0090] When the transaction initiated by the client corresponds to leaf node 8, the ledger server can first generate leaf node 8 and its first digest information based on the transaction data. Then, based on the first digest information corresponding to leaf node 7 and leaf node 8 respectively, it can generate the parent node (i.e., verification node 5) at the next higher level and its corresponding first digest information. Next, based on the verification node (i.e., verification node 4) at the same level as verification node 5 in the root set digest corresponding to leaf node 7, it can generate the parent node (i.e., verification node 6) at the next higher level and its corresponding first digest information. Then, based on the verification node (i.e., verification node 3) at the same level as verification node 6 in the root set digest corresponding to leaf node 7, it can generate the parent node (i.e., verification node 7) at the next higher level and its corresponding first digest information. At this point, the verification node corresponding to leaf node 8 is verification node 7, and the root set digest to be verified for leaf node 8 can include verification node 7 and its corresponding first digest information.

[0091] In practical applications, whenever a new transaction is inserted, the corresponding unverified node (i.e., leaf node) and its first digest information can be generated first. Then, the generation process described above can be followed. Figure 2The method of calculating the root set digest of each node to be verified (which can be called the cal_digest method) is used to determine each verification node and the root set digest of the node to be verified corresponding to the transaction.

[0092] It is understandable that the root set digest for each node to be verified may include not only the first digest information of each of the verification nodes of the node to be verified, but also the first digest information of the node to be verified itself.

[0093] In one embodiment, by targeting Figure 2 As can be seen from the description of each node to be verified, if the root set summary of the node to be verified before the node to be verified does not include a verification node at the same level as the node to be verified, the root set summary of the node to be verified shall at least include the first summary information of the node to be verified.

[0094] Here, the node to be verified can be the leaf node corresponding to any transaction, and the node preceding the node to be verified can be the leaf node preceding the leaf node. For example, Figure 2 The node preceding leaf node 4 is leaf node 3.

[0095] For example, targeting Figure 2 Leaf node 3 has a preceding node (leaf node 2) whose corresponding root set summary to be verified has a verification node 1. Verification node 1 and leaf node 3 do not belong to the same level, so the root set summary to be verified corresponding to leaf node 3 can at least include the first summary information of leaf node 3 and the first summary information of verification node 2.

[0096] Similarly, if the root set summary of the node to be verified includes a verification node at the same level as the node to be verified, the root set summary of the node to be verified will not include the first summary information of the node to be verified.

[0097] Furthermore, after storing transaction data for each transaction, the ledger server can also generate an execution result for that storage and a timestamp corresponding to the storage time of the transaction data. For example, when determining... Figure 2 After obtaining the root set summary of leaf node 3 to be verified, an execution result and timestamp indicating successful data storage of the transaction corresponding to leaf node 3 can be generated; conversely, if the root set summary of leaf node 3 to be verified is not successfully generated, an execution result indicating failure in data storage of the transaction corresponding to leaf node 3 can be generated.

[0098] The target transaction is a transaction from a client that the ledger server has currently completed processing. For example, if the transaction currently initiated by the client corresponds to leaf node 8, the target transaction is the transaction corresponding to leaf node 8. After the transaction data of the transaction corresponding to leaf node 8 is stored, it can be determined that the transaction corresponding to leaf node 8 has been processed. Then, the transaction receipt information of the transaction corresponding to leaf node 8 can be generated.

[0099] For example, the transaction receipt information (receipt) for a target transaction can be the receipt information generated by the ledger server after completing the transaction data storage and signing. Specifically, it may include the transaction sequence number of the target transaction, the root set digest of the node to be verified matching the target transaction, the timestamp, and the execution result. That is, the receipt of the target transaction may include the JSN, timestamp, execution result, Merkle root-set, and journal digest corresponding to the target transaction. The receipt may also include the signature of the ledger server, which can serve as non-repudiable evidence from the ledger server to prove that the information in the receipt was determined by the ledger server.

[0100] For example, a client can send transaction data for a newly inserted transaction to the ledger server at any time. After receiving the transaction data, the ledger server can generate a root set summary of the node to be verified matching the transaction, as well as transaction receipt information, in the manner described above. After generating transaction receipt information for each transaction, the ledger server can designate that transaction as the target transaction for the current processing and send its transaction receipt information back to the client.

[0101] S102: If the trust anchor value of the currently constructed reconstructed verification digest set is less than the transaction sequence number, determine the target verification root set digest corresponding to the target transaction based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server; the target verification root set digest includes the second digest information of each target node corresponding to the target transaction.

[0102] Here, the reconstructed verification digest set can be represented by Shrubs. It's the set of digests for each completed transaction that the client rebuilds based on the transaction data downloaded from the ledger server. A completed transaction is one for which the ledger server has already stored the corresponding transaction data. The trusted anchor value is the transaction number of the completed transaction with the largest transaction number from which the client has currently constructed the target verification root set digest.

[0103] At any given time, a client can download any number of completed transaction data from the ledger server, specifically the transaction data corresponding to the leaf nodes described below. For example, if available resources exist, the client can use the transaction data download command (DBMS_LEDGER_TABLE.GET_RAW_DATA) to download completed transaction data with sequence numbers 1 to 100 from the ledger server. After reconstructing the target verification root set digests corresponding to each of the completed transactions with sequence numbers 1 to 100, a currently constructed set of reconstructed verification digests can be obtained, consisting of the target verification root set digests corresponding to each of the completed transactions with sequence numbers 1 to 100. Then, if available resources exist again, the client can download completed transaction data with sequence numbers 101 to N from the ledger server, where N is a transaction sequence number less than or equal to the target transaction currently processed by the ledger server. Alternatively, it can be considered that the jsn in the transaction receipt information issued by the ledger server each time represents the transaction with the largest transaction sequence number currently processed by the ledger server. After the client reconstructs the target verification root set digests corresponding to the completed transactions with transaction numbers 101 to N, the currently constructed set of reconstructed verification digests can include the target verification root set digests corresponding to the completed transactions with transaction numbers 1 to N. The process of obtaining the set of reconstructed verification digests can be called the RebuildShrubs process.

[0104] The target verification root set digest can be the root set digest reconstructed by the client for each completed transaction. For example, in a completed transaction... Figure 2 When dealing with leaf node 3, the client can generate the target verification root set summary corresponding to leaf node 3 based on the transaction data of leaf node 3 downloaded from the ledger server, following the same method used by the ledger server to generate the root set summary of leaf node 3 to be verified. The target node is the node to be verified and / or the verification node generated by the client. In other words, the client and the ledger server generate root set summaries of transaction data for any transaction using the same generation method (i.e., cal_digest method). The client-generated root set summary is called the target verification root set summary, while the ledger server-generated root set summary is called the root set summary to be verified. Each node determined by the client is called a target node, and the summary information for each node is called the second summary information. Each node determined by the ledger server is called a node to be verified or a verification node, and the summary information for each node is called the first summary information. The target verification root set summary is used to verify the accuracy of the root set summary to be verified generated by the ledger server. The target verification root set summary can include the target nodes corresponding to completed transactions and their second summary information.

[0105] After downloading the transaction data of completed transactions from the ledger server, the client needs to reconstruct the data if available resources exist to obtain the target verification root set digest for each completed transaction. The trust anchor value is determined by the transaction sequence number of the completed transaction with the largest transaction sequence number among those whose target verification root set digests have been constructed. Since the transaction receipt information obtained by the client is sent by the ledger server in real time, there are cases where the JSN in the transaction receipt information is greater than the trust anchor value. In this case, it indicates that the client has not yet reconstructed the target verification root set digest corresponding to the target transaction and cannot verify the target transaction. Therefore, the client needs to generate a target verification root set digest that includes the second digest information of each target node corresponding to the target transaction, based on the transaction data of each completed transaction downloaded from the ledger server. The transaction with the largest sequence number among the completed transactions can be the target transaction, or the transaction sequence number of the transaction with the largest sequence number among the completed transactions is greater than the transaction sequence number of the target transaction.

[0106] In one embodiment, transaction data for any completed transaction downloaded by the client from the ledger server may include the original data of the completed transaction and a first summary information calculated by the ledger server based on the original data. The original data refers to the transaction data of any completed transaction sent by the client to the ledger server, and the first summary information calculated by the ledger server based on the original data may specifically be the first summary information of the leaf node corresponding to the completed transaction generated by the ledger server. It should be noted that the transaction data sent by the client to the ledger server only includes the original data, while the transaction data downloaded by the client from the ledger server may include both the original data and the first summary information.

[0107] If the target transaction is the completed transaction with the largest transaction sequence number downloaded by the client from the ledger server, the step in S102, "determine the target verification root set summary corresponding to the target transaction based on the reconstructed verification summary set and the transaction data of each completed transaction downloaded from the ledger server," can be implemented as follows:

[0108] S102-1: Based on the trust anchor value of the reconstructed verification summary set and the transaction sequence number of each completed transaction, select each transaction data to be constructed from the transaction data of each completed transaction whose transaction sequence number is greater than the trust anchor value.

[0109] For example, if the target transaction's transaction number is 1000, the maximum value of the transaction number of each completed transaction downloaded by the client from the ledger server is 1000, and the trust anchor value of the reconstructed verification digest set is 500, it means that the client currently only reconstructs the target verification root set digest of the 500th completed transaction. If the target transaction number 1000 needs to be verified, it is necessary to filter out the completed transactions with transaction numbers greater than 500 (also the completed transactions with transaction numbers from 501 to 1000) based on the transaction numbers of each completed transaction downloaded from the ledger server. Then, the transaction data of each completed transaction with transaction numbers from 501 to 1000 downloaded by the client can be used as the transaction data to be constructed.

[0110] S102-2: For each transaction data to be constructed, use a hash algorithm to perform hash calculation on the original data in the transaction data to be constructed, and determine the second digest information of the target node corresponding to the transaction data to be constructed.

[0111] For example, using a hash algorithm and the transaction data to be constructed, the second summary information corresponding to each completed transaction with transaction number 501 to 1000 can be calculated respectively.

[0112] S102-3: When the first summary information corresponding to each transaction data to be constructed is consistent with the second summary information of the transaction data to be constructed, the target verification root set summary corresponding to the target transaction is determined based on each transaction data to be constructed and the reconstruction verification set summary.

[0113] For example, if it is determined that the first summary information corresponding to the transaction data to be constructed is consistent with the second summary information of the same transaction data, it indicates that the summary information calculated by the client and the summary information calculated by the ledger server are consistent. Therefore, it can be preliminarily determined that the summary information of the leaf nodes with transaction serial numbers 501 to 1000 determined by the ledger server is accurate. Furthermore, based on each transaction data to be constructed and the reconstruction verification set summary, the target verification root set summary corresponding to the target transaction can be determined.

[0114] In one embodiment, the step of "determining the target verification root set summary corresponding to the target transaction based on each transaction data to be constructed and the reconstruction verification set summary" in S102-3 above can be implemented according to the following steps:

[0115] S102-3-1: Select the target data to be constructed from the transaction data to be constructed in ascending order of the transaction number of each transaction data to be constructed.

[0116] The purpose of this step is to explain that the client will determine the target verification root set digest for each completed transaction in ascending order of the transaction sequence number corresponding to each transaction data to be constructed.

[0117] For example, the transaction data to be constructed corresponding to the completed transaction with transaction number 501 can be used as the target construction data.

[0118] S102-3-2: Based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstruction verification digest set, determine the target verification root set digest of the target constructed data, and update the trust anchor value of the reconstruction verification set to the transaction sequence number of the target constructed data.

[0119] Here, the constructed data refers to the data to be constructed for completed transactions for which the client has reconstructed the corresponding target verification root set summary, and the constructed verification root set summary is the target verification root set summary of the completed transaction.

[0120] For example, when the trust anchor value is 500, the transaction data of each completed transaction with transaction sequence number 1 to 500 can be referred to as constructed data, and the target verification root set digests corresponding to each completed transaction with transaction sequence number 1 to 500 reconstructed by the client can be referred to as constructed verification root set digests.

[0121] In practice, the target verification root set summary of the target construction data can be determined by combining the transaction sequence number of the completed transaction corresponding to the target construction data with the previously constructed verification root set summary and the target construction data. This target verification root set summary is then added to the reconstructed verification set as a new constructed verification root set summary. At the same time, the trust anchor value of the reconstructed verification set can be updated to the transaction sequence number of the target construction data.

[0122] For example, if the transaction sequence number corresponding to the target construction data is 501, the target node (also the leaf node) corresponding to the completed transaction with transaction sequence number 501 can be generated first. Then, based on the second digest information of each target node included in the constructed verification root set digest corresponding to the completed transaction with transaction sequence number 500, and the second digest information of the leaf node with transaction sequence number 501, the target verification root set digest of the completed transaction with transaction sequence number 501 can be determined. This target verification root set digest can be added to the reconstructed verification set as a new constructed verification root set digest. At the same time, the trust anchor value of the reconstructed verification set can be updated to 501.

[0123] In one embodiment, for S102-3-2, when the transaction sequence number of the target constructed data is odd, the target verification root set summary of the target constructed data can be determined based on the target constructed verification root set summary of the constructed data whose transaction sequence number matches the trust anchor value in the reconstructed verification summary set, and the second summary information of the target constructed data.

[0124] For example, when the trust anchor value is 500, the target built verification root set digest of the built data that is consistent with the trust anchor value is the built verification root set digest of the completed transaction with transaction sequence number 500.

[0125] When the transaction sequence number of the completed transaction corresponding to the target construction data is 501, the client can first generate the leaf node for transaction sequence number 501. Then, the second digest information determined based on the target construction data can be used as the second digest information of the leaf node for transaction sequence number 501. Afterwards, each target node and its second digest information in the target constructed verification root set digest, as well as the leaf node for transaction sequence number 501 and its second digest information, can be used as the target verification root set digest of the leaf node for transaction sequence number 501, which is also the target verification root set digest of the target construction data.

[0126] In another embodiment, when the transaction sequence number of the target construction data is even, the target verification root set digest of the target construction data can be determined by following these steps:

[0127] Step 1: Based on the second summary information of the leaf nodes in the target's already constructed verification root set summary and the second summary information of the target's constructed data, generate the target node at the next higher level and the second summary information of that target node; the leaf node is the target node corresponding to the transaction data to be constructed.

[0128] It should be noted that after obtaining the transaction data to be constructed for each completed transaction, the client can first identify the leaf node of that completed transaction, or the target node of the leaf node type. Then, based on the transaction data to be constructed for that completed transaction, the client can generate the second summary information of that leaf node. Furthermore, based on the above embodiments, the root set summary of the node to be verified can include the first summary information of the leaf node. Similarly, the root set summary of the verified node generated by the client can also include the second summary information of the leaf node. A leaf node is a target node of a leaf node type corresponding to the transaction data to be constructed.

[0129] When the transaction sequence number of the target data is even, the preceding sequence number must be odd. Therefore, as can be seen from the previous embodiment, the digest of the completed verification root set corresponding to the preceding sequence number must include the second digest information of the leaf node corresponding to the preceding sequence number. In other words, the digest of the target completed verification root set must include the second digest information of a leaf node.

[0130] In practice, the second digest information of the leaf nodes in the target's constructed verification root set digest and the second digest information of the leaf nodes corresponding to the target's constructed data can be used to generate the next-level parent node and its second digest information. For example, when the transaction sequence number corresponding to the target's constructed data is 4, the transaction sequence number of the leaf node corresponding to the completed transaction of the previous sequence number is 3. The target's constructed verification root set digest corresponding to this leaf node must include the second digest information of that leaf node. Then, the next-level parent node, namely target node 2 (a target node of a verification node type), can be generated, and the second digest information of the leaf node with transaction sequence number 4 and the second digest information of the leaf node with transaction sequence number 3 can be merged as the second digest information of target node 2.

[0131] Step 2: Determine whether there exists a target node in the target already constructed verification root set summary that has the same node level as the target node in the previous level.

[0132] Here, the purpose of determining whether there is an existing target node with the same node level as the target node at the previous level is to determine whether a new target node at the previous level and its second summary information can be generated.

[0133] In specific implementation, if it is determined that there is a constructed target node in the target constructed verification root set summary that has the same node level as the target node in the previous level, then a new node in the previous level can be generated. Otherwise, the target node in the previous level generated in step one and the second summary information of the target node, as well as the target node and the second summary information in the target constructed verification root set summary other than the leaf nodes and their second summary information, can be used as the target verification root set summary of the target construction data.

[0134] Step 3: If yes, then based on the second summary information of the already constructed target node and the second summary information of the target node at the next higher level, generate the second summary information of the target node at the next higher level and the target node at the next higher level.

[0135] For example, if there is a constructed target node in the target's constructed root set digest that has the same node level as the target node generated in step one, a new parent node can be generated in the next level. The second digest information of the constructed target node and the second digest information of the target node generated in step one are then merged to obtain the second digest information of the new parent node in the next level.

[0136] Step 4: Return to the target already constructed verification root set summary to determine whether there is a constructed target node with the same node level as the target node in the previous level, until there is no constructed target node with the same node level as the target node. Based on the second summary information of the latest generated target node, determine the target verification root set summary of the target construction data.

[0137] Here, the newly generated target node is the target node generated according to steps one through four above. Based on the second digest information of the target node and the second digest information in the target already constructed verification root set digest, the target node cannot generate the parent node and the second digest information of the parent node.

[0138] The leaf node corresponding to the target data is designated as leaf node 8. The target verification root set summary corresponding to leaf node 7 includes target nodes 3 and 4 of the verification node type, leaf node 7 of the leaf node type, and the second summary information of each node. Based on steps one through four above, the target node 5 of the verification node type and its corresponding second summary information can be generated first, based on the second summary information of leaf node 8 and leaf node 7. Then, the target node 5 of the verification node type and its corresponding second summary information can be generated based on the second summary information of target node 5 and target node 4. Finally, the target node 7 of the verification node type and its corresponding second summary information can be generated based on the second summary information of target node 3 and target node 5. Thus, the newly generated target node is target node 7 of the verification node type. Since all target nodes in the target verification root set summary are used to generate the target nodes of the next level, there are no unused target nodes. Therefore, target node 7 and its corresponding second summary information can be used as the target verification root set summary of leaf node 8.

[0139] S102-3-3: Returns the steps of filtering out the target construction data from the transaction data to be constructed in ascending order of the transaction number of each transaction data to be constructed, until the target verification root set summary corresponding to the target transaction is determined.

[0140] For example, after updating the trust anchor value of the reconstructed verification set to 501, the process can return to execute S102-3-1. That is, taking the transaction data to be constructed corresponding to the completed transaction with transaction number 502 as the target construction data, execute S102-3-2 to determine the target verification root set digest of the completed transaction with transaction number 502, and add this target verification root set digest as a new constructed verification root set digest to the reconstructed verification set. At the same time, the trust anchor value of the reconstructed verification set can be updated to 502. Then, return to S102-3-1, taking the transaction data to be constructed corresponding to the completed transaction with transaction number 503 as the target construction data, and through continuous looping, directly determine the target verification root set digest of the completed transaction with transaction number 1000.

[0141] S103: If the first digest information of the verification node is consistent with the second digest information of the target node, determine that the root set digest to be verified has passed the verification, and update the trust anchor value to the transaction sequence number.

[0142] In practice, after the client determines the target verification root set digest corresponding to the target transaction, it can directly compare the target verification root set digest with the root set digest to be verified corresponding to the target transaction to determine whether they are consistent. If they are consistent, the root set digest to be verified is considered to have passed verification, and the trust anchor value is updated to the transaction sequence number of the target transaction. Otherwise, the root set digest to be verified is considered to have failed verification, and the trust anchor value can be updated to the transaction sequence number of the target transaction, or it can remain unchanged.

[0143] To determine whether the target verification root set digest and the root set digest to be verified are consistent, the following steps can be taken:

[0144] First, determine if the number of verification nodes in the root set digest to be verified for the target transaction matches the number of target nodes in the target verification root set digest corresponding to the target transaction, and also determine if each verification node matches each target node. For example, if the verification nodes are verification nodes 3 and 4, and the target nodes are target nodes of type verification node 3 and 4, then it can be determined that the number of verification nodes matches the number of target nodes, and that each verification node matches each target node. Otherwise, it can be directly determined that the root set digest verification failed.

[0145] Given that the quantities are consistent and each verification node matches each target node, for any pair of matching verification nodes and target nodes, it can be determined whether the first digest information of the verification node and the second digest information of the target node are consistent. Here, any pair of matching verification nodes and target nodes can be verification nodes and target nodes with the same sequence number. For example, verification node 3 matches target node 3 of verification node type, and verification node 4 matches target node 4 of verification node type.

[0146] If the digest information of each pair of matching verification nodes and target nodes is consistent, that is, if the first digest information of the verification node is consistent with the second digest information of the target node, it can be determined that the digest verification of the root set to be verified has passed, and the trust anchor value is updated to the transaction sequence number.

[0147] For example, when the transaction sequence number of the target transaction is 1000, if the verification of the root set digest to be verified of the target transaction is passed, the trust anchor value of the reconstructed verification digest set can be updated to 1000. In other words, the reconstructed verification digest set includes the target verification root set digests of each completed transaction with transaction sequence numbers from 1 to 1000 reconstructed by the client.

[0148] Understandably, if the root set digest verification passes, the client can provide the user with the target verification root set digest corresponding to the target transaction.

[0149] In this way, when the ledger server is not trusted, the client reconstructs the target verification root set digest corresponding to the target transaction by downloading transaction data of each completed transaction from the ledger server and rebuilding the verification digest set. This allows the client to automatically verify the root set digest to be verified in the transaction receipt information sent by the ledger server based on the reconstructed target verification root set digest, even if the trust anchor value corresponding to the reconstructed verification digest set is less than the transaction number of the target transaction to be verified. This determines whether the root set digest to be verified generated by the ledger server is correct, thus providing a result of whether the ledger server has altered the transaction data. By having the client actively generate a reconstructed verification digest set to verify the transaction data on the ledger server, the existence and accuracy of each transaction data point can be accurately determined.

[0150] In another embodiment, if it is determined that the first digest information and the second digest information are inconsistent, that is, if it is determined that the root set digest verification fails, the client can generate an exception message indicating that the root set digest verification fails and provide feedback on the generated exception message.

[0151] For example, the generated exception information can be displayed on the client or fed back to other clients or other servers. The other clients receiving the exception information can be any client with exception information processing capabilities; the other servers receiving the exception information can be any server with exception information processing capabilities.

[0152] For example, if the generated exception information is an invalid value NULL, the invalid value NULL can be displayed on the client side so that the user can see the exception information on the client. In this way, after receiving the exception information, the user can determine that the data stored on the ledger server is abnormal and that the corresponding stored data on the ledger server has been modified, and then the data can be recovered or adjusted manually.

[0153] In one embodiment, if the trust anchor value of the reconstructed verification digest set is not less than the transaction sequence number of the target transaction, the generated verification root set digest of the constructed target node that matches the transaction sequence number can be found from the reconstructed verification digest set.

[0154] Here, after reconstructing a certain number of generated verification root set digests of completed transactions, the client may need to verify any generated verification root set digest of any completed transaction. This need can be initiated by the server to the client, by the client itself, or by the user to the client; this embodiment does not impose any limitations. In this case, the trust anchor value of the reconstructed verification digest set will definitely not be less than the transaction sequence number of the target transaction.

[0155] Alternatively, if the client can reconstruct the set of reconstructed verification summaries faster than the ledger server, the client may have already generated the target verification root set summary corresponding to the target transaction. At this time, the server may not have generated the transaction receipt information corresponding to the target transaction. In this case, when the client receives the transaction receipt information, the trust anchor value of the reconstructed verification summary set will be no less than the transaction sequence number of the target transaction.

[0156] In either case, as long as the trust anchor value of the reconstructed verification digest set is not less than the transaction sequence number in the transaction receipt information of the target transaction, the generated verification root set digest of the constructed target node that matches the transaction sequence number can be found from the reconstructed verification digest set. Then, it is determined whether the generated verification root set digest and the root set digest to be verified are consistent. If they are consistent, it can be determined that the root set digest to be verified has passed verification. Otherwise, it can be determined that the root set digest to be verified has failed verification. Here, if the generated verification root set digest and the root set digest to be verified are consistent, it can be indicated that the transaction receipt information sent by the ledger server meets the preset requirements; where the preset requirements can be the requirement that the transaction data information has not been modified.

[0157] as follows Figure 3 The diagram shown illustrates transaction receipt information for three target transactions provided in this embodiment of the disclosure. The transaction receipt information obtained by the client corresponds to the three target transactions. Figure 3 The data is represented by server receipt information, which includes the transaction receipt information for target transaction with transaction number 100, target transaction with transaction number 300, and target transaction with transaction number 1000.

[0158] Once the root set digest of the target transaction with transaction number 1000 is verified by the client, the trust anchor value of the client's reconstructed verification digest set will also become 1000. Afterwards, if there is a need to verify the existence of the target transaction with transaction number 100, the client can directly search for the generated verification root set digest corresponding to the completed transaction with transaction number 100 in the reconstructed verification digest set. Then, it is determined whether this generated verification root set digest matches the root set digest to be verified in the transaction receipt information corresponding to the target transaction with transaction number 100. If they match, it can be determined that the target transaction with transaction number 100 exists and is accurate; otherwise, it can be determined that the target transaction with transaction number 100 does not exist. In this way, transaction data verification can be directly converted into a search and matching detection. Compared with the existing technology that requires the client to reconstruct the Merkle set before verification, the verification efficiency is effectively improved and the verification complexity is effectively reduced.

[0159] as follows Figure 4 The image shown illustrates a prior art transaction verification method provided in this disclosure. Figure 4In the Merkel binary tree, for example, when verifying the target transaction with transaction number 11, it is necessary not only to reconstruct the Merkel binary tree based on the transaction data of target transactions with transaction numbers from 1 to 11, but also, when determining the Merkel summary corresponding to the target transaction with transaction number 11, it is necessary to first copy the transaction data of the target transaction with transaction number 11 to obtain a copied transaction data, and generate the virtual leaf node corresponding to the copied transaction data (i.e., Figure 4 The virtual leaf node 12 in the middle), then, based on the transaction data of the target transaction with transaction number 11 and the copied transaction data, generates the node of the next level (i.e., Figure 4 Node a) and its summary information. Then, based on the summary information of node a and the parent node of the leaf node of the target transactions with transaction numbers 9 and 10 (i.e., the node at the next higher level). Figure 4 Node b) in the middle generates the node at the next higher level (i.e., Figure 4 The process involves taking node c and its summary information, and finally copying node c to obtain the copied node (i.e., ...). Figure 4 The virtual node d in the middle), finally, based on the summary information of node c and the replicated node d and its corresponding replicated summary information, generates the node of the next level (i.e., Figure 4 The process involves first identifying node e in the sequence and its summary information. Then, based on the summary information of node f corresponding to leaf node 8 and node e, the root node (i.e., the root node corresponding to the target transaction with transaction number 11) is generated. Figure 4 The above process not only includes the assignment of node values, but also generates intermediate data (such as the summary information corresponding to virtual leaf node 12, the summary information corresponding to virtual node d, etc.), which greatly affects the verification efficiency and increases the verification complexity. However, the data verification method provided in this embodiment directly converts transaction data verification into a search and matching detection method, omitting the step of reconstructing the verification root set summary, thus improving the efficiency and convenience of transaction data verification.

[0160] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0161] Based on the same inventive concept, this disclosure also provides a data verification device corresponding to the data verification method. Since the principle of the device in this disclosure for solving the problem is similar to that of the data verification method described above, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0162] like Figure 5The diagram shown is a schematic representation of a data verification device provided in an embodiment of this disclosure, comprising:

[0163] The acquisition module 501 is used to acquire transaction receipt information of a target transaction that has been processed and completed, sent by the ledger server; the transaction receipt information includes the transaction sequence number of the target transaction and a root set summary of the node to be verified that matches the target transaction; the root set summary includes first summary information of at least one verification node used to verify the node to be verified, and the root set summary is determined by the ledger server based on the transaction data of the target transaction;

[0164] The first verification module 502 is used to determine the target verification root set summary corresponding to the target transaction based on the reconstructed verification summary set and the transaction data of each completed transaction downloaded from the ledger server when the trust anchor value of the currently constructed reconstructed verification summary set is less than the transaction sequence number; the target verification root set summary includes the second summary information of each target node corresponding to the target transaction;

[0165] The second verification module 503 is used to determine that the root set digest to be verified has passed verification when the first digest information of the verification node is consistent with the second digest information of the target node, and to update the trust anchor value to the transaction sequence number.

[0166] In one possible implementation, if the root set summary of the node to be verified does not include a verification node at the same level as the node to be verified, the root set summary of the node to be verified shall at least include the first summary information of the node to be verified.

[0167] In one possible implementation, the second verification module 503 is further configured to:

[0168] If the trust anchor value is not less than the transaction sequence number, find the generated verification root set digest of the constructed target node that matches the transaction sequence number from the reconstructed verification digest set;

[0169] If the generated root set digest and the root set digest to be verified are consistent, the root set digest to be verified is determined to be verified successfully; the successful verification of the root set digest to be verified is used to indicate that the transaction receipt information sent by the ledger server meets the preset requirements.

[0170] In one possible implementation, the completed transaction with the highest transaction sequence number is the target transaction; the transaction data includes the original data of the completed transaction and a first summary information calculated by the ledger server based on the original data;

[0171] The first verification module 502, when determining the target verification root set digest corresponding to the target transaction based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server, is used to:

[0172] Based on the trust anchor value of the reconstructed verification summary set and the transaction sequence number of each completed transaction, each transaction data to be constructed with a transaction sequence number greater than the trust anchor value is selected from the transaction data of each completed transaction.

[0173] For each of the transaction data to be constructed, a hash algorithm is used to perform hash calculation on the original data in the transaction data to be constructed, and to determine the second digest information of the target node corresponding to the transaction data to be constructed.

[0174] If the first summary information corresponding to each of the transaction data to be constructed is consistent with the second summary information of the transaction data to be constructed, the target verification root set summary corresponding to the target transaction is determined based on each of the transaction data to be constructed and the reconstruction verification set summary.

[0175] In one possible implementation, the first verification module 502, when determining the target verification root set summary corresponding to the target transaction based on each of the transaction data to be constructed and the reconstruction verification set summary, is configured to:

[0176] Target construction data is selected from the transaction data to be constructed in ascending order of the transaction sequence number of each transaction data to be constructed;

[0177] Based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstruction verification digest set, the target verification root set digest of the target constructed data is determined, and the trust anchor value of the reconstruction verification set is updated to the transaction sequence number of the target constructed data.

[0178] Return to the step of filtering out target construction data from the transaction data to be constructed in ascending order of the transaction number of each transaction data to be constructed, until the target verification root set digest corresponding to the target transaction is determined.

[0179] In one possible implementation, the first verification module 502, when determining the target verification root set digest of the target construction data based on the transaction sequence number of the target construction data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set, is configured to:

[0180] When the transaction sequence number of the target constructed data is odd, the target verification root set digest of the target constructed data is determined based on the target constructed verification root set digest of the constructed data whose transaction sequence number matches the trust anchor value in the reconstruction verification digest set, and the second digest information of the target constructed data.

[0181] In one possible implementation, the first verification module 502, when determining the target verification root set digest of the target construction data based on the transaction sequence number of the target construction data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set, is configured to:

[0182] When the transaction sequence number of the target construction data is even, the target node and its second summary information are generated based on the second summary information of the leaf nodes in the target already constructed verification root set summary and the second summary information of the target construction data; the leaf node is the target node corresponding to the transaction data to be constructed.

[0183] Determine whether there exists a constructed target node in the target's constructed verification root set digest that has the same node level as the target node in the previous level;

[0184] If so, then based on the second summary information of the already constructed target node and the second summary information of the target node at the next higher level, generate the second summary information of the target node at the next higher level and the target node at the next higher level;

[0185] Return to determine whether there is a built target node in the target's built verification root set digest that has the same node level as the target node in the previous level, until there is no built target node with the same node level as the target node. Based on the second digest information of the latest generated target node, determine the target verification root set digest of the target construction data.

[0186] In one possible implementation, the second verification module 503 is further configured to:

[0187] If the first digest information is inconsistent with the second digest information, an exception message indicating that the digest verification of the root set to be verified has failed is generated.

[0188] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0189] Based on the same technical concept, embodiments of this application also provide a computer device. (Refer to...) Figure 6 The diagram shown is a structural schematic of a computer device provided in an embodiment of this application, comprising:

[0190] The system includes a processor 61, a memory 62, and a bus 63. The memory 62 stores machine-readable instructions executable by the processor 61. The processor 61 executes these machine-readable instructions, and when executed, performs the following steps: S101: Obtain transaction receipt information for the currently completed target transaction sent by the ledger server; the transaction receipt information includes the transaction sequence number of the target transaction and a root set summary of the node to be verified matching the target transaction; the root set summary includes first summary information of at least one verification node used to verify the node to be verified, and the root set summary is the ledger... The server determines the target transaction based on the transaction data of the target transaction; S102: If the trust anchor value of the currently constructed reconstructed verification digest set is less than the transaction sequence number, the target verification root set digest corresponding to the target transaction is determined according to the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server; The target verification root set digest includes the second digest information of each target node corresponding to the target transaction and S103: If the first digest information of the verification node is consistent with the second digest information of the target node, it is determined that the root set digest to be verified has passed the verification, and the trust anchor value is updated to the transaction sequence number.

[0191] The aforementioned memory 62 includes a main memory 621 and an external memory 622. The main memory 621, also known as internal memory, is used to temporarily store the computational data in the processor 61, as well as the data exchanged with external memory such as a hard disk. The processor 61 exchanges data with the external memory 622 through the main memory 621. When the computer device is running, the processor 61 and the memory 62 communicate through the bus 63, so that the processor 61 executes the execution instructions mentioned in the above method embodiments.

[0192] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the data verification method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0193] The computer program product of the data verification method provided in this disclosure includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the data verification method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0194] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0195] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0196] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0197] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0198] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0199] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the user through pop-up information or by asking the user to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0200] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A data verification method, characterized in that, Applied to the client side, including: Obtain transaction receipt information for the currently completed target transaction sent by the ledger server; the transaction receipt information includes the transaction sequence number of the target transaction and a root set summary of the node to be verified that matches the target transaction; the root set summary includes first summary information of at least one verification node used to verify the node to be verified, and the root set summary is determined by the ledger server based on the transaction data of the target transaction. If the trust anchor value of the currently constructed reconstructed verification digest set is less than the transaction sequence number, the target verification root set digest corresponding to the target transaction is determined based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server; the target verification root set digest includes the second digest information of each target node corresponding to the target transaction; If the first digest information of the verification node is consistent with the second digest information of the target node, it is determined that the root set digest to be verified has passed the verification, and the trust anchor value is updated to the transaction sequence number.

2. The method according to claim 1, characterized in that, If the root set summary of the node to be verified does not include a verification node at the same level as the node to be verified, the root set summary of the node to be verified shall at least include the first summary information of the node to be verified.

3. The method according to claim 1, characterized in that, The method further includes: If the trust anchor value is not less than the transaction sequence number, find the generated verification root set digest of the constructed target node that matches the transaction sequence number from the reconstructed verification digest set; If the generated root set digest and the root set digest to be verified are consistent, the root set digest to be verified is determined to be verified successfully; the successful verification of the root set digest to be verified is used to indicate that the transaction receipt information sent by the ledger server meets the preset requirements.

4. The method according to any one of claims 1 to 3, characterized in that, The completed transaction with the highest transaction sequence number is the target transaction; the transaction data includes the original data of the completed transaction and the first summary information calculated by the ledger server based on the original data; The step of determining the target verification root set digest corresponding to the target transaction based on the reconstructed verification digest set and the transaction data of each completed transaction downloaded from the ledger server includes: Based on the trust anchor value of the reconstructed verification summary set and the transaction sequence number of each completed transaction, each transaction data to be constructed with a transaction sequence number greater than the trust anchor value is selected from the transaction data of each completed transaction. For each of the transaction data to be constructed, a hash algorithm is used to perform hash calculation on the original data in the transaction data to be constructed, and to determine the second digest information of the target node corresponding to the transaction data to be constructed. If the first summary information corresponding to each of the transaction data to be constructed is consistent with the second summary information of the transaction data to be constructed, the target verification root set summary corresponding to the target transaction is determined based on each of the transaction data to be constructed and the reconstruction verification set summary.

5. The method according to claim 4, characterized in that, The step of determining the target verification root set digest corresponding to the target transaction based on each of the transaction data to be constructed and the reconstruction verification set digest includes: Target construction data is selected from the transaction data to be constructed in ascending order of the transaction sequence number of each transaction data to be constructed; Based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstruction verification digest set, the target verification root set digest of the target constructed data is determined, and the trust anchor value of the reconstruction verification set is updated to the transaction sequence number of the target constructed data. Return to the step of filtering out target construction data from the transaction data to be constructed in ascending order of the transaction number of each transaction data to be constructed, until the target verification root set digest corresponding to the target transaction is determined.

6. The method according to claim 5, characterized in that, The step of determining the target verification root set digest of the target constructed data based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set includes: When the transaction sequence number of the target constructed data is odd, the target verification root set digest of the target constructed data is determined based on the target constructed verification root set digest of the constructed data whose transaction sequence number matches the trust anchor value in the reconstruction verification digest set, and the second digest information of the target constructed data.

7. The method according to claim 6, characterized in that, The step of determining the target verification root set digest of the target constructed data based on the transaction sequence number of the target constructed data and the constructed verification root set digests of each constructed data included in the reconstructed verification digest set includes: When the transaction sequence number of the target construction data is even, the target node and its second summary information are generated based on the second summary information of the leaf nodes in the target already constructed verification root set summary and the second summary information of the target construction data; the leaf node is the target node corresponding to the transaction data to be constructed. Determine whether there exists a constructed target node in the target's constructed root set digest that has the same node level as the target node in the previous level; If so, then based on the second summary information of the already constructed target node and the second summary information of the target node at the next higher level, generate the second summary information of the target node at the next higher level and the target node at the next higher level; Return to determine whether there is a built target node in the target's built verification root set digest that has the same node level as the target node in the previous level, until there is no built target node with the same node level as the target node. Based on the second digest information of the latest generated target node, determine the target verification root set digest of the target construction data.

8. The method according to claim 1, characterized in that, The method further includes: If the first digest information and the second digest information are inconsistent, an exception message indicating that the digest verification of the root set to be verified has failed is generated.

9. A data verification device, characterized in that, include: The acquisition module is used to acquire transaction receipt information of a target transaction that has been processed and completed, sent by the ledger server. The transaction receipt information includes the transaction sequence number of the target transaction and a root set summary of the node to be verified that matches the target transaction. The root set summary includes first summary information of at least one verification node used to verify the node to be verified. The root set summary is determined by the ledger server based on the transaction data of the target transaction. The first verification module is used to determine the target verification root set summary corresponding to the target transaction based on the reconstructed verification summary set and the transaction data of each completed transaction downloaded from the ledger server, when the trust anchor value of the currently constructed reconstructed verification summary set is less than the transaction sequence number; the target verification root set summary includes the second summary information of each target node corresponding to the target transaction; The second verification module is used to determine that the root set digest to be verified has passed verification when the first digest information of the verification node is consistent with the second digest information of the target node, and to update the trust anchor value to the transaction sequence number.

10. A computer device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, the processor executing the machine-readable instructions stored in the memory, wherein when the machine-readable instructions are executed by the processor, the processor performs the steps of the data verification method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a computer device, performs the steps of the data verification method as described in any one of claims 1 to 8.

Images