CN114706848A

CN114706848A - Block chain data storage, updating and reading method and device and electronic equipment

Info

Publication number: CN114706848A
Application number: CN202210179226.7A
Authority: CN
Inventors: 戚奕统
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-02-25
Filing date: 2022-02-25
Publication date: 2022-07-05

Abstract

A method of blockchain data storage, comprising: acquiring a key-value key value pair of block chain data to be stored; converting the key-value key value pair of the block chain data into a root node, a middle node and a leaf node on a logical tree structure; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the block chain data; respectively storing the root node, the intermediate nodes and the leaf nodes into a database; the nodes on the logical tree structure are stored in at least a plurality of databases respectively.

Description

Block chain data storage, updating and reading method and device and electronic equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for storing, updating, and reading blockchain data, and an electronic device.

Background

The block chain technology, also called as distributed ledger technology, is an emerging technology in which a plurality of node devices participate in accounting together, and a complete distributed database is stored and maintained together.

For node devices of a blockchain, blockchain data which needs to be stored and maintained generally includes blockchain data and account status data corresponding to blockchain accounts in the blockchain; the tile data may further include tile header data, tile transaction data in the tile, and a transaction receipt corresponding to the tile transaction data in the tile, etc.

When storing the various blockchain data shown above, the node devices of the blockchain may generally organize the various blockchain data into a logical tree structure to be stored in the database.

Disclosure of Invention

This specification proposes a block chain data storage method, which includes:

acquiring a key-value key value pair of block chain data to be stored;

converting the key-value key value pair of the block chain data to be stored into a root node, a middle node and a leaf node on a logical tree structure; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the block chain data; determining a database for storing the root node, the intermediate node and the leaf node, and storing the root node, the intermediate node and the leaf node in the determined database; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases.

The present specification also provides a method for updating blockchain data, where key-value key values of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the method comprises the following steps:

determining a root node, a middle node and a leaf node of a key-value key value pair used for storing target block chain data to be updated on the logic tree structure, and determining a database used for storing the updated root node, middle node and leaf node;

updating the determined leaf node based on Value of the key-Value key Value pair of the target block chain data, and after the updating of the leaf node is completed, further writing the updated hash Value of the leaf node and the determined database identifier of the database for storing the updated leaf node into an intermediate node of a previous layer linked with the leaf node so as to update the intermediate node;

after the intermediate node is updated, further writing the updated hash value of the intermediate node and the determined database identifier for storing the updated database of the intermediate node into the node on the previous layer linked to the intermediate node, so as to continuously update the node on the previous layer linked to the intermediate node, and so on until the root node on the logical tree structure is updated.

The present specification also provides a method for reading blockchain data, where key-value key values of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the method comprises the following steps:

reading a hash value of the root node of the logic tree structure, and determining a database for storing the root node of the logic tree structure; taking the hash value of the root node as a query index, querying the root node from the database, and loading the queried root node in a memory;

reading a hash value of an intermediate node which is stored in the root node and is linked to the next layer of the root node and a database identifier of a database storing the intermediate node, taking the hash value of the intermediate node as a query index, querying the intermediate node from the database corresponding to the database identifier, and loading the queried intermediate node in a memory;

and reading a hash value of a node of a next layer linked to the intermediate node and stored in the intermediate node and a database identifier of a database storing the node of the next layer, taking the hash value of the node of the next layer as a query index, querying the node of the next layer from the database corresponding to the database identifier, loading the queried node of the next layer in a memory, and so on until leaf nodes in the logical tree structure are all loaded in the memory.

This specification also provides a block chain data storage apparatus, the apparatus comprising:

the acquisition module is used for acquiring a key-value key value pair of the block chain data to be stored and determining a database for storing the block chain data;

the conversion module is used for converting the key-value key value pairs of the block chain data into a root node, an intermediate node and a leaf node on a logic tree structure; wherein, the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash value of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the target block chain data;

the storage module is used for respectively storing the root node, the middle node and the leaf node into a database; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases.

The present specification further provides a device for updating blockchain data, where key-value key values of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the device comprises:

the determining module is used for determining a root node, a middle node and a leaf node of a key-value key value pair used for storing target block chain data to be updated on the logic tree structure, and determining a database used for storing the updated root node, middle node and leaf node;

the updating module is used for updating the determined leaf node based on the Value of the key-Value key Value pair of the target block chain data, and further writing the hash Value of the updated leaf node and the determined database identifier of the database for storing the updated leaf node into an intermediate node of a previous layer linked with the leaf node after the update of the leaf node is completed so as to update the intermediate node; after the intermediate node is updated, further writing the updated hash value of the intermediate node and the determined database identifier of the database for storing the updated intermediate node into the node at the previous layer linked with the intermediate node, so as to continuously update the node at the previous layer linked with the intermediate node, and so on until the root node on the logic tree structure is updated.

The present specification also provides a device for reading blockchain data, where key-value key values of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the device comprises:

the first reading module is used for reading the hash value of the root node of the logic tree structure and determining a database for storing the root node of the logic tree structure; taking the hash value of the root node as a query index, querying the root node from the database, and loading the queried root node in a memory;

a second reading module, configured to read a hash value of an intermediate node linked to a next layer of the root node and stored in the root node, and a database identifier of a database in which the intermediate node is stored, use the hash value of the intermediate node as a query index, query the intermediate node from the database corresponding to the database identifier, and load the queried intermediate node in a memory;

and the third reading module is used for reading the hash value of the node of the next layer linked to the intermediate node and the database identifier of the database of the next layer stored in the intermediate node, taking the hash value of the node of the next layer as a query index, querying the node of the next layer from the database corresponding to the database identifier, loading the queried node of the next layer in the memory, and so on until all leaf nodes in the logical tree structure are loaded in the memory.

In the above technical solution, on one hand, nodes on a logical tree structure organized based on key-value key values of a blockchain data group are respectively stored in a plurality of databases, so that a performance problem encountered when blockchain data is stored in a single database can be avoided, and the expandability of the database for storing blockchain data is improved.

On the other hand, the data structure of the node on the logical tree structure may include, in addition to the hash value of the node at the next level linked to the node, a database identifier of a database storing the node at the next level; therefore, even if the nodes on the logical tree structure are respectively stored in different databases, the nodes distributed in different databases can still be linked according to the hash value of the next-layer node stored in the node and the corresponding database identifier, so that the nodes distributed in different databases are still logically integrated, and the integrity of the logical tree structure can still be ensured.

Drawings

FIG. 1 is a tree structure diagram of an MPT tree according to an exemplary embodiment

FIG. 2 is a schematic diagram of an example embodiment providing for organizing account status data for individual blockchain accounts in a blockchain into an MPT status tree in the form of key-value key value pairs;

FIG. 3 is a diagram illustrating organization of contract data stored in storage corresponding to a contract account into an MPT storage tree, according to an illustrative embodiment;

FIG. 4 is a tree structure diagram of an FDMT tree provided by an exemplary embodiment;

FIG. 5 is a block diagram of a Tree node provided in an exemplary embodiment;

FIG. 6 is a block diagram of a bucket according to an exemplary embodiment;

FIG. 7 is a flow chart of a method of blockchain data storage provided by an exemplary embodiment;

fig. 8 is a schematic diagram of a tree structure of an MPT tree after being improved on the basis of fig. 1 according to an exemplary embodiment.

Fig. 9 is a schematic diagram of a tree structure of an FDMT tree improved on the basis of fig. 4 according to an exemplary embodiment.

FIG. 10 is a flowchart of a method for updating blockchain data according to an exemplary embodiment;

FIG. 11 is a flowchart of a method for reading blockchain data according to an exemplary embodiment;

FIG. 12 is a schematic diagram of an electronic device according to an exemplary embodiment;

FIG. 13 is a block diagram of a blockchain data storage device provided by an exemplary embodiment;

fig. 14 is a block diagram of a block chain data updating apparatus according to an exemplary embodiment;

fig. 15 is a block diagram of a block chain data reading apparatus according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

In the field of blockchain, an important concept is Account (Account). For various blockchain networks that incorporate intelligent contracts, blockchain accounts can be generally classified into two types:

contract account (contract account): storing the executed intelligent contract code and the value of the state in the intelligent contract code, and usually only calling and activating through an external account;

external account (Externally owned account): that is, an account directly controlled by the user, also referred to as a user account.

The design of the external account and the contract account is actually a mapping of the account address to the account status. The status of an account is typically represented by a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.

In one example, the structure of an account typically includes fields such as Balance, Nonce, Codehash, and Storageroot. Wherein:

a Balance field for maintaining the current account Balance of the account;

a Nonce field for maintaining a number of transactions for the account. The counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;

a Codehash field for maintaining a contract code for the account. In actual practice, only the hash value of the contract code is typically maintained in the Codehash field.

And the Storageoot field is used for maintaining the storage content of the account. For a contract account, a separate persistent storage space is typically allocated for storing the contract data corresponding to the contract account. This separate storage space is often referred to as the account storage of the contract account.

The stored contents of a contract account are typically stored in a data structure constructed as an mpt (media Patricia trie) tree in the form of key-value pairs. An MPT tree is a logical tree structure in the field of blockchains for storing and maintaining blockchain data, and typically includes root nodes, intermediate nodes, and leaf nodes in the tree structure.

In which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage root field typically only maintains the hash value of the root node of the Storage tree. Wherein, for the external account, the field values of the Codehash field and the Storageroot field shown above are both null values.

