WO2024021419A1

WO2024021419A1 - Blockchain data storage method and apparatus, and electronic device

Info

Publication number: WO2024021419A1
Application number: PCT/CN2022/135539
Authority: WO
Inventors: 陆钟豪; 俞本权; 卓海振; 任充慧; 田世坤
Original assignee: 蚂蚁区块链科技 (上海) 有限公司
Priority date: 2022-07-29
Filing date: 2022-11-30
Publication date: 2024-02-01
Also published as: CN115221176A

Abstract

A blockchain data storage method, wherein a key-value pair of blockchain data is stored in a database in the form of a root node, an intermediate node and a leaf node in a logical tree structure. The root node and the intermediate node are used for storing characters in the key of the blockchain data, and the leaf node is used for storing the value of the blockchain data. The method comprises: obtaining a key-value pair of blockchain data to be stored; converting the key-value pair of the blockchain data into a root node, an intermediate node and a leaf node in a logical tree structure; caching at least part of nodes among the root node and the intermediate node into a storage medium which supports data overwrite; and generating a data record for recording modification and update details with respect to the at least part of the nodes, and writing the data record and the nodes among the root node, the intermediate node and the leaf node other than the at least part of the nodes into the database for permanent storage.

Description

Blockchain data storage method and device, electronic equipment

This application claims priority to the Chinese patent application filed with the China Patent Office on July 29, 2022, with the application number 202210908663.8 and the invention title "Blockchain data storage method and device, electronic equipment", the entire content of which is incorporated by reference. in this application.

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain data storage method and device, 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 blockchain node equipment, the blockchain data that needs to be stored and maintained usually includes block data and account status data corresponding to the blockchain account in the blockchain; and the block data can further include area 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 blockchain node device stores the various blockchain data shown above, the above various blockchain data can usually be organized into a logical tree structure in the database in the form of key-value pairs. storage. For example, in practical applications, blockchain data can be organized into a Merkle tree in the form of key-value pairs and stored in the database.

Contents of the invention

This specification proposes a blockchain data storage method. The key-value pairs of the blockchain data are stored in the database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; so The root node and the intermediate node are used to store the characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node on the tree structure passes its hash The value is linked to the node of the previous layer; the method includes:

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

Convert the key-value pairs of the blockchain data into root nodes, intermediate nodes and leaf nodes in a logical tree structure;

Cache at least some of the root nodes and intermediate nodes to a storage medium that supports overwriting data, so as to modify and update at least some of the nodes in the storage medium; and, generate a record for all the nodes. A data record of the modification update details of at least part of the nodes is recorded, and the data record and other nodes among the root node, intermediate node and leaf node except the at least part of the nodes are written into the database for persistent storage.

This specification also proposes a blockchain data storage method. The key-value pairs of the blockchain data are stored in the database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; The root node and intermediate node are used to store the characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node on the tree structure passes through its The hash value is linked to the nodes of the upper layer; wherein, at least some of the root nodes and intermediate nodes are cached in a storage medium that supports overwriting data, and are modified and updated in the storage medium; and, using Data records that record modification and update details for at least some of the nodes, and other nodes among the root nodes, intermediate nodes and leaf nodes other than at least some of the nodes are persistently stored in the database; the method include:

Determine whether at least some of the nodes cached in the storage medium meet persistent storage conditions;

If at least some of the nodes cached in the storage medium meet persistent storage conditions, the at least some of the nodes cached in the storage medium are written into the database for persistent storage. This specification also proposes a blockchain data storage device. The key-value pairs of the blockchain data are stored in the database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; The root node and intermediate node are used to store the characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node on the tree structure passes through its The hash value is linked to the node of the previous layer; the method includes:

Get the module to get the key-value pairs of the blockchain data to be stored;

A conversion module that converts key-value pairs of the blockchain data into root nodes, intermediate nodes and leaf nodes in a logical tree structure;

A storage module that caches at least part of the root node and intermediate nodes to a storage medium that supports overwriting data, so as to modify and update the at least part of the nodes in the storage medium; and, generate Record data records of modification update details for at least part of the nodes, and write the data records and other nodes among the root node, intermediate node and leaf node except the at least part of the nodes into the database for persistence storage.

This specification also proposes a blockchain data storage device. The key-value pairs of the blockchain data are stored in the database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; The root node and intermediate node are used to store the characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node on the tree structure passes through its The hash value is linked to the nodes of the upper layer; wherein, at least some of the root nodes and intermediate nodes are cached in a storage medium that supports overwriting data, and are modified and updated in the storage medium; and, using Data records that record modification and update details for at least some of the nodes, and other nodes among the root nodes, intermediate nodes and leaf nodes except for at least some of the nodes are persistently stored in the database; the device include:

A determination module that determines whether at least some of the nodes cached in the storage medium meet persistent storage conditions;

A writing module, if at least some of the nodes cached in the storage medium meet persistent storage conditions, write at least some of the nodes cached in the storage medium into the database for persistent storage. The above technical solutions have the following technical effects:

When storing the key-value pairs of blockchain data in the database in the form of root nodes, intermediate nodes, and leaf nodes on a logical tree structure, by converting the root nodes on the above logical tree structure Caching at least some of the nodes and intermediate nodes in a storage medium that supports overwriting data, and modifying and updating at least some of the nodes in the storage medium can alleviate the problem of converting the root node to the above logical tree structure. , the write amplification effect caused by the repeated writing of at least some nodes among the intermediate nodes to the database, thereby improving the storage performance of the above-mentioned database.

Description of drawings

Figure 1 is a tree structure diagram of an MPT tree provided by an exemplary embodiment;

Figure 2 is a schematic diagram of organizing the account status data of each blockchain account in the blockchain into an MPT status tree in the form of key-value pairs according to an exemplary embodiment;

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

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

Figure 5 is a structural diagram of a Tree node provided by an exemplary embodiment;

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

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

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

Figure 9 is a block diagram of a blockchain data storage device provided by an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

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

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.

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 types, such as private chain + alliance chain, alliance chain + public chain, etc.

