Blockchain-based transaction data verification method and apparatus

Abstract

The application provides a blockchain-based transaction data verification method and device. The method comprises the following steps: receiving a first request for verifying the existence of target transaction data sent by a first terminal; in response to the first request, generating a proof of existence of the target transaction data based on a target binary tree; and sending the proof of existence to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the proof of existence. The target binary tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a blockchain in the form of a binary tree. The proof of existence comprises a first proof and a second proof. The first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree. The second proof is used to prove that the target transaction data exists in a target block. The blockchain-based transaction data verification method and device provided by the application can generate a proof of existence and obtain a verification result more quickly in a resource-limited occasion.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a transaction data verification method and device based on blockchain. BACKGROUND

[0002] Digital evidence can be used in various occasions to prove that "there is this specific information and it is generated at a specific time" through the credit endorsement provided by an authoritative agency to fix specific information. Based on the principle of data tamper-proofing of blockchain, the transaction data can be stored on the blockchain as specific information to generate a proof of existence (PoE) based on the blockchain to achieve verification.

[0003] In the prior art, the proof provider can also organize the current complete transaction data Merkle tree root sequence [M1, M2, M3…M N ] into a single Merkle tree, and take the tree root of this Merkle tree as the verification information S'(N). The proof provider provides a corresponding proof of existence for each verification information. However, for each blockchain height and corresponding transaction data Merkle tree root sequence, the proof provider will have to store and maintain different Merkle trees to generate the corresponding proof of existence that matches the verification information. When the chain height is N, the space of a single Merkle tree is 2N, and the space overhead of N different Merkle trees grows in proportion to the square of N. Therefore, as the length of the blockchain increases, the length of the verification information and the proof of existence will also increase significantly, resulting in a large increase in the communication and computing overhead required for the proof of existence, making it difficult to obtain verification results in time in various resource-limited situations. SUMMARY

[0004] The present application provides a transaction data verification method and device based on blockchain to solve the defect that it is difficult to obtain verification results in time in various resource-limited situations in the prior art, and to achieve fast and timely transaction verification.

[0005] In a first aspect, the present application provides a transaction data verification method based on blockchain, comprising:

[0006] receiving a first request sent by a first terminal for verifying the existence of target transaction data;

[0007] In response to the first request, generating a proof of existence of the target transaction data based on a target binary tree;

[0008] sending the proof of existence to the first terminal to enable the first terminal to verify whether the target transaction data exists based on the proof of existence;

[0009] The target binomial tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of the blockchain in the form of a binomial tree.

[0010] In one embodiment, before the generating the existence proof of the target transaction data based on the target binomial tree in response to the first request, the method further comprises:

[0011] The Merkle tree root sequence is converted to be stored in the form of a binomial tree to obtain the target binomial tree.

[0012] In one embodiment, before the converting the Merkle tree root sequence to be stored in the form of a binomial tree to obtain the target binomial tree, the method further comprises:

[0013] The transaction data in each block is stored in the form of a Merkle tree in the block.

[0014] In one embodiment, the converting the Merkle tree root sequence to be stored in the form of a binomial tree to obtain the target binomial tree specifically comprises:

[0015] Each Merkle tree root in the Merkle tree root sequence is converted to a leaf node of the target binomial tree to obtain the target binomial tree.

[0016] In a second aspect, the present application provides a transaction data verification method based on a blockchain, comprising:

[0017] sending a first request for verifying existence of target transaction data to a second terminal, so that the second terminal generates an existence proof of the target transaction data based on a target binomial tree in response to the first request;

[0018] receiving the existence proof sent by the second terminal, and verifying whether the target transaction data exists based on the existence proof;

[0019] The target binomial tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of the blockchain in the form of a binomial tree. The existence proof comprises a first proof and a second proof. The first proof is used to prove that a Merkle tree root of the target transaction data exists in the target binomial tree. The second proof is used to prove that the target transaction data exists in a target block.

[0020] In one embodiment, the verifying whether the target transaction data exists based on the existence proof specifically comprises:

[0021] verify the correctness of the first proof and the second proof;

[0022] verify whether the first proof is legal based on verification information in a case where the first proof and the second proof are both correct;

[0023] determine that the target transaction data exists in a case where the first proof is legal.

[0024] In a third aspect, the present application provides a transaction data verification device based on a block chain, comprising:

[0025] a first receiving module configured to receive a first request for verifying existence of target transaction data sent by a first terminal;

[0026] a proof generating module configured to generate an existence proof of the target transaction data based on a target binary tree in response to the first request;

[0027] a first sending module configured to send the existence proof to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the existence proof;

[0028] The target binary tree is configured to store a Merkle tree root sequence composed of Merkle tree roots of transaction data in each block of a block chain in the form of a binary tree; the existence proof comprises a first proof and a second proof; the first proof is configured to prove that a Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is configured to prove that the target transaction data exists in a target block.

[0029] In a fourth aspect, the present application provides a transaction data verification device based on a block chain, comprising:

[0030] a second sending module configured to send a first request for verifying existence of target transaction data to a second terminal, so that the second terminal generates an existence proof of the target transaction data based on a target binary tree in response to the first request;

[0031] a second receiving module configured to receive the existence proof sent by the second terminal and verify whether the target transaction data exists based on the existence proof;

[0032] The target binary tree is configured to store a Merkle tree root sequence composed of Merkle tree roots of transaction data in each block of a block chain in the form of a binary tree; the existence proof comprises a first proof and a second proof; the first proof is configured to prove that a Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is configured to prove that the target transaction data exists in a target block.

[0033] In a fifth aspect, the present application provides an electronic device comprising a processor and a memory storing a computer program, wherein the processor implements the steps of any of the above-mentioned blockchain-based transaction data verification methods when executing the computer program.

