CN115082068B

CN115082068B - Minimum Merck proof generation and block chain transaction verification method supporting aggregation

Info

Publication number: CN115082068B
Application number: CN202210890874.3A
Authority: CN
Inventors: 关志; 陈钟; 王珂; 陈子明; 李青山
Original assignee: Boya Chain Beijing Technology Co ltd; Peking University
Current assignee: Boya Chain Beijing Technology Co ltd; Peking University
Priority date: 2022-07-27
Filing date: 2022-07-27
Publication date: 2022-11-25
Anticipated expiration: 2042-07-27
Also published as: CN115082068A

Abstract

The invention relates to a minimum Mercker proof generation and block chain transaction verification method supporting aggregation, which comprises a complete binary Mercker tree data structure design, a Mercker proof generation algorithm and a Mercker proof verification algorithm. The nodes in the complete binary Mercker tree are sequenced from top to bottom and from left to right; in a complete binary Merck tree generated by N transactions, a node with a sequence number of 0 is Merck root Hash, a node with a sequence number of N-1 is Hash of the 1 st transaction, a node with a sequence number of N is Hash of the 2 nd transaction, and so on. The method for generating and verifying the Mercker certification breaks through the limitation that the traditional Mercker certification only supports single transaction query, can support the common verification of two or more transactions, expands the practical degree and the application range of the Mercker certification on one hand, improves the transaction verification efficiency on the other hand, and further contributes to the improvement of the whole operation efficiency of a block chain.

Description

Minimum Merck proof generation and block chain transaction verification method supporting aggregation

Technical Field

The invention belongs to the field of computer algorithm design, relates to a Mercker certification technology of block chain transaction, and particularly relates to a minimum Mercker certification generation and block chain transaction verification method supporting aggregation.

Background

A blockchain is a decentralized distributed computing and storage architecture, and the schematic structure thereof is shown in FIG. 1. The operation of a member of the blockchain network is referred to as a transaction; a certain number of transactions are packed together and recorded in the block together with the block header; each chunk header contains the hash of the previous chunk and the merkel root hash that records all packed transactions for that chunk, all chunks being concatenated. This is the data structure of the whole blockchain, which gives the blockchain tamper-proof properties.

The transactions contained in the tiles are organized together in the form of a merkel tree. The merkel tree is a typical binary tree structure, consisting of a root node, a set of intermediate nodes, and a set of leaf nodes. As shown in fig. 2: the Merckel tree is constructed from the bottom up, all leaf nodes are Hash1, hash2, \8230, hash6 is the Hash value obtained by Hash calculation of each transaction; each intermediate node is a Hash value obtained by combining Hash values of the left child node and the right child node and then performing Hash calculation, for example, the Hash value 12 is obtained by connecting and combining Hash1 and Hash2 and then performing Hash calculation, that is

HashFun refers to a hash function used for hash computations, such as the cryptographic SM3, SHA256, and the like. If the block contains an odd number of transactions, the Hash of the transaction that is dropped is copied as one copy as the right node, e.g., the processing of transaction 5 in FIG. 2. The topmost root node is called a merkel root hash (Merkle root hash). Because the hash function has the anti-collision property, the change of the value of any node in the merkel tree requires modifying the parent node and the merkel root hash at the same time, so the merkel tree can provide an untamperable record for all transactions in the block.

The Mercker tree can be used to verify whether a transaction exists in a block. Since the data amount of all blocks in the block chain is too large, only part of the nodes store all historical blocks in the block chain (such nodes are called full nodes), the lightweight client only stores the block headers of all the blocks to save storage overhead, and the block headers include the merkel root hash of the blocks. Taking fig. 2 as an example, suppose that a user desires to verify whether a transaction initiated by the user is in block X by a lightweight client, the user only owns the data of the transaction and the mercker root hashes of all blocks. At this time, the user needs to submit an authentication application to the whole node, and provide the Hash and the block number X of the transaction to be authenticated. If the transaction verified by the user is not in the block X, the full node feeds back the failure of the user verification; if the user verified transaction is in block X, such as transaction 2, the global node will feed back the user verification success and return a merkel proof.