Among them, the public chain is the most decentralized. Participants who join the public chain (also called nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, etc. Moreover, each node can freely join or exit the network and perform related operations.

On the contrary, the private chain has the writing permission of the network controlled by an organization or institution, and the data reading permission is regulated by the organization. Simply put, 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 specific organizations.

The alliance 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 nodes join the network through authorization and form an alliance of interests to jointly maintain the operation of the blockchain.

In the field of blockchain, an important concept is account. For blockchain networks that support smart contracts, blockchain accounts can usually be divided into the following two types:

Contract account: stores the executed smart contract code and the value of the state in the smart contract code. It can usually only be activated through external account calls;

External account (Externally owned account): It is an account directly controlled by the user, also called a user account.

The design of external accounts and contract accounts is actually the mapping of account addresses to account status. The status of an account is usually represented by a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the blockchain usually changes.

In an example, the account structure usually includes fields such as Balance, Nonce, Codehash, and Storageroot. in:

Balance field, used to maintain the current account balance of the account;

Nonce field, used to maintain the number of transactions for this account. It is a counter used to ensure that each transaction can and can only be processed once, effectively avoiding replay attacks;

Codehash field, used to maintain the contract code of the account. In practical applications, only the hash value of the contract code is usually maintained in the Codehash field.

The Storageroot field is used to maintain the storage content of this account. For contract accounts, an independent persistent storage space is usually allocated to store the contract data corresponding to the contract account. This independent storage space is usually called the account storage of the contract account.

The storage content of contract accounts is usually constructed into a logical tree structure and stored in the form of key-value pairs. For example, MPT (Merkle Patricia Trie) tree is a logical tree structure commonly used in the blockchain field for storing and maintaining blockchain data. This tree structure usually includes the root node, Intermediate nodes and leaf nodes.

Among them, the logical tree structure constructed based on the storage content of the contract account is usually called the Storage tree. The Storageroot field usually only maintains the hash value of the root node of the Storage tree. Among them, for external accounts, the field values of the Codehash field and the Storageroot field shown above are both null.

In practical applications, most blockchain models usually use Merkle trees; or logical tree structures such as Merkle tree variants designed based on the Merkle tree data structure to store and maintain data.

For example, the MPT tree is a variant of the Merkle tree that is used to store and maintain blockchain data and incorporates the tree structure of a Trie dictionary tree.

Another example is the FDMT (Fixed Depth Merkle Tree) tree, which is also a variant of the Merkle tree that is used to store and maintain blockchain data and incorporates the tree structure of the Trie dictionary tree.

The following is an example of using an MPT tree to store blockchain data.

In one example, the blockchain data that needs to be stored and maintained in the blockchain usually includes account status (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 (also called world state), MPT transaction tree and MPT receipt in the form of key-value pairs. tree and three MPT trees, which 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 into 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 in the form of key-value pairs by the account status (state) data of all accounts in the blockchain (including external accounts and contract accounts).

The MPT transaction tree is an MPT tree organized by the transaction data in the blockchain in the form of key-value pairs.

The MPT receipt tree is the transaction receipt corresponding to each transaction generated after the transaction in the block is executed. It is an MPT tree organized in the form of key-value pairs.

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

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

For example, after a "transfer transaction" in the block is executed, the balances of the transfer-out account and the transfer-in account related to the "transfer transaction" (that is, the field values of the Balance fields of these accounts) are usually also Changes will occur. After the node device completes the execution of 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 based on the current account status data of all accounts in the blockchain. MPT status tree is used to maintain the latest status of all accounts in the blockchain.

Whenever a latest block is generated in the blockchain and the transaction in the latest block is executed, causing the account status of some accounts in the blockchain to change, the node device needs to be based on all accounts in the blockchain. The latest account status data is used to reconstruct an MPT status tree. In other words, each block in the blockchain has a corresponding MPT state tree. The MPT status tree maintains the latest account status of all accounts in the blockchain after the transactions in the block are executed.

Please refer to Figure 1, which is a tree structure diagram of an MPT tree shown in this specification.

Among them, it should be noted that the connection relationship of each node in Figure 1 is only schematic.

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

There are usually three types of nodes in the MPT tree, namely leaf node, extension node and branch node. Among them, the root node of the MPT tree can usually be an extension node. The intermediate nodes of the MPT tree can usually be branch nodes or other extension nodes.

Among them, the extension node and the branch node can be collectively referred to as character nodes, which are used to store the character prefix part of the string corresponding to the key (that is, the account address) of the account status data. For MPT trees, the above character prefix part usually refers to shared character prefixes (shared nibbles). The shared character prefix refers to the same prefix of one or more characters that the keys of all account status data (that is, the blockchain account address) have. The above leaf nodes are used to store the character suffix part (key-end) and Value (that is, specific account status data) of the string corresponding to the key of the blockchain 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 at the next level linked to the extension node (that is, the hash value shown in Figure 1 Next node).

The branch node contains 17 slots. The first 16 slots correspond to the 16 possible hexadecimal characters in the key. One character corresponds to a nibble (half byte). Each slot in the first 16 slots bits, each representing a character in the shared character prefix of an account address. These slots are used to fill the hash value of the node at the next level linked to the branch node. The last slot is the value slot, which is usually a null value.

Leaf nodes are used to store the character suffix of the account address (i.e., the key-end shown in Figure 1), and the value of the account status data (i.e., the account structure described above). Among them, the character suffix of the account address and the shared character prefix of the account address together form a complete account address. The character suffix refers to the suffix consisting of the last or multiple characters other than the shared character prefix of the account address.

Please refer to Figure 2. Figure 2 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 as shown in this specification.

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

Table 1

Among them, it should be noted that in Table 1, the blockchain accounts corresponding to the account addresses in the first three rows are external accounts, and the Codehash and Storage root fields are empty. The blockchain account corresponding to the account address in line 4 is a 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.

The MPT status tree is finally organized according to the account status data in Table 1, as shown in Figure 3.

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

In Figure 2, the prefix field is a prefix field shared by extension nodes and leaf nodes. 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 extended node containing an even number of nibbles; as mentioned above, a nibble represents a nibble and is composed of 4-bit binary. One nibble can correspond to a character that constitutes an account address. The value of the prefix field is 1, indicating an extended node containing an odd number of nibbles; the value of the prefix field is 2, indicating a leaf node containing an even number of nibbles; the value of the prefix field is 3, indicating an odd number of nibbles. The leaf node of (s). As for the branch node, since it is a parallel single nibble character node, the branch 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 the 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 fields in the branch node correspond 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 on the MPT tree, then the branch node The Value field can be empty. The hash value used to fill the next layer node 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 values of each node on the search path from the root node to the leaf node constitute 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 above fields such as Balance, Nonce, Code, and storage can be encoded and then filled in the Value field of the leaf node.

Please refer to Figure 3. Figure 3 is a schematic diagram of organizing the contract data stored in the storage space corresponding to the contract account into an MPT storage tree as shown in this specification.

Please continue to refer to Table 1. The account with the account address "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 root node of the storage tree will also be linked to the leaf node corresponding to the contract account in the MTP status tree shown in Figure 1 based on its hash value. The hash value S1 of the root node of the storage tree will be added to the storage root field in the account status stored in the leaf node corresponding to the contract account in the MTP status tree shown in Figure 1. At this time, the storage tree can be called a subtree extended from the leaf node corresponding to the contract account in the MTP status tree shown in Figure 1.

Assume that the key-value pair of contract data stored in the storage space of the contract account is as shown in Table 2 below:

Table 2

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

The basic structure of the storage tree shown in Figure 3 is similar to the MTP status tree shown in Figure 2, and will not be described again in this specification.

Furthermore, whether it is a node on the MPT state tree as shown in Figure 2 or a node on the storage tree as shown in Figure 3, it can be stored in the database in the form of Key-Value pairs for persistent storage. .

For example, the above-mentioned database can usually be stored in a persistent storage medium (such as a storage disk) mounted on the above-mentioned node device. The above storage medium is the physical storage corresponding to the above database.

Among them, the key in the Key-Value pair corresponding to the node in the above-mentioned MPT state tree or the above-mentioned storage tree can be the hash value of the data content contained in the node; the value in the key-value pair of the node can be specifically The data content contained by node.

When storing the node on the above-mentioned MPT state tree or the above-mentioned storage tree into the database, the hash value of the data content contained in the node can be calculated (that is, hash calculation is performed on the entire node), and the calculated hash value is used as the key. Use the data content contained in the node as value to generate a Key-Value pair. Then, store the generated Key-Value pair in the database. When you need to query the node on the above-mentioned MPT status tree or the above-mentioned storage tree, you can perform content addressing based on the hash value of the data content contained in the node as the key.

Please refer to Figure 4, which is a tree structure diagram of an FDMT tree shown in this specification.

The above-mentioned FDMT tree is also a Merkle tree variant that incorporates the tree structure of a Trie dictionary tree.

In practical applications, blockchain data can also be organized into FDMT trees in the form of key-value pairs and stored in the database.

As shown in Figure 4, the tree structure of the FDMT tree can include the first N layers of Tree nodes (Figure 4 shows 3 layers, which is only schematic), and the last layer of Leaf nodes (i.e. leaves). node). Among the Tree nodes in the first N layers, the Tree node in the first layer will serve as the root node, and the Tree nodes in other layers except the first layer will serve as intermediate nodes.

Among them, what is different from the MPT tree described above is that each Tree node (that is, the root node and the intermediate node) of the first N layers of the above-mentioned FDMT tree will adopt a unified data structure.

As shown in Figure 4, the first N layers of Tree nodes on the above-mentioned FDMT tree can each include multiple blocks representing different characters; the above-mentioned blocks are the "positions" of characters in the key used to store blockchain data. Each block can further include multiple slots representing different characters. The above slot is 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. Among them, the nodes of each layer on the above-mentioned FDMT tree can still be linked by filling the hash value (hash pointer) of the node of the next layer into the node of the upper layer. That is, the nodes in the above FDMT tree are linked to the nodes in the upper layer through their own hash values. Correspondingly, the above slots can be used to fill the hash value of the next-level node linked to the current Tree node. The node at the next level of the Tree node can still be a Tree node or a Leaf node.

It should be explained that the link relationship between the nodes at each layer on the above-mentioned FDMT tree shown in Figure 4 is only schematic and is not a special link relationship between the nodes at each layer on the above-mentioned FDMT tree. limited.

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

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

For each Tree node on the above-mentioned FDMT tree shown in Figure 4, the actual stored characters can specifically be the characters represented by the block in the Tree node (that is, a non-empty block with at least one slot filled with a hash value), A string generated by concatenating the characters represented by the slots filled with hash values (that is, non-empty slots) in the block.

Among them, it should be noted that in actual applications, each block in the Tree node can represent only one character. That is, based on the storage format of the Tree node shown in Figure 4, some of the characters in the character prefix of the key of the above-mentioned blockchain data actually stored by each Tree node are strings with a length of 2 characters.

For example, please refer to Figure 5, which is a structural diagram of a Tree node shown in this specification;

As shown in Figure 5, the Tree node contains 16 blocks representing different hexadecimal characters. Each block further includes 16 slots that represent different hexadecimal characters (only the 16 slots included in block 6 are shown in Figure 5). Assume that block6 (represents hexadecimal character 6) in the Tree node is a non-empty block, and slot4 (represents hexadecimal character 4), slot6 (represents hexadecimal character 6) and slot9 (represents The hexadecimal character 9) is a non-empty slot filled with the hash value of the next-level node linked to the Tree node; then some of the characters in the character prefix of the key of the above-mentioned blockchain data stored in the Tree node are: Hexadecimal strings "64", "66" and "69".

Among them, the number of blocks contained in the above-mentioned Tree node and the number of slots contained in each block are not specifically limited in this specification. In practical applications, the number of sub-blocks contained in the above-mentioned Tree node can be determined based on the number of types of character elements contained in the string corresponding to the key of the above-mentioned blockchain data; and, the number of slots contained in the sub-blocks quantity.

For example, assume that the key corresponding to the above-mentioned blockchain data is a hexadecimal string. At this time, the number of character element types contained in the string corresponding to the key of the above-mentioned blockchain data is 16; then the number of character elements contained in the above-mentioned Tree node The number of blocks and the number of slots contained in each block can be 16.

Among them, the number of layers of Tree nodes contained in the above-mentioned FDMT tree can be a fixed value; in practical applications, the value of the above-mentioned N can be an integer greater than or equal to 1. That is to say, the above-mentioned FDMT tree can be a Merkle tree that contains at least one layer of Tree nodes, and the number of layers of Tree nodes contained is relatively fixed.

For example, in one example, taking the key of the above blockchain data as a blockchain account address, assuming that the blockchain account address supported by the blockchain system is designed, the first 6 address characters can be the same. Well, in this case, since the length of the characters stored in the Tree node is 2 characters; therefore, the above FDMT tree can be designed as a tree structure containing three layers of Tree nodes.

Furthermore, the Tree node and Leaf node on the FDMT tree shown in Figure 4 can also be persistently stored in the database in the form of Key-Value pairs. Among them, the key in the Key-Value pair corresponding to the Tree node or Leaf node on the above-mentioned FDMT tree can specifically be the hash value of the data content contained in the Tree node or Leaf node. The Value in the key-value pair of Tree node or Leaf node can be the data content contained in Tree node or Leaf node.

When storing the Tree node or Leaf node on the FDMT tree to the database, you can also calculate the hash value of the data content contained in the Tree node or Leaf node (that is, perform hash calculation on the entire node), and use the calculated hash value As the key, use the data content contained in the Tree node or Leaf node as the value to generate a Key-Value pair. Then, store the generated Key-Value pair in the database. When you need to query the node on the above FDMT tree, you can perform content addressing based on the hash value of the data content contained in the node as the key.

It should be noted that the tree structure of the FDMT tree shown in Figure 4 can be used to store the account status data of each blockchain account in the blockchain, and can also be used to store the storage space corresponding to a certain contract account. Stored contract data.

Among them, the FDMT tree used to store the account status data of each blockchain account in the blockchain can be called the FDMT status tree. The FDMT tree used to store contract data stored in the storage space corresponding to a certain contract account can be called an FDMT storage tree.

The root node on the above-mentioned FDMT storage tree can also be linked to the leaf node corresponding to the above-mentioned contract account in the above-mentioned FDMT status tree through its hash value. The hash value of the root node on the FDMT storage tree can also be added to the storage root field in the account status stored in the leaf node corresponding to the contract account in the above FDMT status tree, which will not be described again.

Among them, it should be noted that, whether it is the MPT tree shown in Figure 1 or the FDMT tree shown in Figure 4, the actual data stored in the Leaf node on its tree structure usually has a larger size than other types of nodes. Data capacity. For example, the value of the above-mentioned blockchain data actually stored by the above-mentioned Leaf node is usually the original content of the above-mentioned blockchain data. The original content of the above-mentioned blockchain data is relative to the character prefix of the above-mentioned blockchain data. It also takes up more storage space. Therefore, in order to ensure that the above-mentioned Leaf nodes can have larger data capacity, whether it is the MPT tree shown in Figure 1 or the Leaf node on the FDMT tree shown in Figure 4, they are usually designed in the form of large data blocks.

The specific form and storage structure of the above-mentioned data blocks are not particularly limited in this specification.

For example, in practical applications, the above leaf nodes may be in the form of bucket data buckets. The above-mentioned bucket data bucket may specifically be a container or storage space used to store data.

For example, please refer to Figure 6, which is a structural diagram of a bucket data bucket shown in this specification.

As shown in Figure 6, the above bucket data bucket (ie, the bucker node shown in Figure 6) can include several data records. Among them, each data record corresponds to a piece of blockchain data, which is used to store the character suffix (ie, the key-end shown in Figure 6) and value of the key of the above-mentioned blockchain data. That is, a data record refers to a storage record that includes the character suffix and value of the key of the above blockchain data.

It should be noted that the structure of the bucket data bucket shown in Figure 6 is specifically explained by taking the Leaf node on the FDMT tree shown in Figure 4 as an example. In practical applications, the structure of the bucker node shown in Figure 6 can also be used as the Leaf node of the MPT tree shown in Figure 1, which will not be described again in this specification.

It can be seen from the above description that whether it is the MPT tree shown in Figure 1 or the FDMT tree shown in Figure 4, there will be some nodes containing several slots. For example, the branch node on the MPT tree shown in Figure 1 and the Tree node of the first N layers of FDMT shown in Figure 4 both contain several slots for storing characters in the key of the blockchain data. Bit.

In practical applications, for those nodes in the MPT tree or FDMT tree that contain multiple slots, if the content stored in only part of the slots in the node is updated, then even if other slots except this part of the slots are updated, The content stored in the slot has not been updated. Usually, after the update of this part of the slot is completed, the entire node needs to be rewritten to the database for persistent storage, resulting in an obvious write amplification effect.

Among them, it needs to be explained that the so-called write amplification refers to the effect of writing bandwidth amplification caused by the data to be written being smaller than the data actually written.

For example, for a node containing multiple slots in an MPT tree or FDMT tree, if only the content stored in some slots in the node is updated, the content stored in this part of the slots needs to be written. However, due to the MPT The nodes on the tree or FDMT tree are a complete and non-divisible whole of data. Therefore, even if only the content stored in some slots needs to be written, the entire node has to be written to the database on the disk, resulting in the need to write The input data is smaller than the final actual written data, resulting in the above-mentioned write amplification effect, resulting in a waste of write bandwidth.

Moreover, since the Tree nodes in the first N layers of the FDMT tree all use a data structure containing multiple slots, the write amplification effect is particularly obvious when using the FDMT tree to store blockchain data.

In view of this, this specification proposes a technical solution to optimize the write amplification effect produced when using a logical tree structure to store blockchain data.

During implementation, the key-value pairs of blockchain data can be stored in the database in the form of root nodes, intermediate nodes and leaf nodes in a logical tree structure; the root nodes and intermediate nodes are used to store blocks. Characters in the key of the chain data; leaf nodes are used to store the value of the blockchain data; any node on the above tree structure is linked to the node on the previous level through its hash value.

When using the above logical tree structure to store blockchain data, the blockchain data to be stored can be obtained, and the blockchain data can be converted into root nodes, intermediate nodes and leaf nodes on the logical tree structure;

On the one hand, at least some of the above-mentioned root nodes and intermediate nodes can be cached to a storage medium that supports overwriting data, so that at least some of the above-mentioned nodes can be modified and updated in the storage medium;

On the other hand, a data record for recording modification and update details for at least part of the above-mentioned nodes may also be generated, and the above-mentioned data records may be recorded with other nodes among the above-mentioned root nodes, intermediate nodes and leaf nodes except for the above-mentioned at least part of the nodes. Write to the database for persistent storage.

In the above technical solution, at least part of the root nodes and intermediate nodes on the above-mentioned logical tree structure are cached in a storage medium that supports overwriting data, and the at least part of the nodes are processed in the storage medium. Modification and update can alleviate the write amplification effect caused by repeatedly writing at least some of the root nodes and intermediate nodes in the above-mentioned logical tree structure to the database, thereby improving the storage performance of the above-mentioned database.

For example, in practical applications, if there are nodes containing multiple slots in the root node and intermediate nodes of the above logical tree structure, then these nodes will be cached in a storage medium that supports overwriting data. Overwrite writing can be used in the storage medium to modify and update at least some of the nodes, and these overwritten nodes will no longer need to be written to the database in the disk, thus avoiding the need to write these to the database. The entire node writes to the database on disk, causing the write amplification effect described above.

Please refer to Figure 7, which is a flow chart of a blockchain data storage method provided by an exemplary embodiment. The method is applied to blockchain node equipment; the key-value pairs of the blockchain data are stored in the database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; the The root node and the intermediate node are used to store the characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node on the tree structure passes its hash value Link with the node of the previous layer; the method includes the following steps:

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

The above-mentioned blockchain data to be stored may specifically include any type of data that needs to be persistently stored in the blockchain.

In one embodiment shown, the above-mentioned blockchain data to be stored may specifically include account status data corresponding to the blockchain account on the blockchain.

For example, as mentioned above, in practical applications, blockchain accounts in the blockchain can usually include external accounts and contract accounts. Therefore, the account status data corresponding to the blockchain account on the blockchain can be specifically Including account status data corresponding to user accounts on the blockchain (for example, it can be account balance data), and state variable data stored in contract accounts on the blockchain (for example, it can be certificate data stored in smart contracts) .

Of course, in practical applications, the above-mentioned blockchain data to be stored may also include transaction data published to the blockchain network, receipt data corresponding to the transaction data generated after the transaction data is executed, and so on.

In one example, when the node device in the blockchain obtains the key-value pair of the blockchain data to be stored, the node device can locally store the area after obtaining the blockchain data to be stored. Blockchain data is processed into key-value pairs.

In another example, the step of processing the blockchain data to be stored into key-value pairs can also be completed by a third party. The node device can directly obtain the data processed by the third party from the third party. The key-value pair of the blockchain data to be stored.

Among them, the key in the key-value pair of the blockchain data may refer to the primary key of the blockchain data in the database. This primary key can specifically serve as a query index. The value in the key-value pair of blockchain data specifically refers to the data content of the above-mentioned blockchain data.

It should be noted that for different types of blockchain data, there may usually be certain differences in the keys in the key-value pairs.

For example, if the above blockchain data is specifically the account status data corresponding to the blockchain account in the blockchain, then the key in the key-value pair of the account status data can specifically be the account of the blockchain account. address.

If the above blockchain data is specifically transaction data in the blockchain or receipt data corresponding to the transaction data, the key in the key-value pair of the transaction data or receipt data corresponding to the transaction data may specifically be: Transaction identifier; for example, in practical applications, the transaction identifier can be the hash value of the transaction, or it can also be the transaction ID assigned to the transaction when consensus is reached on the transaction.

Step 704: Convert the blockchain data key-value pairs into root nodes, intermediate nodes and leaf nodes in a logical tree structure;

For the key-value pairs of the blockchain data to be stored, they can be organized into a logical tree structure and stored in the database in the form of nodes on the logical tree structure.

Among them, the so-called logical tree structure refers to a tree structure constructed on a logical level based on the nodes stored in the database and the link relationships between the nodes.

For example, the above logical tree structure may specifically include multi-layer nodes, and the multi-layer nodes may be stored in node units in the underlying physical storage (such as a disk) hosting the database. When you need to use the blockchain data stored in the tree structure of the above logic, you can specifically load the multi-layer nodes stored in the database into the memory, and restore them at the logical level in the memory according to the link relationship between each node. Produce a specific tree structure.

In an embodiment shown, the above-mentioned logical tree structure may be a Merkle tree that is integrated with the tree structure of a dictionary tree; for example, it may be the above-mentioned MPT tree or the above-mentioned FDMT tree.

In practical applications, the above logical tree structure may include root nodes, intermediate nodes and leaf nodes. After obtaining the key-value pair of the blockchain data to be stored, the node device in the blockchain can convert the key-value pair of the blockchain data to be stored into the above logical tree shape. Root nodes, intermediate nodes and leaf nodes on the structure.

Among them, when converting the key-value pairs of the blockchain data into the root nodes, intermediate nodes and leaf nodes of the logical tree structure, you can specifically start from the root node of the logical tree structure and search for To store the root node, intermediate node and leaf node of the key-value pair of the blockchain data, and then query the root node, intermediate node and leaf node based on the key-value pair of the blockchain data Make an update. In this case, the updated root node, intermediate nodes, and leaf nodes are the root nodes, intermediate nodes, and leaf nodes that are converted from the key-value pairs of the above blockchain data.

It should be noted that if starting from the root node of the logical tree structure, in addition to the root node, no intermediate nodes and leaf nodes used to store the key-value pairs of the blockchain data are found. In the logical tree structure, intermediate nodes and leaf nodes for storing the key-value pairs of the blockchain data can be created based on the key-value pairs of the blockchain data, and then based on the The key-value pair of the blockchain data updates the queried root node, and the newly created intermediate nodes and leaf nodes.

Of course, if the blockchain data is written to the logical tree structure for the first time, the key-value pairs of the above blockchain data are converted into the root node, intermediate node and node of the logical tree structure. For leaf nodes, you can also initially create root nodes, intermediate nodes, and leaf nodes that store the key-value pairs of the blockchain data. The root node, intermediate node, and leaf node created by initialization at this time are the root node, intermediate node, and leaf node that are converted from the key-value pairs of the above blockchain data.

Among them, the nodes in the above logical tree structure can still be linked to the nodes in 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 corresponding to the key-value key value of the blockchain data. The above leaf nodes are specifically used to store the value of blockchain data (that is, the specific content of blockchain data). The number of layers of intermediate nodes may be one layer or multiple layers, and is not particularly limited in this specification.

For example, in one 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 the intermediate node can be used for storage characters in the above character prefix. The above leaf nodes can be used to store the above character suffix and the value of the blockchain data.

On the one hand, the root node and intermediate nodes in the above logical tree structure can store the characters in the key of the blockchain data; therefore, the above logical tree structure has the characteristics of a Trie dictionary tree. On the other hand, the nodes in the above logical tree structure can be linked to the nodes in the upper layer through their own hash values. Therefore, the above logical tree structure also has the characteristics of Merkle tree. It is easy to understand that the logical tree structure described in this specification can be a Merkle tree variant similar to an MPT tree or an FDMT tree that incorporates the tree structure of a Trie dictionary tree. It should be supplemented that when the above-mentioned blockchain data is account status data corresponding to a blockchain account on the blockchain, the above-mentioned logical tree structure may be based on each block in the blockchain. A Merkle tree generated from the key-value pairs of the account status data corresponding to the chain account. At this time, the Merkle tree can be called a Merkle state tree.

In actual applications, in order to improve the access performance of the Merkle state tree, the above-mentioned Merkle state tree is usually split into a current Merkle state tree (Current State Tree) and a historical Merkle state tree (History State Tree). Among them, the current Merkle state tree is a Merkle state tree organized by the latest account status of each blockchain account; the historical Merkle state tree is a Merkle state tree organized by the historical account status of each blockchain account. Each block has a corresponding current Merkle state tree and historical Merkle state tree.

In this scenario, since the current Merkle state tree maintains the latest account status of each blockchain account, based on this feature, the nodes on the current Merkle state tree usually perform frequent writing, modification and update operations. . Based on this, in this specification, the logical tree structure described in step 702 and step 706 may specifically refer to the above-mentioned current Merkle state tree. That is, for the above-mentioned current Merkle state tree, the technical solution described in steps 702 to 706 can be adopted, while for the historical Merkle state tree, the storage solution in the existing technology can still be adopted. Of course, in practical applications, the technical solution described in steps 702 to 706 can also be used for the historical Merkle state tree.

Step 706: Cache at least part of the root node and intermediate nodes to a storage medium that supports overwriting data, so as to modify and update the at least part of the nodes in the storage medium; and, generate Record data records of modification update details for at least part of the nodes, and write the data records and other nodes among the root node, intermediate node and leaf node except the at least part of the nodes into the database for persistence storage.

Convert the key-value pairs of the above blockchain data into root nodes, intermediate nodes and leaf nodes on the logical tree structure, and convert them into root nodes, intermediate nodes and leaf nodes on the above logical tree structure. Afterwards, the above root nodes, intermediate nodes and leaf nodes can be stored in the database.

Among them, it should be noted that in actual applications, the above-mentioned root nodes, intermediate nodes and leaf nodes are usually written into the database for persistent storage. However, in this specification, in order to ease the need to write the above-mentioned root nodes, intermediate nodes Due to the write amplification effect caused by persistent storage in the database, when storing the above-mentioned root nodes and intermediate nodes, a completely different storage strategy can be adopted from that of leaf nodes.

On the one hand, at least some of the above-mentioned root nodes and intermediate nodes can no longer be written to the above-mentioned database for persistent storage by default, but can be cached to the storage on the node device of the blockchain that supports overwriting data. medium, and modify and update at least some of the above-mentioned nodes in the above-mentioned storage medium.

Among them, in one example, the above-mentioned storage medium that supports overwriting data may be a memory mounted on a node device in the blockchain. Of course, in addition to being a memory, the above storage medium can also be other forms of storage media that support overwriting data, which are not specifically limited in this specification. For example, in practical applications, the above-mentioned storage medium may also be a solid-state hard drive.

On the other hand, other nodes among the above-mentioned root nodes, intermediate nodes and leaf nodes, except for at least some of the above-mentioned nodes, are still stored by writing to the above-mentioned database for persistent storage by default. In addition, a data record for recording modification and update details for at least some of the above nodes can also be generated, and then the data record and the above other nodes are written into the above database for persistent storage.

For example, in practical applications, when all transactions included in a latest block are executed, the execution of these transactions will usually cause the data content stored in some nodes in the logical tree structure to change. In this case, it is usually necessary to re- Calculate the hash value (i.e. roothash) of the root node of the logical tree structure, fill the hash value of the root node into the block header, and then write the updated nodes in the logical tree structure to the database for persistent storage . In related technologies, the process of recalculating the hash value of the root node of the logical tree structure and writing the updated nodes in the logical tree structure to the database for persistent storage is called logical tree structure. The commit operation of the structure. In this specification, specifically, when performing a commit operation on the logical tree structure, the data record and the above-mentioned other nodes can be written into the above-mentioned database for persistent storage.

In an embodiment shown, at least some of the nodes may specifically be nodes including a plurality of slots for storing characters in the key of the blockchain data among the root nodes and intermediate nodes. Of course, in practical applications, at least some of the above-mentioned nodes may also include all root nodes and intermediate nodes in the above-mentioned logical tree structure by default.

For example, in one example, if the above-mentioned logical tree structure is an MPT tree, then at least some of the above-mentioned nodes may be branch nodes (branch nodes) on the MPT tree. In this case, since only the branch node on the MPT tree has multiple slots, only the branch node on the MPT tree can be cached to the above storage medium (that is, only the branch node of the MPT tree can be cached to the storage medium). The branch nodes in the root node and intermediate nodes are cached to the above storage medium).

