WO2022233274A1

WO2022233274A1 - Block chain data storage method and apparatus, and electronic device

Info

Publication number: WO2022233274A1
Application number: PCT/CN2022/090294
Authority: WO
Inventors: 陆钟豪; 卓海振; 俞本权
Original assignee: 支付宝(杭州)信息技术有限公司; 蚂蚁区块链科技(上海)有限公司
Priority date: 2021-05-07
Filing date: 2022-04-29
Publication date: 2022-11-10
Also published as: CN112988910A; CN112988910B

Abstract

A block chain data storage method and apparatus, and an electronic device. The method comprises: obtaining key-value pairs of blockchain data to be stored; converting the key-value pairs of said blockchain data into a root node, an intermediate node, and a leaf node on a logical tree structure, the root node and the intermediate node comprising a plurality of positions for storing characters in keys of the blockchain data, the positions each comprising a plurality of slots for storing characters in the keys of the blockchain data, and the slots being used for storing hash values of the next layer of nodes linked to the corresponding node; and storing in a database the key-value pairs of the root node, the intermediate node, and the leaf node, in the key-value pairs of the leaf node, the intermediate node, and the root node, values being the storage content of the nodes, and the keys being the hash values of the storage content of the nodes.

Description

Blockchain data storage method and device, electronic device

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and apparatus for storing blockchain data, and electronic equipment.

Background technique

Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several node devices jointly participate in "bookkeeping" and jointly store and maintain a complete distributed database.

For the node device of the blockchain, the blockchain data that needs to be stored and maintained usually includes the block data and the account status data corresponding to the blockchain account in the blockchain; and the block data can further include the block data. Block header data, block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, etc.

When the node device of the blockchain stores the various blockchain data shown above, the various blockchain data can usually be organized into a Merkle tree in the form of key-value pairs and stored in the database. When it is necessary to query the above-mentioned various blockchain data stored in the node device, the data can be efficiently queried by traversing the above-mentioned Merkle tree by using the key of the above-mentioned various blockchain data as a query index.

SUMMARY OF THE INVENTION

This specification proposes a method for storing data in a blockchain, including: obtaining a key-value key-value pair of the blockchain data to be stored; converting the key-value key-value pair of the blockchain data to be stored The root node, the intermediate node and the leaf node on the logical tree structure; the root node and the intermediate node include a plurality of positions for storing the characters in the key of the blockchain data, and each position includes multiple positions. a slot for storing the characters in the key of the blockchain data; the slot is used to store the hash value of the next-layer node linked to the node; the root node, the intermediate node and the leaf node are The key-value key-value pair is stored in the database; in the key-value key-value pair of the leaf node, the intermediate node and the root node, the value is the storage content of the node, and the key is the hash of the storage content of the node value.

This specification also proposes a device for storing data in a blockchain, comprising: an acquisition module, which acquires a key-value pair of blockchain data to be stored; a conversion module, which converts the data of the blockchain data to be stored. The key-value key-value pair is converted into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include a plurality of positions for storing characters in the key of the blockchain data , each position includes a plurality of slots for storing characters in the key of the blockchain data; the slots are used to store the hash value of the next layer node linked to the node; the storage module, the The key-value key-value pairs of the root node, the intermediate node and the leaf node are stored in the database; in the key-value key-value pairs of the leaf node, the intermediate node and the root node, the value is the storage of the node Content, the key is the hash value of the node's storage content.

In the above technical solution, on the one hand, each root node and intermediate node in the logical tree structure include multiple positions representing different characters respectively; and each position further includes multiple slots representing different characters respectively Therefore, through this design, each root node and intermediate node will have a larger data storage capacity and data carrying capacity, so that the root node and intermediate node in the above-mentioned logical tree structure are written into the database. When storing; or, when accessing the root node and intermediate node in the logical tree structure stored in the database, the data storage capacity of the root node and the intermediate node can be compared with the single IO read and write of the storage medium carrying the above database. The capacity of the above-mentioned database is more suitable, so that the IO read and write capabilities of the storage medium carrying the above database can be fully utilized to improve the efficiency of data read and write; moreover, the data storage capacity and data carrying capacity of the nodes on the above-mentioned logical tree structure are improved. It will inevitably lead to the improvement of the overall data storage capacity and data carrying capacity of the above-mentioned logical tree structure, so that more blockchain data can be stored in the above-mentioned logical tree structure; secondly, due to the logical tree structure Each root node and intermediate node in the data structure adopts a unified data structure; for the root node and intermediate node in the logical tree structure, the character length of the character prefix of the key of the actually stored blockchain data will also be It is kept fixed; therefore, through this design, frequent splitting of nodes caused by the fact that the actual length of characters stored in the root node and intermediate nodes is not fixed, so as to ensure that the root node and the root node contained in the logical tree structure are guaranteed. The number of layers of intermediate nodes is always in a relatively stable state; thirdly, due to this design, each root node and intermediate node will have greater data storage capacity and data carrying capacity; and, the above-mentioned logical tree The number of layers of root nodes and intermediate nodes contained in the tree-like structure will be in a relatively stable state; therefore, the improvement of the storage capacity of the root nodes and intermediate nodes and the relative stability of the layers of the root nodes and intermediate nodes, in To some extent, it can be ensured that the root node and intermediate node of the above-mentioned logical tree structure will have fewer layers; thus, the root node and intermediate node have greater data storage capacity and data carrying capacity, and the above logical On the basis that the root node and intermediate nodes of the tree structure have fewer layers, when the system performs a cold start, it is necessary to convert the root nodes of the first N layers of the above logical tree structure from the storage medium carrying the above database. and intermediate nodes are loaded into the memory as data that needs to be read frequently, it can significantly reduce the number of IO reads when the root nodes and intermediate nodes of the first N layers stored in the above storage medium are read into the memory, and the The overall reading time when the root nodes and intermediate nodes of the top N layers of the logical tree structure are loaded into the memory, thereby fundamentally shortening the startup delay when the system is cold started.

Description of drawings

FIG. 1 is a schematic diagram of organizing account state data of a blockchain into an MPT state tree provided by an exemplary embodiment;

2 is a schematic diagram of organizing contract data stored in a storage space corresponding to a contract account into an MPT storage tree provided by an exemplary embodiment;

3 is a flowchart of a method for storing blockchain data provided by an exemplary embodiment;

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

5 is a tree structure diagram of another FDMT tree provided by an exemplary embodiment;

Fig. 6 is the structure diagram of a kind of Tree node provided by an exemplary embodiment;

7 is a structural diagram of a bucket data bucket provided by an exemplary embodiment;

8 is a schematic diagram of setting a node ID for a node on an FDMT tree provided by an exemplary embodiment;

9 is a schematic diagram of writing account status data into an FDMT tree provided by an exemplary embodiment;

10 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

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

Detailed ways

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there can also be a combination of the above-mentioned types, such as private chain + alliance chain, alliance chain + public chain, etc. Among them, the most decentralized is the public chain. Participants who join the public chain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each node can freely join or leave the network and perform related operations.

The private chain is on the contrary, the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for internal use within a specific institution.

The consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; the node joins the network through authorization and forms a stakeholder alliance to jointly maintain the operation of the blockchain.

Based on the basic characteristics of the blockchain, the blockchain is usually composed of several blocks. Timestamps corresponding to the creation time of the blocks are respectively recorded in these blocks, and all blocks form a time-ordered data chain strictly according to the timestamps recorded in the blocks.

For the data generated outside the chain, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain. After the consensus, the node device in the blockchain as the accounting node will package the transaction into the block and store the certificate persistently in the blockchain.

In the field of blockchain, an important concept is Account; in practical applications, accounts can usually be divided into external accounts and contract accounts; external accounts are accounts directly controlled by users, also known as User accounts; while contract accounts are created by users through external accounts and contain contract code accounts (ie, smart contracts).

For an account in the blockchain, a structure is usually used to maintain the account state of the account. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes as well.

In one example, the structure of the account usually includes fields such as Balance, Nonce, Code and Storage. Among them: the Balance field is used to maintain the current account balance of the account; the Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can be processed only once, effectively avoiding replay attacks; The Code field is used to maintain the contract code of the account; in practical applications, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is usually also called the Codehash field.

The Storage field is used to maintain the storage content of the account; for the contract account, an independent persistent storage space is usually allocated to store the contract data stored in the storage space corresponding to the contract account; the independent storage The space is usually referred to as the account storage of the contract account.

The storage content of the contract account is usually stored in the above-mentioned independent storage space in the form of a key-value key-value pair constructed as an MPT (Merkle Patricia Trie) tree data structure. MPT tree is a logical tree structure used to store and maintain blockchain data in the blockchain field. This tree structure usually includes root nodes, intermediate nodes, and leaf nodes.

Among them, the MPT tree constructed based on the storage content of the contract account is also commonly referred to as the Storage tree. The Storage field usually only maintains the hash value of the root node of the Storage tree; therefore, the Storage field is usually also called the Storage Root hash field. Wherein, for the external account, the field values of the Code field and the Storage field shown above are all null values.

For most blockchain models, a Merkle tree is usually used; or a logical tree structure such as a Merkle tree variant based on the data structure of the Merkle tree is used to store and maintain data. For example, the MPT tree is a Merkle tree variant that combines the tree structure of the Trie dictionary tree for storing and maintaining blockchain data.

The following uses the MPT tree to store blockchain data as an example to illustrate; in an example, the blockchain data that needs to be stored and maintained in the blockchain usually includes account state data, transaction data and receipt data ; Therefore, in practical applications, the above account status data, transaction data and receipt data can be organized into MPT state tree (ie world state), MPT transaction tree and MPT receipt tree in the form of key-value pairs. Three MPT trees are stored and maintained separately.

Among them, in addition to the above 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 the Storage tree). The hash value of the root node of the Storage tree will be added to the Storage field in the above structure of the contract account corresponding to the Storage tree.

The MPT state tree is an MPT tree organized by the account state data of all accounts (including external accounts and contract accounts) in the blockchain in the form of key-value pairs; the MPT transaction tree is composed of The transaction data in the block chain is an MPT tree organized in the form of key-value key-value pairs; the MPT receipt tree is the transaction corresponding to each transaction generated after the transaction in the block is executed. ) receipt, an MPT tree organized in the form of key-value pairs.

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

Among them, both the MPT transaction tree and the MPT receipt tree correspond to blocks, that is, each block has its own MPT transaction tree and MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific block, but covers the account state data of all accounts in the blockchain. Each time the blockchain generates a newest block, after the transactions in the latest block are executed, the account status of the relevant accounts (which can be external accounts or contract accounts) of the executed transactions in the blockchain, usually will change accordingly.