For most blockchain models, a Merkle tree is typically used; or a logical tree structure such as a Merkle tree variety designed on the basis of the data structure of the Merkle tree to store and maintain data.

For example, the MPT tree is a Merkle tree variant that merges the tree structures of Trie dictionary trees for storing and maintaining blockchain data.

For another example, an fdmt (fixed Depth Merkle tree) tree is also a Merkle tree variation that merges the tree structure of the Trie dictionary tree and is used to store and maintain block chain data.

The following description will be given taking an example in which block chain data is stored using an MPT tree.

In one example, blockchain data that needs to be stored and maintained in the blockchain typically includes account status (state) data, transaction data, and receipt data. Therefore, in practical applications, the above account status data, transaction data and receipt data may be organized into three MPT trees, such as an MPT status tree, an MPT transaction tree and an MPT receipt tree, in the form of key-value key value pairs, and stored and maintained respectively.

In addition to the three MPT trees, the contract data stored in the Storage space corresponding to the contract account is usually constructed as an MTP Storage tree (hereinafter, referred to as a Storage tree). The hash value of the root node of the Storage tree is added to the Storage field in the struct of the contract account corresponding to the Storage tree.

The MPT state tree is an MPT tree which is organized by account state data of all accounts (including external accounts and contract accounts) in a block chain in a key-value key value pair mode.

The MPT transaction tree is an MPT tree which is organized by transaction (transaction) data in a block chain in the form of key-value key value pairs.

The MPT receipt tree is an MPT tree which is organized in a key-value key value pair mode, wherein a transaction (receipt) receipt corresponding to each transaction is generated after the transactions in the block are executed.

The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above are eventually added to the block header of the corresponding block.

The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain. Each time a block chain generates a latest block, the account status of the accounts (which may be external accounts or contract accounts) related to the executed transaction in the block chain is usually changed after the transaction in the latest block is executed.

For example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed. After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.

When a latest block is generated in the block chain and the transaction in the latest block is completed, the account status of some accounts in the block chain changes, and the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has an MPT state tree corresponding to it. The MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.

Referring to fig. 1, fig. 1 is a tree structure diagram of an MPT tree shown in this specification.

It should be noted that the connection relationship of each node in fig. 1 is only schematic.

The MPT tree is a relatively traditional modified Merkle tree variety, and combines the advantages of two tree structures, namely a Merkle tree and a Trie dictionary tree (also called as a prefix tree).

Three types of nodes are typically included in the MPT tree, namely leaf nodes (leaf nodes), extension nodes (extension nodes), and branch nodes (branch nodes). Wherein the root node of the MPT tree may typically be an extension node. The intermediate nodes of the MPT tree may typically be branch nodes or other extended nodes.

The extension node and the branch node may be collectively referred to as a character node, and are used to store a character prefix portion of a character string corresponding to a key (i.e., an account address) of the account status data. For MPT trees, the above character prefix portion is usually referred to as shared character prefixes (shared). The shared character prefix refers to a prefix formed by one or more identical characters possessed by keys (namely, block chain account addresses) of all account state data. The leaf node is used for storing a key-end and Value (specific account status data) of the character string corresponding to the key of the block chain data.

And the extension node is used for storing one or more characters (namely, shared nibbles shown in fig. 1) in the shared character prefix of the account address and a hash value (namely, Next node shown in fig. 1) of a node at the Next layer linked with the extension node.

The branch node comprises 17 slot positions, the first 16 slot positions correspond to 16 possible hexadecimal characters in the key, one character corresponds to one nibble, each slot position in the first 16 slot positions respectively represents one character in a shared character prefix of an account address, and the slot positions are used for filling a hash value of a node at the next layer linked with the branch node. The last slot is a value slot, typically null.

Leaf nodes for storing the character suffix of the account address (i.e., key-end shown in fig. 1), and the value of the account status data (i.e., the structure of the account described above). The character suffix of the account address and the shared character prefix of the account address jointly form a complete account address. The character suffix refers to a suffix composed of the last one or more characters except the shared character prefix of the account address.

Referring to fig. 2, fig. 2 is a schematic diagram illustrating organization of account status data of each blockchain account in a blockchain into an MPT status tree in the form of key-value key value pairs according to the present specification.

Assume that the key-value key value pairs of account status data that need to be organized into an MTP status tree are shown in table 1 below:

TABLE 1

It should be noted that, in table 1, the block chain accounts corresponding to the account addresses in the first three rows are external accounts, and the Codehash and Storage root fields are null values. The block chain account corresponding to the account address in the 4 th row is a contract account, and the Codehash field maintains the hash value of the contract code corresponding to the contract account; the Storage root field maintains a hash value of the root node of the Storage tree of which the Storage contents of the contract account constitute.

Finally, the MPT state tree is organized according to the account state data in the table 1, as shown in FIG. 3.

The MPT state tree is composed of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which serves as a root node).

In fig. 2, the prefix field is a prefix field that the extension node and the leaf node have in common. Different field values of the prefix field may be used to indicate different node types.

For example, the value of the prefix field is 0, which indicates that an extension node includes an even number of nibbles; as previously mentioned, a nibble represents a nibble, consisting of a 4-bit binary, and one nibble may correspond to one character that makes up an account address. The value of the prefix field is 1, and the prefix field represents an expansion node containing odd number of nibbles(s); the value of the prefix field is 2, which represents a leaf node containing an even number of nibbles; the value of the prefix field is 3, which indicates that the leaf node contains an odd number of nibbles(s). And the branch node does not have the prefix field because the branch node is a character node of a parallel single neighbor.

A Shared nib field in the extension node corresponds to a key value of a key value pair contained in the extension node and represents a common character prefix between account addresses; for example, all account addresses in the table above have a common character prefix a 7. The Next Node field is filled with the hash value (hash pointer) of the Next Node.

The fields of the 16-system characters 0-f in the branch nodes correspond to the key values of the key value pairs contained in the branch nodes; if the branch node is an intermediate node of the account address on the search path on the MPT tree, the Value field of the branch node may be null. And the fields 0 to f are used for filling the hash value of the next layer node.

The Key-end in a leaf node, corresponding to the Key value of the Key-value pair contained in that leaf node, represents the last few characters of the account address (the character suffix of the account address). The key values of the nodes on the search path from the root node to the leaf nodes form a complete account address. Filling account state data corresponding to the account address in a Value field of the leaf node; for example, a structure composed of fields such as Balance, Nonce, Code, and storage may be encoded and filled in the Value field of the leaf node.

Referring to fig. 3, fig. 3 is a schematic diagram illustrating organization of contract data stored in a storage space corresponding to a contract account into an MPT storage tree according to this specification.

With continued reference to table 1, the account with the account address "a 77d 397" shown in table 1 is a contract account, and thus the contract data stored in the storage space corresponding to the contract account is organized into a storage tree. The root node of the storage tree is also linked to the leaf node corresponding to the contract account in the MTP state tree shown in fig. 1 based on the hash value of the root node. The hash value S1 of the root node of the storage tree is added to the storage root field in the account status stored in the leaf node corresponding to the contract account in the MTP status tree shown in fig. 1. In this case, the storage tree may be referred to as a subtree extended from the leaf node corresponding to the contract account in the MTP state tree shown in fig. 1.

Assume that the key-value pairs of contract data stored in the storage space of the contract account are as shown in table 2 below:

TABLE 2

It should be noted that the contract data stored in the storage space of the contract account may be in the form of a state variable. When storing, the state variables can be organized into a storage tree as shown in fig. 3 in the form of key-value key value pairs for storage. For example, in one example, a hash value of the account address of the contract account and a storage location of the state variable in the account storage of the contract account may be used as a key, and a value of a variable corresponding to the state variable may be used as a value.

The basic structure of the storage tree shown in fig. 3 is similar to the MTP state tree shown in fig. 2, and is not described in detail in this specification.

Further, either the node on the MPT state tree shown in fig. 2 or the node on the storage tree shown in fig. 3 may be stored in the database in the form of Key-Value Key Value pairs for persistent storage.

For example, the database may be generally stored in a persistent storage medium (such as a storage disk) mounted on the node device. The storage medium is a physical storage corresponding to the database.

A Key in a Key-Value Key Value pair corresponding to a node in the MPT state tree or the storage tree may be a hash Value of data content contained in the node; value in the key Value pair of the node may specifically be data content contained in the node.

When a node in the MPT state tree or the storage tree is stored in the database, a hash Value of data content included in the node may be calculated (that is, the whole node is subjected to hash calculation), the calculated hash Value is used as a Key, the data content included in the node is used as a Value, and a Key-Value Key Value pair is generated. And then storing the generated Key-Value Key Value pair into a database. When a node on the MPT state tree or the storage tree needs to be queried, content addressing can be performed by using a hash value of data content contained in the node as a key.

Referring to fig. 4, fig. 4 is a tree structure diagram of an FDMT tree shown in the present specification.

The above-mentioned FDMT tree is also a Merkle tree variation of the tree structure fused with the Trie dictionary tree.

In practical applications, the blockchain data may also be organized in the form of key-value key value pairs and stored in the database in the form of an FDMT tree.

