CN115082068A

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

Info

Publication number: CN115082068A
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-09-20
Anticipated expiration: 2042-07-27
Also published as: CN115082068B

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 the Merck root Hash, a node with a sequence number of N-1 is the Hash of the 1 st transaction, a node with a sequence number of N is the 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 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 of all packed transactions that record 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 blocks are organized together in the form of a Merck tree. A 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 Merck tree is constructed from the bottom up, and all leaf nodes such as Hash1, Hash2, …, Hash6 is the Hash value obtained by Hash calculation for each transaction; each intermediate node is a Hash value obtained by Hash calculation after the Hash values of the left child node and the right child node are combined, for example, the Hash12 is obtained by Hash calculation after the Hash1 and the Hash2 are connected and combined, that is

HashFun refers to a hash function used for hash calculations, such as the secret SM3, SHA256, and the like. If the block contains an odd number of transactions, a copy of the Hash of the transaction of the drop is taken as the right node, e.g., the processing of transaction 5 in FIG. 2. The topmost root node is called 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 of the block chain is too large, only part of the nodes store all historical blocks of 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 hash 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 merkel proof contains a set of hashes in the merkel tree, and the user can calculate the merkel root Hash from 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 the 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 merkel root Hash (merkel root Hash), compares the merkel root Hash with the merkel root Hash of the block X stored locally, 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

In order to overcome the above-mentioned deficiencies of the prior art, the present invention provides a minimum mercker proof generation and block chain transaction verification method supporting aggregation, which is used to solve the mercker proof generation and verification problem 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 minimum Mercker proof generation and block chain transaction verification method supporting aggregation comprises the following steps:

establishing a complete binary Merck tree;

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

Further, 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 the Merck root Hash, a node with a sequence number of N-1 is the Hash of the 1 st transaction, a node with a sequence number of N is the 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 the node with sequence number i, the parent node has the sequence number

The serial number of the brother node is (i +1) ^1-1, and the serial numbers of the child nodes are 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 mercker proof based on the complete binary mercker tree inputs the Hash and the block number of the transaction to be verified provided by the user; if at least one Hash of the transaction to be verified provided by the user is not in the specified 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 mercker proof based on the complete binary mercker 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 the verification failure, and finishing the algorithm;

2) acquiring 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 acquired 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);

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 step returns to the step 3).

Further, the correctness of the merkel 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, 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;

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, the first element of the queue is dequeued; 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) determining whether H0 equals hash (n); if yes, the verification is passed; if not, the verification fails and the algorithm ends.

A system for minimum mercker certification generation and blockchain transaction verification 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 merkel root hashes and merkel proofs for transactions in blocks. 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 the sequence number of 0 is a Mercker root Hash, a node with the sequence number of N-1 is a Hash of the 1 st transaction, a node with the 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 at the outermost layer indicates that the calculation result is rounded down), the serial number of the sibling node is (i +1) ^1-1 (where ^ is exclusive OR), and the serial numbers of the child nodes are 2i +1 and 2i + 2. Furthermore, the present 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 nodes are arranged in ascending order of sequence 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 a 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 sorted in reverse order into 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 the node Hash in the merkel proof. 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 m, the user does not know the Hash of the node m, so the Hash value of the node m is inserted into the tail part of the linked list B; if m is obtained, namely the user already obtains the Hash of the node with number m, the first element of the queue is dequeued. And continuing to step 5.

5. And judging whether n is 0 or not. 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 with 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 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 corresponding CBMT array in FIG. 5, and determines that T1 and T4 are both in the CBMT. And continuing to step 2.

2. Querying the CBMT array results in the sequence numbers of T1 and T4, which are 6 and 9, respectively, being stored in 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 dequeues, at which time 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 for 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 for node 5 is inserted at the tail of linked list B. The parent node sequence number of node 6 is 2, and 2 enters the queue. The queue elements at this time are: [4, 2]. And continuing to step 5.

5. The first element of the queue is a 4, 4 dequeue, at which time 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 of node 3, H3, is inserted at the tail of linked list B. The parent node sequence number of the node No. 4 is 1, and 1 enters the queue. The queue elements at this time are: [2, 1]. And continuing to step 6.

6. The first element of the queue is the 2, 2 dequeue, at which time 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 hash sequence number of the merkel root. 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 mercker proof returned by the full node, the user can verify whether the proof is correct, namely whether H0 is calculated through the values of T1 and T4 and the data in the mercker 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 the 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 dequeues, at which time the queue elements are: [6]. The sibling node number of node number 9 is 10, i.e. the Hash of node number 10 is needed to compute 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 obtain the Hash temporary record of the parent node of the node 9 as M4 through Hash calculation, and the sequence number of the obtained parent node 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 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 obtain the Hash temporary record of the parent node of the node No. 6 as M2 through Hash calculation, and the sequence number of the obtained parent node 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 a 4, 4 dequeue, at which time 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 parent node of node No. 4 through Hash calculation, which is temporarily marked as M1, and the calculated parent 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, in which case 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. The Hash of the parent node of the node 2 obtained by the Hash calculation of M1 and M2 is M0, and the sequence number of the parent node obtained by the calculation is 0, which indicates that M0 is the Merckel root Hash. M0 is compared with H0, and if equal, the Mercker proof of verification is successful, otherwise the verification 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 the 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 linked list, array, queue, etc. 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 are not intended to be limiting, since various alternatives, modifications, and variations will be apparent to those skilled in the art without departing from the spirit and scope of the invention. The invention should not be limited to the disclosure of the embodiments in the 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;

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 the Merck root Hash, a node with a sequence number of N-1 is the Hash of the 1 st transaction, a node with a sequence number of N is the 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 the node with sequence number i, the parent node has the 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. The method of claim 1, wherein generating the minimum merkel proof based on a complete binary merkel tree comprises:

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 sequence number m and the sequence number n of the brother node 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;

5. The method according to claim 4, characterized in that the correctness of the Mercker proof is verified by the following steps:

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

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

7. The system of claim 6, further comprising a merkel proof verification module for verifying the correctness of the merkel proof.

8. An electronic apparatus, 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 performing the method of any of claims 1-5.

9. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by a computer, implements the method of any of claims 1-5.