For example, when a "transfer transaction" in the block is executed, the balances of the sender's account and the transferer's account related to the "transfer transaction" (that is, the field value of the Balance field of these accounts) are usually also will change accordingly. After the node device executes the transaction in the latest block generated by the blockchain, since the account status in the current blockchain has changed, the node device needs to construct the current account status data based on the current account status data of all accounts in the blockchain. The MPT state tree is used to maintain the latest state of all accounts in the blockchain.

That is, whenever a newest block is generated in the blockchain and the transaction in the latest block is executed, the account status of some accounts in the blockchain changes, and the node device needs to be based on the The latest account status data of all accounts, and rebuild an MPT status tree. In other words, each block in the blockchain has a corresponding MPT state tree; the MPT state tree maintains that after the transaction in the block is executed, all accounts in the blockchain are up-to-date. account status.

Please refer to FIG. 1. FIG. 1 is a schematic diagram of organizing the account status data of each blockchain account in the blockchain into an MPT state tree in the form of key-value pairs.

MPT tree is a more traditional and improved variant of Merkle tree, which combines the advantages of two tree structures of Merkle tree and Trie dictionary tree (also called prefix tree).

There are usually three kinds of nodes in the MPT tree, namely leaf node, extension node and branch node. Wherein, the root node of the MPT tree can usually be an extension node; the middle node of the MPT tree can usually be a branch node or other extension nodes.

The extension nodes and branch nodes may be collectively referred to as character nodes, which are used to store the character prefix part of the character string corresponding to the key (ie the account address) of the account status data; wherein, for the MPT tree, the above character prefix part usually refers to Shared character prefix; the shared character prefix refers to a prefix composed of the same one or more characters that the keys of all account status data (ie, blockchain account addresses) have. The above leaf nodes are used to store the character suffix part of the character string corresponding to the key of the blockchain data and the Value (that is, the specific account status data).

The extension node is used to store one or more characters in the shared character prefix of the account address (that is, the shared nibble shown in Figure 1), and the hash value of the node in the next layer linked to the extension node (that is, the one shown in Figure 1). Next node). Branch node, containing 17 slots, the first 16 slots correspond to the 16 possible hexadecimal characters in the key, one character corresponds to a nibble (nibble), each of the first 16 slots Bits, which respectively represent a character in the shared character prefix of an account address, and these slots are used to fill the hash value of the node of the next layer linked by the branch node. The last slot is the value slot, which is usually an empty value.

The leaf node is used to store the character suffix of the account address (that is, the key-end shown in FIG. 1 ), and the value of the account status data (that is, the structure of the account described above); wherein, the character suffix of the account address and the account address are The shared character prefix of , together forms a complete account address; the character suffix refers to the suffix composed of the last one or more characters except the shared character prefix of the account address.

Assume that the account state data that needs to be organized into an MTP state tree is shown in Table 1 below:

Table 1

Among them, in Table 1, the blockchain account corresponding to the account address in the first three lines is an external account, and the fields of Codehash and Storage root are empty. The blockchain account corresponding to the account address in line 4 is the contract account. The Codehash field maintains the hash value of the contract code corresponding to the contract account; the Storage root field maintains the root node of the Storage tree composed of the storage content of the contract account. hash value. Finally, the MPT state tree is organized according to the account state data in Table 1, as shown in Figure 1; the MPT state tree consists of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which is the extension node as the root). node) composition.

In FIG. 1 , the prefix field is a prefix field shared by the extension node and the leaf node. Different field values of the prefix field can be used to represent different node types. For example, the value of the prefix field is 0, indicating an extension node containing an even number of nibbles; as mentioned above, a nibble represents a nibble, which is composed of 4-bit binary, and a nibble can correspond to a character that constitutes an account address. The value of the prefix field is 1, which means that the extension node contains an odd number of nibble(s); the value of the prefix field is 2, which means that the leaf node contains an even number of nibbles; the value of the prefix field is 3, which means that it contains an odd number of nibbles. (s) leaf nodes.

The branch node, because it is a parallel single nibble character node, does not have the above prefix field.

The Shared nibble field in the extension node corresponds to the key value of the key-value pair contained in the extension node, indicating the common character prefix between account addresses; for example, all account addresses in the above table have a common character prefix a7. The Next Node field is filled with the hash value (hash pointer) of the next node.

The hexadecimal character 0～f field in the branch node corresponds to the key value of the key-value pair contained in the branch node; if the branch node is an intermediate node on the search path of the account address in the MPT tree, the branch node The Value field can be null. The hash value used to fill the next layer of nodes in the 0~f field.

The Key-end in the leaf node corresponds to the key value of the key-value pair contained in the leaf node, and represents the last few characters of the account address (the character suffix of the account address). The key value of each node on the search path from the root node to the leaf node constitutes a complete account address. The Value field of the leaf node is filled with the account status data corresponding to the account address; for example, the structure composed of the fields such as Balance, Nonce, Code, and storage can be encoded, and then filled into the Value field of the leaf node.

Further, the nodes on the MPT state tree shown in Figure 1 are ultimately stored in the database in the form of Key-Value key-value pairs; among them, when the nodes on the MPT state tree are stored in the database, the MPT state The key in the key-value pair of the node on the tree can be the hash value of the data content contained in the node; the value in the key-value pair of the node on the MPT state tree is the data content contained in the node.

When the node on the MPT state tree is stored in the database, the hash value of the data content contained in the node can be calculated (that is, the hash calculation is performed on the entire node), and the calculated hash value can be used as the key. The content of the data is used as value, and a Key-Value key-value pair is generated; then, the generated Key-Value key-value pair is stored in the database.

Because the nodes on the MPT state tree are stored in the form of key-value pairs; among them, the key can be the hash value of the data content contained in the node, and the value can be the data content contained in the node; therefore, when you need to query When a node on the MPT state tree is used, content addressing can usually be performed based on the hash value of the data content contained in the node as a key.

Please refer to FIG. 2, which is a schematic diagram of organizing the contract data stored in the storage space corresponding to the contract account into an MPT storage tree shown in this specification.

Please continue to refer to Table 1. The account whose account address is "a77d397" shown in Table 1 is a contract account, so the contract data stored in the storage space corresponding to the contract account will be organized into a storage tree; among them, the storage tree The hash value S1 of the root node will be added to the storage root field in the leaf node corresponding to the contract account in the MTP state tree shown in Figure 1.

Assume that the contract data stored in the storage space of the contract account is shown in Table 2 below:

Table 2

The contract data stored in the storage space of the contract account can usually be in the form of state variables; when storing, the state variable names can be organized into a storage tree as shown in Figure 2 in the form of key-value pairs for storage .

For example, in one example, the account address of the contract account and the hash value of the storage location of the state variable in the account storage of the contract account can be used as the key, and the variable value corresponding to the state variable can be used as the value.

The basic structure of the storage tree shown in FIG. 2 is similar to the MTP state tree shown in FIG. 1 , and will not be repeated in this specification. As can be seen from the descriptions of Figures 1 and 2 above, based on the tree structure design of the MPT tree, the branch node can store one of the characters in the shared character prefixes of all account addresses; and the extension node can store the shared character prefixes of all account addresses. one or more characters in .

In practical applications, the character length of the shared character prefix of the keys of all data stored in the MPT tree is usually not fixed; moreover, when the newly added data is written to the MPT tree, the characters of the above shared character prefix may be caused The length will also change accordingly; therefore, this may cause the expansion node on the MPT tree to split and split into new branch nodes; that is, the split condition of the nodes on the MPT tree is that the above-mentioned shared character prefix The character length changes; for example, taking the MPT state tree shown in Figure 1 as an example, assuming that the above-mentioned MPT state tree adds an account state data of an account address whose first two characters of the account address are "a8", then the figure The shared character prefix stored in the "Shared nible" field of the extended node as the root node shown in 1 will be changed from "a7" to "a"; according to the splitting conditions of the nodes of the MPT state tree, this is used as the root node. The extension node of , will be split into an extension node with a stored shared character prefixed with "a"; and a branch node with the character "8" occupied.

Once an extended node on the MPT tree is split, the number of node layers in the MPT tree may also change, resulting in an unstable number of nodes in the MPT tree. Because the character length of the shared character prefix of the keys of all the data stored in the above-mentioned MPT tree will frequently change as new data is written into the above-mentioned MPT tree; therefore, according to the node splitting method shown above, there will be This causes frequent splitting of nodes, which in turn affects the data storage efficiency when writing new data to the MPT tree.

In view of this, this specification proposes a new logical tree structure design solution.

During implementation, the above-mentioned logical tree structure may still include a root node, an intermediate node and a leaf node; wherein, the above-mentioned root node and intermediate node are used to store characters in the key of the blockchain data; the above-mentioned leaf node is used for the storage area The value of the blockchain data.

Different from the above-mentioned MPT tree, the above-mentioned root node and intermediate node may include multiple locations for storing characters in the key of blockchain data, and each location may further include multiple locations for storing blockchain data. The slot of the character in the key; the above slot can be used to store the hash value of the next layer node linked to the node.

When storing the blockchain data, the node device in the blockchain can obtain the key-value key-value pair of the blockchain data to be stored, and then convert the blockchain data to be stored into the above-mentioned logical tree structure The root node, the intermediate node and the leaf node on the node; then, the key-value key-value pairs of the above-mentioned root node, the intermediate node and the leaf node are further stored in the database; the above-mentioned leaf node, the intermediate node and the root node are further stored in the database; In the key-value key-value pair, the value can be the storage content of the node, and the key can be the hash value of the storage content of the node.