[0034] In a sixth aspect, the present application provides a processor-readable storage medium storing a computer program, wherein the computer program is configured to make the processor execute the steps of any of the above-mentioned blockchain-based transaction data verification methods.

[0035] The blockchain-based transaction data verification method and device provided by the present application can significantly reduce the communication and calculation overhead of generating the existence proof, and can generate the existence proof more quickly and timely and obtain the verification result based on the existence proof in the case of resource limitation. BRIEF DESCRIPTION OF DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0037] Figure 1 is a flowchart of the blockchain-based transaction data verification method provided by the present application;

[0038] Figure 2 is a schematic diagram of the target binary tree in the blockchain-based transaction data verification method provided by the present application;

[0039] Figure 3 is a schematic diagram of the blockchain in the blockchain-based transaction data verification method provided by the present application;

[0040] Figure 4 is a flowchart of the blockchain-based transaction data verification method provided by the present application;

[0041] Figure 5 is a structural schematic diagram of the blockchain-based transaction data verification device provided by the present application;

[0042] Figure 6This is a schematic diagram of the structure of the blockchain-based transaction data verification device provided by the present invention;

[0043] Figure 7 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0045] To facilitate understanding of this invention, the relevant concepts of blockchain-based transaction data verification are explained below. The following three types of roles can exist in the blockchain-based transaction data verification process:

[0046] First, there are "provers," who are responsible for providing relevant information to prove the existence of specific transaction data. This information is known as "existence proof." Second, there are "verifiers," who can use "existence proof" to determine whether the transaction data actually exists. Third, there are "proof providers," who are participants in the blockchain consensus process or have the ability to continuously observe and record all blockchain data. Therefore, proof providers can provide verifiers and provers with any information needed for existence proof at any time.

[0047] Due to the openness and cryptographic nature of blockchain, proof providers cannot easily deceive validators or provers. For example, a validator can request the block information needed to perform verification from multiple independent proof providers. If the proof providers are honest, the verification information provided by different proof providers will necessarily be consistent. Validators can also verify this verification information based on information from other blockchains (such as header block information). Furthermore, as long as the verification information possessed by the validator is correct, the proof provider cannot provide information in any way to forge an existence proof, making the validator believe that transaction information that does not exist on the chain does exist. Therefore, a strong trust relationship is not required between provers, validators, and proof providers, and provers do not need to rely on the same proof provider providing verification information to obtain a valid existence proof.

[0048] The following is combined Figures 1-7 This invention describes a blockchain-based transaction data verification method and apparatus.

[0049] Figure 1is a flowchart of a blockchain-based transaction data verification method provided by the present application. The following will be described in combination with Figure 1 The blockchain-based transaction data verification method provided by the present application is described. As shown in the figure, the method comprises the following steps. Figure 1 Step 101, receiving a first request for verifying the existence of target transaction data sent by a first terminal.

[0050] Specifically, the execution subject of the blockchain-based transaction data verification method provided by the present application is a transaction data verification device. The transaction data verification device is a second terminal, which communicates with the first terminal. The second terminal is a "prover" or a "proof provider", and the first terminal is a "verifier".

[0051] The first terminal sends a first request to the second terminal, requesting the second terminal to provide a proof of existence of the target transaction data to verify the existence of the target transaction data; and the second terminal receives the first request.

[0052] Step 102, in response to the first request, generating a proof of existence of the target transaction data based on a target binary tree.

[0053] Wherein, the target binary tree is used to store a Merkle tree root sequence composed of Merkle tree roots of transaction data in each block of the blockchain in the form of a binary tree; the proof of existence comprises a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is used to prove that the target transaction data exists in the target block.