As shown in fig. 4, in the Tree structure of the FDMT Tree, there may be Tree nodes of the first N layers (3 layers are shown in fig. 4, which is only schematic), and Leaf nodes (i.e., Leaf nodes) of the last layer. Among the Tree nodes of the first N layers, the Tree node of the first layer will be the root node, and the Tree nodes of the other layers except the first layer will be the intermediate nodes.

Unlike the MPT Tree described above, the Tree nodes (i.e., the root node and the middle node) in the first N layers of the FDMT Tree described above adopt a unified data structure.

As shown in fig. 4, the Tree nodes in the first N layers of the FDMT Tree may each include a plurality of blocks respectively representing different characters; the block is the "location" of the character in the key used to store the block chain data. And each block may further comprise a plurality of slots each representing a different character. The slot is also used for storing characters in keys of the block chain data.

For example, fig. 4 shows that each Tree node includes N blocks; each block further comprises N slots. Among the nodes in each layer of the FDMT tree, the nodes may still be linked by filling the nodes in the previous layer with the hash value (hash pointer) of the nodes in the next layer. That is, the nodes in the above-described FDMT tree are linked to the nodes of the upper layer by their own hash values. Correspondingly, the slot may be specifically used to fill a hash value of a next node linked by the current Tree node. The node at the next layer of the Tree node may be the Tree node or a Leaf node.

It should be noted that the link relationship between the nodes in each layer of the FDMT tree shown in fig. 4 is only an exemplary one, and is not a specific limitation on the link relationship between the nodes in each layer of the FDMT tree.

With continued reference to fig. 4, each Tree node on the FDMT Tree shown in fig. 4 may be used to store at least a portion of the characters in the key of the blockchain data.

The character string corresponding to the key of the above block chain data may still include a character prefix and a character suffix. In this case, the Tree node may be used to store the characters in the character prefix of the key of the blockchain data. The leaf node may be configured to store a character suffix of the key of the blockchain data and a Value of the blockchain data.

For each Tree node on the FDMT Tree shown in fig. 4, the actually stored characters may be specifically a character represented by a block in the Tree node (that is, a non-empty block with at least one slot filled with a hash value), and a character string generated by splicing the characters represented by the slots in the block filled with the hash value (that is, the non-empty slots).

It should be noted that, in practical applications, each block in the Tree node may represent only one character. That is, based on the storage format of the Tree node shown in fig. 4, each of the partial characters in the character prefix of the key of the block chain data actually stored by the Tree node is a character string having a length of 2-bit characters.

For example, please refer to fig. 5, fig. 5 is a structural diagram of a Tree node shown in the present specification;

as shown in fig. 5, the Tree node contains 16 blocks representing different 16-ary characters; each block further includes 16 slots each representing a different 16-ary character (only the 16 slots contained in block6 are shown in fig. 5). Assuming that block6 (representing 16-system character 6) in the Tree node is a non-empty block, slot4 (representing 16-system character 4), slot6 (representing 16-system character 6) and slot9 (representing 16-system character 9) in the block are non-empty slots filled with hash values of nodes at the next layer of the Tree node link; the partial characters in the character prefix of the key of the above block chain data stored by the Tree node are 16-ary character strings "64", "66" and "69", respectively.

The number of blocks included in the Tree node and the number of slots included in each block are not particularly limited in this specification. In practical applications, the number of subblocks included in the Tree node may be determined based on the number of types of character elements included in a character string corresponding to the key of the block chain data; and the number of slots contained in the sub-block.

For example, assume that the key corresponding to the blockchain data is a 16-ary character string, and at this time, the number of types of character elements included in the character string corresponding to the key of the blockchain data is 16; the number of blocks contained in the Tree node and the number of slots contained in each block may be 16.

The number of layers of the Tree node included in the FDMT Tree may be a fixed value; in practical applications, the value of N may be an integer greater than or equal to 1. That is, the FDMT Tree may be a Merkle Tree which contains at least one layer of Tree nodes and the number of layers of the Tree nodes is relatively fixed.

For example, in one example, taking the key of the blockchain data as the blockchain account address as an example, it is assumed that the blockchain account addresses supported by the blockchain system are designed such that the first 6-bit address characters may be the same. Then, in this case, since the length of the character stored by the Tree node is a 2-bit character; thus, the above-described FDMT Tree can be designed to have a Tree structure including three levels of Tree nodes.

Further, for the Tree node and Leaf node on the FDMT Tree shown in fig. 4, persistent storage in the form of Key-Value Key Value pairs may also be performed in the database. The Key in the Key-Value Key pair corresponding to the Tree node or the Leaf node in the FDMT Tree may specifically be a hash Value of data content contained in the Tree node or the Leaf node. The Value in the key Value pair of the Tree node or the Leaf node may specifically be data content contained in the Tree node or the Leaf node.

When the Tree node or Leaf node in the FDMT Tree is stored in the database, a hash Value of data content included in the Tree node or Leaf node may be calculated (that is, the whole node is subjected to hash calculation), the calculated hash Value is used as a Key, the data content included in the Tree node or Leaf node is used as a Value, and a Key-Value Key Value pair is generated. And then storing the generated Key-Value Key Value pair into a database. When a node on the FDMT tree needs to be queried, content addressing can be performed by using a hash value of data content contained in the node as a key.

It should be noted that the tree structure of the FDMT tree shown in fig. 4 may be used to store account status data of each blockchain account in a blockchain, and may also be used to store contract data stored in a storage space corresponding to a certain contract account. The FDMT tree used for storing account status data of each blockchain account in the blockchain may be referred to as an FDMT status tree. The FDMT tree used for storing contract data stored in a storage space corresponding to a certain contract account may be referred to as an FDMT storage tree. The root node of the FDMT storage tree may be specifically linked to a leaf node of the FDMT status tree corresponding to the contract account through a hash value of the root node. The hash value of the root node in the FDMT storage tree may also be added to the storage root field in the account state stored in the leaf node corresponding to the contract account in the FDMT state tree, which is not described in detail.

It should be noted that, in both the MPT tree shown in fig. 1 and the FDMT tree shown in fig. 4, the Leaf nodes on the tree structure actually store data, which generally has a larger data capacity than other types of nodes. For example, the value of the blockchain data actually stored by the Leaf node is usually the original content of the blockchain data, and the original content of the blockchain data occupies a larger storage space relative to the character prefix of the blockchain data. Therefore, to ensure that the above Leaf nodes can have a larger data capacity, both the MPT tree shown in fig. 1 and the Leaf nodes on the FDMT tree shown in fig. 4 are typically designed in the form of large data blocks.

The specific format and storage structure of the data block are not particularly limited in this specification.

For example, in practical applications, the leaf node may be in the form of a bucket. The bucket may be a container or a storage space for storing data.

For example, referring to fig. 6, fig. 6 is a structural diagram of a bucket shown in this specification.

As shown in fig. 6, in the above-mentioned bucket data (i.e., the bucket node shown in fig. 6), several data records may be included. Each data record corresponds to a piece of blockchain data, and is used for storing a character suffix (i.e., key-end shown in fig. 6) and a value of a key of the blockchain data. That is, a data record refers to a stored record including the value and the character suffix of the key of the above block chain data.

It should be noted that the structure of the bucket shown in fig. 6 is specifically described as an example of a Leaf node on the FDMT tree shown in fig. 4. In practical application, the structure of the bucker node shown in fig. 6 may also be specifically used as a Leaf node of the MPT tree shown in fig. 1, and is not described in detail in this specification.

In practical applications, since the data size of the blockchain data in the blockchain generally continuously increases, with the continuous increase of the data size of the blockchain data, whether the blockchain data is organized to be stored in the database by the MPT tree shown in fig. 1 or the FDMT tree shown in fig. 4, the database may eventually be subject to performance problems.

For example, when the capacity of blockchain data stored in a database is overloaded, it usually results in a decrease in the read/write performance of the database. Moreover, once a file in the database is damaged, the recovery time is usually very long when the database is recovered.

In view of this, the present specification proposes a technical solution that nodes in a logical tree structure are respectively stored in a plurality of databases without sacrificing the integrity of the logical tree structure.

In implementation, the nodes included in the logical tree structure for storing the blockchain data may be stored in a plurality of databases.

In addition, the data structure of the node on the logical tree structure may be expanded, and the storage content of the node on the logical tree structure may include not only the hash value of the node on the next layer linked to the node, but also the database identifier of the database storing the node on the next layer.

By respectively storing the nodes on the logic tree structure organized by the key-value key values based on the block chain data groups in a plurality of databases, the performance problem caused by storing the block chain data in a single database can be avoided, and the expandability of the database for storing the block chain data is improved.

On the other hand, the data structure of the node on the logical tree structure may include, in addition to the hash value of the node at the next level linked to the node, a database identifier of a database storing the node at the next level; therefore, by this way, even if the nodes on the logical tree structure are respectively stored in different databases, the nodes distributed in different databases can still be linked according to the hash value of the next-level node stored in the node and the corresponding database identifier, so that the nodes distributed in different databases are still logically integrated, thereby still ensuring the integrity of the logical tree structure.

Referring to fig. 7, fig. 7 is a flowchart illustrating a method for storing blockchain data according to an exemplary embodiment. The method is applied to node equipment in a block chain; the method comprises the following steps:

step 702, acquiring a key-value key value pair of block chain data to be stored;