In another example, if the above-mentioned logical tree structure is an FDMT tree, then at least some of the above-mentioned nodes may be Tree nodes of the first N layers of FDMT. In this case, since the Tree nodes of the first N layers of the FDMT tree have multiple slots, only the Tree nodes of the first N layers of the FDMT tree can be cached to the above storage medium. (That is, all the root nodes and intermediate nodes of the FDMT tree are cached in the above storage medium).

Correspondingly, the above-mentioned data record may specifically be a data record used to record modification and update details for each slot in at least some of the above-mentioned nodes.

The specific form of the above data recording is not particularly limited in this specification.

In an embodiment shown, the above data record may specifically be a WAL (write ahead log) log. Among them, WAL logging technology is an efficient logging algorithm. In a storage system with WAL mode turned on, all data modifications to the storage system will be written to the WAL log before being submitted to the storage system; then, the WAL log will be updated through checkpoint events that are triggered periodically or manually by the user. The data stored in the log file is modified and written to the storage system.

In this case, when at least some of the nodes cached in the storage medium experience data loss due to device abnormalities (such as device endpoints), the at least some nodes cached in the storage medium can be updated based on the WAL logs persistently stored in the database. Perform data recovery.

For example, when a device abnormality causes data loss in at least some of the cached nodes, the user can restore the cached data in the storage medium through exception recovery instructions. The node device in the blockchain can receive the user's abnormal recovery instruction for at least some of the nodes cached in the above storage medium, and then can respond to the above abnormal recovery instruction based on the WAL log stored in the database, cache the storage medium Perform data recovery on at least some of the above nodes.