[0054] Specifically, after the second terminal receives the first request, based on the block position p (i.e. the target block) where the target transaction data is located, the Merkle tree root M p and M p currently located in the binary tree element T of the target transaction data are found in the target binary tree. Since T is also a Merkle tree, a proof of existence {P p p t} of M p t} in T can be generated. {P

[0055] Based on the block position p where the target transaction data is located, a proof of existence {P p b} that the target transaction data exists in the target block can be generated. {P p b} is the second proof.

[0056] ​The Merkle tree root sequence of the transaction data in each block of the blockchain is converted into the form of a Binominal tree in advance and stored. The target Binominal tree is a set of complete binary trees, and each element T m in the set is a complete binary tree. The complete binary tree is a Merkle tree.

[0057] The Merkle tree root of the transaction data in the i-th block of the blockchain is M i Therefore, for the current blockchain with a height of N, there is a Merkle tree root sequence [M1, M2, M3…M N ].

[0058] Figure 2 The target Binominal tree is shown. The height of the blockchain is 53 (binary representation is 110101), and the transaction Merkle tree root sequence of the corresponding block is [M0…M52], which is distributed on the leaf nodes of the Binominal tree containing 4 elements. The tree heights of the 4 elements are 0, 2, 4, and 5, respectively, and there are 1, 4, 16, and 32 leaf nodes, respectively. There are no elements with heights of 1 and 3 in the Binominal tree. The digest information is the root of the 4 elements: S(53)={0:Root(T0),2:Root(T2),4:Root(T4),5:Root(T5)}, or it can be represented using a sequence: S(53)=[Root(T0),nil,Root(T2),nil,Root(T4),Root(T5)].

[0059] It can be understood that the proof provider continuously maintains the Merkle tree root sequence information and generates a digest information S(N) of the sequence, and when the verifier makes a request, the proof provider provides the current digest information S(N) to the verifier as verification information. Using this verification information, the verifier can verify the existence proof corresponding to all transactions contained in the chain up to height N. The Merkle tree root sequence corresponding to the blockchain with a length of N is the leaf sequence of the elements in the Binominal tree BI(N). Therefore, the number of elements in the Binominal tree does not exceed lg(N), and accordingly, the length of S(N) as verification information is proportional to lg(N).

[0060] The first proof and the second proof can constitute the existence proof of the target transaction data. The structure of the existence proof is a new structure of transaction data existence proof.

[0061] Step 103, sending the existence proof to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the existence proof.

[0062] Specifically, after generating the existence proof, the second terminal sends the existence proof to the first terminal.

[0063] After the first terminal receives the existence proof, it verifies whether the target transaction data exists based on the existence proof.

[0064] It is obvious that the target binary tree does not delete any element in the generation process, nor does it change the parent-child relationship of any element; therefore, a binary tree based on block height M actually contains all elements in any verification information S(0)…S(M) from 0 to M, and the element in the verification information S(m) generated from block height m is always the root element of the first m leaf elements (i.e., leaf nodes) in any binary tree at height n>m.

[0065] When the proof provider provides a Merkle tree root M p based on the current recorded binary tree information for the transaction data located in the block at height p, {P p t} is an existence proof of M p t} given by the element (Merkle tree) where M p is located. Therefore, for any verification information S(n>p) generated after p, the elements of these verification information are root elements of the subtree where leaf M p is located. From the property of the existence proof of the Merkle tree, it is easy to know that {P p p t} is a path from leaf M p to the root of the Merkle tree where M p is located, so this path must pass through the root element of any subtree where M p t} is located, that is, at least one element in any verification information appears in the path, i.e., {P

[0066] Therefore, based on the existence proof including the first proof and the second proof, it can be verified whether the target transaction data exists.

[0067] An embodiment of the above scheme is a cross-chain smart contract: a business party wants to perform a specific transaction (e.g., perform a guarantee operation) on a certain block chain B before a certain time T, and trigger a smart contract on another block chain A (e.g., obtain corresponding rights based on a certain guarantee operation); therefore, a scheme is needed to enable the smart contract on A to determine that the input transaction data content has indeed occurred on chain B.

[0068] ​The author of the smart contract can request the proof provider to provide the verification information currently on chain B at time T, and solidify it into the smart contract deployed on A. After that, any user who wants to execute this smart contract can input the transaction information executed on chain B before time T and the existence proof data into the smart contract, and the smart contract parses and verifies the input transaction content and existence proof, thereby triggering the execution of the smart contract.

[0069] It can be understood that the lengths of the first proof and the second proof correspond to the height of the transaction Merkle tree and the height of the elements in the target binomial tree, respectively. In a general blockchain system, the number of transactions in a single block has an upper limit, i.e., the block size; therefore, the length of the first proof is a constant, and the length of the second proof is proportional to lg(N). p b The length of the first proof can be regarded as a constant, and the length of the second proof is proportional to lg(N). p t The length of the second proof is proportional to lg(N).

[0070] Both the verifier and the prover can complete the submission and verification of the existence proof of the on-chain transaction data based on a limited amount of information and a calculation process proportional to the logarithm of the current height N of the blockchain, i.e., lg(N). In the traditional scheme, in order to prove the existence of a specific block, the complete block sequence data is required, and the amount of information and the verification process are both proportional to the current block height N in the worst case. Therefore, the embodiments of the present application significantly reduce the communication and calculation overhead required for executing the existence proof, which is of great significance in various resource-limited scenarios (such as specific hardware devices and / or smart contracts, etc.).

[0071] For the scheme of organizing the current complete transaction data Merkle tree root sequence [M1, M2, M3…M N ] into a single Merkle tree, and taking the tree root of this Merkle tree as the verification information S'(N), the proof provider will have to store and maintain different Merkle trees to generate the corresponding existence proof matching the verification information. When the height of the blockchain is N, the space of a single Merkle tree is 2N, and the space overhead of N different Merkle trees grows in proportion to the square of N. Therefore, this scheme is very difficult to implement and is basically unrealistic.

[0072] In the embodiments of the present application, when the height of the blockchain is N, the storage space overhead of maintaining a single binomial tree is only proportional to N (more accurately, 2N), thus significantly reducing the communication and calculation overhead required for executing the existence proof, which is of great significance in various resource-limited scenarios (such as specific hardware devices and / or smart contracts, etc.).

[0073] The embodiment of the present application is based on a target binary tree of a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a block chain stored in the form of a binary tree, generates a first proof for proving that the Merkle tree root of the target transaction data exists in the target binary tree and a second proof for proving that the target transaction data exists in the target block, and combines the first proof and the second proof into an existence proof, which can significantly reduce the communication and calculation overhead of generating the existence proof and can generate the existence proof more quickly and timely and obtain a verification result based on the existence proof in a resource-limited case.

[0074] According to the content of any of the above embodiments, in response to the first request, before generating the existence proof of the target transaction data based on the binary tree, the method further includes: converting the Merkle tree root sequence into storage in the form of a binary tree to obtain the target binary tree.

[0075] Specifically, before step 102, the Merkle tree root sequence formed by the Merkle tree roots of the transaction data in each block of the block chain can be converted into storage in the form of a binary tree to obtain the target binary tree.

[0076] The embodiment of the present application stores the Merkle tree root sequence formed by the Merkle tree roots of the transaction data in each block of the block chain in the form of a binary tree, which can significantly reduce the communication and calculation overhead of generating the existence proof and can generate the existence proof more quickly and timely and obtain a verification result based on the existence proof in a resource-limited case.

[0077] According to the content of any of the above embodiments, before converting the Merkle tree root sequence into storage in the form of a binary tree to obtain the target binary tree, the method further includes: storing the transaction data in each block in the form of a Merkle tree in the block.

[0078] Specifically, the transaction data in the same block is organized in the form of a Merkle tree, and the verifier only needs to know the root information (a simple digest information, usually a sequence of tens of bytes of information) of the Merkle tree corresponding to the transaction data of each block, without needing to know the specific transaction data content in the block in advance, which greatly reduces the amount of information the verifier needs to know to complete the verification. When the existence proof is needed, the prover gives the proof that the transaction data exists in the corresponding Merkle tree according to the properties of the Merkle tree. Using its own characteristics, for a Merkle tree containing n transactions, the information length of the existence proof is proportional to the height of the tree, that is, lg(n); the verifier only needs to check the correctness of the submitted proof and confirm that the proof indeed corresponds to the root hash of the transaction data Merkle tree corresponding to the specific block.

[0079] As shown in Figure 3 , the block chain includes sequential blocks B1, …, B 2+2 , B 2+1, B2, … In each block, in addition to storing the digest of the previous block, the transaction data in the block is stored in the form of a Merkle tree, and the Merkle tree root of the Merkle tree is stored.

[0080] The embodiment of the present application can reduce the communication and calculation overhead of generating the existence proof, and can generate the existence proof more quickly and timely and obtain the verification result based on the existence proof in the case of resource limitation by storing the transaction data in each block in the form of a Merkle tree in the block.

[0081] Based on the content of any of the above embodiments, the sequence of Merkle tree roots is converted into a form of a binary tree to obtain a target binary tree, specifically including: converting each Merkle tree root in the sequence of Merkle tree roots into a leaf node of the target binary tree to obtain the target binary tree.

[0082] Specifically, the leaf node is the data that needs to be maintained. Each Merkle tree root in the sequence of Merkle tree roots (i.e. the Merkle tree root value M x of the transaction in each block on the chain) is converted into a leaf node of the target binary tree.

[0083] The height of each element in the target binary tree is different, and the height m of a specific element can be used to mark the element. It is easy to know that the element T m contains 2 m-1 leaf nodes.

[0084] The operation of adding an element with a height of a to a specific binary tree BI is called merge (Merge), and the result is a new binary tree BI'. This operation is defined as follows:

[0085]

[0086] * indicates that if the current binary tree already contains an element T'a with a height of a.

[0087] Since the value M of a Merkle tree root is also a binary tree element T0 with a height of 0, the recursive form of the binary tree BI N corresponding to a chain with a height of N is

[0088] BI N = Merge (T0: {M N}, BI N-1 )

[0089] The proof provider can at any time start from the first block (genesis block) of the blockchain, and add the Merkle tree root value Mi corresponding to each block i in turn into the current binomial tree, thereby maintaining the binomial tree data BI(N) corresponding to the height N of the current blockchain all the time. The summary information S(N) is the tree root value of each element (also a Merkle tree) in the current BI(N).

[0090] The elements in the target binomial tree can be determined based on the height of the blockchain. Specifically, the elements corresponding to the number of 1s in the binary representation of the height of the blockchain can be determined as the elements included in the target binomial tree.

[0091] For example, the height of the blockchain is 53 (binary representation is 110101), and the 1s in the binary number 110101 represent 1, 4, 16, and 32, respectively, so Figure 2 The target binomial tree shown includes elements with heights of 0, 2, 4, and 5 (corresponding to 1, 4, 16, and 32, respectively), and does not include elements with heights of 1 and 3.

[0092] After determining the elements in the target binomial tree, each Merkle tree root in the Merkle tree root sequence is converted to the leaf node of each element included in the target binomial tree in turn, thereby obtaining the target binomial tree.

[0093] The embodiments of the present application store the Merkle tree root sequence formed by the Merkle tree roots of the transaction data in each block of the blockchain in the form of a binomial tree, which can significantly reduce the communication and calculation overhead of generating the existence proof, and can generate the existence proof more quickly and timely in resource-limited occasions and obtain the verification result based on the existence proof.

[0094] Figure 4 is a flowchart of the transaction data verification method based on the blockchain provided by the present application. The following describes the transaction data verification method based on the blockchain provided by the embodiments of the present application in combination with Figure 4 The embodiments of the present application provide a transaction data verification method based on a blockchain. As shown in Figure 4 The method comprises the following steps: 401, sending a first request for verifying the existence of target transaction data to a second terminal, so that the second terminal generates an existence proof of the target transaction data based on a target binomial tree in response to the first request.

[0095] The target binomial tree is used to store a Merkle tree root sequence formed by the Merkle tree roots of the transaction data in each block of the blockchain in the form of a binomial tree. The existence proof includes a first proof and a second proof. The first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binomial tree. The second proof is used to prove that the target transaction data exists in the target block.

[0096] Specifically, the execution entity of the blockchain-based transaction data verification method provided in this embodiment of the invention is a transaction data verification device. This transaction data verification device is a first terminal that communicates with a second terminal. The second terminal is a "provider" or "proof provider," and the first terminal is a "verifier."

[0097] The first terminal sends a first request to the second terminal, requesting the second terminal to provide proof of the existence of the target transaction data in order to verify the existence of the target transaction data; the second terminal receives the first request.

[0098] After receiving the first request, the second terminal, based on the block location p (i.e., the target block) where the target transaction data is located, searches for the Merkle root M of the target transaction data in the target binomial tree. p and M p The current element in the binomial tree is T. Since T is also a Merkle tree, it can generate M. p Existence proof in T {P p t}. {P p t This is the first proof.

[0099] Based on the block position p where the target transaction data is located, an existence proof {P} can be generated to demonstrate that the target transaction data exists in the target block. p b}. {P p b This is the second proof.

[0100] The first and second proofs can constitute a proof of the existence of the target transaction data.

[0101] After generating the existence proof, the second terminal sends the existence proof to the first terminal.

[0102] Step 402: Receive the existence proof sent by the second terminal, and verify the existence of the target transaction data based on the existence proof.

[0103] Specifically, after receiving the existence proof, the first terminal verifies whether the target transaction data exists based on the existence proof.

[0104] It is easy to see that no elements are deleted or the parent-child relationship of any element is changed during the generation of the target binomial tree; therefore, a binomial tree based on block height M actually contains all elements of any verification information S(0)...S(M) from 0 to M, and the elements in the verification information S(m) generated from block height m are always the root elements of the first m leaf elements (i.e. leaf nodes) in any binomial tree with height n>m.

[0105] When the proof provider uses the binomial tree information of the current record as the Merkle root M of the transaction data located in the block at height p, p Generate existence proof {P p t When}, {P p t} is the current M p The element (Merkel tree) given by the M pair p An existence proof. Therefore, for any verification information S (n>p) generated after p, the elements of this verification information are leaf M. p The root element of the subtree in which it resides is easily known from the properties of the existence proof of Merkle trees, {P p t} is from leaf M p A path leading to the root of the Merkel tree, therefore this path must pass through M. p The root element of any subtree, that is, any verification message, must contain at least one element that appears in the path, which is {P}. p t}among.

[0106] Therefore, based on the existence proof including the first proof and the second proof, it is possible to verify whether the target transaction data exists.

[0107] This invention provides a target binomial tree based on the Merkle root sequence of transaction data in each block of the blockchain, which is stored in the form of a binomial tree. It generates a first proof to prove that the Merkle root of the target transaction data exists in the target binomial tree and a second proof to prove that the target transaction data exists in the target block. Combining the first and second proofs into an existence proof can significantly reduce the communication and computation overhead of generating the existence proof. It can generate the existence proof more quickly and timely in resource-constrained situations and obtain the verification result based on the existence proof.

[0108] Based on any of the above embodiments, verifying the existence of target transaction data based on existence proof specifically includes: verifying the correctness of the first proof and the second proof.

[0109] Specifically, the existence proof of the submitted Merkle tree {P} is first verified. p t} and {P p b The correctness of} itself.