the above-mentioned blockchain data to be stored may specifically include any type of data that needs to be persistently stored in the blockchain. In an embodiment shown, the blockchain data to be stored may specifically include account status data corresponding to blockchain accounts on the blockchain. For example, as described above, in practical applications, the blockchain accounts in the blockchain may generally include an external account and a contract account, and thus the account status data corresponding to the blockchain accounts on the blockchain may specifically include account status data (for example, account balance data) corresponding to the user account and the contract account on the blockchain, and status variable data (for example, status data stored in the intelligent contract) stored in the contract account on the blockchain. In practical applications, the blockchain data to be stored may also include transaction data issued to the blockchain network, and receipt data corresponding to the transaction data generated after the transaction data is executed, and the like.

In an example, when acquiring a key-value key value pair of blockchain data to be stored, a node device in a blockchain may specifically process the blockchain data to be locally processed into the key-value key value pair after acquiring the blockchain data to be stored.

In another example, the step of processing the blockchain data to be stored into key-value key value pairs may also be performed by a third party, and the node device may directly obtain the key-value key value pairs of the blockchain data to be stored, which are processed by the third party, from the third party.

The key in the key-value key value pair of the blockchain data may refer to a primary key of the blockchain data in the database. The primary key may specifically serve as a query index. The value in the key-value key value pair of the blockchain data specifically refers to the data content of the blockchain data.

It should be noted that, for different types of blockchain data, there may be some difference in key in the key-value key pair. For example, if the blockchain data is account status data corresponding to a blockchain account in a blockchain, a key in a key-value key value pair of the account status data may be an account address of the blockchain account. If the blockchain data is transaction data in the blockchain or receipt data corresponding to the transaction data, the transaction data or a key in a key-value key value pair of the receipt data corresponding to the transaction data may be a transaction identifier specifically; for example, in practical applications, the transaction identifier may specifically be a hash value of the transaction, or may also be a transaction ID assigned to the transaction when the transaction is identified.

Step 704, converting the key-value key value pairs of the block chain data into root nodes, intermediate nodes and leaf nodes on a logical tree structure; wherein, the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash value of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the block chain data;

for the key-value key value pair of the block chain data to be stored, the key-value key value pair can be organized into a logical tree structure, and the logical tree structure is stored in a database in the form of nodes on the logical tree structure. The logical tree structure is a tree structure that is logically constructed based on nodes stored in a database and a link relationship between the nodes.

For example, in practical applications, the logical tree structure may specifically include multiple layers of nodes, and the multiple layers of nodes may specifically be stored in the underlying physical storage (such as a disk) that carries the database in units of nodes. When the block chain data stored in the logical tree structure needs to be used, multiple layers of nodes stored in the database may be loaded into the memory, and the logical tree structure is restored in the memory according to the link relationship between the nodes.

In practical applications, the logical tree structure may include a root node, a middle node, and a leaf node. After the node device in the block chain acquires the key-value key value pair of the block chain data to be stored, the node device may convert the key-value key value pair of the block chain data to be stored into the root node, the intermediate node, and the leaf node on the logical tree structure.

For example, in an example, the node device may mount a storage interface or a storage service, and the storage interface or the storage service may be specifically configured to convert a key-value key value pair of blockchain data to be stored into a node on a logical tree structure. After the node device acquires the key-value key value pair of the blockchain data to be stored, the node device can convert the key-value key value pair of the blockchain data to be stored into a root node, a middle node and a leaf node of a logical tree structure by calling the storage interface or the storage service.

The nodes in the logical tree structure can still be linked with the nodes in the previous layer through the hash values of the nodes. The root node and the intermediate node are specifically used for storing at least one character in a key-value key value pair of the block chain data. The leaf node is specifically used for storing the value of the blockchain data (i.e., the specific content of the blockchain data). The number of layers of the intermediate node may be one or more, and is not particularly limited in this specification.

For example, in one example, the key of the above tile chain data may still include a character prefix portion (Shared neighbor) and a character suffix portion (key-end); in this case, the root node and the intermediate nodes may be used to store the characters in the character prefixes described above. The leaf node may be used to store values of the character suffix and the blockchain data.

On one hand, because of the root node and the middle node in the logical tree structure, the characters in the keys of the block chain data can be stored; therefore, the tree structure of the logic has the characteristics of the Trie dictionary tree. On the other hand, the nodes on the logical tree structure can be linked with the nodes on the upper layer through the hash value of the nodes; therefore, the logical tree structure described above also has the characteristics of a Merkle tree. In summary, the logical tree structure described in this specification is actually a Merkle tree variation of a tree structure that merges Trie dictionary trees, similar to an MPT tree or an FDMT tree.

Unlike the conventional logical tree structures such as the conventional MPT tree and the FDMT tree described in the above embodiments, in the present specification, the data structure of the nodes on the logical tree structure can be expanded. The data structure of the node on the tree structure of the logic after the extension may include a field for filling the hash value of the node of the next layer linked to the node, and may further include a field for storing a database identifier of the database of the node of the next layer.

In this way, the nodes on the logical tree structure can be filled with more abundant information, and besides the hash value of the node at the next layer linked to the node can be filled, the database identifier of the database of the node at the next layer can be stored.

In an embodiment, the logical tree structure may still be a Merkle tree with a tree structure of a dictionary tree. For example, in some examples, the logical tree structure may be an MPT tree or an FDMT tree after an improvement that extends the data structure of the nodes.

Referring to fig. 8, fig. 8 is a schematic diagram illustrating a tree structure of an MPT tree after being improved on the basis of fig. 1.

When the logical tree structure is an MPT tree, the root node of the logical tree structure may be an extension node in the MPT tree. The intermediate node of the logical tree structure may be an extension node or a branch node in the MPT tree.

As shown in fig. 8, in the improved MPT tree shown in fig. 8, the next node field in the extension node is further extended into two fields, one of which is used to store the hash value of the node in the next layer linked to the extension node, and the other is used to store the database identifier (i.e., num shown in fig. 8) of the database corresponding to the node in the next layer. The database corresponding to the next node is a database storing the next node.

Each of the branch nodes represents a branch slot of a different character, and may be further extended to two fields. One of the fields is used to store a hash value of a node of a next level linked to the extension node, and the other field is used to store a database identification (i.e., n shown in fig. 8) of a database corresponding to the node of the next level.

For a leaf node of the MPT tree, a database identification field may also be extended for storing the database identification of the database of the next level node linked to the leaf node.

For example, as described above, a leaf node on the MPT tree may specifically adopt the bucket structure shown in fig. 6, and a leaf node on the MPT tree may specifically include several data records, in which case each data record in the leaf node may extend one of the above-mentioned database identification fields.

It should be noted that, when a leaf node is not linked to a root node of another MPT tree, the database identification field in the leaf node may be null. When the leaf node is linked with the root node of another MPT tree, the database identifier field in the leaf node may be used to store a database identifier corresponding to the database storing the root node of the other MPT tree. For example, the MPT tree shown in fig. 8 may be the MPT state tree described above, and the another MPT tree may be specifically the leaf node of the MPT state tree described above and another MPT storage tree linked to the leaf node of the MPT state tree, which is not described again.

Referring to fig. 9, fig. 9 is a schematic diagram of a tree structure of an FDMT tree after being improved on the basis of fig. 4.

When the logical Tree structure is an FDMT Tree, the root node and the intermediate node of the logical Tree structure may be Tree nodes in the FDMT Tree.

As shown in fig. 9, in the improved FDMT Tree shown in fig. 9, each Tree node may still include a plurality of blocks each representing a different character. Each block may still further include a plurality of slots each representing a different character. The slot may be further expanded by a field into two fields, where one field is used to store a hash value of a node of a next layer linked to the Tree node, and the other field is used to store a database identifier (i.e., n shown in fig. 9) of a database corresponding to the node of the next layer. The database corresponding to the next node is a database storing the next node.

For a leaf node of the FDMT tree, a database identification field may also be extended for storing the database identification of the database of the next level node to which the leaf node is linked.

For example, as described above, the leaf node in the FDMT tree may also specifically adopt the bucket data bucket structure shown in fig. 6, and the leaf node in the FDMT tree may also specifically include several data records, in which case, each data record in the leaf node may extend one of the above-mentioned database identification fields.

It should be noted that, when a leaf node is not linked to the root node of another FDMT tree, the database identification field in the leaf node may be null. When the leaf node is linked to a root node of another FDMT tree, the database identification field in the leaf node may be used to store a database identification corresponding to a database storing the root node of the other FDMT tree.

For example, in practical applications, account state data corresponding to a user account and a contract account on a blockchain may be organized into an FDMT state tree, and state variable data stored in each contract account on the FDMT state tree may be organized into an FDMT storage tree. In this case, the FDMT tree shown in fig. 9 may be an FDMT state tree, and the another MPT tree may be specifically a leaf node of the FDMT state tree and another linked FDMT storage tree, which is not described again.

In this specification, in order to avoid using a single database to store blockchain data, a node device in a blockchain may specifically mount a plurality of databases for storing blockchain data. When the node device in the block chain stores the key-value key value pair of the block link data to be stored in the database in the form of the node on the logical tree structure, the node on the logical tree structure may be specifically stored in a plurality of databases.

In this case, in the process of converting the key-value key value pairs of the to-be-stored blockchain data into the root node, the intermediate node, and the leaf node on the logical tree structure, the node device in the blockchain also needs to determine a database of the root node, the intermediate node, and the leaf node corresponding to the key-value key value pairs for storing the blockchain data on the logical tree structure.

