CN110602239B

CN110602239B - Block chain information storage method and related equipment

Info

Publication number: CN110602239B
Application number: CN201910902073.2A
Authority: CN
Inventors: 刘攀
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-09-20
Filing date: 2019-09-20
Publication date: 2023-09-19
Anticipated expiration: 2039-09-20
Also published as: CN110602239A

Abstract

The embodiment of the invention provides a block chain information storage method and related equipment, wherein the method comprises the following steps: generating a first transaction for a first transaction, and performing a first hash operation on the first transaction to obtain a first hash value; acquiring a first merck tree of the latest version; inserting a first leaf node corresponding to the first hash value into a first merck tree, and updating the first merck tree to obtain a second merck tree with updated version; transmitting the first transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree to the consensus node; and under the condition that the received signature confirmation message sent by the consensus node meets a preset consensus strategy, sending the first transaction, the second merck tree and the first leaf node to the accounting node for corresponding storage at the position of the second merck tree. The invention refines the storage granularity of the block chain information, thereby improving the efficiency of the block chain information inquiry.

Description

Block chain information storage method and related equipment

Technical Field

The present invention relates to the field of blockchain technologies, and in particular, to a blockchain information storage method and related devices.

Background

With the increasing maturity of the blockchain technology, more and more industries, such as supply chain industry, financial industry, hotel management industry, electronic commerce industry and logistics industry, deploy own business in a blockchain system to run, upload generated business data to a blockchain, and ensure the normal running of each industry business due to the characteristics of difficult tampering, repudiation and the like of the blockchain.

The current blockchain generally takes blocks as basic units, and the block head of each block on the chain contains the block hash value of the previous block of the block, so that the chain structure of the blockchain is realized. In a block, there is a merck tree that corresponds to all transactions in the block, for example, 8 transactions are included in a block, and then the merck tree that corresponds to all 8 transactions in the block of the block is verified by the root node of the merck tree, that is, if an lawbreaker should tamper with 8 transactions in the block, the tampering difficulty is low, so that the security of the transactions on the blockchain is poor due to this form of the block.

Disclosure of Invention

The invention provides a block chain information storage method and related equipment, and the safety of transactions on a block chain can be improved through the method and the device.

In one aspect, an embodiment of the present invention provides a blockchain information storage method, including:

under the condition that occurrence of a first transaction is detected, generating a first transaction for the first transaction, and performing first hash operation on the first transaction to obtain a first hash value;

acquiring a first merck tree of the latest version from merck trees of different versions prestored for transaction transactions, wherein the first merck tree comprises a plurality of nodes, the nodes comprise leaf nodes corresponding to different transaction transactions, the nodes have hash values corresponding to the nodes respectively, and the hash values corresponding to the leaf nodes are obtained by performing first hash operation on the transaction transactions corresponding to the leaf nodes;

determining the first hash value as a hash value corresponding to a first leaf node, inserting the first leaf node into the first merck tree, and updating hash values corresponding to nodes except the leaf node in the first merck tree to obtain a second merck tree with updated version, wherein the second merck tree comprises a root node;

Acquiring the position of the first leaf node in the second merck tree, transmitting the first transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree to a consensus node, so that the consensus node verifies the hash value corresponding to the root node of the second merck tree according to the position of the first transaction and the first leaf node in the second merck tree, and generating a signature confirmation message after verification is passed;

and under the condition that the received signature confirmation message sent by the consensus node meets a preset consensus strategy, sending the first transaction, the second merck tree and the first leaf node to an accounting node at the position of the second merck tree, so that the accounting node correspondingly stores the first transaction, the second merck tree and the first leaf node at the position of the second merck tree.

Another aspect of an embodiment of the present invention provides a blockchain information storage device, including:

the transaction generation module is used for generating a first transaction for the first transaction under the condition that occurrence of the first transaction is detected, and performing first hash operation on the first transaction to obtain a first hash value;

The device comprises a merck tree acquisition module, a first hash algorithm module and a second hash algorithm module, wherein the merck tree acquisition module is used for acquiring a first merck tree of the latest version from merck trees of different versions prestored for transaction transactions, the first merck tree comprises a plurality of nodes, the nodes comprise leaf nodes corresponding to different transaction transactions, the nodes have hash values corresponding to the leaf nodes, and the hash values corresponding to the leaf nodes are obtained by performing first hash operation on the transaction transactions corresponding to the leaf nodes;

the merck tree updating module is used for determining the first hash value as a hash value corresponding to a first leaf node, inserting the first leaf node into the first merck tree, and updating hash values corresponding to nodes except the leaf node in the first merck tree to obtain a version-updated second merck tree, wherein the second merck tree comprises a root node;

the consensus module is used for acquiring the position of the first leaf node in the second merck tree, transmitting the first transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree to the consensus node, so that the consensus node verifies the hash value corresponding to the root node of the second merck tree according to the position of the first transaction and the first leaf node in the second merck tree, and generating a signature confirmation message after verification is passed;

The accounting module is used for sending the first transaction, the second merck tree and the first leaf node to an accounting node at the position of the second merck tree under the condition that the received signature confirmation message sent by the consensus node meets a preset consensus strategy, so that the accounting node correspondingly stores the first transaction, the second merck tree and the first leaf node at the position of the second merck tree.

Each node in the first merck tree is distributed in different node layers, wherein a leaf node layer is a node layer positioned at the bottommost layer of the first merck tree, and the leaf nodes are distributed in the leaf node layer;

the merck tree updating module comprises:

a target node layer determining unit, configured to determine the leaf node layer as a target node layer;

the hash value determining unit is used for determining the hash value corresponding to the node in the node layer of the upper layer of the target node layer through a second hash operation according to the hash value corresponding to each node in the target node layer;

a circulation unit, configured to end updating the first merck tree and determine the unique node as a root node of the second merck tree when it is determined that a node layer above the target node layer includes only a unique node;

The circulating unit is further configured to determine, when the node layer above the target node layer includes two or more nodes, the node layer above the target node layer as the target node layer, and trigger the hash value determining unit to determine, according to hash values corresponding to respective nodes in the target node layer, hash values corresponding to the nodes in the node layer above the target node layer through a second hash operation.

Determining the hash value of a parent node corresponding to each node in the target node layer in a node layer above the target node layer according to the hash value corresponding to each node in the target node layer;

the hash value determination unit includes:

a judging subunit, configured to judge whether a node exists on the rear side of a node in the odd-numbered ordering position in the target node layer;