The Mercker proof contains a set of Hash values in the Mercker tree, and the user can calculate the Mercker root Hash according to the Hash values. Thus, the above-mentioned Merckel proof consists of Hash1, hash34, hash 55. The user can verify the correctness of the Mercker proof after receiving the Mercker proof by himself, and the judgment process is as follows: the user carries out Hash calculation based on transaction 2 to obtain Hash2, calculates based on Hash1 and Hash2 to obtain Hash12, calculates based on Hash12 and Hash34 to obtain Hash1234, finally calculates based on Hash1234 in Hash55 to obtain a merkel root Hash (Merkle root Hash), compares the Merkle root Hash with the locally stored block X, and if the comparison result is consistent, the user can confirm that the transaction 2 really exists in the block X.

The existing merkel proof technology only supports the verification of a single transaction, and cannot simultaneously verify whether two or more transactions are in the same block. With the rapid growth of data in the blockchain, the verification of transactions is inevitably more and more complex, and the current mercker certification technology is difficult to meet the requirement of complex transaction verification.

Disclosure of Invention

To overcome the above-mentioned deficiencies of the prior art, the present invention provides a method for minimum mercker proof generation and block chain transaction verification supporting aggregation to solve the mercker proof generation and verification problems of two or more transactions. Where aggregation refers to the ability to support the common authentication of two or more transactions.

The technical scheme provided by the invention is as follows:

a method for minimum mercker certification generation and blockchain transaction verification supporting aggregation, comprising the steps of:

establishing a complete binary Merck tree;

for at least two transactions, a minimum Merckel proof is generated based on a complete binary Merckel tree, i.e. a proof whether the at least two transactions exist in the same block in a chain of blocks.

Further, the nodes in the complete binary Merck tree are rankedThe sequence is from top to bottom and from left to right; in a complete binary Merck tree generated by N transactions, a node with a sequence number of 0 is Merck root Hash, a node with a sequence number of N-1 is Hash of the 1 st transaction, a node with a sequence number of N is Hash of the 2 nd transaction, and so on; the total number of nodes in the complete binary Merck tree is 2N-1, and the serial number of the transaction i is i + N-1; for a node with sequence number i, its parent node has sequence number

The serial number of the brother node is (i + 1) ^1-1, and the serial number of the child node is 2i +1 and 2i +2; for the case without any transaction, the number of nodes in the complete binary merkel tree is 1, i.e., the merkel root hash, whose value is SHA256 (0).

Further, the generation of the minimum merck proof based on the complete binary merck tree inputs the Hash and the block number of the transaction to be verified provided for the user; if at least one Hash of the transaction to be verified provided by the user is not in the designated block, outputting verification failure; if the hashes of the transactions to be verified provided by the user are all in the designated block, generating a corresponding Mercker proof, which contains the serial number of the transaction to be verified in a complete binary Mercker tree, and a set of hashes required for the user to compute the Mercker root Hash.

Further, the generating the minimum merck proof based on the complete binary merck tree includes:

1) Reading the array of the complete binary Merck tree and the Hash of the transaction to be verified, judging whether the Hash of the transaction to be verified is in the array of the complete binary Merck tree, if so, continuing the step 2), otherwise, outputting verification failure, and finishing the algorithm;

2) Acquiring the serial number of the Hash of the transaction to be verified in an array of a complete binary Merckel tree, storing the serial number in an array A, and arranging the serial number in a queue in a reverse order, wherein the queue maintains the Hash value which is acquired by a user but is not calculated and used; the declaration chain table B is used for storing node Hash in the Mercker certification; continuing with step 3);

3) Judging whether the queue is empty; if the queue is not empty, the first element of the queue is dequeued, the brother node serial number m and the father node serial number n of the corresponding node are calculated, and the step 4) is continued; if the queue is empty, outputting an array A and a linked list B, and ending the algorithm;

4) Judging whether the first element of the queue is m or not; if not, inserting the node Hash value with the serial number of m into the tail part of the linked list B; if m, the first element of the queue is dequeued; continuing with step 5);

5) Judging whether n is 0; if not, putting n into the queue; if 0, the merkel root hash is calculated, and the process returns to the step 3).

Further, the correctness of the mercker proof was verified using the following procedure:

1) Reading the array A and the linked list B, putting the elements in the array A into the queue in reverse order, and continuing the step 2)

2) Judging whether the queue is empty; if so, outputting the verification failure, and ending the algorithm; if the queue is not empty, the first element x of the queue is dequeued, the sequence number m and the sequence number n of the brother node of the corresponding node are calculated, and the step 3) is continued;

3) Judging whether the first element of the queue is m or not; if not, the first element of the linked list B is the Hash corresponding to the node with the sequence number m; if m, dequeuing the first element of the queue; continuing with step 4);

4) Judging whether the node with the sequence number x is a left node or not; if yes, the Hash corresponding to n is Hash (n) = Hash fun (Hash (x) | | Hash (m)), wherein the Hash fun is a Hash function for Hash calculation; if not, the Hash corresponding to n is Hash (n) = Hash fun (Hash (m) | Hash (x)); continuing with step 5);

5) Judging whether n is 0; if yes, the merkel root hash is calculated, and the step 6) is continued; if not, putting n into the queue, and returning to the step 2);

6) Judging whether H0 is equal to Hash (n); if yes, the verification is passed; if not, the verification fails and the algorithm ends.

A minimum mercker proof generation and blockchain transaction verification system supporting aggregation, comprising:

a complete binary Merck tree establishing module used for establishing a complete binary Merck tree;

a mercker proof generating module for generating a minimum mercker proof based on a complete binary mercker tree for at least two transactions, i.e. proving whether the at least two transactions exist in the same block in a chain of blocks.

Further, the system also comprises a merkel proof verification module for verifying the correctness of the merkel proof.

Compared with the prior art, the invention has the beneficial effects that:

1. compared with the traditional block chain Merckel tree, the CBMT provided by the invention adopts a complete binary tree as a data structure, has the minimum Hash calculation amount in the construction process, and has the minimum Merckel proof generated by the CBMT due to the minimum layer number. The method has more advantages in terms of calculation amount and storage and transmission space.

2. The Mercker proof generation and verification algorithm provided by the invention breaks through the limitation that the traditional Mercker proof only supports single transaction query, can support the common verification of two or more transactions, expands the practical degree and the application range of the Mercker proof on one hand, and improves the transaction verification efficiency on the other hand, thereby being beneficial to improving the overall operation efficiency of a block chain.

Drawings

Fig. 1 is a block chain structure diagram.

FIG. 2 is a schematic representation of the structure of the Merckel tree.

FIG. 3 is a flow chart of the Mercker proof generation algorithm.

FIG. 4 is a flow chart of the Mercker proof of identity verification algorithm.

FIG. 5 is a schematic diagram of a 6 transaction CBMT architecture.

FIG. 6 is a schematic diagram of a 7 transaction CBMT architecture.

Detailed Description

In order to make the aforementioned objects, features and advantages of the present invention comprehensible, the present invention shall be described in further detail with reference to the following detailed description and accompanying drawings.

The invention relates to a minimum Mercker proof generation and block chain transaction verification method supporting aggregation, which comprises a complete binary Mercker tree data structure design, a Mercker proof generation algorithm and a Mercker proof verification algorithm.

(1) Complete binary merkel tree data structure

The present invention uses a Complete Binary merkel Tree (hereinafter CBMT) to generate the merkel root hash and merkel proof for transactions in a block. CBMT is a complete binary tree, and the height of the CMBT is minimal compared to other binary trees with the same number of nodes, so the CMBT has the least amount of Hash computation and the mercker proof generated by the CMBT is minimal.

The nodes in the CBMT are ordered from top to bottom and from left to right (numbered starting with 0). In a CBMT generated by N transactions, a node with a sequence number of 0 is a Mercker root Hash, a node with a sequence number of N-1 is a Hash of the 1 st transaction, a node with a sequence number of N is a Hash of the 2 nd transaction, and so on. This arrangement is used because from the location of the transaction, its location in the CBMT corresponding to the node can be easily calculated: the total number of the nodes is 2N-1, and the serial number of the transaction i is i + N-1; for sequence number i (i)>0) The parent node of the node (c) is