[0110] If both the first and second proofs are correct, verify the validity of the first proof based on the verification information.

[0111] Specifically, {P p t} and {Pp b If all the elements in S are correct, each element in the verification information S (the value of the Merkle tree root, also the value of the Merkle tree branch node) is used to find a matching value in {P p t}.

[0112] {P p t} or {P p b} is incorrect, it can be determined that the target transaction data does not exist on the blockchain.

[0113] In the first case of proving legality, it is determined that the target transaction data exists.

[0114] Specifically, if one element in S appears in {P p t}, {P p t} is legal, that is, it is proved that the transaction Merkle tree root value corresponding to {P p b} does exist in the transaction Merkle tree root sequence used to generate the verification information S, thereby proving that the target transaction data does exist in the blockchain that generates S.

[0115] Note that the prerequisite for the above verification to be true: when generating the verification information S, the block height corresponding to the binomial tree state owned by the proof provider is r, and the block height corresponding to the binomial tree state based on which the proof provider generates the existence proof is p, then only when p >= r, the verification is true. Similar to the traditional scheme, the prover cannot reserve an existence proof in advance and must request the corresponding existence proof from the proof provider when encountering a verification requirement. The proof provider generates the verification information for the verifier and the existence proof for the prover based on the current block height. In the traditional scheme, the prover also needs to submit a block sequence information from the block where the transaction is located to the current latest block, so as to match the specific block information known by the verifier.

[0116] The embodiment of the application is based on the target binomial tree of the Merkle tree root sequence formed by the Merkle tree roots of the transaction data in the blocks of the blockchain stored in the form of a binomial tree, generates a first proof for proving that the Merkle tree root of the target transaction data exists in the target binomial tree and a second proof for proving that the target transaction data exists in the target block, and combines the first proof and the second proof into an existence proof. The communication and computing overhead of generating the existence proof can be significantly reduced, and the existence proof can be generated more quickly and timely in resource-limited situations and the verification result can be obtained based on the existence proof.

[0117] The blockchain-based transaction data verification device provided by the present application is described below. The blockchain-based transaction data verification device described below can be referred to in correspondence with the blockchain-based transaction data verification method described above.

[0118] Figure 5 is a structural schematic diagram of the blockchain-based transaction data verification device provided by the present application. Based on the content of any of the above embodiments, as shown in Figure 5 , the blockchain-based transaction data verification device comprises a first receiving module 501, a proof generation module 502, and a first sending module 503, wherein:

[0119] The first receiving module 501 is configured to receive a first request for verifying the existence of target transaction data sent by a first terminal.

[0120] The proof generation module 502 is configured to generate an existence proof of the target transaction data based on a target binary tree in response to the first request.

[0121] The first sending module 503 is configured to send the existence proof to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the existence proof.

[0122] The target binary tree is configured to store a Merkle tree root sequence composed of Merkle tree roots of transaction data in each block of the blockchain in the form of a binary tree. The existence proof comprises a first proof and a second proof. The first proof is configured to prove that the Merkle tree root of the target transaction data exists in the target binary tree. The second proof is configured to prove that the target transaction data exists in the target block.

[0123] Specifically, the blockchain-based transaction data verification device provided by the embodiments of the present application is a second terminal. The second terminal communicates with a first terminal. The second terminal is a "prover" or a "proof provider", and the first terminal is a "verifier".

[0124] The first receiving module 501, the proof generation module 502, and the first sending module 503 are sequentially electrically connected.

[0125] The first terminal sends a first request to the second terminal, requesting the second terminal to provide an existence proof of the target transaction data to verify the existence of the target transaction data.

[0126] The first terminal receives the first request through the first receiving module 501.

[0127] The proof generation module 502 finds the Merkle tree root M p and M pThe current binomial tree element T. Since T is also a Merkel tree, M can be generated p The existence proof {P p t} in T. The existence proof {P p t} is the first proof.

[0128] The proof generation module 502 can generate the existence proof {P p b} of the target transaction data in the target block based on the block position p where the target transaction data is located. p b} is the second proof.