the father node determining subunit is used for splicing the hash value corresponding to the node with the judging result of yes in the target node layer with the hash value corresponding to the node adjacent to the rear side of the father node, performing a second hash operation on the spliced value, and taking the hash value obtained after operation as the hash value of the father node corresponding to the node with the judging result of yes in the target node layer;

The father node determining subunit is further configured to determine, according to the hash value corresponding to the node with the no judgment result in the target node layer, through a second hash operation, the hash value of the father node corresponding to the node with the no judgment result.

The parent node determines a child unit, and is specifically configured to:

and performing a second hash operation on the hash value corresponding to the node with the judging result of no, and taking the hash value obtained after operation as the hash value of the father node corresponding to the node with the judging result of no in the target node layer.

The parent node determines a child unit, and is specifically configured to:

and splicing the hash value corresponding to the node with the judging result of no with the copy value of the node, performing a second hash operation on the spliced value, and taking the hash value obtained after operation as the hash value of the father node corresponding to the node with the judging result of no in the target node layer.

The transaction generation module is further used for generating a second transaction for the second transaction under the condition that occurrence of the second transaction is detected;

the merck tree acquisition module is further configured to:

under the condition that the merck tree prestored for the transaction does not exist, performing first hash operation on the second transaction to obtain a second hash value;

Splicing the second hash value with the copy value of the second hash value, and performing second hash operation on the spliced value to obtain a third hash value;

and determining the second hash value as a hash value corresponding to a leaf node of the merck tree of the initial version of the transaction, determining the third hash value as a hash value corresponding to a root node of the merck tree of the initial version, and establishing the merck tree of the initial version.

Wherein, the blockchain information storage device further includes a query module for:

under the condition that a reading request of a client side for the first transaction is received, acquiring the second merck tree stored corresponding to the first transaction from merck trees of a plurality of versions prestored for the transaction, and the position of the first leaf node stored corresponding to the first transaction in the second merck tree;

determining a first verification path from the first leaf node to a root node of the second merck tree according to the position of the first leaf node in the second merck tree and the second merck tree;

obtaining at least one first branch node matched with the first verification path from the second merck tree;

And responding to the reading request, and returning the hash value corresponding to the root node of the first transaction, the hash value corresponding to the root node of the second merck tree, the first branch node and the first verification path to the client so that the client verifies the received first transaction according to the hash value corresponding to the root node of the second merck tree and the first verification path.

In yet another aspect, an embodiment of the present application provides a blockchain information storage device, including a processor, a memory, and a communication interface, where the processor, the memory, and the communication interface are connected to each other, where the communication interface is used to receive and send data, and the memory is used to store program code, and the processor is used to call the program code to perform a method in the foregoing aspect of the embodiment of the present application.

Yet another aspect of the present application provides a computer-readable storage medium storing a computer program comprising program instructions which, when executed by a processor, perform a method as in one aspect of the present application.

In the embodiment of the application, under the condition that the occurrence of a first transaction is detected, a first transaction is generated for the first transaction, a first hash value of the first transaction is calculated, then a first merck tree of the latest version is obtained from merck trees of different versions prestored for the transaction, the first hash value is used as a hash value corresponding to a first leaf node, the first leaf node is inserted into the first merck tree, hash values corresponding to all nodes except the leaf node in the first merck tree are updated, a second merck tree after version updating is obtained, the position of the first leaf node in the second merck tree, the first transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree are further transmitted to a consensus node for verification, a signature confirmation message is generated after verification is passed, and under the condition that the received signature confirmation message transmitted by the consensus node meets a preset strategy, the first transaction, the second leaf node and the corresponding first leaf node are transmitted to the second merck node for billing. In the embodiment of the application, when the blockchain ledger is updated for the first transaction, the updating is performed on the basis of the merck tree of the latest version, so that the chain structure of the blockchain ledger is maintained, and each transaction has the corresponding merck tree for verifying the reliability of the transaction, thereby improving the security of the transaction on the blockchain.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of a merck tree according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating a block chain information storage method according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a merck tree of different versions pre-stored by blockchain nodes according to an embodiment of the present invention;

FIG. 4 is a flowchart illustrating another exemplary method for storing blockchain information according to the present invention;

FIG. 5a is a schematic diagram of updating a first merck tree according to an embodiment of the present invention;

FIG. 5b is a schematic diagram of another update of the first merck tree according to an embodiment of the present invention;

FIG. 6a is a schematic diagram of a first verification path according to an embodiment of the present invention;

FIG. 6b is a schematic diagram of another first verification path according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of a block chain information storage device according to an embodiment of the present invention;

FIG. 8 is a schematic diagram of another block chain information storage device according to an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

The block chain information storage method provided by the embodiment of the invention is a storage method based on the merck tree, and before the block chain information storage method provided by the invention is introduced, the related technology of the merck tree is briefly introduced:

the merck tree (Merkle Trees), also called Merkle tree, is usually a binary tree, and can also be a multi-way tree, the merck tree has all the characteristics of a tree structure, the merck tree comprises a plurality of nodes, the nodes at least comprise at least one leaf node and a root node, and usually comprise a plurality of intermediate nodes between the leaf node and the root node, each node has a corresponding hash value, wherein the hash value of the leaf node is usually a hash value obtained by performing hash operation on a transaction, the hash value of the intermediate node is a hash value obtained by performing hash operation on the leaf nodes after splicing two by two, and the unique hash value obtained through layer-by-layer splicing and hash calculation of the intermediate nodes is used as the hash value of the root node of the merck tree. Taking fig. 1 as an example, referring to fig. 1, fig. 1 is a schematic diagram of a merck tree provided by an embodiment of the present invention, where, in the merck tree shown in the figure, nodes 101, 102, 103, 104 are respectively 4 leaf nodes, and hash values of each node are obtained by performing hash operations on a transaction 1, a transaction 2, a transaction 3, and a transaction 4 respectively; the nodes 105 and 106 are 2 intermediate nodes, the hash value of the node 105 is obtained by performing hash operation after the hash values of the node 101 and the node 102 are spliced, and the hash value of the node 106 is obtained by performing hash operation after the hash values of the node 103 and the node 104 are spliced; the node 107 is a root node, and the corresponding hash value is obtained by performing hash operation after the hash values of the node 105 and the node 106 are spliced. The hash operation performed on the transaction when the hash value of the leaf node is determined and the hash operation performed after the hash value is spliced when the intermediate node and the root node are determined can be the same hash operation or different hash operations.