In an embodiment shown, a persistent storage condition may be set for at least some of the nodes cached in the storage medium. The persistent storage condition specifically refers to at least some of the nodes cached in the storage medium. Write conditions to the database for persistent storage.

In this case, it can be determined whether at least some of the above-mentioned nodes cached in the storage medium satisfy the persistent storage condition; for example, in practical applications, the above-mentioned nodes cached in the storage medium can be determined periodically based on a preset period. Whether at least some nodes meet the persistent storage conditions. If at least some of the nodes cached in the storage medium satisfy the persistent storage condition, at least some of the nodes cached in the storage medium can be further written into the database for persistent storage.

Among them, the above-mentioned persistent storage conditions are not particularly limited in this specification, and can be flexibly set based on actual storage requirements in actual applications.

For example, in one embodiment shown, the above-mentioned persistent storage conditions may specifically include one or a combination of more of the following conditions:

Condition 1: The number of the above data records persistently stored in the above database reaches the threshold;

In this case, when the number of the data records persistently stored in the database reaches a threshold, writing back at least some of the cached nodes to the database in the disk can be triggered for persistent storage.

Condition 2: The storage capacity of persistently stored data records in the above database reaches the threshold;

In this case, when the storage capacity of the data records persistently stored in the database reaches a threshold, writing back at least part of the cached nodes to the database in the disk can be triggered for persistent storage.