The specific manner of determining the databases for storing the root node, the intermediate node, and the leaf nodes is generally determined by a data storage policy adopted when node devices in the blockchain utilize a plurality of databases to store blockchain data, and is not particularly limited in this specification.

In an embodiment shown in the present disclosure, the data storage policy may specifically be a data storage policy that stores a root node, a middle node, and a leaf node, which correspond to the blockchain data in a logical tree structure, in the same database with the blockchain data as a minimum storage unit.

In this case, when determining the databases for storing the root node, the intermediate node, and the leaf node corresponding to the blockchain data in the logical tree structure, the node device in the blockchain may determine the database for storing the blockchain data first, and then further determine the determined database for storing the blockchain data as the database for storing the root node, the intermediate node, and the leaf node.

The method of determining the database for storing the blockchain data is not particularly limited in this specification.

In one implementation shown, the database for storing the blockchain data may be determined based on the block number of the block to which the blockchain data corresponds.

For example, a corresponding block number interval may be set for each of the databases, and each database is only used for storing the block chain data belonging to each block in the corresponding block number interval. In this case, the node devices in the blockchain may respectively maintain a mapping table; the mapping table may specifically include a mapping relationship between a database identifier and a block number interval configured for the database corresponding to the database identifier.

When determining the database for storing the block chain data based on the block number of the block corresponding to the block chain data, the node device in the block chain may query the mapping table, determine a block number interval in which the block number of the block corresponding to the block chain data is located, and then determine the database corresponding to the database identifier having a mapping relationship with the block number interval as the database for storing the block chain data.

In this way, the block chain data corresponding to the blocks belonging to different block number intervals can be mapped to different databases for storage.

It should be noted that, in an example, the mapping table locally maintained by each node device in the blockchain may specifically be the mapping table stored on the blockchain after each node device agrees through the consensus mechanism of the blockchain. By the method, the consistency of the mapping tables maintained by each node device in the block chain can be ensured, and the problem of block chain bifurcation caused by difference of the mapping tables maintained by each node device can be avoided.

Of course, it should be emphasized that, in addition to the above description that the database for storing the blockchain data may be determined based on the block number of the blockchain data, the database for storing the blockchain data may also be determined in other ways; for example, the database for storing the blockchain data may also be determined based on the type of blockchain data, the size of blockchain data, or other factors, which are not listed in this specification.

In an embodiment shown in the present invention, the data storage policy may specifically be a data storage policy that takes a node in the logical tree structure as a minimum storage unit, and respectively stores a root node, a middle node, and a leaf node, which correspond to the blockchain data in the logical tree structure, in different databases.

In this case, when determining the databases for storing the root node, the intermediate node, and the leaf node corresponding to the blockchain data in the logical tree structure, the node devices in the blockchain may specifically determine the databases for different types of nodes, respectively. For example, a corresponding node type may be set for each of the databases, and each database is only used for storing the node corresponding to the node type. In this case, the root node, the intermediate node, and the leaf node corresponding to the blockchain data in the logical tree structure may be stored in different databases. For example, 3 databases may be provided for storing the root node, the intermediate nodes, and the leaf nodes, respectively.

In this specification, after determining the databases of the root node, the intermediate node, and the leaf node corresponding to the key-value key value pair for storing the blockchain data on the logical tree structure, the node devices in the blockchain also need to further fill the database identifiers of the databases determined for storing the nodes into the nodes at the previous layer of the link of the node.

For the leaf node on the logical tree structure, the node on the upper layer linked to the leaf node is usually an intermediate node, and therefore for the leaf node, the intermediate node on the upper layer linked to the leaf node needs to be further filled with the database identifier corresponding to the database for storing the leaf node. For the intermediate node on the above logical tree structure, the node at the upper layer of the link is also usually the intermediate node or the root node, so for the intermediate node, the database identifier corresponding to the database for storing the intermediate node needs to be further filled into the intermediate node at the upper layer of the link of the intermediate node or the root node at the upper layer.

For the root node on the above logical tree structure, there are two general cases as follows:

in one case, if the logical tree structure is a sub-tree extending from a leaf node of another logical tree structure, the node at the upper layer of the root node of the logical tree structure is a leaf node of the other logical tree structure, and therefore in this case, the database identifier of the database for storing the root node of the logical tree structure can be filled into the leaf node of the other logical tree structure.

For example, referring to fig. 8, the logical tree structure is an MPT tree, in which case the logical tree structure can be an MPT state tree, and the another logical tree structure can be an MPT storage tree. For the root node on the MPT state tree, the database identification of the database used to store the root node needs to be further populated into the database identification field of the leaf node linked to it on the MPT storage tree.

In another case, if the logical tree structure is not a sub-tree extending from a leaf node of another logical tree structure, the node at the upper layer of the root node of the logical tree structure is usually the block header of the block corresponding to the logical tree structure, so in this case, the database identifier of the database for storing the root node of the logical tree structure may be filled into the block header of the block corresponding to the logical tree structure.

It should be noted that, in some cases, if the logical tree structure is not a sub-tree extending from a leaf node of another logical tree structure, the database identifier of the database for storing the root node of the logical tree structure may not be filled into the block header of the block corresponding to the logical tree structure.

For example, as mentioned above, if the database for storing the blockchain data is determined based on the block number of the blockchain data, the database for storing the root node in the logical tree structure may be determined based on the block number of the block corresponding to the logical tree structure, and the block header of the block corresponding to the logical tree structure usually contains the block number of the block. In this case, therefore, the database identifier of the database for storing the root node of the logical tree structure may not be filled in the block header of the block corresponding to the logical tree structure, and the block number in the block header may be read subsequently, and the database for storing the root node of the logical tree structure may be determined based on the block number.

In this specification, the process of converting the key-value key value pair of the blockchain data to be stored into the root node, the intermediate node, and the leaf node on the logical tree structure by the node device in the blockchain generally refers to a process of traversing and searching a node corresponding to the blockchain data in an existing logical tree structure from the root node, and then newly adding and inserting a new node in the logical tree structure on the basis of the searched node, so as to completely write the key-value key value pair of the blockchain data into the logical tree structure.

For example, in implementation, the characters stored in each node in the logical tree structure may be matched with the characters in the key of the blockchain data, starting from the root node. If the character stored in a certain node is matched with the character in the key of the block chain data, the node is the node corresponding to the block chain data. After the search is completed, the searched nodes corresponding to the blockchain data may usually only store part of the characters in the keys of the blockchain data, and then, on the basis of the searched nodes, nodes for storing the remaining characters except the part of the characters in the keys of the blockchain data may be newly added and inserted, so as to completely write the key-value key value pairs of the blockchain data into the logical tree structure.

Step 706, storing the root node, the intermediate node and the leaf node in the determined database; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases.

After converting the blockchain data to be stored into the root node, the intermediate node, and the leaf node in the logical tree structure, the root node, the intermediate node, and the leaf node may be respectively stored in the corresponding databases, so as to complete the storage process for the blockchain data.

For example, if the storage policy with the minimum storage unit of the blockchain data as described above is adopted, the root node, the middle node, and the leaf node corresponding to different blockchain data in the logical tree structure may be stored in different databases. The root node, intermediate nodes and leaf nodes corresponding to the same blockchain data are stored in the same database.

If the storage strategy that the node on the logical tree structure is the minimum storage unit is adopted, even the root node, the intermediate node and the leaf node corresponding to the same block chain data are stored in different databases; for example, the root node, the intermediate nodes, and the leaf nodes may be stored in three different databases, respectively, according to the node type.

In the above technical solution, the nodes on the logical tree structure organized based on the key-value key values of the blockchain data group are respectively stored in a plurality of databases, so that the performance problem encountered when blockchain data is stored in a single database can be avoided, and the expandability of the database for storing blockchain data is improved.

In this specification, in addition to organizing key-value key value pairs of blockchain data into a logical tree structure and storing the logical tree structure in a database, in practical applications, when some target blockchain data stored in the logical tree structure is updated, the root node, the intermediate node, and the leaf node corresponding to the target blockchain data in the logical tree structure may also be updated.

The following describes in detail a specific process of updating the nodes on the logical tree structure through a specific embodiment.

Referring to fig. 10, fig. 10 is a flowchart of a method for updating block chain data provided on the basis of the embodiment shown in fig. 7. The method is applied to node equipment in a block chain; the method comprises the following steps:

step 1002, determining a root node, a middle node and a leaf node of a key-value key value pair used for storing target block chain data to be updated on the logic tree structure, and determining a database used for storing the updated root node, the middle node and the leaf node;

the logical tree structure may be a Merkle tree with a tree structure fused with a dictionary tree. For example, the logical tree structure may be specifically an improved MPT tree as shown in fig. 8, or an improved FDMT tree as shown in fig. 9, and is not particularly limited in this embodiment.

The node device in the blockchain may update the root node, the intermediate node, and the leaf node corresponding to the target blockchain data in the logical tree structure stored in the database in synchronization when the target blockchain data stored in the logical tree structure is updated.

For example, in an example, taking the target blockchain data as account status data corresponding to a blockchain account on a blockchain as an example, a user may update an account status corresponding to a blockchain account on the blockchain by issuing a blockchain transaction on the blockchain. After receiving the transaction, the node device in the blockchain can execute the blockchain transaction on the blockchain, and synchronously update the root node, the intermediate node and the leaf node which correspond to the account state data of the blockchain account on the logical tree structure stored in the database.