In the above technical solution, on the one hand, each root node and intermediate node in the logical tree structure include multiple positions representing different characters respectively; and each position further includes multiple positions representing different characters respectively. slot; therefore, through this design, each root node and intermediate node will have a larger data storage capacity and data carrying capacity, so that the root node and intermediate node in the above-mentioned logical tree structure will be written into the database. When storing; or, when accessing the root node and the intermediate node in the logical tree structure stored in the database, the data storage capacity of the root node and the intermediate node can be compared with the single IO read of the storage medium carrying the above-mentioned database. The write capacity is more suitable, so that the IO read and write capabilities of the storage medium carrying the above database can be fully utilized to improve the data read and write efficiency; moreover, the data storage capacity and data carrying capacity of the nodes in the above-mentioned logical tree structure are improved. , it will inevitably lead to the improvement of the overall data storage capacity and data carrying capacity of the above-mentioned logical tree structure, so that more blockchain data can be stored in the above-mentioned logical tree structure; secondly, due to the logical tree structure Each root node and intermediate node in the structure adopts a unified data structure; for the root node and intermediate node in the logical tree structure, the character length of the character prefix of the key of the actually stored blockchain data is also will remain fixed; therefore, through this design, frequent splitting of nodes can be avoided due to the fact that the actual length of characters stored in the root node and intermediate nodes is not fixed, so that the root node contained in the logical tree structure can be guaranteed. and the number of layers of intermediate nodes are always in a relatively stable state; thirdly, due to this design, each root node and intermediate nodes will have larger data storage capacity and data carrying capacity; and, the above logic The number of layers of the root node and intermediate node contained in the tree structure of the tree structure will be in a relatively stable state; therefore, the storage capacity of the root node and the intermediate node is improved and the number of layers of the root node and the intermediate node is relatively stable, To a certain extent, it can be ensured that the root node and intermediate nodes of the above-mentioned logical tree structure will have fewer layers; thus, the root node and intermediate nodes have greater data storage capacity and data carrying capacity, and the above logic On the basis that the root node and intermediate nodes of the tree structure have fewer layers, when the system performs a cold start, it is necessary to transfer the roots of the first N layers of the above logical tree structure from the storage medium carrying the above database. When the nodes and intermediate nodes are loaded into the memory as data that needs to be read frequently, the number of IO reads when the root nodes and intermediate nodes of the top N layers stored in the above storage medium are read into the memory can be significantly reduced, and The overall read time when the root nodes and intermediate nodes of the first N layers of the logical tree structure are loaded into the memory, thereby fundamentally shortening the startup delay when the system is cold-started.

Please refer to FIG. 3 , which is a flowchart of a method for storing blockchain data provided by an exemplary embodiment. The method is applied to a block chain node device; the method includes the following steps: step 302, obtaining a key-value key-value pair of the block chain data to be stored; step 304, storing the block chain data to be stored The key-value key-value pair is converted into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include a plurality of characters used to store the characters in the key of the blockchain data. location, each location includes a plurality of slots for storing characters in the key of the blockchain data; the slots are used to store the hash value of the next-layer node linked to the node; Step 306, The key-value key-value pairs of the root node, the intermediate node and the leaf node are stored in the database; in the key-value key-value pairs of the leaf node, the intermediate node and the root node, the value is the value of the node. Storage content, the key is the hash value of the storage content of the node.

In this specification, in order to avoid frequent splitting of nodes, a logical tree structure with a fixed number of layers of character nodes in the key for storing blockchain data in the first N layers is proposed.

Among them, the so-called logical tree structure means that in the underlying physical storage of the database, there is no physical storage structure completely corresponding to the tree structure, but only the physical data of each node on the above tree structure is stored in the database. and link relationship data between each node, so that the above tree structure can be restored on a logical level based on the physical data and link relationship data of each node stored in the database.

The above-mentioned logical tree-like structure may specifically include a root node, an intermediate node and a leaf node; wherein, the nodes on the above-mentioned logical tree-like structure may be linked with the nodes of the upper layer through their own hash values. The above-mentioned root node and intermediate node are specifically used to store at least one character in the key in the key-value key-value pair of the blockchain data; the above-mentioned leaf nodes are specifically used to store the value of the blockchain data (that is, the blockchain data specific content). The number of layers of the intermediate nodes may be one or more layers, and is not particularly limited in this specification.

For example, in an example, the key of the above blockchain data can still include a character prefix part (Shared nibble) and a character suffix part (key-end); in this case, the root node and intermediate nodes can be used for storage The characters in the above character prefixes; and the above leaf nodes can be used to store the above character suffixes and the value of blockchain data.

On the one hand, since the root node and intermediate nodes in the above-mentioned logical tree structure can store the characters in the key of the blockchain data; therefore, the above-mentioned logical tree structure has the characteristics of Trie dictionary tree; on the other hand, the above-mentioned The nodes on the logical tree structure can be linked with the nodes of the upper layer through their own hash values; therefore, the above logical tree structure also has the characteristics of Merkle tree. To sum up, the logical tree structure described in this specification is actually a Merkle tree variant similar to the MPT tree that incorporates the tree structure of the Trie dictionary tree.

Please refer to Fig. 4, Fig. 4 is a tree structure diagram of a FDMT (Fixed Depth Merkle Tree) tree shown in this specification. The above FDMT tree is a Merkle tree variant incorporating the tree structure of the Trie dictionary tree.

As shown in FIG. 4 , in the tree structure of the FDMT tree shown in this specification, it includes the Tree nodes of the first N layers (the three layers shown in FIG. 4 are only illustrative), and the Leaf of the last layer. node (ie leaf node). Among them, in the Tree node of the first N layers, the first layer is the Tree node as the root node, and the other layers are the Tree node as the intermediate node.

Wherein, unlike the MPT tree described above, each Tree node (that is, the root node and the intermediate node) in the first N layers of the above-mentioned FDMT tree will adopt a unified data structure, so that each Tree node in the first N layers of the above-mentioned FDMT tree will be , node splitting can no longer occur because the length of stored characters changes due to newly written data.

As shown in Figure 4, the tree nodes of the first N layers on the above-mentioned FDMT tree may include multiple blocks representing different characters respectively; the above-mentioned blocks are the "positions" of the characters in the key used to store the blockchain data. And each block may further include a plurality of slots representing different characters; the above slots are also used to store the characters in the key of the blockchain data.

For example, Figure 4 shows that each Tree node includes N blocks; each block further includes N slots. Wherein, among the nodes of each layer on the above-mentioned FDMT tree, the method of filling the hash value (hash pointer) of the node of the next layer in the node of the upper layer can still be used to carry out the link between the nodes. That is, the nodes in the above-mentioned FDMT tree are linked to the nodes of the upper layer through their own hash values. Correspondingly, the above slot can be specifically used to fill the hash value of the next layer node linked by the current Tree node. The next-level node of the Tree node can still be a Tree node or a Leaf node.

Among them, in practical applications, when the hash value filled in any slot in any block in the tree node on the above FDMT tree is updated, it is usually necessary to recalculate the hash value of the tree node, and according to the calculated hash value The hash value is re-linked with the node in the previous layer.

When calculating the hash value of the tree node, it is usually necessary to use all the data filled in the tree node as calculation parameters for hash calculation; therefore, when the tree node adopts the data structure shown in Figure 4, if necessary To calculate the hash value of the tree node, you need to first calculate the hash of each block contained in the tree node, then splicing the hash of each block, and then perform a second hash calculation for the spliced hash.

In this way, when the hash value filled in any slot in any block in the Tree node on the above-mentioned FDMT tree is updated, when the hash value of the Tree node is recalculated, even if the other each other in the Tree node is recalculated There is no data update in the block, and it still needs to be used as a calculation parameter to participate in the hash calculation. Obviously, there is a problem of a large amount of calculation in the hash calculation.

Based on this, in this specification, in order to reduce the amount of calculation when calculating the hash of the Tree node, the above-mentioned Tree node can specifically adopt the data structure of the main block (ie the main position) and multiple sub-blocks (ie the sub-positions).

Please refer to FIG. 5, which is a tree structure diagram of another FDMT tree shown in this specification.

As shown in FIG. 5 , the tree structure of the FDMT tree shown in this specification still includes the Tree nodes of the first N layers and the leaf nodes of the last layer.

Wherein, what is different from the structure of the above-mentioned FDMT tree shown in FIG. 4 is that the tree nodes of the first N layers on the above-mentioned FDMT tree shown in FIG. 5 may include the main block (that is, the root shown in FIG. 5 ). block) and a plurality of sub-blocks representing different characters respectively; and each block may further include a plurality of slots; for example, as shown in FIG. 5, each Tree node includes a main block and N sub-blocks; and each sub-block The block further includes N slots.

Among them, the functions of the slots included in the above-mentioned main block and sub-blocks may be different; as shown in FIG. 5 , for the main block, it may include a plurality of slots corresponding to each sub-block, and each slot Specifically, it can be used to fill the hash of the data content stored in the corresponding sub-block; for example, when calculating the hash of any sub-block, the hash values filled in each slot in the sub-block can be spliced together, and then spliced together The hash of the sub-block performs a secondary hash calculation to obtain the hash of the sub-block.

As for the sub-block, it can contain multiple slots representing different characters, and each slot can be used to fill the hash value of the next-level node linked by the tree node.

In this specification, according to the structure of the Tree node shown in Figure 5, the hash value of the main block in the Tree node can be used to represent the hash value of the Tree node; thus, in this case, when the above-mentioned FDMT tree After the hash value filled in the slot in any sub-block in the tree node above is updated, when recalculating the hash value of the tree node, it is only necessary to update the data in each slot in the sub-block. The filled hash value is spliced, and the spliced hash value is used as a calculation parameter to re-hash calculation, and then the calculated hash value is filled into the slot corresponding to the sub-block in the main block in the tree node, and then The hash of each slot in the main block is spliced, and the spliced hash value is used as a calculation parameter to re-calculate the hash to obtain the hash of the tree node.

In the whole process, the hash value filled in each slot in other sub-blocks without data update will no longer need to be spliced and used as a calculation parameter to participate in the hash calculation, which can reduce the time when the hash value of the tree node is recalculated. The hash calculation amount and calculation time are improved, and the calculation efficiency of hash calculation is improved.

It should be explained that the link relationship between the nodes of each layer on the above-mentioned FDMT tree shown in FIG. 4 and FIG. 5 is only schematic, and does not refer to the link relationship between the nodes of each layer on the above-mentioned FDMT tree. a special limitation of .

Please continue to refer to Fig. 4 and Fig. 5. Each tree node on the above-mentioned FDMT tree shown in Fig. 4 and Fig. 5 can be used to store at least some characters in the key of the above-mentioned blockchain data.

For each Tree node on the above-mentioned FDMT tree shown in FIG. 4, the characters actually stored can be specifically the characters represented by blocks in the Tree node (that is, at least one slot is filled with a non-empty block with a hash value), A string generated by splicing with the character represented by the slot filled with the hash value (ie, the non-empty slot) in the block.

And for each Tree node on the above-mentioned FDMT tree shown in FIG. 5, the characters actually stored can be specifically the characters represented by the sub-blocks in the Tree node, and the characters represented by the slots filled with hash values in the block. character, the string generated by concatenation.