Condition 3: Receive the user's persistent storage instruction for at least some of the nodes stored in the storage medium.

In this case, upon receiving a persistent storage instruction input by the user for at least part of the nodes stored in the storage medium, it may be triggered to write back the cached at least part of the nodes to the database in the disk for persistent storage. .

In an embodiment shown, after at least some of the nodes cached in the storage medium are successfully written into the database for persistent storage, in order to improve the storage space utilization of the storage medium, the storage space may be further stored in the database for persistent storage. At least some of the above nodes cached in the media are deleted. In addition, after at least some of the nodes cached in the storage medium are successfully written into the database for persistent storage, based on the same consideration, in order to improve the storage space utilization of the database, the above-mentioned nodes can be further written into the database for persistent storage. Delete the data records persistently stored in the database corresponding to at least some of the above nodes.

In this specification, when storing the root node, intermediate node and leaf node on the above logical tree structure, a completely different storage strategy is adopted from that in related technologies; for example, as mentioned above, in this specification , different from related technologies, at least some of the root nodes and intermediate nodes on the above-mentioned logical tree structure will no longer be persistently stored in the database by default, but will be cached in the above-mentioned storage medium; therefore, When reading the root node, the intermediate node and the leaf node on the above logical tree structure, specifically, a reading method of reading from the above storage medium and the above database respectively may be adopted.