[0129] The proof generation module 502 can combine the first proof and the second proof to form the existence proof of the target transaction data.

[0130] After generating the existence proof, the second terminal sends the existence proof to the first terminal through the first sending module 503.

[0131] Optionally, the transaction data verification apparatus can further include:

[0132] The conversion module is configured to convert the Merkel tree root sequence into a form of a binomial tree to obtain a target binomial tree.

[0133] The storage module is configured to store the transaction data in each block in the form of a Merkel tree in the block.

[0134] Optionally, the conversion module can be specifically configured to convert each Merkel tree root in the Merkel tree root sequence into a leaf node of the target binomial tree to obtain the target binomial tree.

[0135] The transaction data verification apparatus based on a blockchain provided by the embodiments of the present application is used to execute the transaction data verification method based on a blockchain of the present application, and the implementation manner and the same beneficial effects can be achieved, which will not be described here.

[0136] The transaction data verification apparatus based on a blockchain is used for the transaction data verification method based on a blockchain of each of the foregoing embodiments. Therefore, the description and definition in the transaction data verification method based on a blockchain in each of the foregoing embodiments can be used to understand each execution module in the embodiments of the present application.

[0137] The embodiment of the present application is based on a target binary tree of a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a block chain stored in the form of a binary tree, generates a first proof for proving that the Merkle tree root of the target transaction data exists in the target binary tree and a second proof for the target transaction data existing in the target block, and constitutes the existence proof by combining the first proof and the second proof, which can significantly reduce the communication and calculation overhead of generating the existence proof, and can generate the existence proof more quickly and timely and obtain a verification result based on the existence proof in a resource-limited occasion.