In the process of updating the root node, the intermediate node and the leaf node of the key-value key value pair used for storing the target blockchain data on the logic tree structure, the node equipment in the blockchain:

on one hand, the root node, the intermediate node and the leaf node of the key-value key value pair used for storing the target blockchain data on the logic tree structure can be determined first.

It should be noted that, when updating the root node, the middle node, and the leaf node of the key-value key value pair used for storing the target blockchain data in the logical tree structure, the node device in the blockchain may specifically adopt a manner of first loading the node in the logical tree structure from the database into the memory, then updating the node corresponding to the key-value key value pair of the target blockchain data in the memory, and then writing the updated node into the database.

In an embodiment shown in the present disclosure, when updating the root node, the middle node, and the leaf node of the key-value key value pair used for storing the target blockchain data in the logical tree structure, the node device in the blockchain may specifically adopt a mode that the node in the logical tree structure is loaded into a memory from the database, then the node corresponding to the key-value key value pair of the target blockchain data is updated in the memory, and then the updated node is written into the database.

In this case, when determining the root node, the intermediate node, and the leaf node of the key-value key value pair used for storing the target blockchain data in the logical tree structure, the node device in the blockchain may first read the node in the logical tree structure from the database, and load the read node into the memory; then, the root node, the intermediate node and the leaf node for storing the target block chain data are further determined from the nodes on the logic tree structure loaded to the memory. The detailed process of reading the nodes in the logical tree structure from the database is not described in detail in this embodiment, please refer to the following embodiments.

Of course, in practical applications, when the node device in the blockchain updates the root node, the middle node, and the leaf node of the key-value key value pair used for storing the target blockchain data in the logical tree structure, a manner of directly updating the relevant nodes stored in the database may be specifically adopted, and is not particularly limited in this specification.

On the other hand, the node device in the blockchain may determine, in addition to the root node, the intermediate node, and the leaf node on the logical tree structure for storing the key-value key value pair of the target blockchain data, a database for storing the updated root node, intermediate node, and leaf node.

The specific manner for determining the databases used for storing the updated root node, intermediate node, and leaf node also generally depends on the data storage policy adopted when the node device in the block chain stores the block chain data by using multiple databases carried on the node device, which is not described in this embodiment again.

For example, as mentioned above, in an illustrated embodiment, if the data storage policy is a policy that, specifically, a storage unit with the minimum blockchain data is used to store the root node, the intermediate node, and the leaf node, which correspond to the blockchain data in the logical tree structure, into the same database, when determining the database for storing the updated root node, intermediate node, and leaf node, the node device in the blockchain may first determine the database for storing the target blockchain data, and then further determine the determined database for storing the target blockchain data as the database for storing the updated root node, intermediate node, and leaf node.

In one implementation manner shown, when determining the database for storing the target blockchain data, the database for storing the target blockchain data may still be determined based on the block number of the block corresponding to the target blockchain data.

When determining the database for storing the target block chain data based on the block number of the block corresponding to the target block chain data, the node device in the block chain may query the mapping table, determine a block number interval in which the block number of the block corresponding to the target block chain data is located, and then determine the database corresponding to the database identifier having a mapping relationship with the block number interval as the database for storing the target block chain data. It should be further noted that, in an example, the mapping table locally maintained by each node device in the blockchain may specifically be the mapping table stored on the blockchain after each node device agrees through a consensus mechanism of the blockchain.

In addition to determining the database for storing the blockchain data based on the block number of the blockchain data, the database for storing the blockchain data may also be determined in other ways; for example, the database for storing the blockchain data may also be determined based on the type of blockchain data, the size of blockchain data, or other factors, and is not listed.

Step 1004, updating the determined leaf node based on Value of the key-Value key Value pair of the target block chain data, and after the update of the leaf node is completed, further writing the hash Value of the updated leaf node and the determined database identifier of the database for storing the updated leaf node into an intermediate node on the previous layer linked to the leaf node, so as to update the intermediate node;

step 1006, after the updating of the intermediate node is completed, further writing the updated hash value of the intermediate node and the determined database identifier of the database for storing the updated intermediate node into a node on the previous layer linked to the intermediate node, so as to continuously update the node on the previous layer linked to the intermediate node, and so on until the updating of the root node on the logical tree structure is completed.

After determining the root node, the intermediate node, and the leaf node of the key-value key value pair used for storing the target blockchain data in the logical tree structure, the node device in the blockchain may sequentially update the leaf node, the intermediate node, and the root node of the key-value key value pair used for storing the target blockchain data in the logical tree structure, starting from the leaf node, according to the link relationship between the nodes.

The storage content of the node on the logical tree structure includes not only the hash value of the node at the next layer linked to the node, but also the database identifier of the database storing the node at the next layer. Therefore, the process of updating the determined root node, intermediate node and leaf node is a process of filling the hash of the next-layer node linked with the root node, intermediate node and leaf node to the database identifier of the database for storing the updated next-layer node.

In an implementation shown in the above, for example, a data update method is used in which a node device of a blockchain loads a node in the logical tree structure from a database into a memory, then updates a node corresponding to a key-Value key Value pair of the target blockchain data in the memory, and writes the updated node into the database, in this case, after the node device in the blockchain determines a root node, a middle node, and a leaf node for storing the target blockchain data from the nodes in the logical tree structure loaded into the memory, the determined leaf node may be updated based on Value of the key-Value key Value pair of the target blockchain data, and after the leaf node is updated, a hash Value of the leaf node and a database identifier of a database for storing the updated leaf node determined before are further written into a higher-level database of the leaf link And the intermediate node is used for updating the intermediate node.

After the intermediate node is updated, the updated hash value of the intermediate node and the database identifier of the database for storing the updated intermediate node, which is determined before, may be further written into the node on the previous layer linked to the intermediate node, so as to update the node on the previous layer linked to the intermediate node, and so on, until the root node in the logical tree structure is updated.

In this embodiment, after the root node in the logical tree structure is updated:

in one aspect, the node device in the blockchain may store the updated root node, intermediate node, and leaf node into the databases determined for the root node, intermediate node, and leaf node, respectively, in response to an instruction to store the updated root node, intermediate node, and leaf node in the databases. For example, in an example, the instruction may specifically be a commit instruction that writes the updated root node, intermediate node, and leaf node stored in the memory into the database.

On the other hand, the node device in the block chain may also fill the hash value of the updated root node in the logical tree structure to the node of the previous layer linked thereto.

For example, if the logical tree structure is a sub-tree extended from a leaf node of another logical tree structure, the node at the upper layer linked by the updated root node on the logical tree structure is the leaf node of the another logical tree structure. In this case, the updated hash value of the root node in the tree structure of the edit can be filled into the leaf nodes of another logical tree structure linked to the root node of the logical tree structure.

If the logical tree structure is not a sub-tree extended from a leaf node of another logical tree structure, the node at the upper layer linked with the updated root node in the logical tree structure is the block head of the block corresponding to the logical tree structure. In this case, the updated hash value of the root node in the edited tree structure may be filled in the block header of the block corresponding to the logical tree structure. For example, if the logical tree structure is the MPT state tree corresponding to the 100 th block, the hash value of the root node of the MPT state tree may be filled in the block header of the 100 th block.

In the above embodiment, when a node on the above logical tree structure is updated, in addition to the hash value of the node needs to be filled into the node on the previous layer linked to the node, the database identifier of the database for storing the node may also be filled into the node on the previous layer linked to the node. Therefore, by this way, even if the nodes on the logical tree structure are respectively stored in different databases, the nodes distributed in different databases can still be linked according to the hash value of the next-level node stored in the node and the corresponding database identifier, so that the nodes distributed in different databases are still logically integrated, thereby still ensuring the integrity of the logical tree structure.

In this specification, as described above, when a certain target blockchain data stored in the logical tree structure is updated and a root node, a middle node, and a leaf node corresponding to the target blockchain data in the logical tree structure are updated, the nodes in the logical tree structure may be loaded from the database into the memory, the nodes corresponding to the key-value key values of the target blockchain data may be updated in the memory, and the updated nodes may be written into the database.

The following describes in detail a detailed process of reading a node on the above logical tree structure from a database and loading the node into a memory mounted on a node device in a block chain, by using a specific embodiment.

Referring to fig. 11, fig. 11 is a flowchart of a method for reading block chain data according to the embodiment shown in fig. 7 and fig. 10. The method is applied to node equipment in a block chain; the method comprises the following steps:

step 1102, reading a hash value of a root node of the logical tree structure, and determining a database for storing the root node of the logical tree structure; taking the hash value of the root node as a query index, querying the root node from the database, and loading the queried root node in a memory;

the logical tree structure may still be a Merkle tree with a tree structure fused with a dictionary tree. For example, the logical tree structure may be specifically an improved MPT tree as shown in fig. 8, or an improved FDMT tree as shown in fig. 9, and is not particularly limited in this embodiment.

When reading the nodes in the logical tree structure from the database, the node device in the block chain may specifically start from the root node of the logical tree structure, and then sequentially read the root node, the intermediate nodes, and the leaf nodes in the logical tree structure according to the link relationship among the nodes.

When reading the root node in the logical tree structure, the node device in the block chain may first read the hash value of the root node.