For example, in an embodiment shown, when a node device in the blockchain receives a read instruction for a node on the above-mentioned logical tree structure, the node can be read from the above-mentioned storage medium by default, And when the node is not read from the storage medium, the node is further read from the database.

For example, taking the above logical tree structure as an FDMT tree, since only the branch node in the traditional MPT tree will contain 16 slots for characters in the key of blockchain data, the nodes in the MPT tree When persisting storage in the database, although the write amplification effect will also be caused, the write amplification effect is usually not obvious.

The FDMT tree is significantly different from the traditional MPT tree.

Since the Tree nodes of the first N layers of the FDMT tree will include multiple blocks used to store the characters in the key of the blockchain data, each position will include multiple blocks used to store the characters in the key of the blockchain data. slot; therefore, based on this special data structure, the Tree node on the FDMT tree usually has more slots than the branch node of the MPT tree. For example, if a Tree node contains 16 blocks, and each block contains 16 slots, a Tree node will contain 256 slots, and the number of slots is much larger than the branch nodes on the MPT tree.

Having more slots means that the Tree node on the FDMT tree will have larger data capacity than the branch node on the MPT tree. In this case, when the Tree node on the FDMT tree is written to the database for persistent storage, the write amplification effect caused by it will be more obvious compared to the MPT tree. For example, if the data stored in any of the 256 slots contained in a certain Tree node on the FDMT tree is updated, when the Tree node containing 256 slots is rewritten into the database for persistent storage, its consumption The write bandwidth is obviously much greater than the write bandwidth consumed when writing the entire branch node containing only 16 slots in the MPT tree to the database.