(the parenthesis on the outermost layer indicates that the calculation result is rounded down), the serial number of the sibling node is (i + 1) ^1-1 (^ is exclusive OR), and the serial numbers of the child nodes are 2i +1 and 2i +2. Furthermore, the invention provides that for the case where the CBMT does not contain any transactions, the number of nodes in the CBMT is 1, i.e. the Mercker root hash, which has the value SHA256 (0).

In the program, the CMBT is stored in the form of an array, and the nodes are arranged in ascending order of numbers.

(2) Mercker proof generation algorithm

The algorithm can provide proof of whether two or more transactions exist in the same block. The input of the algorithm is the Hash and block number of the transaction to be verified provided by the user; if at least one transaction Hash provided by the user is not in the designated block, outputting verification failure; if the transaction hashes provided by the user are all in the specified block, a corresponding Mercker proof is generated, which contains the sequence number of the transaction to be verified in the CBMT, and the set of hashes required by the user to compute the Mercker root Hash. The structure of the merkel proof in the procedure is shown in table 1.

TABLE 1

The algorithm flow chart of the merkel proof generation algorithm is shown in fig. 3, and comprises the following steps:

1. after receiving the input provided by the user, the whole node traverses the CBMT array of the designated block and judges whether the Hash of the given transaction is in the CBMT or not. If yes, continuing to step 2; otherwise, the output verification fails, and the algorithm is ended.

2. Querying the CBMT array results in the node sequence numbers (i.e., their subscripts in the array) for a given transaction Hash, which is stored in array A. The sequence numbers are arranged in reverse order in a queue that maintains the Hash value that the user has acquired but not yet calculated for use. The declaration linked list B is used to store node hashes in the mercker certificate. And continuing to step 3.

3. And judging whether the queue is empty or not. If the queue is not empty, the first element of the queue is dequeued, the brother node serial number m and the father node serial number n of the node corresponding to the serial number are calculated, and the step 4 is continued; and if the queue is empty, outputting the array A and the linked list B, and finishing the algorithm.

4. And judging whether the first element of the queue is m or not. If not, the user does not know the Hash of the node with the number m, and therefore the Hash value of the node with the number m is inserted into the tail part of the linked list B; if m is the number m, namely the user has obtained the Hash of the node with number m, the first element of the queue is dequeued. And continuing with step 5.

5. It is judged whether n is 0. If not, putting n into the queue; if 0, this indicates that the merkel root hash has been calculated. And returning to the step 3.

(3) Merkel proof verification algorithm

The algorithm flow chart of the merkel proof verification algorithm is shown in fig. 4, and comprises the following steps:

1. after receiving the Mercker proof provided by the full node, the user obtains an array A for recording the transaction sequence number, a linked list B for recording the Hash list and a Mercker root Hash H0 obtained by inquiring the block head. The elements in array A are placed in the queue in reverse order. And continuing to step 2.

2. And judging whether the queue is empty or not. If so, the output verification fails, and the algorithm is ended. If the queue is not empty, the first element x of the queue is dequeued, the sibling node sequence number m and the father node sequence number n of the node corresponding to the sequence number are calculated, and the step 3 is continued.

3. And judging whether the first element of the queue is m or not. If not, the first element of the linked list B is the Hash corresponding to the node with the sequence number m; if m, the first element of the queue is dequeued. And continuing with step 4.

4. And judging whether the node with the sequence number x is a left node or not. If yes, the Hash corresponding to n is Hash (n) = Hash fun (Hash (x) | Hash (m)); if not, the Hash corresponding to n is Hash (n) = Hash fun (Hash (m) | Hash (x)). And continuing to step 5.

5. And judging whether n is 0 or not. If yes, the Mercker root hash is calculated, and the step 6 is continued; if not, putting n into the queue, and returning to the step 2.

6. It is determined whether H0 is equal to Hash (n). If yes, the verification is passed; if not, the verification fails. The algorithm ends.

For example, 6 transactions (assuming that the hashes of the transactions are T0, T1, T2, T3, T4, T5, respectively) are shown in fig. 5; the structure of the CMBT generated for 7 transactions (assuming that the hashes of these transactions are T0, T1, T2, T3, T4, T5, T6, respectively) is shown in fig. 6. The root and middle nodes of the CBMT are denoted by H with sequence numbers, and the sequence numbers of all nodes are shown in parentheses on the right side of the nodes. The representation in the program is shown in table 2.