Among them, in practical applications, each block in the Tree node can only represent one character; that is, based on the storage format of the Tree node shown in Figures 4 and 5, the above-mentioned blockchain actually stored by each Tree node Part of the characters in the character prefix of the key of the data is a string of 2 characters in length.

For example, please refer to FIG. 6, which is a structural diagram of a Tree node shown in this specification; as shown in FIG. 6, the Tree node contains 16 sub-blocks representing different hexadecimal characters; each sub-block It further includes 16 slots that represent different hexadecimal characters respectively (only 16 slots included in block6 are shown in Figure 6); it is assumed that the sub-block6 (representing the hexadecimal character 6) in the tree node is not Empty block, slot4 (representing the hexadecimal character 4), slot6 (representing the hexadecimal character 6) and slot9 (representing the hexadecimal character 9) in the sub-block are filled with the next tree node link The non-empty slot of the hash value of the layer node; then some characters in the character prefix of the key of the above blockchain data stored by the tree node are the hexadecimal strings "64", "66" and "69" respectively.

Among them, the number of sub-blocks contained in the above-mentioned Tree node, and the number of slots contained in each sub-block are not particularly limited in this specification; The number of types of character elements contained in the corresponding string to determine the number of sub-blocks contained in the above-mentioned Tree node; and the number of slots contained in the sub-blocks; for example, assume that the key corresponding to the above blockchain data is Hexadecimal string. At this time, the number of character elements contained in the string corresponding to the key of the above blockchain data is 16; then the number of sub-blocks contained in the above tree node, and the number of sub-blocks contained in each sub-block The number of slots can be 16.

In practical applications, the number of sub-blocks contained in the above-mentioned tree node and the number of slots contained in the above-mentioned sub-blocks can be kept the same; for example, in an example, the characters corresponding to the keys of the above-mentioned blockchain data are used The string is a hexadecimal string as an example. In this case, the above-mentioned tree nodes of the first N layers can each include 16 sub-blocks representing different hexadecimal characters; and each sub-block can further include 16 sub-blocks. Slots representing different hexadecimal characters.

In this way, a single Tree node in each layer of the first N layers of the above-mentioned FDMT tree tree can have 16*16=256 slots. Obviously, the Tree node on the FDMT tree shown in Figure 4 is relative to Figure 1. In terms of the nodes used to store character prefixes on the MPT tree, it will have a larger storage capacity.

Currently, in practical applications, the number of sub-blocks contained in the above-mentioned tree node may be different from the number of slots contained in the above-mentioned sub-blocks;

For example, in practical applications, the character string corresponding to the key of the above-mentioned blockchain data can also be a character string composed of two different base characters; for example, the character string corresponding to the key of the above-mentioned blockchain data can be is a string composed of a mixture of hexadecimal characters and hexadecimal characters. In this case, the above-mentioned tree nodes of the first N layers can each include 16 sub-blocks representing different hexadecimal characters; and Each sub-block may further include 10 slots representing different decimal characters; or, the above-mentioned tree nodes of the first N layers may include 10 sub-blocks representing different decimal characters respectively; and each The sub-block may further include 16 slots representing different hexadecimal characters.

In the illustrated embodiment, the number of layers of Tree nodes included in the above-mentioned FDMT tree may be a fixed value; in practical applications, the value of the above-mentioned N may be an integer greater than or equal to 1; or That is, the above-mentioned FDMT tree may specifically be a Merkle tree including at least one layer of Tree nodes, and the number of layers of the included Tree nodes is relatively fixed.

For example, in an example, taking the key of the above blockchain data as the blockchain account address as an example, assuming that the blockchain account address supported by the blockchain system is designed so that the first 6 address characters can be the same, then in In this case, the first 6 address characters of the blockchain account address can be used as the character prefix of the blockchain account address; moreover, since the length of the characters in the character prefix of the blockchain account address stored by the Tree node is 2-bit character; therefore, the above FDMT tree can be designed as a tree structure containing three levels of Tree nodes.

Based on the tree structure design of the FDMT tree shown in Figure 4 and Figure 5, on the one hand, because each Tree node in the FDMT tree includes a plurality of blocks representing different characters respectively; and each block further includes a plurality of Slots representing different characters respectively; therefore, through this design, each Tree node will have a larger data storage capacity and data carrying capacity, so that when the Tree node in the above FDMT tree is written into the database for storage; Alternatively, when accessing the Tree node in the above-mentioned FDMT tree stored in the database, the data storage capacity of the Tree node can be more adapted to the capacity of a single IO read and write of the storage medium carrying the above-mentioned database, so that the bearing capacity can be fully utilized. The IO read and write capability of the storage medium of the above-mentioned database improves the efficiency of data read and write; moreover, the improvement of the data storage capacity and data carrying capacity of a single tree node on the above-mentioned FDMT tree will inevitably lead to the overall data storage capacity of the above-mentioned FDMT tree. and the improvement of data carrying capacity, so that more blockchain data can be stored on the above FDMT tree; for example, taking the storage medium carrying the above database as a disk with a single physical sector of 4KB as an example, it is assumed that the disk has a single IO The capacity of reading and writing is 4kb (one sector). For a Branch node on the MPT tree described in Figure 1, assuming that the 16 fields contained in the Branch node are filled with a 32byte hash value, the data of the Branch Node is The storage capacity is about 32 bytes*16=512 bytes; obviously, the maximum capacity of one IO read for Branch node can only be about 512 bytes, which is far less than the maximum read capacity of 4Kb that can be read by one IO read of the disk. Obviously, the IO read capability of the disk cannot be fully utilized, and there is a serious performance waste.

However, if the tree structure design of the FDMT tree as shown in Figure 4 and Figure 5 is adopted, it is assumed that the above-mentioned tree nodes of the first N layers can each include 16 blocks representing different hexadecimal characters; each block can Further including 16 slots representing different hexadecimal characters, then a single tree node in each layer of the first N layers of the above FDMT can have 16*16=256 slots; assuming that each slot is filled with With a hash value of 32 bytes, when all slots are fully loaded, the maximum storage capacity of a tree node is 256*32byte=8192byte=8kb, which is exactly the capacity of two sectors. Obviously, the data storage capacity of each Tree node in the tree structure of FDMT shown in Figure 4 and Figure 5 is more suitable for the single IO read and write capacity of the above-mentioned disk, and can make full use of the IO of the disk itself. Read and write ability, improve data read and write efficiency.

Moreover, the improvement of the data storage capacity and data carrying capacity of a single tree node on the above-mentioned FDMT will inevitably lead to the improvement of the overall data storage capacity and data carrying capacity of the above-mentioned FDMT, so that more blockchain data can be stored on the above-mentioned FDMT. For example, suppose that the tree structure of the FDMT shown in Figure 4 and Figure 5 includes 3 layers of Tree nodes, and the Tree nodes of each layer can include 16 sub-blocks representing different hexadecimal characters respectively; each block can It further includes 16 slots representing different hexadecimal characters; then, a single tree node in each layer can have 16*16=256 slots; then the three-layer tree node can carry a total of 256*256* 256=16.77M character combination, a total of 16.77M bucket data blocks can be linked; assuming that each bucket data block can be defined by the user to carry 16 data records, the entire FDMT tree can carry up to 16.77M*16 blockchain data Obviously, compared with the MPT tree shown in FIG. 1, the above-mentioned FDMT shown in FIG. 4 and FIG. 5 can store more blockchain data and has a larger data carrying capacity.

In the second aspect, since each Tree node in FDMT adopts a unified data structure; for the Tree nodes of each layer in the above-mentioned FDMT, the character length of the character prefix of the key of the actually stored blockchain data will also remain unchanged. Fixed; therefore, through this design, frequent splitting of nodes caused by the fact that the length of characters actually stored in each layer of Tree nodes is not fixed can be avoided, thereby ensuring the number of layers of Tree nodes contained in the tree structure of FDMT. , is always in a relatively stable state.

Thirdly, due to this design, each Tree node will have greater data storage capacity and data carrying capacity; and, the number of layers of Tree nodes contained in the tree structure of the FDMT will be in a relatively stable state. Therefore, the improvement of the storage capacity of the Tree node and the number of layers of the Tree node are relatively stable, to some extent, it can be ensured that the Tree node of the above FDMT will have fewer layers; thus, the Tree node has a larger data storage On the basis of the capacity and data carrying capacity, and the tree node of the above FDMT has fewer layers, the system needs to use the tree node of the first N layers of the above FDMT from the storage medium carrying the above database as the cold start. When the data that needs to be read frequently is loaded into the memory, it can significantly reduce the number of IO reads when reading the tree nodes of the first N layers stored in the above storage medium into the memory, and the tree nodes of the first N layers of the FDMT can be read into the memory. The overall read time when the node is loaded into memory, thereby fundamentally shortening the startup delay when the system is cold started.

For example, the FDMT shown in Fig. 4 and Fig. 5 is fixed as a 3-layer Tree node, and the Tree node of each layer includes 16 blocks representing different hexadecimal characters; each block further includes 16 blocks representing different hexadecimal characters. Take the slot of hexadecimal characters as an example, when all the slots are fully loaded, the maximum storage capacity of a Tree node is 256*32byte=8192byte=8kb; for the MPT tree shown in Figure 1, due to It needs frequent node splitting, and the number of layers of the MPT tree is not fixed; moreover, because the storage capacity of its single Branch Node node is 512 bytes, it is much smaller than the Tree node on the FDMT tree shown in Figure 4 and Figure 5; it will inevitably cause the MPT tree. Has a larger number of layers (for example, the MPT tree can reach up to 64 layers, which is much larger than 3 layers). When the system is cold-started, when the first N layers of the FDMT tree are read into the memory, they are usually read layer by layer; therefore, based on the MPT tree shown in Figure 1, obviously more reads are required.

Moreover, since the storage capacity of a single Branch Node node on the MPT tree is 512 bytes, only the single physical sector carrying the above database is one-eighth of 4KB, and the reading efficiency is very low; therefore, even according to the MPT tree and The FDMT tree shown in Figures 4 and 5 stores the same data, and the number of IO reads for the MPT tree during the cold start of the system may be at least 8 times the number of IO reads for the FDMT tree shown in Figures 4 and 5 times.

Obviously, when the system is cold-started, the number of IO reads for the above FDMT tree shown in Figures 4 and 5 will be much smaller than the number of IO reads for the MPT tree shown in Figure 1; therefore, Figures 4 and 5 The tree structure design of the above FDMT tree shown in 5 will be more friendly to the cold start of the system.