[0138] Figure 6 is a structural schematic diagram of a transaction data verification device based on a block chain provided by the present application. Based on the content of any of the above embodiments, as shown in Figure 6 , the transaction data verification device based on a block chain includes a second sending module 601 and a second receiving module 602, wherein:

[0139] The second sending module 601 is configured to send a first request for verifying the existence of target transaction data to a second terminal, so that the second terminal generates an existence proof of the target transaction data based on a target binary tree in response to the first request;

[0140] The second receiving module 602 is configured to receive the existence proof sent by the second terminal and verify whether the target transaction data exists based on the existence proof;

[0141] The target binary tree is configured to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a block chain in the form of a binary tree; the existence proof includes a first proof and a second proof; the first proof is configured to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is configured to prove that the target transaction data exists in the target block.

[0142] Specifically, the transaction data verification device based on a block chain provided by the embodiment of the present application is a first terminal. The second terminal communicates with the first terminal. The second terminal is a “prover” or a “proof provider”, and the first terminal is a “verifier”.

[0143] The second sending module 601 and the second receiving module 602 are electrically connected.

[0144] The second sending module 601 sends the first request to the second terminal, requests the second terminal to provide the existence proof of the target transaction data, and verifies the existence of the target transaction data.

[0145] After the second terminal receives the first request, the second terminal finds the Merkle tree root M p of the target transaction data in the target binary tree based on the block position p (i.e., the target block) where the target transaction data is located, and generates the second proof for proving that the target transaction data exists in the target block. pThe current element in the binomial tree is T. Since T is also a Merkle tree, it can generate M. p Existence proof in T {P p t}. {P p t This is the first proof.

[0146] The second terminal, based on the block location p where the target transaction data is located, can generate an existence proof {P} of the target transaction data existing in the target block. p b}. {P p b This is the second proof.

[0147] The second terminal can combine the first and second proofs to form a proof of the existence of the target transaction data and send the proof of existence to the first terminal.

[0148] After receiving the existence proof, the second receiving module 602 verifies whether the target transaction data exists based on the existence proof.

[0149] Optionally, the second receiving module 602 may include a verification unit;

[0150] The verification unit is specifically used for:

[0151] Verify the correctness of the first and second proofs;

[0152] If both the first and second proofs are correct, verify the validity of the first proof based on the verification information.

[0153] In the case of the first area where the proof is valid, the existence of the target transaction data is confirmed.

[0154] The blockchain-based transaction data verification device provided in this embodiment of the invention is used to execute the blockchain-based transaction data verification method of the present invention. Its implementation method is consistent with the implementation method of the blockchain-based transaction data verification method provided by the present invention, and can achieve the same beneficial effects, which will not be repeated here.

[0155] This blockchain-based transaction data verification device is used in the blockchain-based transaction data verification methods of the foregoing embodiments. Therefore, the descriptions and definitions in the blockchain-based transaction data verification methods of the foregoing embodiments can be used to understand the execution modules in the embodiments of the present invention.

[0156] The embodiment of the present application generates a first proof for proving that the Merkle tree root of the target transaction data exists in the target binary tree and a second proof for proving that the target transaction data exists in the target block, assembles the first proof and the second proof into the existence proof, can significantly reduce the communication and calculation overhead of generating the existence proof, and can generate the existence proof more quickly and timely and obtain the verification result based on the existence proof in a resource-limited occasion.

[0157] The electronic device and the storage medium provided by the present application are described below, and the electronic device and the storage medium described below can be referred to each other in correspondence with the transaction data verification method based on the block chain described above.

[0158] Figure 7 An example of an entity structure diagram of an electronic device is shown in Figure 7 As shown, the electronic device can include a processor 710, a communication interface 720, a memory 730, and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 can communicate with each other through the communication bus 740. The processor 710 can call the computer program in the memory 730 to execute the steps of the transaction data verification method based on the block chain, for example, including: receiving a first request for verifying the existence of target transaction data sent by a first terminal; in response to the first request, generating an existence proof of the target transaction data based on a target binary tree; sending the existence proof to the first terminal to make the first terminal verify whether the target transaction data exists based on the existence proof; wherein the target binary tree is used to store a Merkle tree root sequence composed of the Merkle tree roots of the transaction data in each block of the block chain in the form of a binary tree; the existence proof includes a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; the second proof is used to prove that the target transaction data exists in the target block; or including: sending a first request for verifying the existence of target transaction data to a second terminal to make the second terminal generate an existence proof of the target transaction data based on a target binary tree in response to the first request; receiving the existence proof sent by the second terminal and verifying whether the target transaction data exists based on the existence proof; wherein the target binary tree is used to store a Merkle tree root sequence composed of the Merkle tree roots of the transaction data in each block of the block chain in the form of a binary tree; the existence proof includes a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; the second proof is used to prove that the target transaction data exists in the target block.

[0159] Moreover, the logic instructions in the memory 730 described above can be implemented in the form of software functional units and sold or used as independent products, and can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or parts of the technical solutions can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0160] In another aspect, the present application also provides a computer program product, which comprises a computer program stored on a non-transitory computer readable storage medium, and the computer program comprises program instructions, when the program instructions are executed by a computer, the computer can execute the steps of the blockchain-based transaction data verification method provided by the above-mentioned methods, for example, comprising: receiving a first request for verifying the existence of target transaction data sent by a first terminal; in response to the first request, generating a proof of existence of the target transaction data based on a target binary tree; sending the proof of existence to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the proof of existence; wherein the target binary tree is used to store a Merkle tree root sequence composed of Merkle tree roots of transaction data in each block of a blockchain in the form of a binary tree; the proof of existence comprises a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is used to prove that the target transaction data exists in the target block; or comprising: sending a first request for verifying the existence of target transaction data to a second terminal, so that the second terminal generates a proof of existence of the target transaction data based on a target binary tree in response to the first request; receiving the proof of existence sent by the second terminal, and verifying whether the target transaction data exists based on the proof of existence; wherein the target binary tree is used to store a Merkle tree root sequence composed of Merkle tree roots of transaction data in each block of a blockchain in the form of a binary tree; the proof of existence comprises a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is used to prove that the target transaction data exists in the target block.