TABLE 2

Assuming that the user wishes to verify whether T1 and T4 are in the CMBT shown in FIG. 5, the Mercker proof returned by all nodes should be and only should be: [ T5, T0, H3] and [6, 9]. The proof was generated as follows:

1. after receiving the input provided by the user, the full node traverses the CBMT array corresponding to fig. 5, and determines that T1 and T4 are both in the CBMT. And continuing to step 2.

2. The sequence numbers of T1 and T4, which are 6 and 9 respectively, obtained by querying the CBMT array are stored in the array A. The sequence numbers are arranged into the queue in reverse order, and the queue elements are: [9, 6]. And continuing to step 3.

3. The first element of the queue is the 9,9 dequeue, where the queue elements are: [6]. The sibling node number of node number 9 is 10, i.e., the user needs the Hash of node number 10 to compute the merkel root Hash. The first element of the queue is not 10, i.e. the user does not know the Hash of node 10, so the Hash value T5 of node 10 is inserted at the tail of linked list B. The parent node sequence number of node number 9 is 4,4 enqueues. The queue elements at this time are: [6, 4]. And continuing to step 4.

4. The first element of the queue is the 6,6 dequeue, at which time the queue elements are: [4]. The sibling node of node number 6 has a sequence number of 5, i.e., the user needs the Hash of node number 5 to compute the merkel root Hash. The first element of the queue is not 5, i.e. the user does not know the Hash of node 5, so the Hash value T0 of node 5 is inserted into the tail of linked list B. The parent node sequence number of node number 6 is 2,2 enqueue. The queue elements at this time are: [4, 2]. And continuing to step 5.

5. The first element of the queue is the 4,4 dequeue, where the queue elements are: [2]. The sibling node of node No. 4 has a sequence number of 3, i.e., the user needs the Hash of node No. 3 to compute the merkel root Hash. The first element of the queue is not 3, i.e. the user does not know the Hash of node 3, so the Hash value H3 of node 3 is inserted at the tail of linked list B. The parent node sequence number of node 4 is 1,1 enqueue. The queue elements at this time are: [2, 1]. Continue with step 6.

6. The first element of the queue is the 2,2 dequeue, where the queue elements are: [1]. The sibling node of node number 2 has a sequence number of 1, i.e., the user needs the Hash of node number 1 to compute the merkel root Hash. The first element of the queue is 1, i.e. the user has obtained a Hash for node number 1, so 1 is dequeued. The parent node sequence number of node 2 is 0, and node 0 is the sequence number of the merkel root hash. The queue is now empty, i.e., the user has acquired all the data needed to compute the merkel root hash. The algorithm ends.

In summary, the results of the Mercker proof generation algorithm are [6, 9] and [ T5, T0, H3].

After receiving the merkel proof returned by the whole node, the user can verify whether the proof is correct or not by himself, namely whether H0 can be obtained through the values of T1 and T4 and the calculation of data in the merkel proof. The verification steps are as follows:

1. after receiving the Mercker proof provided by the whole node, the user obtains the serial numbers of T1 and T4 in the CBMT as 6 and 9 respectively, and a linked list B for storing the node Hash. And putting the serial numbers of the transactions to be verified into a queue according to a reverse order. The queue elements at this time are: [9, 6]. And continuing to step 2.

2. The first element of the queue is the 9,9 dequeue, where the queue elements are: [6]. The sibling node of node number 9 has a sequence number of 10, i.e. the Hash of node number 10 is needed to calculate the merkel root Hash. The first element of the queue is not 10, i.e., the Hash of node 10 is in linked list B. The first element of linked list B is fetched and deleted from linked list B. The element and the T4 are subjected to Hash calculation to obtain a Hash temporary record M4 of the father node of the node 9, and the calculated father node serial number is 4.4 into the queue, this time the queue element is [6, 4]. And continuing to step 3.