As can be seen from the corresponding example of fig. 1, the plurality of nodes in the merck tree are distributed in different node layers, the leaf node is located in the node layer at the bottom layer, the root node is located in the node layer at the top layer, the middle node is located in the node layer between the leaf node and the root node, and the hash value corresponding to the node in the node layer above is determined according to the hash value corresponding to the node in the node layer below in any two adjacent node layers.

In the process of determining the hash value corresponding to the nodes in the upper node layer according to the hash value corresponding to the nodes in the lower node layer, firstly judging that the number of the nodes in the lower node layer is even or odd, if the number of the nodes in the lower node layer is even, dividing each node in the odd-numbered ordering position in the lower node layer and the nodes at the rear side of the node in the lower node layer into a group according to the positions of the nodes in the lower node layer, splicing the hash values corresponding to the nodes divided into the group, and carrying out hash operation on the spliced values to obtain the hash value of the corresponding node in the upper node layer of each grouped node in the lower node layer; if the number of nodes in the lower node layer is odd, dividing each node in the lower node layer at an even number (an even number except 0) sequencing position into a group with the node at the left side according to the positions of the nodes in the lower node layer, splicing the hash values corresponding to the nodes divided into a group, carrying out hash operation on the spliced values to obtain the hash value of the node corresponding to the node in the upper node layer in the lower node layer, carrying out hash operation on the hash value corresponding to the last sequencing position in the lower node layer to obtain the hash value corresponding to the last node in the upper node layer, or carrying out hash operation on the hash value corresponding to the last node in the upper node layer after splicing with the copy value of the hash value, and carrying out hash operation on the hash value corresponding to the last node in the upper node layer to ensure the reliability and the accuracy of data verification through the merck tree in the same block chain.

Referring to fig. 2, fig. 2 is a schematic flow chart of a block chain information storage method according to an embodiment of the present invention, where as shown in the figure, the method may include:

s201, under the condition that occurrence of a first transaction is detected, generating a first transaction for the first transaction, and performing first hash operation on the first transaction to obtain a first hash value.

The method for processing blockchain information provided by the embodiment of the invention can be applied to any blockchain node, namely, the execution subject in the embodiment can be any blockchain node in a blockchain system. In one implementation, the blockchain node may periodically detect whether a first transaction has occurred based on a preset smart contract. The first transaction may be any transaction generated by a blockchain link point, may also be a transaction based on a blockchain node uploading a blockchain, for example, may include a transaction of a virtual asset performed between two blockchain nodes, may also be a transaction in a hotel management scenario that generates a hotel order, a transaction in an electronic commerce scenario that generates a commodity order, and so on.

The first transaction may include, in addition to the first transaction, generation time of the first transaction, a version corresponding to the first transaction, a blockchain channel identifier of a blockchain of the uploading transaction corresponding to the blockchain point, and the like. After the first transaction is generated, a first hash operation is performed on the first transaction, where the first hash operation may be one of encryption algorithms such as SHA-2 (Secure Hash Algorithm, secure hash algorithm 2) and MD5 (Message-digest algorithm 5).

S202, acquiring a first merck tree of the latest version from merck trees of different versions prestored for transaction transactions.

Here, the blockchain node may maintain a transaction blockchain ledger for transactions, in which transaction transactions corresponding to different transactions are recorded, and store, for each transaction recorded in the blockchain ledger, a version of merck tree corresponding to each transaction. Except for the first transaction of the uplink, the merck tree of different versions prestored for other transaction transactions is obtained after at least one version update based on the merck tree of the initial version established by the block chain node for the first transaction.

In one implementation manner, if the unified manner of hash value assignment corresponding to the node above the node is determined for the node at the odd-numbered ordering position and without other nodes at the rear side in the blockchain system to perform hash operation after the hash value corresponding to the node is spliced with the copy value of the node, the establishment of the merck tree for the initial version may include the following steps: generating a second transaction for the second transaction if the occurrence of the second transaction is detected; under the condition that the merck tree prestored for the transaction does not exist, performing first hash operation on the second transaction to obtain a second hash value; splicing the second hash value with the copy value of the second hash value, and performing second hash operation on the spliced value to obtain a third hash value; and determining the second hash value as a hash value corresponding to a leaf node of the merck tree of the initial version of the transaction, determining the third hash value as a hash value corresponding to a root node of the merck tree of the initial version, and establishing the merck tree of the initial version.

Referring to fig. 3, fig. 3 is a schematic diagram of a merck tree of different versions pre-stored in a block chain node, where, as shown in the drawing, the merck tree of different versions pre-stored in the block chain node includes n merck trees corresponding to n transaction transactions, where, transaction 1 is a first transaction of an uplink in a block chain book maintained by the block chain node, an initial version of the block chain book, that is, a merck tree of version 1 is established according to transaction 1, after transaction 2 is generated, according to transaction 2, update is performed on the basis of the merck tree of version 1, so as to obtain a merck tree of a second version of the block chain book, that is, a merck tree of version 2 corresponding to transaction 2, and after transaction 3 is generated, update is performed on the basis of the merck tree of version 2 according to transaction 3, so as to obtain a merck tree of a third version of the block chain book, that is, update is performed on the basis of the merck tree of version n corresponding to n of the block chain book, that is updated according to the transaction 1, that is, and n is updated on the basis of the merck tree of version n is maintained by the corresponding to n.

In this step, the latest version of the merck tree is obtained from the pre-stored merck trees with different versions and is used as the first merck tree. In the corresponding example of fig. 3, transaction n is the last transaction in the blockchain ledger maintained by the blockchain point, that is, the merck tree of version n is the latest version of the merck tree, and then the merck tree of version n is taken as the first merck tree.

The first merck tree comprises a plurality of nodes, wherein the nodes comprise leaf nodes corresponding to different transaction transactions and root nodes of the first merck tree. In the case that the first merck tree is the first initial version of the block chain ledger maintained by the block chain node or the second version of the merck tree corresponding to the block chain ledger maintained by the block chain node, the plurality of nodes of the first merck tree only include leaf nodes and root nodes; in the case where the first merck tree is not the merck tree that maintains the first initial version of the blockchain ledger, nor is it the log merck tree of the second version of the blockchain ledger maintained by the blockchain node, the plurality of nodes of the first merck tree include leaf nodes, root nodes, and intermediate nodes between the leaf nodes and the root nodes. Each node of the first merck tree has a corresponding hash value, the hash value corresponding to the leaf node is obtained by performing a first hash operation on the transaction corresponding to the leaf node, the hash value corresponding to the intermediate node can be determined according to the hash value corresponding to the leaf node, and the hash value corresponding to the root node can be determined according to the hash value of the intermediate node. The hash algorithm for determining the hash value corresponding to the intermediate node according to the hash value corresponding to the leaf node and the hash algorithm for determining the hash value corresponding to the root node according to the hash value corresponding to the intermediate node are both second hash operations, wherein the second hash operations can be one of encryption algorithms such as SHA-2 and MD5, and the second hash operations can be the same as or different from the first hash operations.