If the storage solution described in the above embodiment is used, the Tree nodes of the first N layers of the FDMT tree are cached in the memory, and modified and updated in the memory, it can avoid repeatedly writing the Tree nodes of the first N layers of the FDMT tree. into the database on disk, thus mitigating the resulting write amplification effect.

Corresponding to the above method embodiments, this 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 in this specification can be applied to electronic devices. The device embodiments may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory and running them through the processor of the electronic device where it is located.

From the hardware level, as shown in Figure 8, it is a hardware structure diagram of the electronic device where the blockchain data storage device of this specification is located. In addition to the processor, memory, network interface, and non-volatile components shown in Figure 8 In addition to the permanent memory, the electronic device where the device in the embodiment is located may also include other hardware based on the actual functions of the electronic device, which will not be described again.

Figure 9 is a block diagram of a blockchain data storage device according to an exemplary embodiment of this specification.

Please refer to Figure 9. The blockchain data storage device 90 can be applied in the electronic device shown in Figure 8, wherein the key-value pairs of the blockchain data are based on the root of the logical tree structure. The form of nodes, intermediate nodes and leaf nodes are stored in the database; the root nodes and intermediate nodes are used to store the characters in the key of the blockchain data; the leaf nodes are used to store the blockchain data value; any node on the tree structure is linked to the node on the previous level through its hash value; the device 90 includes:

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