In the illustrated embodiment, the character string corresponding to the key of the above-mentioned blockchain data may still include character prefixes and character suffixes; in this case, the above-mentioned Tree node can be used to store the The character in the character prefix of the key; the leaf node can be used to store the character suffix of the key of the blockchain data and the Value of the blockchain data.

Among them, the data actually stored by the above-mentioned leaf nodes usually has a larger data capacity than the above-mentioned Tree nodes; for example, the value of the above-mentioned blockchain data actually stored by the above-mentioned leaf nodes is usually the above-mentioned blockchain data. Compared with the character prefix of the above blockchain data, the original content of the above-mentioned blockchain data also occupies a larger storage space; therefore, in this specification, in order to ensure that the above-mentioned leaf nodes can have more For large data capacity, the above leaf nodes can specifically store data in the form of large data blocks.

The specific form and storage structure of the above-mentioned data block are not particularly limited in this specification; in the illustrated embodiment, the above-mentioned leaf node may specifically be in the form of a bucket data bucket; wherein, the above-mentioned bucket data bucket specifically Can be a container or storage space for storing data.

Please refer to FIG. 7 , which is a structural diagram of a bucket data bucket shown in this specification; as shown in FIG. 7 , the above-mentioned bucket data bucket (ie, the bucket node shown in FIG. 7 ) may include several Data records; wherein, the above-mentioned several data records contained in the above-mentioned bucket data buckets may not logically be a whole, but logically separated several different data records. Each data record corresponds to a piece of blockchain data, which is used to store the value of the above-mentioned blockchain data; that is, a data record refers to a storage record whose data content includes the value of the blockchain data. .

The above-mentioned several data records contained in the above-mentioned bucket data bucket are not logically a whole, which means that each data record can correspond to an independent query key value (key), so that the query key of each data record can be based on value, to perform precise query for each data record in the above bucket data bucket, instead of reading all the data records stored in the above bucket data bucket as a whole.

The specific form and specific content of the query key value corresponding to each data record are not particularly limited in this specification, and can be any form of character string that can be used as a query index for each data record.

In the illustrated embodiment, the query key value corresponding to each data record may specifically be the hash value of the data content contained in each data record; the above-mentioned data record contained in the above-mentioned bucket data bucket may specifically include the following: A key-value key-value pair formed by the hash value of the value of the above blockchain data and the data content corresponding to the value of the above blockchain data.

Of course, in practical applications, the query key value corresponding to each data record may also be a string other than the hash value that can be used as the query index of each data record, which is not particularly limited in this description; for example, , in an example, the query key value corresponding to each data record may also be a unique identifier (such as a serial number) respectively set by the node device for each data record.

In the illustrated embodiment, if the above-mentioned Tree node is used to store the characters in the character prefix of the key of the above-mentioned blockchain data; then the above-mentioned leaf node is used to store the character suffix of the key of the above-mentioned blockchain data and the above-mentioned The value of the blockchain data; correspondingly, the above data records contained in the above bucket data buckets may specifically be the data content corresponding to the character suffix in the key of the above blockchain data and the value of the above blockchain data as a whole. The hash value obtained by the hash calculation is a key-value key-value pair formed by the character suffix of the key of the above-mentioned blockchain data and the data content corresponding to the value of the above-mentioned blockchain data.

In practical applications, the above data records may also be other types of data forms other than key-value pairs, which will not be listed one by one in this specification.

Through the above implementation, since several data records contained in the leaf nodes in the FDMT tree are no longer a whole logically, they are logically separated several key-value pairs; therefore, the above FDMT The data contained in the leaf nodes in the tree will no longer be accessed as a whole access unit in the database, and each key-value pair contained in the above leaf nodes will be used as an independent access unit, so that the data access to the above-mentioned database will be more flexible; for example, the value of the above-mentioned blockchain data is the latest account status data corresponding to the blockchain account in the blockchain, and the value of the above-mentioned blockchain data is For example, the key is the blockchain account address. In this case, the key of the key-value key-value pair corresponding to the above data record contained in the above bucket data bucket can be the character suffix of the blockchain account address and the corresponding The hash value of the two parts of the account status data; the value of the key-value pair can be the character suffix of the blockchain account address and the data content of the corresponding account status data.

Suppose you need to read the character suffix of a specific account address and the corresponding account status data contained in the above bucket data bucket, because each key-value pair in the above bucket data bucket is an independent access unit ; Therefore, it is only necessary to perform content addressing in the database based on the character suffix of the specific account address and the hash value of the corresponding account status data of the two parts of the data content, and it is no longer necessary to retrieve the leaf node from the database. All the data contained in it are read into the memory as a whole, and then the character suffix of the account address to be read and the corresponding account status data are further searched in the memory; accordingly, if it is necessary to write a new The character suffix of the account address and the corresponding account status data, or to update the account status data corresponding to a specific account address contained in the above bucket data bucket, it can be directly based on the character suffix of the new account address and the corresponding account. The state data can construct a key-value key-value pair, and write the key-value key-value pair into the above bucket data bucket; or, based on the character suffix of the specific account address and the corresponding account status data two parts of the data content The hash value of the account address, perform content addressing in the database, find the corresponding key-value key-value pair, and then write the updated account status data corresponding to the specific account address, and the original key-value key-value pair. value can be updated.

The number of data records contained in the above-mentioned bucket data bucket is not particularly limited in this specification; in the illustrated implementation manner, the number of data records contained in the above-mentioned bucket data bucket may specifically be Custom configuration by the user.

For example, the above blockchain data is the latest account status data corresponding to the blockchain account in the blockchain, and the key of the above blockchain data is the blockchain account address. In this case, the above bucket data Each data record in the bucket corresponds to the account status of a blockchain account; the number of data records in the above bucket data bucket actually represents that the bucket data bucket can accommodate the account bearer of the blockchain account Therefore, by customizing the number of data records that the above bucket data bucket can hold, the user can flexibly customize the account carrying capacity of the above bucket data bucket; for example, in an example, the above bucket data bucket The number of data records contained in it can be configured by the user to be 16 or 64, so that a single bucket can carry the status data of 16 or 64 blockchain accounts.

Wherein, the total storage capacity of the data records stored in the above bucket data bucket is not particularly limited in this specification; in an implementation manner shown, the total storage capacity of the data records stored in the above bucket data bucket Capacity, which can be customized by the user.

For example, in the implementation, it is assumed that the storage medium carrying the above-mentioned database is a disk with a single physical sector of 4KB. It is set to 4KB; or an integer multiple of 4KB, so that the maximum storage capacity of the bucket data bucket can be adapted to the storage capacity of a single physical sector of the storage medium.

In this specification, as mentioned above, each Tree node of the first N layers on the above-mentioned FDMT tree adopts a unified data structure; therefore, each Tree node of the first N layers on the above-mentioned FDMT tree will no longer be split. . However, the leaf nodes on the above-mentioned FDMT tree can still perform node splitting when certain splitting conditions are met.

Different from the above-mentioned MPT tree, in this specification, when the leaf nodes on the above-mentioned FDMT tree are split, they can no longer be split according to the change of the character length of the shared character prefix, but according to the storage capacity of the leaf node. split. When the storage capacity of the leaf node on the above-mentioned FDMT tree satisfies the node splitting condition, an intermediate node (ie, the Extend node shown in FIG. 5 ) is split from the leaf node. The split intermediate node is the upper-level node of the above leaf node. For the same leaf node, multiple splits can be performed.

The above-mentioned node splitting condition may include any form of condition related to the storage capacity of the above-mentioned leaf node, which is not particularly limited in this specification; in the illustrated embodiment, the above-mentioned node splitting condition may specifically be: Condition 1 and Condition 2 shown below; or a combination of Condition 1 and Condition 2 shown below: Condition 1: The total number of data records stored in the above leaf nodes is greater than the threshold; Condition 2: The total storage capacity of the data records stored in the above leaf nodes is greater than the threshold.

For example, in one example, the above-mentioned node splitting condition may be set as, when the total number of data records stored in the above-mentioned leaf nodes is greater than 64; and/or, the total storage capacity of the data records stored in the above-mentioned leaf nodes is greater than 4KB , the intermediate node is split from the leaf node.

In this specification, the above-mentioned Extend node, which is also the intermediate node of the above-mentioned FDMT tree, can adopt the exact same data structure as the above-described Tree node, and is specifically used to store the characters split from the character suffixes stored in the above-mentioned leaf nodes; for example , please refer to Figure 4 and Figure 5, the Extend node split from the leaf node may also include multiple blocks representing different characters; and each block may further include multiple slots representing different characters; the slot The bit can be used to fill in the hash value of the next layer node linked by this node. For example, for an Extend node, the next-layer node is the above-mentioned leaf node; therefore, the slot contained in the block in the Extend node can be used to fill the hash value of the next-layer leaf node linked by the Extend node.

In this specification, for an Extend node split from the above-mentioned leaf nodes, it may also be merged with the lower-level leaf nodes linked to the Extend node according to the storage capacity of the Extend node. When the storage capacity of the Extend node on the above FDMT tree satisfies the node merging condition, the Extend node can be merged into the lower-level leaf node linked to it.

Wherein, merging the Extend node into the lower-level leaf node linked to it means that the character stored in the Extend node is used as the above-mentioned character suffix and written into one or more leaf nodes of the lower layer linked with the Extend node.

The above-mentioned node merging condition may also include any form of condition related to the storage capacity of the above-mentioned Extend node, which is not particularly limited in this specification; in the illustrated embodiment, the above-mentioned node merging condition may specifically be is any one of Condition 3 and Condition 4 shown below; or, it can also be a combination of Condition 3 and Condition 3 shown below: Condition 1: The total number of characters stored in the Extend node above is less than or equal to the threshold ; That is, the total number of non-empty slots (that is, slots filled with hash values) in each block in the Extend node above; Condition 2: The total storage capacity of the characters stored in the Extend node above is less than or equal to the threshold. That is, the total storage capacity of the hash values filled in the non-empty slots in each block in the Extend node above; for example, in an example, the above node merging condition can be set as, when the total number of characters stored in the Extend node above Less than or equal to 1; and/or, when the total storage capacity of the characters stored in the Extend node is less than or equal to 1KB, the characters stored in the Extend node are used as character suffixes, and are written into one of the lower layers of the Extend node link or multiple leaf nodes.