3. The first element of the queue is the 6,6 dequeue, at which time the queue elements are: [4]. The sibling node of node number 6 has a sequence number of 5, i.e., the Hash of node number 5 is needed to compute the merkel root Hash. The first element of the queue is not 5, i.e. the Hash of node number 5 is in linked list B. The first element of linked list B is fetched and deleted from linked list B. The element and the T1 are subjected to Hash calculation to obtain a Hash temporary record M2 of the father node of the node No. 6, and the calculated father node serial number is 2.2 into the queue, this time the queue element is [4, 2]. And continuing to step 4.

4. The first element of the queue is the 4,4 dequeue, where the queue elements are: [2]. The sibling node of node No. 4 has a sequence number of 3, i.e., the Hash of node No. 3 is needed to compute the merkel root Hash. The first element of the queue is not 3, i.e., the Hash of node number 3 is in linked list B. The first element of linked list B is fetched and deleted from linked list B. The element and M4 obtain the Hash of the father node of the node No. 4 through Hash calculation, temporarily marked as M1, and the calculated father node serial number is 1.1 into the queue, with the queue element being [2, 1]. And continuing to step 5.

5. The first element of the queue is the 2,2 dequeue, where the queue elements are: [1]. The sibling node of node number 2 has a sequence number of 1, i.e., the Hash of node number 1 is needed to compute the merkel root Hash. The first element of the queue is the 1,1 dequeue, at which time the queue is empty. M1 and M2 obtain the Hash of the father node of the node No. 2 as M0 through Hash calculation, the sequence number of the father node is 0 through calculation, and M0 is the Mercker root Hash. And comparing M0 with H0, if the M0 and the H0 are equal, the Merck proof is successful, otherwise, the authentication fails. The algorithm ends.

Another embodiment of the present invention provides a system for minimum mercker proof generation and blockchain transaction verification supporting aggregation, comprising:

In another embodiment of the present invention, the system further comprises a merkel proof verification module for verifying the correctness of merkel proof.

Another embodiment of the invention provides an electronic device (computer, server, smartphone, etc.) comprising a memory storing a computer program configured to be executed by a processor, and a processor, the computer program comprising instructions for performing the steps of the method of the invention.

Another embodiment of the invention provides a computer readable storage medium (e.g., ROM/RAM, magnetic disk, optical disk) storing a computer program which, when executed by a computer, performs the steps of the method of the invention.

The key point of the invention is the complete binary Mercker tree data structure design, the Mercker proof generation algorithm and the Mercker proof verification algorithm. The three are not in binding relationship and can be implemented as separate technical schemes respectively.

In the merkel proof generation algorithm and the verification algorithm, in other embodiments, the parent node and the sibling node can be obtained not by sequence number calculation but by a program pointer, and other processes are similar, so that the same result can be obtained, and the merkel proof generation algorithm and the verification algorithm also belong to the protection scope of the invention.

The merkel proof generation algorithm and the verification algorithm of the present invention may replace the data storage structures such as the linked list, the array, the queue and the like in other embodiments, but other processes are similar and obtain the same result, which also belongs to the protection scope of the present invention.

The particular embodiments of the present invention disclosed above are illustrative only and not intended to be limiting as to the scope of the invention which is to be given the full breadth of the claims appended and any and all modifications and variations which may be apparent to those skilled in the art may be resorted to without departing from the spirit and scope of the invention. The invention should not be limited to the disclosure of the embodiments in the present specification, but the scope of the invention is defined by the appended claims.

Claims

1. A minimum Merck proof generation and block chain transaction verification method supporting aggregation is characterized by comprising the following steps:

establishing a complete binary Merck tree;

for at least two transactions, generating a minimum Merck proof based on a complete binary Merck tree, i.e., proving whether the at least two transactions exist in the same block in a chain of blocks;

the generation of the minimum Merck proof based on a complete binary Merck tree includes:

1.1 Read the array of complete binary merkel tree and Hash of the transaction to be verified, judge whether the Hash of the transaction to be verified is in the array of complete binary merkel tree, if yes, continue step 2), otherwise output the verification failure, the algorithm is over;

1.2 Obtaining the serial number of the Hash of the transaction to be verified in the array of the complete binary Merck tree, storing the serial number in the array A, and arranging the serial numbers in a queue in a reverse order, wherein the queue maintains the Hash value which is obtained by the user but is not used by calculation; the declaration chain table B is used for storing node Hash in the Mercker certification; continuing with step 3);