The conversion module 902 converts the key-value pairs of the blockchain data into root nodes, intermediate nodes and leaf nodes in a logical tree structure;

The storage module 903 caches at least part of the root node and intermediate nodes to a storage medium that supports overwriting data, so as to modify and update the at least part of the nodes in the storage medium; and, generate Data records that record modification and update details for at least part of the nodes, and write the data records and other nodes among the root node, intermediate node and leaf node except the at least part of the nodes into the database. Persistent storage.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, or a game controller. 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 non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. 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), and 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, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

The foregoing describes specific embodiments of this 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 a different order than in the embodiments and still achieve desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain implementations.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the one or more embodiments of this specification. As used in one or more embodiments of this specification 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 should be understood that although one or more embodiments of this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining."

The above 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. Within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent substitutions, improvements, etc. shall be included in the scope of protection of one or more embodiments of this specification.

Claims

A method of storing blockchain data. The key-value pairs of the blockchain data are stored in a database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; the root node , the intermediate node is used to store the characters in the key of the blockchain data; the leaf node is used to store the value of the blockchain data; any node on the tree structure passes its hash value and the above One layer of node links; the method includes:

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

Convert the key-value pairs of the blockchain data into root nodes, intermediate nodes and leaf nodes in a logical tree structure;

Cache at least some of the root nodes and intermediate nodes to a storage medium that supports overwriting data, so as to modify and update at least some of the nodes in the storage medium; and, generate a record for all the nodes. A data record of the modification update details of at least part of the nodes is recorded, and the data record and other nodes among the root node, intermediate node and leaf node except the at least part of the nodes are written into the database for persistent storage.
According to the method of claim 1, the at least some nodes include a plurality of slots for storing characters in the key of the blockchain data; the slots are used to store the next layer linked to the node. The hash value of the node; the data record is used to record modification and update details for each slot in at least some of the nodes.
According to the method of claim 2, the logical tree structure includes a Merkle tree fused with the tree structure of a dictionary tree.
According to the method of claim 3, the blockchain data includes account status data corresponding to the blockchain account on the blockchain;

The Merkle tree generated based on the key-value pairs of the account status data corresponding to each blockchain account in the blockchain includes: the current Merkle status tree generated based on the latest account status data of each blockchain account ; And, a historical Merkle state tree organized based on the historical account status data of each blockchain account; the logical tree structure is the current Merkle state tree.
The method according to claim 3, the logical tree structure includes an MPT tree;

The root node is an extension node on the MPT tree; the intermediate node is the extension node or a branch node on the MPT tree; and at least some of the nodes are on the MPT tree. branch node.
The method according to claim 3, the logical tree structure includes an FDMT tree;

Among them, the root node and the intermediate node on the FDMT tree include multiple locations for storing characters in the key of the blockchain data; each location further includes multiple locations for storing the characters in the blockchain data key. The slot of the character in the key of the data; the slot is used to store the hash of the node at the next level linked to the node; at least some of the nodes are the root node and intermediate nodes on the FDMT tree.
The method of claim 1, further comprising:

Determine whether at least some of the nodes cached in the storage medium meet persistent storage conditions;

If at least some of the nodes cached in the storage medium meet persistent storage conditions, the at least some of the nodes cached in the storage medium are written into the database for persistent storage.
The method of claim 7, further comprising:

After the at least part of the nodes cached in the storage medium is successfully written into the database for persistent storage, the at least part of the nodes cached in the storage medium is further deleted.
The method of claim 7, further comprising:

After the at least part of the nodes cached in the storage medium is successfully written into the database for persistent storage, the data records corresponding to the at least part of the nodes that are persistently stored in the database are further deleted. .
The method according to claim 1, the persistent storage conditions include any one or a combination of more of the following:

The number of persistently stored data records in the database reaches a threshold;

The storage capacity of persistently stored data records in the database reaches a threshold;

Persistent storage instructions for the at least part of the nodes stored in the storage medium are received.
The method of claim 1, further comprising:

In response to a read instruction for a node on the logical tree structure, read the node from the storage medium, and when the node is not read from the storage medium, further read the node from the storage medium. Read the node from the database.
The method of claim 1, the data records include WAL logs.
The method of claim 12, further comprising:

Receive exception recovery instructions for at least some of the nodes cached in the storage medium;

In response to the exception recovery instruction, data recovery is performed on at least some of the nodes cached in the storage medium based on the WAL log stored in the database.
The method of claim 1, the storage medium includes memory.
A blockchain data storage device, the key-value pairs of the blockchain data are stored in the database in the form of root nodes, intermediate nodes and leaf nodes on a logical tree structure; the root node , the intermediate node is used to store the characters in the key of the blockchain data; the leaf node is used to store the value of the blockchain data; any node on the tree structure passes its hash value and the above One layer of node links; the device includes:

Get the module to get the key-value pairs of the blockchain data to be stored;

A conversion module that converts key-value pairs of the blockchain data into root nodes, intermediate nodes and leaf nodes in a logical tree structure;

A storage module that caches at least part of the root node and intermediate nodes to a storage medium that supports overwriting data, so as to modify and update the at least part of the nodes in the storage medium; and, generate Record data records of modification update details for at least part of the nodes, and write the data records and other nodes among the root node, intermediate node and leaf node except the at least part of the nodes into the database for persistence storage.
An electronic device including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor executes the steps of the method according to any one of claims 1-14 by running the executable instructions.
A computer-readable storage medium having computer instructions stored thereon, which when executed by a processor, implements the steps of the method according to any one of claims 1-14.