S203, determining the first hash value as a hash value corresponding to a first leaf node, inserting the first leaf node into the first merck tree, and updating hash values corresponding to nodes except the leaf node in the first merck tree to obtain a second merck tree with updated version, wherein the second merck tree comprises a root node.

Here, the first leaf node is inserted into the first merck tree as a corresponding leaf node of the first transaction in the first merck tree, specifically, the first leaf node may be inserted into a position of any one leaf node in the first merck tree, taking the merck tree of version n in fig. 3 as an example, a position before the first leaf node is inserted into the leaf node 1, a position after the first leaf node is inserted into the leaf node n, or a position between any two leaf nodes between the leaf node 1 and the leaf node n.

After the first leaf node is inserted into the first merck tree, the hash value corresponding to each node except the leaf node in the first merck tree is updated, which is actually a process of determining the hash value of the node in the upper node layer from the leaf node layer of the bottom layer where the leaf node of the first merck tree is located, layer by layer, upwards according to the hash value of the node in the lower node layer, specifically: determining a leaf node layer as a target node layer; according to the hash value corresponding to each node in the target node layer, determining the hash value corresponding to the node in the node layer of the upper layer of the target node layer through second hash operation; if the upper node layer of the target node layer is determined to only contain unique nodes, ending updating the first merck tree, and determining the unique nodes as root nodes of the second merck tree; if the upper node layer of the target node layer is determined to contain two or more nodes, the upper node layer of the target node layer is re-determined to be the unique target node layer, the hash value corresponding to each node in the target node layer is returned to be executed, and the hash value corresponding to the node in the upper node layer of the target node layer is determined through the second hash operation.

Optionally, the block link point stores, for each merck tree, a position of a leaf node corresponding to each transaction in the merck tree, after the first leaf node is inserted into the first merck tree, a first node position of the first leaf node in the first merck tree is recorded, and positions of leaf nodes with other changed positions are updated, so as to obtain positions of leaf nodes corresponding to each transaction in the second merck tree.

S204, acquiring the position of the first leaf node in the second merck tree, and sending the first transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree to a consensus node.

The consensus node herein may be a consensus node predetermined based on a consensus mechanism of the blockchain system, such as a PoW (Proof of Work) consensus mechanism, a PoS (Proof of status equity) consensus mechanism, a DPoS (Delegated Proof of Stake, proof of equity) consensus mechanism, and so on. The position of the corresponding leaf node (i.e., the first leaf node) of the first transaction in the second merck tree can be determined according to the position of the leaf node corresponding to each transaction in the stored second merck tree, and then the first log transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree are sent to the consensus node.

The common node verifies the hash value of the root node corresponding to the first transaction according to the positions of the first transaction and the first leaf node in the second merck tree, specifically, the common node performs a first hash operation on the first transaction to obtain the merck tree of the latest version stored by the common node or the merck tree of the latest version obtained by other paths, the common node determines that the hash value of the root node obtained after the leaf node corresponding to the first transaction is inserted in the position corresponding to the position of the first leaf node in the second merck tree in the latest version obtained by the common node, and if the hash value of the root node finally determined is consistent with the hash value corresponding to the root node of the second merck tree, the hash verification is passed. Under the condition that verification is passed, the consensus node can perform consensus signature on the hash value corresponding to the root node of the second merck tree through the private key of the consensus node, and returns the consensus signature to the execution main body blockchain node through the signature confirmation message. In the process, the hash value of the root node of the second merck tree is identified through the identification node, so that the reliability of the uplink first transaction is ensured.

S205, when the received signature confirmation message sent by the consensus node meets a preset consensus strategy, the first transaction, the second merck tree and the first leaf node are sent to an accounting node at the position of the second merck tree.

Specifically, the preset consensus strategy specifies that the consensus is successful when the number of signature confirmation messages returned by different consensus nodes is greater than the preset number, or the consensus is successful when the signature confirmation messages returned by the designated consensus nodes are received. After receiving the signature confirmation message, the blockchain node acquires the consensus signature therein, and verifies the consensus signature, and only the signature confirmation message passing the verification is valid, the blockchain node can count the number of valid signature confirmation messages to judge whether the consensus strategy is met or not, and can also recognize whether the sending node of the signature confirmation message is a designated consensus node or not through the consensus signature in the valid signature confirmation message, so as to judge whether the consensus strategy is met or not.

In the case that the consensus strategy is confirmed to be met, the block link point sends the first transaction, the second merck tree and the first leaf node to the accounting node at the position of the second merck tree, and the accounting node stores the first transaction, the second merck tree and the first leaf node in a log transaction database of the accounting node in a one-to-one correspondence mode at the position of the second merck tree.

Optionally, the executing main blockchain node in this embodiment may also be one of the accounting nodes, and then the executing main blockchain node stores the first transaction, the second merck tree, and the first leaf node in the log transaction database of the executing main blockchain node in a corresponding manner at the position of the second merck tree.

In the embodiment of the invention, under the condition that the occurrence of a first transaction is detected, a first transaction is generated for the first transaction, a first hash value of the first transaction is calculated, then a first merck tree of the latest version is obtained from merck trees of different versions prestored for the transaction, the first hash value is used as a hash value corresponding to a first leaf node, the first leaf node is inserted into the first merck tree, hash values corresponding to all nodes except the leaf node in the first merck tree are updated, a second merck tree after version updating is obtained, the position of the first leaf node in the second merck tree, the first transaction, the position of the first leaf node in the second merck tree and the hash value corresponding to the root node of the second merck tree are further transmitted to a consensus node for verification, a signature confirmation message is generated after verification is passed, and under the condition that the received signature confirmation message transmitted by the consensus node meets a preset strategy, the first transaction, the second leaf node and the corresponding first leaf node are transmitted to the second merck node for billing. In the embodiment of the invention, when the blockchain ledger is updated for the first transaction, the updating is performed on the basis of the merck tree of the latest version, so that the chain structure of the blockchain ledger is maintained, and each transaction has the corresponding merck tree for verifying the reliability of the transaction, thereby improving the security of the transaction on the blockchain.