As can be seen from the above description, the Extend node described in this specification can be a dynamically scalable intermediate node on the above-mentioned FDMT tree; when the storage capacity of any leaf node on the above-mentioned FDMT tree satisfies the node splitting condition, it can be used from the leaf node. At least one Extend node and at least one leaf node are split in the middle; when the storage capacity of any Extend node satisfies the node merging condition, the Extend node can be merged into the lower-level leaf node linked to it.

In this specification, the blockchain data to be stored may specifically include at least the following four types of data: transactions included in the block; Transaction receipt; after the transaction in the block is executed, the latest account status data corresponding to the blockchain account in the blockchain; the storage content of the smart contract account; Correspondingly, the above-mentioned FDMT tree may also specifically include: A transaction tree used to store transactions included in the block; a receipt tree used to store transaction receipts corresponding to transactions included in the block; used to store the latest account corresponding to the blockchain account in the blockchain A state tree for state data; a storage tree for storing the storage content of smart contract accounts.

Of course, in practical applications, only the tree structure of the above FDMT tree can be used to store some types of data in the above four types of data; for example, only the above FDMT tree can be used to store the latest account status corresponding to the above blockchain account Data, other types of data can be stored using other forms of binary trees (such as MPT or other forms of binary trees).

The hash value of the root node of the above transaction tree, receipt tree and state tree can be stored in the block header; the hash value of the root node of the above storage tree can be stored in the structure of the contract account corresponding to the storage tree. in the Storage field.

The key of the above-mentioned blockchain data may specifically refer to the corresponding search key value of the blockchain data in the database; correspondingly, the value of the above-mentioned blockchain data may specifically be the original content of the above-mentioned blockchain data; wherein, In practical applications, the above-mentioned search key may be a string corresponding to the blockchain data; when the above-mentioned blockchain data is of different types, the corresponding keys will also be different; for example, when the above-mentioned blockchain data is of different types The above blockchain data is the transaction included in the block; or, after the transaction in the block is executed, when the transaction receipt corresponding to the transaction included in the block is the transaction receipt, the key corresponding to the blockchain data at this time , which can be the sequence number of the transaction in the block; or, a transaction identifier in other forms.

When the above blockchain data is the latest account status data corresponding to the blockchain account in the blockchain after the transaction in the block is completed, the key corresponding to the blockchain data at this time can be specifically The account address of the blockchain account.

When the above-mentioned blockchain data is the storage content of the smart contract account, the key corresponding to the blockchain data at this time may specifically be the account address of the contract account and the storage location of the above-mentioned storage content in the account storage of the contract account. Hash value; for example, in an example, the above storage content can usually be a state variable, then the account address of the contract account and the hash value of the storage location of the state variable in the account storage of the contract account can be used as the key.

In this specification, when the node device in the blockchain is storing blockchain data, it can first obtain the key-value pair of the blockchain data to be stored; for example, in an example, the node device can be stored in the When the blockchain data to be stored is obtained, the blockchain data is processed into key-value key-value pairs; after the key-value key-value pairs of the blockchain data to be stored are obtained, the to-be-stored blockchain data can be The key-value key-value pair of the blockchain data is converted into the root node, intermediate node and leaf node on the above-mentioned logical tree structure; for example, in an example, the above-mentioned node device can carry a corresponding FDMT tree. Storage interface or storage service, the storage interface or storage service can specifically be used to convert the key-value key-value pair of the blockchain data to be stored into a node on the FDMT tree; After the key-value key-value pair of the blockchain data, the key-value of the blockchain data to be stored can be stored according to the tree structure of the FDMT tree shown in Figure 4 or Figure 5 by calling the storage interface or storage service. The value key-value pair is converted into the root node, intermediate node and leaf node in Figure 4 or Figure 5.

After the key-value key-value pairs of the stored blockchain data are converted into the root nodes, intermediate nodes and leaf nodes on the above-mentioned logical tree structure, these root nodes, intermediate nodes and leaf nodes can be converted into key-value The key-value pair is stored in the database; for example, the above-mentioned database is usually stored in a persistent storage medium (such as a storage disk) carried on the above-mentioned node device; the above-mentioned storage medium is the physical storage corresponding to the above-mentioned database; When the above-mentioned FDMT tree is stored in the database, specifically, by executing the commit command, the nodes on the above-mentioned FDMT tree can be further written into the storage carrying the above-mentioned database from the memory of the node device in the form of a Key-Value key-value pair. medium.

Wherein, the specific type of the above-mentioned database is not particularly limited in this specification, and those skilled in the art can flexibly choose based on actual needs; in an implementation manner, the above-mentioned database can be specifically a Key-Value type database; For example, in one example, the above database may be a LevelDB database using a multi-layer storage structure; or, a database based on a LevelDB architecture; for example, a Rocksdb database is a typical database based on a LevelDB database architecture.

When the node on the above-mentioned FDMT tree is stored in the above-mentioned database in the form of a Key-Value key-value pair, the key of the above-mentioned Key-Value key-value pair may specifically be the node ID of the node on the above-mentioned FDMT tree; wherein, The above-mentioned node ID may specifically include identification information that can uniquely identify the node on the above-mentioned FDMT tree; for example, in an implementation manner, the above-mentioned node ID may specifically be the hash value of the data content contained in the node on the above-mentioned FDMT tree; in this In this case, when a node on the FDMT tree needs to be queried, content addressing can be performed based on the hash value of the data content contained in the node as a key.

In another implementation manner, the node ID may specifically include path information of the node on the FDMT tree in the FDMT tree; that is, the path information of the node on the FDMT tree in the FDMT tree is used as the The node ID of the node; wherein, the above-mentioned path information may specifically include information in any form that can describe the link relationship between the node and other nodes, and the position of the node on the above-mentioned FDMT tree; for example, please refer to FIG. 8, FIG. 8 A schematic diagram of setting a node ID for a node on the FDMT tree shown in this specification; for a FDMT tree containing a three-layer Tree node as shown in Figure 8, it is assumed that the node ID of the tree node as the root node is represented by 0x00, then The node ID of the bucket node shown in Figure 8 can be represented as 0x00123456.

Among them, 0x00 is the node ID of the root node; 123456 refers to the path information of the above bucket node from the root node to the bucket node in the FDMT tree; 12 refers to the second slot of the first block of the first layer tree node; 34 represents the 4th slot of the 3rd block of the second-level tree node; 56 represents the 6th slot of the 5th block of the third-level tree node.

Based on the node ID, the link relationship between the bucket node and other nodes can be clarified, as well as the specific location of the bucket node on the above FDMT tree; for example, based on the node ID, it can be clarified that the bucket node is linked to the third-level tree The sixth slot of the fifth block of the node; and the tree node of the third layer is linked to the fourth slot of the third block of the second layer of the tree node; the tree node of the second layer is further linked in The first layer is the second slot of the first block of the tree node of the root node.

In this way, when a node stored in the FDMT tree is retrieved by using the node ID, the specific slot in the FDMT tree where the node is located can be precisely located.

In another implementation manner, the node ID may specifically include the relative position of the node on the FDMT tree in the FDMT tree, and the hash value of the data content contained in the node (at this time, the node ID can also be used as The hash identifier of the node); that is, the relative position of the node on the FDMT tree in the FDMT tree and the hash value of the data content contained in the node are used as the node ID of the node.

For example, during implementation, the relative position of the node in the above-mentioned FDMT tree and the hash value of the data content contained in the node can be concatenated with the generated string as the node ID of the node; of course, in practical applications, in In the process of splicing, other types of information other than the above-mentioned relative position and the above-mentioned hash value can also be further introduced to generate a node ID; they will not be listed one by one in this specification.

In this way, in addition to the content addressing based on the hash value of the data content contained in the node as the key, when the node ID is used to retrieve the node stored in the FDMT tree, the node can be precisely located in the FDMT The specific slot on the tree.

Wherein, the storage medium used to carry the above-mentioned database on the above-mentioned node device may specifically be a persistent storage medium; for example, it may be a disk, memory or other forms of storage medium capable of persistently storing data, which is not described in this specification. List them one by one.

In this specification, before the key-value pairs of the nodes on the FDMT tree are written into the database respectively, the nodes on the FDMT tree can also be encoded in advance, and then the key of the encoded node can be encoded. -value key-value pairs are stored in the database.

Among them, since both the Tree node and Extend node on the above-mentioned FDMT tree are adopted, they contain multiple blocks, and each block further includes a data structure of multiple slots; therefore, in this specification, coding is performed for the above-mentioned FDMT tree. , bitmap encoding can be performed for the blocks in the Tree node and Extend node on the above FDMT tree.

When bitmap coding is performed on the blocks in the Tree node and Extend node (which may include main block and sub-block) on the above FDMT tree, it can be specifically calculated whether each slot in the block in the Tree node and Extend node is filled with hash. value, and then express the statistical results with special encoding characters to obtain bitmap encoding information, and finally add the bitmap encoding information to the block to complete the bitmap encoding process for the block; for example, in an example, the above bitmap encoding Information, which can be a hexadecimal string used to identify whether each slot in the block is filled with a hash value; it is assumed that the block to be encoded (can be a main block or a sub-block) contains a total of 16 slots ; The 0th, 8th, 9th, 10th, and 11th bits in the 16 slots are filled with hash values respectively; then whether each slot in the block is filled with the hash statistics, you can use The binary string 0000 1111 0000 0001 represents; the leftmost of the binary string is the highest 15th bit, and the rightmost is the lowest 0th bit; finally, the binary string can be converted into a hexadecimal string 0x0f01; At this time, the hexadecimal string 0x0f01 is the bitmap encoding information of the block.

Among them, when bitmap encoding is performed on the blocks in the Tree node and Extend node on the above-mentioned FDMT tree, whether it is the main block or the sub-block, the bitmap encoding process is exactly the same.

In this way, since the blocks contained in the Tree node and Extend node in the encoded FDMT tree are added, it can indicate whether each slot in the block is filled with bitmap encoding information of the hash value; When querying the data filled in the block in each tree node stored in the database, the non-empty slot in the block can be determined through the bitmap encoding information in the block, and there is no need to traverse each slot in the block. , which can improve the search efficiency.

Among them, because the leaf nodes on the above-mentioned FDMT tree use a completely different data structure from the Tree node and Extend node; therefore, when encoding the leaf nodes on the above-mentioned FDMT tree, it can also be completely different from the above-mentioned Tree node and Extend node. different encodings.

In the illustrated embodiment, when encoding the leaf nodes on the above-mentioned FDMT tree, RLP (Recursive Length Prefix, recursive length prefix encoding) encoding can still be used; wherein, the RLP encoding is as shown in FIG. 1 . The MPT tree is a commonly used encoding method, and its specific encoding process will not be described in detail in this specification.