[0161] In another aspect, the embodiments of the present application also provide a processor-readable storage medium, which stores a computer program for causing a processor to perform the steps of the method provided by any of the above embodiments, for example comprising: receiving a first request for verifying existence of target transaction data sent by a first terminal; in response to the first request, generating a proof of existence of the target transaction data based on a target binary tree; sending the proof of existence to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the proof of existence; wherein the target binary tree is used to store a sequence of Merkle tree roots constituted by Merkle tree roots of transaction data in each block of a block chain in the form of a binary tree; the proof of existence comprises a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is used to prove that the target transaction data exists in a target block; or comprising: sending a first request for verifying existence of target transaction data to a second terminal, so that the second terminal generates a proof of existence of the target transaction data based on a target binary tree in response to the first request; receiving the proof of existence sent by the second terminal, and verifying whether the target transaction data exists based on the proof of existence; wherein the target binary tree is used to store a sequence of Merkle tree roots constituted by Merkle tree roots of transaction data in each block of a block chain in the form of a binary tree; the proof of existence comprises a first proof and a second proof; the first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is used to prove that the target transaction data exists in a target block.

[0162] The processor-readable storage medium can be any available medium or data storage device that a processor can access, including but not limited to a magnetic storage (e.g. floppy disk, hard disk, magnetic tape, MO, etc.), an optical storage (e.g. CD, DVD, BD, HVD, etc.), and a semiconductor memory (e.g. ROM, EPROM, EEPROM, NAND FLASH, SSD, etc.), etc.