Referring to fig. 4, fig. 4 is a flow chart of another blockchain information storage method provided by the present invention, where the blockchain information storage method in the corresponding embodiment of fig. 4 may be implemented on any one of the accounting nodes in the blockchain node, and as shown in the figure, the method may include:

s401, under the condition that occurrence of a first transaction is detected, generating a first transaction for the first transaction, and performing first hash operation on the first transaction to obtain a first hash value.

S402, acquiring a first merck tree of the latest version from merck trees of different versions prestored for transaction transactions.

The first merck tree comprises a plurality of nodes, the nodes comprise leaf nodes corresponding to different transaction transactions, the nodes have hash values corresponding to the nodes, and the hash values corresponding to the leaf nodes are obtained by performing first hash operation on the transaction transactions corresponding to the leaf nodes.

S403, determining the first hash value as a hash value corresponding to the first leaf node, and inserting the first leaf node into the first merck tree.

The specific implementation manner of step S401 to step S403 may refer to the specific implementation details of step S201 to step S203 in the corresponding embodiment of fig. 2, which are not described herein again.

S404, determining a leaf node layer where the leaf node in the first merck tree is located as a target node layer.

Each node in the first merck tree is distributed in different node layers, the leaf nodes are distributed in the leaf node layer at the bottommost layer, the root nodes are distributed in the root node layer at the topmost layer, and the middle node is distributed in the middle node layer between the leaf node layer and the root node layer.

S405, according to the hash value corresponding to each node in the target node layer, determining the hash value corresponding to the node in the node layer of the upper layer of the target node layer through a second hash operation.

Here, according to the hash value corresponding to each node in the target node layer, the hash value corresponding to the node in the node layer of the upper layer of the target node layer is determined through the second hash operation, and actually, the hash value of the parent node corresponding to each node in the target node layer in the upper layer of the target node layer is determined. The hash value corresponding to the father node of any first node in the target node layer is a node determined according to the hash value corresponding to the first node. Specific: whether nodes exist at the rear side of the nodes in the odd-numbered ordering positions in the target node layer or not can be judged; splicing the hash value corresponding to the node with the judging result being yes in the target node layer with the hash value corresponding to the node adjacent to the rear side of the target node layer, performing a second hash operation on the spliced value, and taking the hash value obtained after operation as the hash value of the father node corresponding to the node with the judging result being yes in the target node layer; and determining the hash value of the father node corresponding to the node with the judging result of no through a second hash operation according to the hash value corresponding to the node with the judging result of no in the target node layer.

The method comprises the steps of directly carrying out second hash operation on hash values corresponding to nodes in a block chain link point according to a unified mode appointed by the target node layer, aiming at nodes which are in odd-numbered sequence positions and have no other nodes at the rear side, obtaining hash values of father nodes, or carrying out second hash operation on the hash values corresponding to the nodes and copy values of the father nodes after splicing the hash values corresponding to the nodes.

S406, judging whether the number of nodes in the node layer of the upper layer of the target node layer is larger than 1.

If not, step S407 is executed, and if yes, step S408 is executed.

If the number of nodes in the upper node layer of the target node layer is 1 or more than 1, under the condition that the number is 1, the upper node layer of the target node layer is the root node layer, and updating of the first merck tree is completed; if the number is greater than 1, it is indicated that the node layer above the target node layer is an intermediate node layer, and the update of the first merck tree is not completed yet, and further update is required.

S407, finishing updating the first merck tree, determining one node in the node layer of the upper layer of the target node layer as the root node of the second merck tree, and obtaining the second merck tree after version updating.

The steps S404 to S407 are exemplified: referring to fig. 5a, fig. 5a is a schematic diagram of updating a first merck tree, where the first merck tree includes five leaf nodes, i.e. a leaf node 1 to a leaf node 5, and the first leaf node may be inserted into a position after the leaf node 5, and then, in a process of updating hash values corresponding to nodes other than the leaf node, a leaf node layer is first determined as a target node layer, and hash values corresponding to nodes in a node layer above the leaf node layer are determined, and as hash values of nodes corresponding to respective lower layers of the intermediate node 1, the intermediate node 2, and the intermediate node 4 are unchanged, the corresponding hash values are unchanged; the hash value of the intermediate node 3 is determined in the first merck tree only according to the hash value of the leaf node 5, after the first leaf node is inserted, the hash value of the intermediate node 3 is determined by the hash values corresponding to the leaf node 5 and the first leaf node together, and the hash value of the intermediate node 3' updated in the second merck tree is obtained by updating the hash value; because the upper node layer of the leaf node layer comprises three nodes including a middle node 1, a middle node 2 and a middle node 3', the node layer where the three nodes are positioned is redetermined as a target node layer, and the hash value corresponding to the node in the upper node layer of the target node layer is updated; since the hash value of the node corresponding to the lower layer of the intermediate node 4 is unchanged, the hash value corresponding to the intermediate node 4 is unchanged; and the intermediate node 3 is updated to be the intermediate node 3", so that the hash value of the intermediate node 3" is subjected to a second hash operation according to a specified unified mode, the hash value of the intermediate node 3 "is spliced with the copy value of the intermediate node 3" and then subjected to the second hash operation, the hash value of the intermediate node 5 'updated by the intermediate node 5 is obtained, the hash value of the root node 1 is updated in the same way, the hash value of the root node 1' updated in the second merck tree is obtained, and the updating is completed, so that the second merck tree is finally obtained.

Referring to fig. 5b, fig. 5b is another schematic diagram of updating a first merck tree provided by the embodiment of the present invention, where, as shown in the fig. 5b, the first merck tree is the same as the first merck tree shown in fig. 5a, but a first leaf node is illustratively inserted between the leaf node 2 and the leaf node 3, where, in the same way as in fig. 5a, hash values corresponding to other nodes are unchanged, only hash values corresponding to each of the intermediate node 2, the intermediate node 3, the intermediate node 4, the intermediate node 5 and the root node 1 need to be updated, and hash values corresponding to each of the intermediate node 2", the intermediate node 3", the intermediate node 4", the intermediate node 5" and the root node 1 "in the second merck tree are determined, so as to finally obtain an updated second merck tree.

S408, determining the node layer above the target node layer as the target node layer.

Updating the corresponding hash value of the nodes in each node layer is realized through updating the target node layer.

S409, acquiring the position of the first leaf node in the second merck tree, and sending the first transaction, the position of the first leaf node in the second merck tree, and the hash value corresponding to the root node of the second merck tree to the consensus node.