In one embodiment, if the logical tree structure is a sub-tree extending from a leaf node of another logical tree structure, as mentioned above, the hash value of the root node of the logical tree structure is usually filled in the leaf node of another logical tree structure linked by the root node. In this case, a node device in a blockchain may read the hash value of a root node of the logical tree structure from another logical tree structure leaf node linked to the root node.

In one embodiment, if the logical tree structure is not a sub-tree extending from a leaf node of another logical tree structure, as mentioned above, the hash value of the root node of the logical tree structure is usually filled in the block header of the block corresponding to the logical tree structure. In this case, the node device in the block chain may read the hash value of the root node from the block header of the block corresponding to the logical tree structure.

After reading the hash value of the root node of the logical tree structure, the node device in the block chain may further determine a database for storing the root node.

In one embodiment, if the logical tree structure is a sub-tree extending from a leaf node of another logical tree structure, as described above, the database identifier of the database storing the root node of the logical tree structure is typically populated at the leaf node of the other logical tree structure linked to the root node. In this case, the node device in the blockchain may read the database identification of the database for storing the root node of the logical tree structure from the leaf node of the other logical tree structure linked to the root node of the logical tree structure, and determine the database for storing the root node of the logical tree structure based on the read database identification.

In the illustrated embodiment, if the logical tree structure is not a sub-tree extending from a leaf node of another logical tree structure, the following two cases can be generally included in determining the database for storing the root node of the logical tree structure:

in one case, if the database identifier of the database for storing the root node of the logical tree structure is pre-populated into the block header of the block corresponding to the logical tree structure, the database identifier of the database for storing the root node of the logical tree structure may be read from the block header of the block, and the database for storing the root node of the logical tree structure may be determined based on the read database identifier.

In another case, if a manner is adopted for determining the database for storing the blockchain data based on the block number of the blockchain data, at this time, the database identifier of the database for storing the root node of the logical tree structure is not pre-filled in the block header of the block corresponding to the logical tree structure, the block number may be read from the block header of the block, and the database for storing the root node of the logical tree structure may be determined based on the read block number.

When determining the database for storing the root node in the logical tree structure based on the block number, the node device in the block chain may query the mapping table, determine the block number interval in which the block number is located, and then determine the database corresponding to the database identifier having a mapping relationship with the block number interval as the database for storing the root node in the logical tree structure. It should be noted that, in an example, the mapping table locally maintained by each node device in the blockchain may specifically be the mapping table stored on the blockchain after each node device agrees through a consensus mechanism of the blockchain.

After reading the hash value of the root node of the logical tree structure and further determining the database for storing the root node, the node device in the block chain may use the hash value of the root node as a query index, query the root node from the database, and then load the queried root node into the memory.

Step 1104, reading a hash value of an intermediate node linked to a next layer of the root node and stored in the root node and a database identifier of a database storing the intermediate node, taking the hash value of the intermediate node as a query index, querying the intermediate node from the database corresponding to the database identifier, and loading the queried intermediate node in a memory;

step 1106, reading the hash value of the node of the next layer linked to the intermediate node and the database identifier of the database storing the node of the next layer stored in the intermediate node, taking the hash value of the node of the next layer as a query index, querying the node of the next layer from the database corresponding to the database identifier, loading the queried node of the next layer in the memory, and so on until all the leaf nodes in the logical tree structure are loaded in the memory.

After the node device in the block chain loads the root node of the logical tree structure into the memory, the node device may continue to read the hash value of the intermediate node in the next layer linked to the root node, which is stored in the root node, and the database identifier of the database storing the intermediate node, and then may use the hash value of the intermediate node as a query index, query the intermediate node from the database corresponding to the database identifier, and load the queried intermediate node into the memory.

After the node device in the block chain loads the intermediate node linked to the root node into the memory, the node device may continue to read the hash value of the node linked to the next intermediate layer stored in the intermediate node and store the database identifier of the database of the node of the next layer, and then may use the hash value of the node of the next layer as a query index, query the node of the next layer from the database corresponding to the database identifier, and load the queried node of the next layer into the memory. And for the next node loaded into the memory, the same action as before can be continuously executed, and the nodes linked to the lower layer of the next node are continuously loaded into the memory, and so on, until all the leaf nodes of the logic tree structure are loaded into the memory.

After all the nodes in the logical tree structure are loaded into the memory, the node devices in the block chain can operate the nodes in the logical tree structure in the memory. The operation type of the operation performed on the node in the logical tree structure in the memory is not particularly limited in this embodiment. For example, in one example, the nodes in the logical tree structure may be modified and updated in the memory, and then the modified and updated nodes are rewritten into the database.

In the above embodiment, since the data structure of the node on the logical tree structure may include, in addition to the hash value of the node at the next layer linked to the node, a database identifier of the database storing the node at the next layer; therefore, by this way, even if the nodes on the logical tree structure are respectively stored in different databases, the nodes distributed in different databases can still be linked according to the hash value of the next-layer node stored in the node and the corresponding database identifier, and the nodes are uniformly loaded into the memory to be linked, so that the nodes distributed in different databases are still logically integrated, and the integrity of the logical tree structure can still be ensured.

Corresponding to the method embodiment, the application also provides an embodiment of the device.

Embodiments of the apparatus of the present description may be applied to electronic devices. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

From a hardware aspect, as shown in fig. 12, the hardware structure diagram of the electronic device in which the apparatus of this specification is located is shown in fig. 12, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 12, the electronic device in which the apparatus is located in the embodiment may also include other hardware according to an actual function of the electronic device, which is not described again.

Fig. 13 is a block diagram of a blockchain data storage device shown in an exemplary embodiment of the present description.

Referring to fig. 13, the block chain data storage apparatus 1300 can be applied to the electronic device shown in fig. 12, and the apparatus 130 includes:

the obtaining module 1301 obtains a key-value key value pair of the block chain data to be stored;

a conversion module 1302, configured to convert the key-value key value pairs of the blockchain data into a root node, a middle node, and a leaf node on a logical tree structure; wherein, the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash value of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the block chain data;

the storage module 1303 is used for respectively storing the root node, the middle node and the leaf node into a database; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases.

Fig. 14 is a block diagram illustrating a block chain data updating apparatus according to an exemplary embodiment of the present disclosure.

Referring to fig. 14, the blockchain data updating apparatus 140 may also be applied to the electronic device shown in fig. 12, wherein the key-value key value pairs of the blockchain data are stored in the database in the form of nodes on a logical tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the apparatus 140 comprises:

a determining module 1401, configured to determine a root node, an intermediate node, and a leaf node on the logical tree structure, where the root node, the intermediate node, and the leaf node are used to store a key-value key value pair of target block chain data to be updated, and determine a database used to store the updated root node, intermediate node, and leaf node;

an updating module 1402, configured to update the determined leaf node based on Value of the key-Value key Value pair of the target block chain data, and after the update of the leaf node is completed, further write the hash Value of the updated leaf node and the determined database identifier of the database for storing the updated leaf node into an intermediate node on a previous layer linked to the leaf node, so as to update the intermediate node; after the intermediate node is updated, further writing the updated hash value of the intermediate node and the determined database identifier for storing the updated database of the intermediate node into the node on the previous layer linked to the intermediate node, so as to continuously update the node on the previous layer linked to the intermediate node, and so on until the root node on the logical tree structure is updated.

Fig. 15 is a block diagram of a block chain data reading apparatus according to an exemplary embodiment of the present disclosure.

Referring to fig. 15, the blockchain data reading apparatus 1500 may also be applied to the electronic device shown in fig. 12, where key-value key value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the nodes on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the apparatus 1500 comprises:

a first reading module 1501, configured to read a hash value of a root node of the logical tree structure, and determine a database for storing the root node of the logical tree structure; taking the hash value of the root node as a query index, querying the root node from the database, and loading the queried root node in a memory;

a second reading module 1502, configured to read a hash value of an intermediate node in a next layer linked to the root node and a database identifier of a database storing the intermediate node, where the hash value of the intermediate node is stored in the root node, query the intermediate node from the database corresponding to the database identifier by using the hash value of the intermediate node as a query index, and load the queried intermediate node in a memory;

the third reading module 1503 reads the hash value of the node of the next layer linked to the intermediate node and stored in the intermediate node and the database identifier of the database stored in the next layer, uses the hash value of the node of the next layer as a query index, queries the node of the next layer from the database corresponding to the database identifier, loads the queried node of the next layer in the memory, and so on until all leaf nodes in the logical tree structure are loaded in the memory.

The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if," as used herein, may be interpreted as "at … …" or "when … …" or "in response to a determination," depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A method of blockchain data storage, the method comprising:

acquiring a key-value key value pair of block chain data to be stored;

converting the key-value key value pairs of the blockchain data into root nodes, intermediate nodes and leaf nodes on a logical tree structure; wherein, the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash value of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the block chain data;

respectively storing the root node, the intermediate nodes and the leaf nodes into a database; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases.

2. The method of claim 1, further comprising:

determining a database for storing the blockchain data;

and determining the determined database for storing the blockchain data as the database of the root node, the intermediate node and the leaf node corresponding to the key-value key value pair for storing the blockchain data on the logical tree structure.

3. The method of claim 2, determining a database for storing the blockchain data, comprising:

and determining a database for storing the block chain data based on the block number of the block corresponding to the block chain data.

4. The method of claim 3, wherein node devices in the blockchain maintain mapping tables, respectively; the mapping table comprises a mapping relation between a database identifier and a block number interval configured for the database identifier;