1.3 Determine whether the queue is empty; if the queue is not empty, the first element of the queue is dequeued, the brother node serial number m and the father node serial number n of the corresponding node are calculated, and the step 4) is continued; if the queue is empty, outputting an array A and a linked list B, and ending the algorithm;

1.4 Determine whether the first element of the queue is m; if not, inserting the node Hash value with the serial number of m into the tail part of the linked list B; if m, the first element of the queue is dequeued; continuing with step 5);

1.5 Judging whether n is 0; if not, putting n into a queue; if the hash value is 0, the merkel root hash value is calculated, and the step returns to the step 3);

the correctness of the merkel proof was verified using the following procedure:

2.1 Read array A and linked list B, put the elements in array A into queue in reverse order, continue step 2)

2.2 Determine whether the queue is empty; if so, the output verification fails, and the algorithm is ended; if the queue is not empty, the first element x of the queue is dequeued, the brother node serial number m and the father node serial number n of the corresponding node are calculated, and the step 3) is continued;

2.3 Determine whether the first element of the queue is m; if not, the first element of the linked list B is the Hash corresponding to the node with the sequence number m; if m, the first element of the queue is dequeued; continuing with step 4);

2.4 ) judging whether the node with the sequence number x is a left node or not; if yes, the Hash corresponding to n is Hash (n) = Hash fun (Hash (x) | | Hash (m)), wherein the Hash fun is a Hash function for Hash calculation; if not, the Hash corresponding to n is Hash (n) = Hash fun (Hash (m) | Hash (x)); continuing with step 5);

2.5 Judging whether n is 0; if yes, the merkel root hash is calculated, and the step 6) is continued; if not, putting n into the queue, and returning to the step 2);

2.6 Determining whether the merkel root Hash is equal to Hash (n); if yes, the verification is passed; if not, the verification fails and the algorithm ends.

2. The method according to claim 1, wherein the nodes in the complete binary merkel tree are ordered from top to bottom and from left to right; in a complete binary Merck tree generated by N transactions, a node with a sequence number of 0 is Merck root Hash, a node with a sequence number of N-1 is Hash of the 1 st transaction, a node with a sequence number of N is Hash of the 2 nd transaction, and so on; the total number of nodes in the complete binary Mercker tree is 2N-1, and the serial number of the transaction i is i + N-1; for a node with sequence number i, its parent node has sequence number

3. The method according to claim 1, characterized in that the generation of the minimum mercker proof based on a complete binary mercker tree inputs the Hash and block number of the transaction to be verified provided for the user; if at least one Hash of the transaction to be verified provided by the user is not in the designated block, outputting verification failure; if the hashes of the transactions to be verified provided by the user are all in the designated block, generating a corresponding Mercker proof, which contains the serial number of the transaction to be verified in a complete binary Mercker tree, and a set of hashes required for the user to compute the Mercker root Hash.

4. A system for minimum mercker proof generation and blockchain transaction verification supporting aggregation, comprising:

a Merckel proof generation module for generating, for at least two transactions, a minimum Merckel proof based on a complete binary Merckel tree, i.e. proof whether the at least two transactions exist in the same block in a chain of blocks;

the mercker proof verification module is used for verifying the correctness of the mercker proof;

the generating of the minimum mercker proof based on the complete binary mercker tree includes:

1.1 Reading the array of the complete binary Merck tree and the Hash of the transaction to be verified, judging whether the Hash of the transaction to be verified is in the array of the complete binary Merck tree, if so, continuing to the step 2), otherwise, outputting the verification failure, and finishing the algorithm;

the mercker proof verification module adopts the following steps to verify the correctness of the mercker proof:

2.4 ) judging whether the node with the sequence number x is a left node or not; if yes, the Hash corresponding to n is Hash (n) = HashFun (Hash (x) | Hash (m)), wherein the HashFun is a Hash function for Hash calculation; if not, the Hash corresponding to n is Hash (n) = Hash fun (Hash (m) | Hash (x)); continuing with step 5);

5. An electronic device comprising a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program comprising instructions for carrying out the method of any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that it stores a computer program which, when executed by a computer, implements the method of any one of claims 1 to 3.