And the consensus node verifies the hash value corresponding to the root node of the second merck tree according to the first transaction and the position of the first leaf node in the second merck tree, and generates a signature confirmation message after the verification is passed.

S410, correspondingly storing the first transaction, the second merck tree and the position of the first leaf node in the second merck tree under the condition that the received signature confirmation message sent by the consensus node meets the preset consensus strategy.

When the signature confirmation message sent by the consensus node meets the preset consensus policy, the accounting node can also send the first transaction, the second merck tree and the position of the first leaf node in the second merck tree to other accounting nodes in the blockchain system, and the other accounting nodes correspondingly store the first transaction, the second merck tree and the position of the first leaf node in the second merck tree.

S411, receiving a read request of a client for a first transaction, acquiring a second merck tree stored corresponding to the first transaction from merck trees of a plurality of versions prestored for the transaction, and storing a first leaf node corresponding to the first transaction in the position of the second merck tree.

S412, determining a first verification path from the first leaf node to a root node of the second merck tree according to the position of the first leaf node in the second merck tree and the second merck tree.

Here, the first verification path includes a plurality of first path nodes, where the first path nodes include a first leaf node and a root node of the second merck tree. A plurality of first path nodes on the first verification path may be determined in the second merck tree by sequentially determining parent nodes from the first leaf node upward.

If the second merck tree is the merck tree of the first initial version corresponding to the blockchain ledger maintained by the accounting node or the merck tree of the second version of the blockchain ledger maintained by the accounting node, the first path node on the first verification path only comprises the first leaf node and the root node of the second merck tree; if the second merck tree is not the first version of the merck tree or the second version of the merck tree, the first path node on the first verification path includes at least one intermediate node between the first leaf node and the root node of the second merck tree in addition to the first leaf node and the root node of the second merck tree.

For example, if the second merck tree is the merck tree corresponding to the initial version of the blockchain ledger maintained by the accounting node, as shown in fig. 6a, fig. 6a is a schematic diagram of a first verification path provided by the embodiment of the present invention, and the second merck tree corresponding to the first transaction is shown in fig. 6a, and the parent node of the first leaf node is the root node, then the first path node on the first verification path only includes the first leaf node and the root node of the second merck tree. If the second merck tree is not the first initial version merck tree corresponding to the blockchain ledger maintained by the accounting node, and is not the second version merck tree corresponding to the blockchain ledger maintained by the blockchain node, see fig. 6b, fig. 6b is a schematic diagram of another first verification path provided by the embodiment of the present invention, as shown in the diagram, assuming that the second merck tree corresponding to the first transaction is shown in the merck tree in fig. 6b, the father node of the first leaf node is the intermediate node 1, the father node of the intermediate node 1 is the intermediate node 2, and the father node of the intermediate node 2 is the root node of the second merck tree, then the first path node on the first verification path includes the first leaf node, the intermediate node 1, the intermediate node 2 and the root node of the second merck tree is determined.

S413, at least one first branch node matched with the first verification path is obtained from the second merck tree.

The first branch node is a node which has a common father node with the first path node. In a specific implementation, starting from a first leaf node along a first verification path, judging whether a node with a common father node with the first leaf node exists, and if so, determining the node with the same father node with the first leaf node as a first branch node; judging whether the father node of the first leaf node is the root node of the second merck tree, if yes, ending the determining process of the first branch node, if not, judging whether a node which has a common father node with the father node of the first leaf node exists, and if yes, determining the node which has a common father node with the father node of the first leaf node as a first branch node; and further judging whether the father node of the first leaf node is the root node of the second merck tree, and the like until all nodes except the root node on the first verification path are used for determining the first branch node and then ending.

S414, responding to the reading request, and returning the first transaction, the hash value corresponding to the root node of the second merck tree, the first branch node and the first verification path to the client.

After receiving the first transaction, the hash value corresponding to the root node of the second merck tree, the first branch node and the first verification path, the client verifies the received first transaction according to the hash value corresponding to the root node of the second merck tree, the first branch node and the first verification path.

Specifically, if the first verification path only includes the first leaf node and the root node of the second merck tree, the client receives that the first branch node is empty, and if the client confirms that the received first branch node is empty, the client directly performs a first hash operation on the first transaction, determines that the obtained hash value is an unreliable transaction after being possibly tampered according to a unified mode specified by the hash value corresponding to the node above the obtained hash value according to the node which is in an odd-numbered ordering position and has no other node at the rear side, or performs a second hash operation after being spliced with the copy value of the client, and if the hash value obtained by the second hash operation is consistent, the verification is confirmed to be passed, so that the first transaction is the reliable transaction stored by the accounting node, otherwise, the verification is confirmed to be failed, so that the received first transaction is the unreliable transaction possibly tampered.

If the first verification path comprises a first leaf node, a root node of a second merck tree and at least one intermediate node, the first branch nodes received by the client side comprise at least one, each first branch node carries information indicating the self-matched first path node, the client side carries out first hash operation on the first transaction, the verification root hash value is determined through second hash operation along the first verification path according to the hash value obtained through the first hash operation and the hash value corresponding to each first branch node, verification is confirmed to pass under the condition that the verification root hash value is consistent with the hash value of the root node of the second merck tree, the first transaction is a reliable transaction stored by the accounting node, otherwise, verification is confirmed to not pass, and the received first transaction is an unreliable transaction possibly tampered.

In the process of determining the verification root hash value, each first path node can be sequentially determined as a target path node along a first verification path according to the direction from the first leaf node to the root node, and the hash value obtained by performing first hash operation on the first transaction is determined as a target node hash value; judging whether the target path node has a matched first branch node, if so, performing second hash operation after splicing the hash value of the target node and the hash value of the first branch node, determining the obtained hash value as a new target node hash value, if not, determining a unified mode designated by the hash value corresponding to the node above the node in the block chain system according to the nodes which are in odd-numbered sequence positions and have no other nodes at the rear side, directly performing second hash operation on the hash value of the target node, or performing second hash operation after splicing the hash value of the target node and the copy value of the target node, and determining the obtained hash value as a new target node hash value; and then repeatedly executing the process on the target path node and the target node hash value until the root node is determined to be the target path node, stopping, and determining the target node hash value at the moment as the verification root hash value.