[0163] The above-described device embodiments are only illustrative, wherein the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e. can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected to achieve the purposes of the embodiments according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0164] Those skilled in the art can clearly understand the technical solutions of the various embodiments from the above description of the embodiments, and the various embodiments can be implemented by means of software with the necessary general hardware platforms, and of course, can also be implemented by hardware. Based on such understanding, the above technical solutions, essentially or in other words, the part of the prior art that makes a contribution, can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0165] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some technical features therein; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A blockchain-based transaction data verification method, characterized in that, The method comprises: receiving a first request for verifying existence of target transaction data sent by a first terminal; in response to the first request, generating a proof of existence of the target transaction data based on a target binary tree; sending the proof of existence to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the proof of existence; wherein the target binary tree is a set of complete binary trees, each element in the set being a complete binary tree, the complete binary tree being a Merkle tree, and the target binary tree being used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in blocks of a blockchain in the form of a binary tree, each Merkle tree root in the Merkle tree root sequence being converted into a leaf node of the target binary tree; the proof of existence comprises a first proof and a second proof; the first proof is a proof of existence of a Merkle tree root of the target transaction data in a binary tree element after the Merkle tree root of the target transaction data is found in the target binary tree based on a block position where the target transaction data is located and the Merkle tree root is currently located, and is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; and the second proof is a proof of existence of the target transaction data in a target block based on the block position where the target transaction data is located, and is used to prove that the target transaction data exists in the target block. Before the step of generating the proof of existence of the target transaction data based on the binary tree in response to the first request, the method further comprises: 2.The blockchain-based transaction data verification method of claim 1, wherein, converting the Merkle tree root sequence into a form of storage in a binary tree to obtain the target binary tree. Before the step of converting the Merkle tree root sequence into a form of storage in a binary tree to obtain the target binary tree, the method further comprises: 3.The blockchain-based transaction data verification method of claim 2, wherein, storing transaction data in each block in the form of a Merkle tree in the block. The method comprises: 4.A blockchain-based transaction data verification method, characterized in that, sending a first request for verifying existence of target transaction data to a second terminal, so that the second terminal generates a proof of existence of the target transaction data based on a target binary tree in response to the first request; receiving the proof of existence sent by the second terminal, and verifying whether the target transaction data exists based on the proof of existence; ​ The target binary tree is a set of complete binary trees, each element in the set is a complete binary tree, and the complete binary tree is a Merkle tree. The target binary tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a blockchain in the form of a binary tree. Each Merkle tree root in the Merkle tree root sequence is converted into a leaf node of the target binary tree. The existence proof includes a first proof and a second proof. The first proof is an existence proof of the Merkle tree root in the binary tree element, which is generated based on the block position of the target transaction data after finding the Merkle tree root of the target transaction data and the binary tree element currently containing the Merkle tree root in the target binary tree. The first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree. The second proof is an existence proof of the target transaction data in the target block, which is generated based on the block position of the target transaction data. The second proof is used to prove that the target transaction data exists in the target block. 5.The blockchain-based transaction data verification method of claim 4, wherein, The existence of the target transaction data is verified based on the existence proof, specifically including: Verifying the correctness of the first proof and the second proof; In the case that the first proof and the second proof are both correct, verifying whether the first proof is legal based on verification information; In the case that the first proof is legal, determining that the target transaction data exists. 6.A blockchain-based transaction data verification apparatus, characterized by, The first receiving module is configured to receive a first request for verifying the existence of the target transaction data sent by a first terminal. The proof generation module is configured to generate an existence proof of the target transaction data based on a target binary tree in response to the first request. The first sending module is configured to send the existence proof to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the existence proof. The target binary tree is a set of complete binary trees, each element in the set is a complete binary tree, and the complete binary tree is a Merkle tree. The target binary tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a blockchain in the form of a binary tree. Each Merkle tree root in the Merkle tree root sequence is converted into a leaf node of the target binary tree. The existence proof includes a first proof and a second proof. The first proof is an existence proof of the Merkle tree root in the binary tree element, which is generated based on the block position of the target transaction data after finding the Merkle tree root of the target transaction data and the binary tree element currently containing the Merkle tree root in the target binary tree. The first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree. The second proof is an existence proof of the target transaction data in the target block, which is generated based on the block position of the target transaction data. The second proof is used to prove that the target transaction data exists in the target block. The existence of the target transaction data is verified based on the existence proof, specifically including: 7.A blockchain-based transaction data verification apparatus characterized by comprising: Verifying the correctness of the first proof and the second proof; In the case that the first proof and the second proof are both correct, verifying whether the first proof is legal based on verification information; In the case that the first proof is legal, determining that the target transaction data exists. The first receiving module is configured to receive a first request for verifying the existence of the target transaction data sent by a first terminal. The proof generation module is configured to generate an existence proof of the target transaction data based on a target binary tree in response to the first request. The first sending module is configured to send the existence proof to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the existence proof. The target binary tree is a set of complete binary trees, each element in the set is a complete binary tree, and the complete binary tree is a Merkle tree. The target binary tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in each block of a blockchain in the form of a binary tree. Each Merkle tree root in the Merkle tree root sequence is converted into a leaf node of the target binary tree. The existence proof includes a first proof and a second proof. The first proof is an existence proof of the Merkle tree root in the binary tree element, which is generated based on the block position of the target transaction data after finding the Merkle tree root of the target transaction data and the binary tree element currently containing the Merkle tree root in the target binary tree. The first proof is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree. The second proof is an existence proof of the target transaction data in the target block, which is generated based on the block position of the target transaction data. The second proof is used to prove that the target transaction data exists in the target block. The existence of the target transaction data is verified based on the existence proof, specifically including: Verifying the correctness of the first proof and the second proof; In the case that the first proof and the second proof are both correct, verifying whether the first proof is legal based on verification information; In the case that the first proof is legal, determining that the target transaction data exists. The first receiving module is configured to receive a first request for verifying the existence of the target transaction data sent by a first terminal. The proof generation module is configured to generate an existence proof of the target transaction data based on a target binary tree in response to the first request. The first sending module is configured to send the existence proof to the first terminal, so that the first terminal verifies whether the target transaction data exists based on the existence proof. The second sending module is configured to send a first request for verifying existence of target transaction data to a second terminal, so that the second terminal generates a proof of existence of the target transaction data based on a target binary tree in response to the first request; The second receiving module is configured to receive the proof of existence sent by the second terminal, and verify whether the target transaction data exists based on the proof of existence; The target binary tree is a set of complete binary trees, each element in the set is a complete binary tree, the complete binary tree is a Merkle tree, and the target binary tree is used to store a Merkle tree root sequence formed by Merkle tree roots of transaction data in blocks of a blockchain in the form of a binary tree, each Merkle tree root in the Merkle tree root sequence is converted into a leaf node of the target binary tree; the proof of existence includes a first proof and a second proof; the first proof is a proof of existence of a Merkle tree root of the target transaction data in a binary tree element after the Merkle tree root of the target transaction data is found in the target binary tree based on a block position of the target transaction data and the Merkle tree root currently exists in the binary tree element, and is used to prove that the Merkle tree root of the target transaction data exists in the target binary tree; The second proof is a proof of existence of the target transaction data in a target block based on the block position of the target transaction data, and is used to prove that the target transaction data exists in the target block.

8. An electronic device comprising a processor and a memory having a computer program stored therein, characterized in that, The processor executes the computer program to implement the steps of the blockchain-based transaction data verification method according to any one of claims 1 to 5.

9. A processor-readable storage medium, comprising: The processor readable storage medium stores a computer program, and the computer program is used to make the processor execute the steps of the blockchain-based transaction data verification method according to any one of claims 1 to 5.

Images