Of course, in practical applications, the encoding method used when encoding the leaf nodes on the above-mentioned FDMT tree may also be encoding methods other than RLP encoding. In practical applications, it can be flexibly selected. will not be listed one by one.

In this specification, after the encoding of the nodes on the FDMT tree is completed, the key-value pairs of the nodes on the FDMT tree may be stored in the database.

Wherein, in the illustrated embodiment, for the Tree node and Extend node on the above-mentioned FDMT tree, before storing the encoded key-value key-value pair of the Tree node and Extend node in the database, it can be determined according to the The encoded bitmap information is added to the block in the Tree node and Extend node after encoding to determine the empty slots in the block that are not filled with hash values, and then delete the determined empty slots from the block.

In this way, when the key-value pairs of each Tree node and Extend node are stored in the database, the empty slots in each block can be deleted, which can further save the time required for storing each Tree node and each Extend node in the database. Take up storage space and improve storage efficiency.

Among them, for the encoded block, when calculating the hash value of the block, the bitmap encoding information contained in the encoded block and the hash value filled with the non-empty character slot can be used as a whole for hash calculation; of course, you can also Exclude bitmap encoding information.

In this specification, after the node key-value pairs on the above FDMT tree are written into the above database, if the value corresponding to a certain block chain data written in the above FDMT tree is updated, it may be necessary to For the leaf node on the above FDMT tree used to store the character suffix and value of the blockchain data, the Extend node split from the leaf node, and the tree node used to store the character prefix of the key of the blockchain data Update separately.

Of course, if the leaf nodes used to store the character suffix and value of the blockchain data have not been split, it is only necessary to change the leaf nodes of the character suffix and value used to store the blockchain data on the above FDMT tree, and The tree node of the character prefix of the key used to store the blockchain data can be updated separately.

In this case, the node device can search the above-mentioned database for the node corresponding to the above-mentioned blockchain data that needs to be updated; wherein, the specific search method will not be repeated; and then read the found node from the above-mentioned database to In the memory, these nodes are modified and updated in the memory, and then the updated nodes are further written into the above database to update the original updated nodes.

For example, updating the leaf node on the FDMT tree whose data is updated may specifically include updating the value of the blockchain data stored in the leaf node. After the update is completed, the hash value of the leaf node can be recalculated, and based on the hash value, it can be re-linked with the nodes in the upper layer of the node.

And updating the Extend node or Tree node on the upper layer of the leaf node where the data update occurs on the above-mentioned FDMT tree may specifically include updating the slot in the Extend node or Tree node filled with the hash value of the leaf node; After completion, you can recalculate the hash value of the Extend node or Tree node, and continue to re-link with the node on the layer above the node based on the hash value.

In the illustrated embodiment, for the splitting judgment of the leaf node on the FDMT tree and the specific node splitting operation, the hash value of the leaf node can be recalculated, and based on the hash value and the previous leaf node The node of the layer (which can be a Tree node or an Extend node) is re-linked.

In this case, the node device can determine whether the leaf node on the above-mentioned FDMT tree is updated with data, and if any leaf node on the above-mentioned FDMT tree is updated with data, the node device can recalculate the hash value of the leaf node, And based on the hash value, before relinking with the Tree node or Extend node on the upper layer of the leaf node, further determine whether the storage capacity of the leaf node meets the node splitting condition; if the storage capacity of the leaf node meets the node splitting condition, you can further from The leaf node is split into at least one Extend node.

For example, in an example, when the storage capacity of the leaf node satisfies the node splitting condition, in order to rapidly reduce the storage capacity of the leaf node, the leaf node may be split into one Extend node and multiple leaf nodes.

Among them, the splitting strategy for splitting the Extend node from the above-mentioned leaf nodes is not particularly limited in this specification. In practical applications, users can customize settings according to specific splitting requirements; in the one shown in the In an embodiment, the above-mentioned splitting strategy may specifically include: splitting the latest data record written into the leaf node in the current block cycle, splitting it from the leaf node, and additionally creating an Extend node and a leaf based on the latest data. node.

In this case, when node splitting is performed on any target leaf node, the latest data records written to the target leaf node in the current block cycle can be determined; Delete the node from the node, and split the character prefix from the character suffix contained in these latest data records; for example, in one example, the first two digits of these latest data records can be split by default; or, in these latest data records If there is a shared character prefix in the character suffix included in the data record, and when the length of the shared character prefix reaches two digits, the shared character prefix is split.

Then, at least one Extend node for storing the split character prefix and at least one leaf node for storing the latest data record after splitting the character prefix are further created.

In this way, since the latest data records written to the target leaf node in the current block cycle can be deleted from the target leaf node, and based on these deleted latest data records, at least one Extend node and At least one leaf node is used as a split node; therefore, for the target leaf node, after the node split is performed, the data records actually stored by the target leaf node will be the same as the data records stored by the target leaf node in the previous block cycle. The data records are completely consistent; the hash value of the target leaf node will not change from the previous block cycle. Therefore, when the target leaf node writes new blockchain data in the current block cycle, so that the storage capacity of the target leaf node satisfies the node splitting condition, it only needs to split the newly written data record and re-create it. It is enough to create additional Extend nodes and leaf nodes, and it is no longer necessary to recalculate the hash value of the target leaf node and relink the nodes of the previous layer; through this splitting method, not only the leaves that meet the node splitting conditions can be guaranteed The hash value of the node is in a stable state, and the number of times of recalculating the hash value of the leaf node can be reduced.

In another illustrated embodiment, the splitting strategy may specifically include: splitting the shared character prefixes between the character suffixes included in several data records stored by the leaf node from the leaf node, and splitting the shared character prefixes from the leaf node based on the Shared character prefixes to additionally create Extend nodes.

In this case, when splitting any target leaf node, it can be determined whether there is a shared character prefix between the character suffixes contained in several data records stored by the target leaf node; If there is a shared character prefix between the character suffixes included in a data record, the shared character prefix can be deleted from the above-mentioned several data records, and at least one Extend node for storing the shared character prefix is created.

For example, since the above Extend node can also use the same data structure as the Tree node; therefore, the characters stored in the above Extend node can also be the characters represented by the block and the slot filled with the hash value in the block. A character string with a length of two digits; then there is a shared character prefix among the character suffixes contained in several data records stored in the target leaf node, and when the length of the shared character prefix reaches two digits, the shared character prefix can be changed from The above-mentioned several data records are split out.

In the illustrated embodiment, for the merging judgment of the Extend node on the above-mentioned FDMT and the specific node merging operation, the hash value of the Extend node can also be recalculated, and based on the hash value and the Extend node on the The nodes of the layer undergo a relinking phase to complete.

In this case, the node device can determine whether the data update occurs on the Extend node on the FDMT tree. If the data update occurs on any Extend node split from the leaf node on the FDMY tree, the node device recalculates the data update. The hash value of the Extend node, and before re-linking with the node on the upper layer of the Extend node based on the hash value, it can be further determined whether the storage capacity of the Extend node satisfies the node merging condition; if the storage capacity of the Extend node satisfies the node splitting condition, The Extend node can be further merged into the leaf node of the next layer linked with the Extend node.

For example, during implementation, the leaf node of the next layer of the link of the Extend node can be determined first; for example, the lower node of the link of the Extend node can be determined according to the hash value filled in the non-empty slot in the block contained in the Extend node. A leaf node of one layer; then, the character stored by the Extend node can be used as part of the above character suffix, and written to the determined leaf node of the next layer of the Extend node link.

In practical applications, when a leaf node is split multiple times, the leaf node can be split into multiple layers of Extend nodes; in this case, when any Extend node satisfies the node merging condition, if its lower nodes still is an Extend node, not a leaf node, the Extend node cannot be merged temporarily; in this case, you can wait for the lower Extend node and the lower leaf node to complete the merge to form a new leaf node, and then merge with the lower layer. The new leaf node is merged twice, and the specific merging method will not be described again.

The following takes the above blockchain data as the latest account status data corresponding to the blockchain account, and the key of the above blockchain data is the blockchain account address as an example. Form, the writing adopts the specific process of the FDMT tree as shown in Figure 4 and Figure 5, which will be described in detail.

During implementation, the user client connected to the blockchain can package the transaction data into a standard transaction format supported by the blockchain, and then publish it to the blockchain; while the node devices in the blockchain can be based on the The consensus algorithm and other node devices, together with other node devices, agree on these transactions published by the user client to the blockchain, so as to generate the latest block for the blockchain; the specific consensus process will not be repeated.

After the node device in the blockchain executes the transaction in the target block, the account status of the target account related to the executed transaction in the blockchain usually changes accordingly; therefore, the node device in the target After the transaction in the block is executed, the latest account status data of the target account after account update (that is, the account status after the transaction in the target block is executed) can be obtained, and the obtained latest account status of the target account can be obtained. The data is processed into key-value key-value pairs; wherein, the key of the key-value key-value pair is the account address of the target account; the value of the key-value key-value pair is the latest account status of the target account.

After the obtained latest account status data of the target account is processed into key-value key-value pairs, the key-value key-value pairs can be converted into Tree node, Extend node and Leaf node on the above FDMT tree, and the The key-value pairs of the above Tree node, Extend node and Leaf node are stored in the database.

Please refer to Fig. 9, Fig. 9 is a schematic diagram of writing account state data into the FDMT state tree shown in this specification; in the above-mentioned FDMT state tree shown in Fig. 9, the first three layers are Tree nodes, and the last layer is Leaf node; wherein, the above-mentioned leaf node may adopt the storage structure of the bucket data bucket described above. The tree nodes of each layer include a main block and 16 sub-blocks representing different hexadecimal characters 1-f respectively; and each sub-block further includes 16 slots representing different hexadecimal characters 1-f respectively .

Suppose the account address of the above target account is "a71135125", and the latest account status data is "state1"; at this time, the character prefix (Shared nibble) of the account address is "a71135"; the character suffix (key-end) is "125" ".

When the account state data "state1" of the account address "a71135125" is written into the above-mentioned FDMT tree in the form of key-value key-value pairs, the Tree node as the root node on the FDMT tree can be located in the database (for example, according to The hash of the root node filled in the block header is used to locate the root node); if the data is written for the first time and the root node has not been created, the root node can be created at this time; then start from the root node Tree node1 of the first layer, and in turn in the third layer Determine the character slot corresponding to the character prefix "a71135" of the account address in the Tree node. As shown in Figure 9, the character slot corresponding to the character prefix "a71135" of the account address specifically includes: the 8th slot (representing character 7) in the 11th sub-block (representing character a) of Tree node1; The second slot (representing character 1) in the second sub-block of Tree node2 (representing character 1); the sixth slot (representing character 5) in the fourth sub-block (representing character 3) of Tree node3.