Taking the first verification path shown in fig. 6b as an example, the first path node on the first verification path includes a first leaf node, an intermediate node 1, an intermediate node 2 and a root node, the first branch node includes a leaf node 1 (matched with the first leaf node), an intermediate node 5 (matched with the intermediate node 1) and an intermediate node 3 (matched with the intermediate node 2), the client performs a first hash operation on the first transaction to obtain a hash1, and the hash1 and the first branch node matched with the first leaf node, namely, the hash value corresponding to the leaf node 1 is spliced and then performs a second hash operation to obtain a hash2; splicing the hash value corresponding to the first branch node, namely the intermediate node 5, of which the hash2 is matched with the intermediate node 1, and then performing a second hash operation to obtain a hash3; and (3) splicing the hash value corresponding to the first branch node, namely the intermediate node 3, matched with the intermediate node 2, and then performing a second hash operation to obtain a hash4, further judging whether the hash4 is compared with the hash value corresponding to the root node of the second merck tree, if so, verifying to pass, otherwise, verifying to not pass.

In the embodiment of the invention, a first hash value obtained by carrying out a first hash operation on a first transaction is used as a hash value corresponding to a first leaf node, the first leaf node is inserted into a first merck tree of the latest version of the transaction, then the leaf node layer of the first merck tree is determined as a target node layer, the hash value corresponding to the node in the upper node layer of the target node layer is determined through a second hash operation according to the hash value corresponding to each node in the target node layer, under the condition that the number of the nodes in the upper node layer of the target node layer is 1, the updating of the first merck tree is finished to obtain a second merck tree, under the condition that the number is greater than 1, the upper node layer of the target node layer is redetermined as a unique target node layer, and the step of circularly executing the hash value corresponding to the node in the upper node layer of the target node layer is determined through the second hash operation; when the number of nodes in the upper layer of the target node layer is 1, finishing updating the first merck tree to obtain a second merck tree, enabling the consensus node to verify the hash value of the root node of the second merck tree, and correspondingly storing the first transaction, the second merck tree and the positions of the first leaf nodes in the second merck tree after receiving the signature confirmation message sent by the consensus node; and when receiving a read request sent by the client for the first transaction, acquiring a first verification path from the first leaf node to the root node and a first branch node matched with the first verification path, and responding to the read request, and returning hash values corresponding to the first transaction, the root node of the second merck tree, the first branch node and the first verification path to the client so that the client verifies the first transaction. The method and the system realize updating of the blockchain ledger by taking the transaction as granularity, not only improve the security of the transaction on the blockchain, but also refine the storage granularity of the blockchain information and improve the query efficiency for the transaction.

Referring to fig. 7, fig. 7 is a schematic structural diagram of a blockchain information storage device according to an embodiment of the present invention, as shown in the drawing, the blockchain information storage device 70 may at least include a transaction generating module 701, a merck tree obtaining module 702, a merck tree updating module 703, a consensus module 704, and a billing module 705, where:

the transaction generating module 701 is configured to generate a first transaction for a first transaction when the occurrence of the first transaction is detected, and perform a first hash operation on the first transaction to obtain a first hash value;

the merck tree obtaining module 702 is configured to obtain a first merck tree of a latest version from merck trees of different versions prestored for transaction transactions, where the first merck tree includes a plurality of nodes, the plurality of nodes include leaf nodes corresponding to different transaction transactions, the plurality of nodes have hash values corresponding to the leaf nodes, and the hash values corresponding to the leaf nodes are obtained by performing a first hash operation on the transaction transactions corresponding to the leaf nodes;

a merck tree updating module 703, configured to determine the first hash value as a hash value corresponding to a first leaf node, insert the first leaf node into the first merck tree, and update hash values corresponding to nodes in the first merck tree except for the leaf node, so as to obtain a version-updated second merck tree, where the second merck tree includes a root node;

The consensus module 704 is configured to obtain a position of the first leaf node in the second merck tree, send the first transaction, the position of the first leaf node in the second merck tree, and a hash value corresponding to a root node of the second merck tree to a consensus node, so that the consensus node verifies the hash value corresponding to the root node of the second merck tree according to the first transaction and the position of the first leaf node in the second merck tree, and generates a signature confirmation message after verification is passed;

and a billing module 705, configured to send the first transaction, the second merck tree, and the position of the first leaf node in the second merck tree to a billing node if the received signature confirmation message sent by the consensus node meets a preset consensus policy, so that the billing node correspondingly stores the first transaction, the second merck tree, and the position of the first leaf node in the second merck tree.

The merck tree update module 703 includes:

a target node layer determining unit 7301 for determining the leaf node layer as a target node layer;

a hash value determining unit 7302, configured to determine, according to hash values corresponding to nodes in the target node layer, hash values corresponding to nodes in a node layer that is a layer above the target node layer through a second hash operation;

a circulation unit 7303 configured to, in a case where it is determined that a node layer above the target node layer contains only a unique node, end updating of the first merck tree, and determine the unique node as a root node of the second merck tree;

the circulation unit 7303 is further configured to determine, when the previous node layer of the target node layer includes two or more nodes, the previous node layer of the target node layer as the target node layer, and trigger the hash value determining unit to determine, according to the hash values corresponding to the respective nodes in the target node layer, hash values corresponding to the nodes in the previous node layer of the target node layer through a second hash operation.

Optionally, determining, according to the hash value corresponding to each node in the target node layer, a hash value of a parent node corresponding to each node in the target node layer in a node layer above the target node layer;

The hash value determination unit 7303 includes:

a judging subunit 3031, configured to judge whether a node exists on the rear side of the node in the odd-numbered ordering position in the target node layer;

a parent node determining subunit 3032, configured to splice hash values corresponding to nodes in the target node layer, where the result of the judgment is yes, with hash values corresponding to nodes adjacent to the respective rear sides, perform a second hash operation on the spliced values, and use the hash value obtained after the operation as a hash value of a parent node corresponding to the node in the target node layer, where the result of the judgment is yes;

the parent node determining subunit 3032 is further configured to determine, according to the hash value corresponding to the node of which the determination result is no in the target node layer, a hash value of the parent node corresponding to the node of which the determination result is no through a second hash operation.

Optionally, the parent node determining subunit 3032 is specifically configured to:

The parent node determining subunit 3032 is specifically configured to:

Optionally, the transaction generating module 701 is further configured to generate a second transaction for the second transaction if the occurrence of the second transaction is detected;

the merck tree obtaining module 702 is further configured to:

Optionally, the blockchain information storage device 70 further includes a query module 706 for:

In a specific implementation, the blockchain information storage device may execute each step in the blockchain information storage method shown in fig. 2 and 5 through each built-in functional module, and specific implementation details may refer to implementation details of each step in the corresponding embodiment of fig. 2 and 5, which are not described herein again.