determining a database for storing the blockchain data based on the block number of the block corresponding to the blockchain data, including:

and inquiring the mapping table, determining a block number interval where the block number of the block corresponding to the block chain data is located, and determining a database corresponding to the database identifier with the mapping relation with the block number interval as a database for storing the block chain data.

5. The method of claim 4, wherein the mapping table is stored on the blockchain after passing through consensus of node devices in the blockchain.

6. The method of claim 1, wherein the logical tree structure comprises a Merkle tree that merges a tree structure of a dictionary tree.

7. The method of claim 6, the logical tree structure comprising an MPT tree; the root node comprises an extension node on the MPT tree; the intermediate node comprises the extension node or branch node on the MPT tree;

the next node field in the extended node is used for storing a hash value of a node of a next layer linked to the extended node and a database identifier of a database storing the node of the next layer;

each branch slot position in the branch nodes represents different characters and is used for storing the hash of the node at the next layer linked to the branch node and the database identification of the database storing the node at the next layer;

the leaf nodes on the MPT tree comprise newly added database identification fields; the database identifier field is used for storing the database identifier of the database storing the root node of another MPT tree when the Value of the blockchain data stored in the leaf node is linked with the root node of the another MPT tree.

8. The method of claim 7, the logical tree structure comprising an FDMT tree;

the root node and the middle node on the FDMT tree respectively comprise a plurality of positions of characters in a character string corresponding to keys of key-value key value pairs used for storing the block chain data; each position comprises a plurality of slot positions used for storing characters in character strings corresponding to keys of the key-value key value pairs of the block chain data; the slot position is used for storing a hash of a node of a next layer linked to the node and a database identifier of a database storing the node of the next layer;

the leaf nodes on the FDMT tree comprise newly added database identification fields; the database identification field is used for storing the database identification of the database storing the root node of another FDMT tree when the Value of the blockchain data stored in the leaf node links the root node of the another FDMT tree.

9. The method of claim 1, the blockchain data comprising account status data corresponding to blockchain accounts on the blockchain.

10. The method of claim 9, the account status data comprising:

account status data corresponding to user accounts and contract accounts on the blockchain;

state variable data stored in a contract account on the blockchain.

11. A block chain data updating method, the key-value key value pair of the block chain data is stored in a database in the form of nodes on a logic tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the method comprises the following steps:

determining a root node, a middle node and a leaf node of a key-value key value pair used for storing target block chain data to be updated on the logic tree structure, and determining a database used for storing the updated root node, the middle node and the leaf node;

12. The method of claim 11, further comprising:

filling the updated hash value of the root node on the logic tree structure into a block head of a block corresponding to the target block chain data in response to the completion of the update of the root node on the logic tree structure;

or, filling the updated hash value of the root node of the logical tree structure into a leaf node of another logical tree structure linked with the root node of the logical tree structure.

13. The method of claim 11, prior to determining a root node, an intermediate node, and a leaf node of the logical tree structure for storing the key-value pair of the target blockchain data, further comprising:

reading nodes on the logic tree structure from the database, and loading the read nodes into a memory;

determining a root node, a middle node and a leaf node of the key-value key value pair used for storing the target block chain data on the logic tree structure, including:

and determining a root node, a middle node and a leaf node for storing the target block chain data from the nodes on the logic tree structure loaded to the memory.

14. The method of claim 13, further comprising:

and responding to an instruction for storing the updated root node, the intermediate node and the leaf node in a database, and respectively storing the updated root node, the intermediate node and the leaf node stored in the memory into the corresponding databases.

15. The method of claim 13, determining a database for storing the updated root, intermediate, and leaf nodes, comprising:

determining a database for storing the target blockchain data;

and determining the determined database for storing the block chain data as a database for storing the updated root node, intermediate nodes and leaf nodes.

16. The method of claim 15, determining a database for storing the target blockchain data, comprising:

and determining a database for storing the target block chain data based on the block number of the block corresponding to the target block chain data.

17. The method of claim 16, wherein node devices in the blockchain maintain mapping tables, respectively; the mapping table comprises a mapping relation between a database identifier and a block number interval configured for the database identifier;

determining a database for storing target block chain data based on the block number of the block corresponding to the target block chain data, including:

and querying the mapping table, determining a block number interval where the block number of the block corresponding to the target block chain data is located, and determining a database corresponding to the database identifier having a mapping relation with the block number interval as a database for storing the target block chain data.

18. The method of claim 17, wherein the mapping table is stored on the blockchain after passing through consensus by each node device in the blockchain.

19. The method of claim 11, wherein the logical tree structure comprises a Merkle tree that merges a tree structure of a dictionary tree.

20. The method of claim 19, the logical tree structure comprising an MPT tree; the root node comprises an extension node on the MPT tree; the intermediate node comprises the extension node or branch node on the MPT tree;

the leaf nodes on the MPT tree comprise newly added database identification fields; the database identifier field is used for storing the database identifier of the database storing the root node of another MPT tree when the Value of the blockchain data stored in the leaf node links the root node of the other MPT tree.

21. The method of claim 19, the logical tree structure comprising an FDMT tree;

22. The method of claim 11, the target blockchain data comprising account status data corresponding to blockchain accounts on the blockchain.

23. The method of claim 22, the account status data comprising:

state variable data stored in a contract account on the blockchain.

24. A block chain data reading method is characterized in that key-value key value pairs of block chain data are stored in a database in the form of nodes on a logic tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the method comprises the following steps:

25. The method of claim 24, wherein the first and second light sources are selected from the group consisting of,

reading a hash value of a root node of the logical tree structure, including:

reading a hash value of a root node of the logical tree structure from a leaf node of another logical tree structure linked to the root node of the logical tree structure;

or reading a hash value of a root node of the logical tree structure from a block header of a block corresponding to the logical tree structure;

determining a database for storing a root node of a tree structure of the logic, comprising:

reading a database identifier of a database for storing a root node of the logical tree structure from a leaf node of another logical tree structure linked to the root node of the logical tree structure, and determining the database for storing the root node of the logical tree structure based on the read database identifier;

or reading a block number corresponding to the block from a block header of the block corresponding to the logical tree structure, and determining a database for storing a root node of the logical tree structure based on the block number.

26. The method of claim 25, wherein node devices in the blockchain maintain mapping tables, respectively; the mapping table comprises a mapping relation between a database identifier and a block number interval configured for the database identifier;

determining a database for storing a root node of the logical tree structure based on the block number, comprising:

and inquiring the mapping table, determining a block number interval where the block number is located, and determining a database corresponding to a database identifier with a mapping relation with the block number interval as a database for storing the root node of the logical tree structure.

27. The method of claim 26, wherein the mapping table is stored on the blockchain after passing through consensus by each node device in the blockchain.

28. The method of claim 27, wherein the logical tree structure comprises a Merkle tree that merges a tree structure of a trie.

29. The method of claim 28, the logical tree structure comprising an MPT tree; the root node comprises an extension node on the MPT tree; the intermediate node comprises the extension node or branch node on the MPT tree;

the next node field in the extended node is used for storing a hash value of a node of a next layer linked to the extended node and storing a database identifier of a database of the node of the next layer;

30. The method of claim 28, the logical tree structure comprising an FDMT tree;

31. The method of claim 28, the blockchain data comprising account status data corresponding to blockchain accounts on the blockchain.

32. The method of claim 31, the account status data comprising:

state variable data stored in a contract account on the blockchain.

33. A block chain data storage device, the device comprising:

the acquisition module is used for acquiring a key-value key value pair of the block chain data to be stored;

the conversion module is used for converting the key-value key value pairs of the block chain data into root nodes, intermediate nodes and leaf nodes on a logical tree structure; wherein, the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash value of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the root node and the intermediate node are used for storing characters in keys of the key-value key value pairs corresponding to the block chain data; the leaf node is used for storing the value of the key-value key value pair corresponding to the block chain data;

34. A block chain data updating device is characterized in that key-value key value pairs of block chain data are stored in a database in the form of nodes on a logic tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the node on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the device comprises:

the updating module is used for updating the determined leaf node based on the Value of the key-Value key Value pair of the target block chain data, and further writing the hash Value of the updated leaf node and the determined database identifier of the database for storing the updated leaf node into an intermediate node of a previous layer linked with the leaf node after the update of the leaf node is completed so as to update the intermediate node; after the intermediate node is updated, further writing the updated hash value of the intermediate node and the determined database identifier for storing the updated database of the intermediate node into the node on the previous layer linked to the intermediate node, so as to continuously update the node on the previous layer linked to the intermediate node, and so on until the root node on the logical tree structure is updated.

35. A device for reading blockchain data, wherein key-value key value pairs of the blockchain data are stored in a database in the form of nodes on a logic tree structure; the logic tree structure comprises a root node, a middle node and a leaf node which are used for storing block chain data; wherein, the nodes on the logic tree structure are at least respectively stored in a plurality of databases; the nodes on the logic tree structure are linked to the nodes on the upper layer through the hash values of the nodes; the storage content of the nodes on the logic tree structure comprises a hash value of a node at the next layer linked to the node and a database identifier of a database storing the node at the next layer; the device comprises:

36. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the steps of the method of any one of claims 1-32 by executing the executable instructions.

37. A computer-readable storage medium having stored thereon computer instructions, which when executed by a processor, perform the steps of the method according to any one of claims 1-32.