After the above slots are determined, the data record consisting of the character suffix "125" and the state data "state1" can be written in the bucket node linked by the sixth slot of the fourth sub-block of Tree node3; of course, if There is already a data record corresponding to the character suffix "125" in the bucket node, indicating that the value corresponding to the historical account status data of the above account address "a71135125" has been written to the FMDT tree; at this time, the value stored in the data record can be updated It can be "state1".

After the data writing is completed, the hash value of the data content contained in the bucket node can be recalculated, and the hash value can be filled into the sixth slot of the fourth block of Tree node3, and the original hash value of the slot to update.

Further, after updating the original hash value in the sixth slot of the fourth block of Tree node3, recalculate the hash value of the data content contained in the main block of Tree node3, and fill the hash value into the Tree. In the second slot of the second block of node2, the original hash value of the slot is updated.

Then, after updating the original hash value of the second slot of the second block of Tree node2, recalculate the hash value of the data content contained in the main block of Tree node2, and continue to fill the hash value into the Tree. In the 8th slot of the 11th block of node1 (that is, the root node), the original hash value of the slot is updated.

When the original hash value of the 8th slot of the 11th block of the root node Tree node1 is also updated, the hash value of the data content contained in the main block of the root node Tree node1 is recalculated, and based on the hash value The value updates the hash value of the root node of the FDMT state tree stored in the block header. When the hash value of the root node of the FDMT state tree stored in the block header is updated, and the update of the FDMT state tree is completed at this time, the key- The value key-value pair is successfully written to the FDMT state tree.

Taking the above-mentioned blockchain data as the latest account status data corresponding to the blockchain account as an example, it is only exemplary; in practical applications, when the above-mentioned blockchain data is other types of the four types of blockchain data described above When the block chain data is stored, the specific process of writing it into the corresponding FDMT tree is similar to the implementation process described above, and will not be repeated in this specification.

Corresponding to the above method embodiments, the present application also provides device embodiments.

Corresponding to the above method embodiments, this specification also provides an embodiment of a blockchain data storage device.

The embodiments of the blockchain data storage device of this specification can be applied to electronic devices. The apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, a device in a logical sense is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the electronic device where the device is located.

From the perspective of hardware, as shown in FIG. 10, it is a hardware structure diagram of the electronic equipment where the blockchain data storage device of this specification is located, except for the processor, memory, network interface, and non-volatile shown in FIG. 10. In addition to the non-volatile memory, the electronic device in which the apparatus in the embodiment is located usually may also include other hardware according to the actual function of the electronic device, which will not be repeated here.

FIG. 11 is a block diagram of a blockchain data storage device shown in an exemplary embodiment of the present specification.

Please refer to FIG. 11 , the blockchain data storage device 110 can be applied to the electronic equipment shown in the aforementioned FIG. 10 , and the device 110 includes: an acquisition module 1101 for acquiring the key-value key of the blockchain data to be stored value pair; the conversion module 1102 converts the key-value key-value pair of the blockchain data to be stored into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include A plurality of positions for storing characters in the key of the blockchain data, and each position includes a plurality of slots for storing characters in the key of the blockchain data; the slots are used for Store the hash value of the next layer node linked to the node; the storage module 1103 stores the key-value pairs of the root node, the intermediate node and the leaf node in the database; the leaf node, the intermediate node In the key-value key-value pair with the root node, the value is the storage content of the node, and the key is the hash value of the storage content of the node.

In this embodiment, the number of layers of the root node and the intermediate node is a fixed value.

In this embodiment, the root node and the intermediate node are used to store at least part of the characters in the key of the blockchain data; the at least part of the characters stored by the root node and the intermediate node are the root node , The character string represented by the position in the intermediate node is spliced with the character represented by the slot filled with the hash value in the position.

In this embodiment, the leaf node is a bucket data bucket; the bucket data bucket contains several data records; the data content stored in the data record includes the value of the blockchain data.

In this embodiment, the character string corresponding to the key of the blockchain data includes a character prefix and a character suffix; the root node and the intermediate node include a plurality of locations for storing the characters in the character prefix, each The location includes a plurality of slots for storing characters in the character prefix; the data content stored in the data record includes the character suffix and the value of the blockchain data.

In this embodiment, the number of the positions included in the root node and the intermediate node is the same as the number of slots included in the positions.

In this embodiment, the root node and the intermediate node include 16 positions that respectively represent different hexadecimal characters; the positions include 16 slots that respectively represent different hexadecimal characters.

In this embodiment, the blockchain data includes any one of the following: transactions included in the block; transaction receipts corresponding to transactions included in the block; The latest account status data corresponding to the blockchain account; the storage content of the smart contract account.

In this embodiment, the logical tree structure includes any one of the following: a transaction tree for storing transactions included in the block; a receipt for storing transaction receipts corresponding to transactions included in the block tree; a state tree used to store the latest account state data corresponding to the blockchain account in the blockchain; a storage tree used to store the storage content of the smart contract account.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, 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.

Memory may include forms of non-persistent memory, random access memory (RAM) and/or non-volatile memory in computer readable media, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, 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 Disc (DVD) or other optical storage, Magnetic tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

The terms "comprising", "comprising" or any other variation thereof are intended to encompass non-exclusive inclusion such that a process, method, article or device comprising a list of elements includes not only those elements, but also other not expressly listed elements, or also include elements inherent to such a process, method, commodity or device. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

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

It will be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of one or more embodiments of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc. made should be included within the protection scope of one or more embodiments of this specification.

Claims

A method of storing data in a blockchain, comprising:

Obtain the key-value key-value pair of the blockchain data to be stored;

Convert the key-value key-value pair of the blockchain data to be stored into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include a plurality of nodes for storing the The position of the characters in the key of the blockchain data, and each position includes a plurality of slots for storing the characters in the key of the blockchain data; The hash value of a layer of nodes;

The key-value key-value pairs of the root node, the intermediate node and the leaf node are stored in the database; in the key-value key-value pairs of the leaf node, the intermediate node and the root node, the value is the value of the node. Storage content, the key is the hash value of the storage content of the node.
The method according to claim 1, wherein the number of layers of the root node and the intermediate node is a fixed value.
The method according to claim 1, wherein the root node and the intermediate node are used to store at least part of the characters in the key of the blockchain data; the at least part of the characters stored by the root node and the intermediate node are the The character string represented by the position in the root node and the intermediate node and the character represented by the slot filled with the hash value in the position are spliced to generate a string.
The method according to claim 3, wherein the leaf node is a bucket data bucket; the bucket data bucket contains several data records; and the data content stored in the data record includes the value of the blockchain data.
The method according to claim 4, wherein the character string corresponding to the key of the blockchain data includes a character prefix and a character suffix; the root node and the intermediate node include a plurality of positions for storing the characters in the character prefix , each position includes a plurality of slots for storing the characters in the character prefix; the data content stored in the data record includes the character suffix and the value of the blockchain data.
The method according to claim 1, wherein the number of the positions included in the root node and the intermediate node is the same as the number of slots included in the positions.
The method according to claim 6, wherein the root node and the intermediate node comprise 16 positions respectively representing different hexadecimal characters; the positions comprise 16 slots respectively representing different hexadecimal characters.
The method of claim 1, the blockchain data comprising any of the following:

Transactions included in the block;

A transaction receipt corresponding to the transaction recorded in the block;

the latest account status data corresponding to the blockchain account in the blockchain;

The storage content of the smart contract account.
The method of claim 8, the logical tree structure comprising any of the following:

The transaction tree used to store the transactions included in the block;

A receipt tree for storing transaction receipts corresponding to transactions included in the block;

A state tree for storing the latest account state data corresponding to the blockchain account in the blockchain;

The storage tree used to store the storage contents of smart contract accounts.
A device for storing data in a blockchain, comprising:

The acquisition module obtains the key-value key-value pair of the blockchain data to be stored;

A conversion module, which converts the key-value key-value pair of the blockchain data to be stored into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include a plurality of The positions of the characters in the keys of the blockchain data, each of which includes a plurality of slots for storing the characters in the keys of the blockchain data; the slots are used to store the The hash value of the next layer node of the link;

The storage module stores the key-value key-value pairs of the root node, the intermediate node and the leaf node in the database; in the key-value key-value pairs of the leaf node, the intermediate node and the root node, value is the storage content of the node, and the key is the hash value of the storage content of the node.
The device according to claim 10, wherein the number of layers of the root node and the intermediate node is a fixed value.
The device according to claim 10, wherein the root node and the intermediate node are used to store at least part of the characters in the key of the blockchain data; the at least part of the characters stored by the root node and the intermediate node are the The character string represented by the position in the root node and the intermediate node and the character represented by the slot filled with the hash value in the position are spliced together to generate a character string.
The device according to claim 12, wherein the leaf node is a bucket data bucket; the bucket data bucket contains several data records; and the data content stored in the data record includes the value of the blockchain data.
The device according to claim 13, wherein the character string corresponding to the key of the blockchain data includes a character prefix and a character suffix; the root node and the intermediate node include a plurality of locations for storing characters in the character prefix , each position includes a plurality of slots for storing the characters in the character prefix; the data content stored in the data record includes the character suffix and the value of the blockchain data.
The device according to claim 10, wherein the number of the positions included in the root node and the intermediate node is the same as the number of slots included in the positions.
The device according to claim 15, wherein the root node and the intermediate node comprise 16 positions respectively representing different hexadecimal characters; the positions comprise 16 slots respectively representing different hexadecimal characters.
The apparatus of claim 10, the blockchain data comprising any of the following:

Transactions included in the block;

A transaction receipt corresponding to the transaction recorded in the block;

the latest account status data corresponding to the blockchain account in the blockchain;

The storage content of the smart contract account.
The apparatus of claim 17, the logical tree structure comprising any of the following:

The transaction tree used to store the transactions included in the block;

A receipt tree for storing transaction receipts corresponding to transactions included in the block;

A state tree for storing the latest account state data corresponding to the blockchain account in the blockchain;

The storage tree used to store the storage contents of smart contract accounts.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method of any one of claims 1-9 by executing the executable instructions.
A computer-readable storage medium having computer instructions stored thereon which, when executed by a processor, implement the steps of the method of any one of claims 1-9.