In the embodiment of the invention, when the transaction generating module detects that a first transaction occurs, generating a first transaction for the first transaction, calculating a first hash value of the first transaction, acquiring a first merck tree of the latest version from merck trees of different versions prestored for the transaction by the merck tree acquiring module, inserting the first leaf node into the first merck tree by using the first hash value as a hash value corresponding to the first leaf node, updating hash values corresponding to nodes except the leaf node in the first merck tree, obtaining a second merck tree after version updating, transmitting the position of the first leaf node in the second merck tree, the first transaction, the hash value corresponding to a root node of the first leaf node in the second merck tree to the consensus node by the consensus module, verifying, generating a signature confirmation message after verification, and transmitting the signature confirmation message which is transmitted by the billing module and meets the preset strategy to the first transaction node and the second node under the condition that the received signature confirmation message is satisfied by the consensus node, and storing the corresponding transaction in the first transaction tree to the first leaf node. In the embodiment of the invention, when the blockchain ledger is updated for the first transaction, the updating is performed on the basis of the merck tree of the latest version, so that the chain structure of the blockchain ledger is maintained, and each transaction has the corresponding merck tree for verifying the reliability of the transaction, thereby improving the security of the transaction on the blockchain.

Referring to fig. 8, fig. 8 is a schematic structural diagram of another blockchain information storage device according to an embodiment of the present invention, as shown in the drawing, the service data transferring device 80 includes a processor 801, a memory 802, and a communication interface 803. The processor 801 is connected to the memory 802 and the communication interface 803, for example, the processor 801 may be connected to the memory 802 and the communication interface 803 through a bus.

The processor 801 is configured to support the blockchain information storage device to perform the corresponding functions in the blockchain information storage methods described in fig. 2 and 5. The processor 801 may be a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), a hardware chip or any combination thereof. The hardware chip may be an Application-specific integrated circuit (ASIC), a programmable logic device (Programmable Logic Device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (Complex Programmable Logic Device, CPLD), a Field programmable gate array (Field-Programmable Gate Array, FPGA), general array logic (Generic Array Logic, GAL), or any combination thereof.

The memory 802 is used for storing program codes and the like. Memory 802 includes internal memory, which may include at least one of: volatile memory (e.g., dynamic Random Access Memory (DRAM), static RAM (SRAM), synchronous Dynamic RAM (SDRAM), etc.) and nonvolatile memory (e.g., one-time programmable read-only memory (OTPROM), programmable ROM (PROM), erasable Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM)), memory 802 may also include external memory that may include at least one of a Hard Disk (HDD) or Solid State Drive (SSD), flash Drive, e.g., high density flash memory (CF), secure Digital (SD), microsD, mini SD, extreme digital (xD), memory stick, etc.

The communication interface 803 is used to receive or transmit data.

The processor 801 may call the program code to:

It should be noted that implementation of each operation may also correspond to the corresponding description of the method embodiment shown in fig. 2 and 5; the processor 801 may also be used to perform other operations in the method embodiments described above.

Embodiments of the present invention also provide a computer storage medium storing a computer program comprising program instructions which, when executed by a computer, cause the computer to perform a method as described in the previous embodiments, the computer being part of a blockchain information storage device as mentioned above.

Those skilled in the art will appreciate that implementing all or part of the above-described methods in accordance with the embodiments may be accomplished by way of a computer program stored on a computer readable storage medium, which when executed may comprise the steps of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), or the like.

The foregoing disclosure is illustrative of the present invention and is not to be construed as limiting the scope of the invention, which is defined by the appended claims.

Claims

1. A blockchain information storage method, comprising:

2. The method of claim 1, wherein nodes in the first merck tree are distributed at different node layers, wherein a leaf node layer is a node layer located at a bottommost layer of the first merck tree, and the leaf nodes are distributed at the leaf node layer;

The updating the hash value corresponding to each node except the leaf node in the first merck tree, and the obtaining the second merck tree after version updating comprises the following steps:

determining the leaf node layer as a target node layer;

according to the hash value corresponding to each node in the target node layer, determining the hash value corresponding to the node in the node layer of the upper layer of the target node layer through a second hash operation;

if the upper node layer of the target node layer is determined to only contain a unique node, ending updating the first merck tree, and determining the unique node as a root node of the second merck tree;

if it is determined that the node layer above the target node layer contains two or more nodes, determining the node layer above the target node layer as the target node layer, and returning to execute the hash value corresponding to each node in the target node layer, and determining the hash value corresponding to the node in the node layer above the target node layer through a second hash operation.

3. The method according to claim 2, wherein the hash value of the parent node corresponding to each node in the target node layer in the node layer above the target node layer is determined according to the hash value corresponding to each node in the target node layer;

And determining the hash value corresponding to the node in the node layer above the target node layer through a second hash operation according to the hash value corresponding to each node in the target node layer comprises the following steps:

judging whether nodes exist at the rear sides of the nodes in the odd-numbered ordering positions in the target node layer;

splicing the hash value corresponding to the node with the judging result being yes in the target node layer and the hash value corresponding to the node adjacent to the rear side of the target node layer, performing a second hash operation on the spliced value, and taking the hash value obtained after operation as the hash value of the father node corresponding to the node with the judging result being yes in the target node layer;

and determining the hash value of the father node corresponding to the node with the judging result of no through a second hash operation according to the hash value corresponding to the node with the judging result of no in the target node layer.

4. The method of claim 3, wherein the determining, according to the hash value corresponding to the node in the target node layer for which the determination result is no, the hash value of the parent node corresponding to the node for which the determination result is no through the second hash operation includes:

5. The method of claim 3, wherein the determining, according to the hash value corresponding to the node in the target node layer for which the determination result is no, the hash value of the parent node corresponding to the node for which the determination result is no through the second hash operation includes:

6. The method of claim 1, wherein, in the event that a first transaction occurrence is detected, prior to generating a first transaction for the first transaction, further comprising:

generating a second transaction for a second transaction if the occurrence of the second transaction is detected;

7. The method according to claim 1, wherein the method further comprises:

8. A blockchain information storage device, comprising:

9. A blockchain information storage device comprising a processor, a memory and a communication interface, the processor, memory and communication interface being interconnected, wherein the communication interface is for receiving and transmitting data, the memory is for storing program code, and the processor is for invoking the program code to perform the method of any of claims 1-7.

10. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program, which is executed by a processor to implement the method of any one of claims 1 to 7.