Blockchain data storage method and device, and electronic equipment

Abstract

A blockchain data storage method, a key-value pair of blockchain data in a logical tree structure of root nodes, intermediate nodes and leaf nodes is stored in a database; the root nodes and the intermediate nodes are used to store characters in the key of the blockchain data; the leaf nodes are used to store values of the blockchain data; comprising: obtaining a key-value pair of the blockchain data to be stored; converting the key-value pair of the blockchain data into root nodes, intermediate nodes and leaf nodes in a logical tree structure; caching at least part of the nodes in the root nodes and the intermediate nodes to a storage medium supporting overlay writing data; generating a data record for recording modification update details of the at least part of the nodes, and writing the data record and other nodes in the root nodes, the intermediate nodes and the leaf nodes except the at least part of the nodes into the database for persistent storage.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and more particularly to a blockchain data storage method, apparatus, and electronic device. Background Technology

[0002] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which multiple node devices jointly participate in "accounting," storing, and maintaining a complete distributed database. For blockchain node devices, the blockchain data that needs to be stored and maintained typically includes block data and account status data corresponding to blockchain accounts; block data can further include block header data, block transaction data, and transaction receipts corresponding to the block transaction data, and so on.

[0003] When storing the various types of blockchain data shown above, blockchain node devices typically organize this data into a logical tree structure in the database, using key-value pairs. For example, in practical applications, blockchain data can be stored in the database as a Merkle tree, also using key-value pairs. Summary of the Invention

[0004] This specification proposes a blockchain data storage method, wherein the key-value pairs of the blockchain data are stored in a database in the form of a root node, intermediate nodes, and leaf nodes in a logical tree structure; the root node and intermediate nodes 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 in the tree structure is linked to the node in the previous layer through its hash value; the method includes:

[0005] Retrieve key-value pairs of blockchain data to be stored;

[0006] The key-value pairs of the blockchain data are converted into root nodes, intermediate nodes, and leaf nodes in a logical tree structure;

[0007] At least some of the root nodes and intermediate nodes are cached in a storage medium that supports overwrite data writing, so that modifications and updates are made to the at least some nodes in the storage medium; and, data records are generated to record the details of the modifications and updates to the at least some nodes, and the data records and other nodes in the root nodes, intermediate nodes and leaf nodes other than the at least some nodes are written to the database for persistent storage.

[0008] This specification also proposes a blockchain data storage method, wherein the key-value pairs of the blockchain data are stored in a 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 characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node in the tree structure is linked to the node in the next layer through its hash value; wherein at least some of the root nodes and intermediate nodes are cached in a storage medium that supports overwrite data writing and are modified and updated in the storage medium; and data records are used to record the modification and update details of the at least some nodes, and the other nodes in the root nodes, intermediate nodes, and leaf nodes other than the at least some nodes are persistently stored in the database; the method includes:

[0009] Determine whether the at least some nodes cached in the storage medium meet the persistent storage conditions;

[0010] If at least some of the nodes cached in the storage medium meet the 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, wherein the key-value pairs of the blockchain data are 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 characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node in the tree structure is linked to the node in the previous layer through its hash value; the method includes:

[0011] The acquisition module retrieves key-value pairs of the blockchain data to be stored.

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

[0013] The storage module caches at least some of the root nodes and intermediate nodes to a storage medium that supports overwrite data writing, so as to modify and update the at least some nodes in the storage medium; and generates data records for recording the modification and update details of the at least some nodes, and writes the data records and other nodes among the root nodes, intermediate nodes and leaf nodes other than the at least some nodes into the database for persistent storage.

[0014] This specification also proposes a blockchain data storage device, wherein the key-value pairs of the blockchain data are stored in a 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 characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node in the tree structure is linked to the node in the next layer through its hash value; wherein at least some of the root nodes and intermediate nodes are cached in a storage medium that supports overwrite data writing and are modified and updated in the storage medium; and data records are used to record the modification and update details of the at least some nodes, and the other nodes of the root nodes, intermediate nodes, and leaf nodes other than the at least some nodes are persistently stored in the database; the device includes:

[0015] The determination module determines whether at least some of the nodes cached in the storage medium meet the persistent storage conditions;

[0016] The write module, if the at least some nodes cached in the storage medium meet the persistent storage conditions, writes the at least some nodes cached in the storage medium into the database for persistent storage. The above technical solution has the following technical effects:

[0017] When storing blockchain data key-value pairs in the form of root nodes, intermediate nodes, and leaf nodes in a logical tree structure in a database, the write amplification effect caused by repeatedly writing at least some of the root nodes and intermediate nodes in the logical tree structure to the database can be mitigated by caching these nodes in a storage medium that supports overwrite data writing and modifying and updating these nodes in the storage medium. This can improve the storage performance of the database. Attached Figure Description

[0018] Figure 1 This is a tree structure diagram of an MPT tree provided in an exemplary embodiment;

[0019] Figure 2 This is a schematic diagram of an exemplary embodiment that organizes the account state data of each blockchain account in the blockchain into an MPT state tree in the form of key-value pairs;

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

[0021] Figure 4 This is a tree structure diagram of an FDMT tree provided in an exemplary embodiment;

[0022] Figure 5 This is a structural diagram of a tree node provided in an exemplary embodiment;

[0023] Figure 6 This is a structural diagram of a bucket data bucket provided in an exemplary embodiment;

[0024] Figure 7 This is a flowchart illustrating a blockchain data storage method as provided in an exemplary embodiment;

[0025] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment;

[0026] Figure 9 This is a block diagram of a blockchain data storage device provided in an exemplary embodiment. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

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

[0029] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application.

[0030] Blockchain is generally classified into three types: public blockchain, private blockchain, and consortium blockchain. Furthermore, combinations of these types are possible, such as private blockchain + consortium blockchain, or consortium blockchain + public blockchain.

[0031] Among them, public blockchains offer the highest degree of decentralization. Participants in a public blockchain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, nodes can freely join or leave the network and perform related operations.

[0032] In contrast, private blockchains control write permissions within a single organization or institution, and read permissions are governed by organizational regulations. Simply put, a private blockchain can be a weakly centralized system with strict restrictions on the number of nodes and a relatively small node count. This type of blockchain is more suitable for use within specific organizations.

[0033] Consortium blockchains are a type of blockchain that falls between public and private blockchains, enabling "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; nodes join the network through authorization and form a consortium of stakeholders to jointly maintain the blockchain's operation.

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

[0035] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0036] Externally owned account: This is an account directly controlled by the user, also known as a user account.

[0037] The design of external accounts and contract accounts is essentially a mapping from account addresses to account states. The state of an account is typically represented by a structure. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes.

[0038] In one example, the account structure typically includes fields such as Balance, Nonce, Codehash, and Storageroot. Among these:

[0039] The Balance field is used to maintain the current account balance.

[0040] The Nonce field is used to maintain the number of transactions for this account. It is a counter used to ensure that each transaction can be processed exactly once, effectively preventing replay attacks;

[0041] The Codehash field is used to maintain the contract code for this account. In practice, the Codehash field typically only maintains the hash value of the contract code.

[0042] The Storageroot field is used to maintain the storage content of this account. For contract accounts, a separate persistent storage space is typically allocated to store the contract data corresponding to that contract account. This separate storage space is usually referred to as the account storage for that contract account.

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

[0044] The logical tree structure built based on the stored content of the contract account is often referred to as a Storage tree. The Storageroot field typically only maintains the hash value of the root node of this Storage tree. For external accounts, both the Codehash and Storageroot fields shown above have null values.

[0045] In practical applications, most blockchain models typically use Merkle trees; or, based on the Merkle tree data structure, they design logical tree structures such as Merkle tree variants to store and maintain data.

[0046] For example, the MPT tree is a Merkle tree variant that incorporates the tree structure of the Trie dictionary tree for storing and maintaining blockchain data.

[0047] For example, the FDMT (Fixed Depth Merkle Tree) is a Merkle tree variant that combines the tree structure of the Trie dictionary tree to store and maintain blockchain data.

[0048] The following explanation uses the MPT tree as an example to illustrate how to store blockchain data.

[0049] In one example, the blockchain data that needs to be stored and maintained typically includes account state data, transaction data, and receipt data. Therefore, in practical applications, the aforementioned account state data, transaction data, and receipt data can be organized into three MPT trees—an MPT state tree (also known as a worldstate), an MPT transaction tree, and an MPT receipt tree—in the form of key-value pairs, and stored and maintained separately.

[0050] In addition to the three MPT trees mentioned above, the contract data stored in the storage space corresponding to the contract account is also usually constructed into an MTP Storage tree (hereinafter referred to as Storage tree). The hash value of the root node of this Storage tree is added to the Storage field of the above structure of the contract account corresponding to this Storage tree.

[0051] The MPT state tree is a tree composed of the account state data of all accounts (including external accounts and contract accounts) in the blockchain, organized in the form of key-value pairs.

[0052] The MPT (Mean Transmission Tree) is a tree composed of transaction data from the blockchain, organized in the form of key-value pairs.

[0053] The MPT receipt tree is a tree that generates a receipt for each transaction after the transactions in a block have been executed. It is organized in the form of key-value pairs.

[0054] 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.

[0055] The MPT transaction tree and MPT receipt tree both correspond to blocks; each block has its own MPT transaction tree and MPT receipt tree. The MPT state tree, however, is a global MPT tree and does not correspond to a specific block. Instead, it encompasses the account state data of all accounts in the blockchain. Each time a new block is generated, and the transactions in that block are successfully executed, the account states of the blockchain accounts (which can be external accounts or contract accounts) associated with those executed transactions typically change accordingly.

[0056] For example, when a "transfer transaction" in a block is completed, the balances (i.e., the values ​​of the Balance field in these accounts) of the sender and receiver accounts associated with that "transfer transaction" typically change accordingly. After a node device completes the execution of transactions in the latest block generated by the blockchain, because the account states in the current blockchain have changed, the node device needs to construct an MPT state tree based on the current account state data of all accounts in the blockchain to maintain the latest state of all accounts in the blockchain.

[0057] Whenever a new block is generated in the blockchain, and the transactions in that block are executed, causing changes in the account states of some accounts in the blockchain, the node devices need to rebuild an MPT state tree based on the latest account state data of all accounts in the blockchain. In other words, each block in the blockchain has a corresponding MPT state tree. This MPT state tree maintains the latest account states of all accounts in the blockchain after the transactions in that block have been executed.

[0058] Please see Figure 1 , Figure 1 This is a tree structure diagram of an MPT tree shown in this specification.

[0059] It should be noted that, Figure 1 The connection relationships between the nodes are only illustrative.

[0060] MPT trees are a relatively traditional and improved variant of Merkle trees, which combine the advantages of both Merkle trees and Trie trees (also known as prefix trees).

[0061] An MPT tree typically includes three types of nodes: leaf nodes, extension nodes, and branch nodes. The root node of an MPT tree is usually an extension node. The intermediate nodes of an MPT tree are usually branch nodes or other extension nodes.

[0062] In this system, extension nodes and branch nodes can be collectively referred to as character nodes, which store the character prefix portion of the string corresponding to the key (i.e., account address) of the account status data. For an MPT tree, this character prefix portion typically refers to shared character prefixes. A shared character prefix is ​​a prefix consisting of one or more identical characters shared by all account status data keys (i.e., blockchain account addresses). The leaf nodes, on the other hand, store the character suffix portion (key-end) of the string corresponding to the blockchain data key and the value (i.e., the specific account status data).

[0063] Extended nodes are used to store one or more characters from the shared character prefix of an account address (i.e., Figure 1 The shared nibble shown, and the hash value of the next level node linked by that extended node (i.e., Figure 1 (The next node is shown).

[0064] The branch node contains 17 slots. The first 16 slots correspond to the 16 possible hexadecimal characters in the key, with each character corresponding to a nibble. Each of the first 16 slots represents a character from the shared character prefix of an account address. These slots are used to fill the hash value of the next level of nodes linked by this branch node. The last slot is the value slot, which is usually empty.

[0065] Leaf nodes are used to store the character suffix of the account address (i.e., Figure 1 The key-end shown is the key, and the value of the account status data (i.e., the account structure described above). 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 last one or more characters excluding the shared character prefix of the account address.

[0066] Please see Figure 2 , Figure 2 This specification illustrates a method for organizing the account state data of various blockchain accounts in a blockchain into an MPT state tree in the form of key-value pairs.

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

[0068]

[0069] Table 1

[0070] 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 accounts corresponding to the account addresses in the fourth row are contract accounts. The Codehash field maintains the hash value of the contract code corresponding to this contract account; the Storage root field maintains the hash value of the root node of the Storage tree formed by the storage content of this contract account.

[0071] The final MPT state tree, organized according to the account status data in Table 1, is as follows: Figure 3 As shown.

[0072] The MPT state tree consists of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which serves as the root node).

[0073] exist Figure 2 In this context, the prefix field is a common prefix field shared by both extended nodes and leaf nodes. Different values ​​of this prefix field can be used to represent different node types.

[0074] For example, a value of 0 in the `prefix` field indicates an extended node containing an even number of nibbles. As mentioned earlier, a nibble represents a half-byte, consisting of 4 bits, and one nibble can correspond to a character that makes up an account address. A value of 1 in the `prefix` field indicates an extended node containing an odd number of nibbles(s); a value of 2 in the `prefix` field indicates a leaf node containing an even number of nibbles; and a value of 3 in the `prefix` field indicates a leaf node containing an odd number of nibbles(s). Branch nodes, being character nodes with parallel single nibbles, do not have the aforementioned `prefix` field.

[0075] The Shared nibble field in the extended node corresponds to the key value of the key-value pairs contained in that extended node, representing the common character prefix among the account addresses; for example, all account addresses in the table above share the common character prefix a7. The Next Node field is filled with the hash value (hash pointer) of the next node.

[0076] The hexadecimal characters 0 to f in the branch node correspond to the key value of the key-value pair contained in that branch node; if the branch node is an intermediate node on the search path of the account address in the MPT tree, the value field of the branch node can be empty. The 0 to f fields are used to fill the hash value of the next level node.

[0077] The Key-end field in a leaf node corresponds to the key value of the key-value pair contained within that leaf node, representing the last few characters of the account address (the character suffix of the account address). The key values ​​of each node along the search path from the root node to the leaf node constitute a complete account address. The Value field of this leaf node is filled with the account status data corresponding to the account address; for example, the structure composed of the aforementioned Balance, Nonce, Code, and storage fields can be encoded and then filled into the Value field of the leaf node.

[0078] Please see Figure 3 , Figure 3This is a schematic diagram illustrating how contract data stored in the storage space corresponding to a contract account is organized into an MPT storage tree, as shown in this specification.

[0079] Please refer to Table 1. The account with the address "a77d397" shown in Table 1 is a contract account. Therefore, the contract data stored in the storage space corresponding to this contract account will be organized into a storage tree. The root node of this storage tree will also be linked to other nodes based on its hash value. Figure 1 The leaf node corresponding to this contract account in the MTP state tree is shown. The hash value S1 of the root node of this storage tree will be added to... Figure 1 The storage root field in the leaf node corresponding to the contract account in the shown MTP state tree contains the account state. At this point, the storage tree can be referred to as... Figure 1 The shown MTP state tree is a subtree extending from the leaf node corresponding to the contract account.

[0080] Assume that the key-value pairs of contract data stored in the storage space of this contract account are as shown in Table 2 below:

[0081]

[0082]

[0083] Table 2

[0084] It should be noted that the contract data stored in the contract account's storage space is typically in the form of state variables. When storing these, state variables can be organized as key-value pairs, such as... Figure 3 The storage is done using the storage tree shown. For example, in one case, 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 value of the variable corresponding to the state variable can be used as the value.

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

[0086] Furthermore, regardless of Figure 2 The nodes on the MPT state tree shown are still as Figure 3 The nodes in the storage tree shown can all be stored persistently in the database as key-value pairs.

[0087] For example, the database described above can typically be stored in persistent storage media (such as storage disks) mounted on the node devices mentioned above. This storage media refers to the physical storage corresponding to the database.

[0088] Specifically, the key in the key-value pair corresponding to the node in the MPT state tree or the 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 the data content contained in the node.

[0089] When storing nodes in the MPT state tree or storage tree to a database, the hash value of the data content contained in the node can be calculated (i.e., a hash calculation is performed on the entire node). The calculated hash value is used as the key, and the data content contained in the node is used as the value to generate a key-value pair. This key-value pair is then stored in the database. When querying a node in the MPT state tree or storage tree, the content can be addressed using the hash value of the data content contained in the node as the key.

[0090] Please see Figure 4 , Figure 4 This is a tree structure diagram of an FDMT tree shown in this specification.

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

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

[0093] like Figure 4 As shown, the tree structure of the FDMT tree can contain the first N levels ( Figure 4 The diagram shows a 3-layer (illustrative only) tree node and the leaf node of the last layer. In the first N layers of tree nodes, the first-layer tree node serves as the root node, and all other tree nodes (excluding the first layer) serve as intermediate nodes.

[0094] Unlike the MPT tree described above, the first N layers of the FDMT tree will use a unified data structure for each tree node (i.e., the root node and intermediate nodes).

[0095] like Figure 4As shown, the first N levels of the tree node in the FDMT tree can each include multiple blocks representing different characters; these blocks are used to store the "positions" of characters in the key of the blockchain data. Each block can further include multiple slots representing different characters. These slots are also used to store characters in the key of the blockchain data.

[0096] For example, Figure 4 The diagram shows that each tree node comprises N blocks. Each block further comprises N slots. In the FDMT tree described above, nodes at different levels can still be linked by filling the hash value (hash pointer) of the next-level node into the node of the previous level. That is, nodes in the FDMT tree are linked to nodes at the previous level through their own hash values. Correspondingly, the slots can be used to fill the hash values ​​of the next-level nodes linked to by the current tree node. The next-level node of a tree node can be either a tree node or a leaf node.

[0097] It needs to be explained that, Figure 4 The link relationships between nodes at each level of the FDMT tree shown above are merely illustrative and are not a specific limitation on the link relationships between nodes at each level of the FDMT tree.

[0098] Please continue reading Figure 4 , Figure 4 Each tree node on the FDMT tree shown above can be used to store at least a portion of the characters in the key of the aforementioned blockchain data.

[0099] The string corresponding to the key of the aforementioned blockchain data can still include a character prefix and a character suffix. In this case, the aforementioned tree node can be used to store the characters in the character prefix of the blockchain data key. The aforementioned leaf node can be used to store the character suffix of the blockchain data key and the value of the aforementioned blockchain data.

[0100] for Figure 4 The characters actually stored in each tree node of the FDMT tree shown above can be the characters represented by the block in the tree node (i.e., a non-empty block with at least one slot filled with a hash value) and the characters represented by the slots in the block filled with hash values ​​(i.e., non-empty slots), which are then concatenated to form a string.

[0101] It should be noted that in practical applications, each block in a tree node can represent only one character. That is, based on... Figure 4 The storage format of the tree node shown is such that a portion of the character prefix of the key of the blockchain data actually stored in each tree node is a string of length 2 characters.

[0102] For example, see Figure 5 , Figure 5 This is a structural diagram of a tree node shown in this specification;

[0103] like Figure 5 As shown, this tree node contains 16 blocks representing different hexadecimal characters. Each block further includes 16 slots, each representing a different hexadecimal character. Figure 5 The image only shows the 16 slots contained in block 6. Assuming that block 6 (representing the hexadecimal character 6) in this tree node is a non-empty block, and slots 4 (representing the hexadecimal character 4), 6 (representing the hexadecimal character 6), and 9 (representing the hexadecimal character 9) in this block are non-empty slots filled with the hash values ​​of the next-level nodes linked to this tree node; then the characters in the prefix of the key of the above blockchain data stored in this tree node are the hexadecimal strings "64", "66", and "69", respectively.

[0104] The number of blocks contained in the aforementioned 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 aforementioned Tree node, and the number of slots contained in each sub-block, can be determined based on the number of character element types contained in the string corresponding to the key of the aforementioned blockchain data.

[0105] For example, assuming the key corresponding to the above blockchain data is a hexadecimal string, the number of character elements contained in the string corresponding to the key of the above blockchain data is 16; then the number of blocks contained in the above Tree node, and the number of slots contained in each block, can both be 16.

[0106] The number of levels of tree nodes in the aforementioned FDMT tree can be a fixed value; in practical applications, the value of N can be an integer greater than or equal to 1. That is, the aforementioned FDMT tree can specifically be a Merkle tree containing at least one level of tree nodes, and the number of levels of tree nodes is relatively fixed.

[0107] For example, taking the blockchain data key as a blockchain account address, assuming the blockchain system supports blockchain account addresses where the first 6 address characters can be the same, then, since the length of the characters stored in a tree node is 2 characters, the above FDMT tree can be designed as a tree structure containing three levels of tree nodes.

[0108] Furthermore, for Figure 4 The tree nodes and leaf nodes in the FDMT tree shown above can also be persistently stored in a database as key-value pairs. Specifically, the key in the key-value pair corresponding to the tree node or leaf node can be the hash value of the data content contained in the tree node or leaf node. The value in the key-value pair of the tree node or leaf node can be the data content contained in the tree node or leaf node.

[0109] When storing a tree node or leaf node from an FDMT tree to a database, the hash value of the data content contained in that tree node or leaf node can be calculated (i.e., a hash calculation is performed on the entire node). The calculated hash value is then used as the key, and the data content contained in that tree node or leaf node is used as the value, generating key-value pairs. These key-value pairs are then stored in the database. When querying a node in the FDMT tree, the content can be addressed using the hash value of the node's data content as the key.

[0110] It should be noted that, Figure 4 The tree structure of the FDMT tree shown can be used to store the account status data of each blockchain account in the blockchain, or to store the contract data stored in the storage space corresponding to a certain contract account.

[0111] The FDMT tree used to store the account state data of each blockchain account can be called the FDMT state tree. The FDMT tree used to store the contract data stored in the storage space corresponding to a specific contract account can be called the FDMT storage tree.

[0112] The root node of the FDMT storage tree can also be linked to the leaf node corresponding to the contract account in the FDMT state tree through its hash value. The hash value of the root node can also be added to the storageroot field of the account status stored in the leaf node corresponding to the contract account in the FDMT state tree, which will not be elaborated further.

[0113] It should be noted that, regardless of Figure 1 The MPT tree shown is still Figure 4 The FDMT tree shown typically stores more data in its Leaf nodes compared to other node types. For example, the value of the blockchain data stored in the Leaf node is usually the original content of the blockchain data, which occupies more storage space than the character prefix. Therefore, to ensure the Leaf node has a larger data capacity, regardless of... Figure 1 The MPT tree shown is still Figure 4 The leaf nodes in the FDMT tree shown are typically designed to be in the form of large data blocks.

[0114] The specific form and storage structure of the aforementioned data blocks are not specifically limited in this specification.

[0115] For example, in practical applications, the leaf nodes mentioned above can specifically take the form of buckets. These buckets can be containers or storage spaces used to store data.

[0116] For example, see Figure 6 , Figure 6 This is a structural diagram of a bucket data bucket as shown in this specification.

[0117] like Figure 6 As shown, in the above-mentioned bucket data bucket (i.e. Figure 6 The bucket node shown can include several data records. Each data record corresponds to a blockchain data entry, and the string suffix used to store the key of the aforementioned blockchain data (i.e.,...) Figure 6The key-end and value are shown in the diagram. That is, a data record refers to a storage record that includes the character suffix of the key and the value of the blockchain data mentioned above.

[0118] It should be noted that, Figure 6 The structure of the bucket shown is specifically designed as... Figure 4 The example shown is a leaf node in an FDMT tree. In practical applications, Figure 6 The structure of the bucker node shown can also be used as a specific example. Figure 1 The leaf nodes of the MPT tree shown will not be described again in this specification.

[0119] From the above description, it can be seen that... Figure 1 The MPT tree shown is still as Figure 4 The FDMT trees shown all contain nodes with several slots. For example, Figure 1 The branch node shown is located on the MPT tree. Figure 4 The first N layers of tree nodes in the FDMT diagram all contain several slots for storing characters from the keys of the blockchain data.

[0120] In practical applications, for nodes with multiple slots in an MPT tree or FDMT tree, if only some of the slots in the node are updated, even if the contents of the other slots are not updated, the entire node usually needs to be rewritten to the database for persistent storage after the update of those slots, resulting in a significant write amplification effect.

[0121] It is important to explain that write amplification refers to the effect of increasing write bandwidth when the amount of data to be written is less than the amount of data actually written.

[0122] For example, for a node in an MPT tree or FDMT tree that contains multiple slots, if only some of the slots in the node are updated, then only the content stored in those slots needs to be written. However, since a node in an MPT tree or FDMT tree is a complete and indivisible data unit, even if only some of the slots need to be written, the entire node still has to be written to the database on disk. This results in the data that needs to be written being less than the data that is actually written, producing the write amplification effect mentioned above and causing a waste of write bandwidth.

[0123] Moreover, since the first N layers of the FDMT tree tree nodes all use a data structure with multiple slots, the write amplification effect is particularly pronounced when using the FDMT tree to store blockchain data.

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

[0125] In 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 the characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node in the above tree structure is linked to the node in the previous layer through its hash value.

[0126] When using the tree structure described above to store blockchain data, the blockchain data to be stored can be obtained and converted into the root node, intermediate node and leaf node in the logical tree structure.

[0127] On the one hand, at least some of the aforementioned root nodes and intermediate nodes can be cached in a storage medium that supports overwrite data, so that modifications and updates can be made to the aforementioned at least some nodes in the storage medium;

[0128] On the other hand, data records can also be generated to record the modification and update details for at least some of the nodes mentioned above, and the data records and other nodes among the root node, intermediate node and leaf node except for at least some of the nodes mentioned above can be written into the database for persistent storage.

[0129] In the above technical solution, by caching at least some of the root nodes and intermediate nodes of the above logical tree structure in a storage medium that supports overwrite data, and modifying and updating the at least some nodes in the storage medium, the write amplification effect caused by repeatedly writing the root nodes and intermediate nodes of the above logical tree structure into the database can be alleviated, thereby improving the storage performance of the above database.

[0130] For example, in practical applications, if there are nodes with multiple slots in the root node and intermediate nodes of the tree structure described above, then caching these nodes in a storage medium that supports overwrite data can be used to modify and update at least some of these nodes in the storage medium using an overwrite method. These nodes that are overwritten will no longer need to be written to the database on disk, thus avoiding the write amplification effect described above caused by writing all these nodes to the database on disk.

[0131] Please see Figure 7 , Figure 7 This is a flowchart illustrating a blockchain data storage method provided in an exemplary embodiment. The method is applied to a blockchain node device; the key-value pairs of the blockchain data are stored in a database in the form of a root node, intermediate nodes, and leaf nodes in a logical tree structure; the root node and intermediate nodes are used to store characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node in the tree structure is linked to the node in the previous layer through its hash value; the method includes the following steps:

[0132] Step 702: Obtain the key-value pairs of the blockchain data to be stored;

[0133] The aforementioned blockchain data to be stored can specifically include any type of data that needs to be persistently stored in the blockchain.

[0134] In one embodiment shown, the blockchain data to be stored may specifically include account status data corresponding to blockchain accounts on the blockchain.

[0135] For example, as mentioned earlier, in practical applications, blockchain accounts in a blockchain can typically include external accounts and contract accounts. Therefore, the account status data corresponding to a blockchain account on the blockchain can specifically include account status data corresponding to a user account on the blockchain (such as account balance data) and state variable data stored in a contract account on the blockchain (such as evidence data stored in a smart contract).

[0136] Of course, in practical applications, the blockchain data to be stored may also include transaction data published to the blockchain network, as well as receipt data corresponding to the transaction data generated after the transaction data is executed, and so on.

[0137] In one example, when a node device in a blockchain obtains key-value pairs of blockchain data to be stored, it can process the blockchain data into key-value pairs locally after obtaining the data.

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

[0139] In blockchain data, the "key" in a key-value pair can refer to the primary key of that blockchain data in a database. This primary key can specifically act as a query index. The "value" in the key-value pair specifically refers to the data content of the aforementioned blockchain data.

[0140] It should be noted that for different types of blockchain data, the keys in their key-value pairs may also differ to some extent.

[0141] For example, if the aforementioned blockchain data specifically refers to the account status data corresponding to a blockchain account in the blockchain, then the key in the key-value pair of the account status data can specifically be the account address of the blockchain account.

[0142] If the aforementioned blockchain data specifically refers to 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 the receipt data corresponding to the transaction data can specifically be a transaction identifier; for example, in practical applications, the transaction identifier can specifically be the hash value of the transaction, or it can be the transaction ID assigned to the transaction when reaching a consensus on the transaction.

[0143] Step 704: Convert the blockchain data key-value pairs into a logical tree structure with root node, intermediate node and leaf node;

[0144] For the key-value pairs of blockchain data to be stored, they can be organized into a logical tree structure and stored in the database as nodes in this logical tree structure.

[0145] The so-called logical tree structure refers to a tree structure constructed at the logical level based on the nodes stored in the database and the links between the nodes.

[0146] For example, the tree structure described above can specifically include multiple layers of nodes, which can be stored as nodes in the underlying physical storage (such as a disk) that hosts the database. When blockchain data stored on the tree structure described above needs to be used, the multiple layers of nodes stored in the database can be loaded into memory, and the specific tree structure can be reconstructed at the logical level according to the link relationships between the nodes.

[0147] In one embodiment shown, the tree structure of the above logic can specifically be a Merkle tree that incorporates a trie tree structure; for example, it can be the MPT tree or the FDMT tree described above.

[0148] In practical applications, the tree structure described above can include a root node, intermediate nodes, and leaf nodes. After obtaining the key-value pairs of the blockchain data to be stored, the node devices in the blockchain can convert these key-value pairs into the root, intermediate, and leaf nodes of the tree structure described above.

[0149] Specifically, when transforming the key-value pairs of blockchain data into the root, intermediate, and leaf nodes of a logical tree structure, the process begins by finding the root node of this logical tree structure and then locating the root, intermediate, and leaf nodes used to store the key-value pairs of the blockchain data. These queried root, intermediate, and leaf nodes are then updated based on the key-value pairs of the blockchain data. In this case, the updated root, intermediate, and leaf nodes are the root, intermediate, and leaf nodes formed by transforming the key-value pairs of the aforementioned blockchain data.

[0150] It should be noted that if, starting from the root node of the logical tree structure, no intermediate or leaf nodes for storing the blockchain data are found other than the root node, intermediate and leaf nodes for storing the blockchain data can be created within the logical tree structure based on the blockchain data's key-value pairs. Then, the queried root node and the newly created intermediate and leaf nodes can be updated based on the blockchain data's key-value pairs.

[0151] Of course, if this is the first time writing blockchain data into a logical tree structure, when converting the key-value pairs of the aforementioned blockchain data into the root, intermediate, and leaf nodes of the logical tree structure, the root, intermediate, and leaf nodes used to store the key-value pairs of the blockchain data can be initialized at this time. These initialized root, intermediate, and leaf nodes are the root, intermediate, and leaf nodes formed from the key-value pairs of the aforementioned blockchain data.

[0152] Within the tree structure described above, nodes can still be linked to nodes at the next higher level via their own hash values. The root and intermediate nodes specifically store at least one character from the key corresponding to the key-value pair in the blockchain data. The leaf nodes specifically store the value (i.e., the actual content of the blockchain data). The number of intermediate nodes can be single or multi-level, and this specification does not impose any specific limitations.

[0153] For example, in one instance, the key of the aforementioned blockchain data could still include a character prefix (Sharednibble) and a character suffix (key-end); in this case, the root node and intermediate nodes could be used to store the characters in the character prefix. The leaf nodes, on the other hand, could be used to store the character suffix and the value of the blockchain data.

[0154] On the one hand, since the root and intermediate nodes in the tree structure described above can store characters from the keys of the blockchain data, this tree structure exhibits characteristics of a Trie (prefix tree). On the other hand, nodes in the tree structure can be linked to nodes at the next higher level through their own hash values. Therefore, this tree structure also exhibits characteristics of a Merkle tree. It is easy to understand that the tree structure described in this specification can be a Merkle tree variant that combines a Trie tree with a tree structure similar to an MPT tree or FDMT tree. It should be further noted that when the blockchain data is account state data corresponding to blockchain accounts, the tree structure can specifically be a Merkle tree generated based on the key-value pairs of the account state data corresponding to each blockchain account. In this case, the Merkle tree can be called a Merkle state tree.

[0155] In practical applications, to improve the access performance of the Merkle state tree, it is typically split into a Current State Tree and a History State Tree. The Current State Tree is composed of the latest account states of each blockchain account; the History State Tree is composed of the historical account states of each blockchain account. Each block has a corresponding Current State Tree and History State Tree.

[0156] In this scenario, because the current Merkle state tree maintains the latest account states of each blockchain account, nodes on the current Merkle state tree typically perform frequent write and update operations. Therefore, in this specification, the tree structure of the logic described in steps 702 and 706 specifically refers to the aforementioned current Merkle state tree. That is, for the current Merkle state tree, the technical solutions described in steps 702-706 can be adopted, while for historical Merkle state trees, existing storage solutions can still be used. Of course, in practical applications, the technical solutions described in steps 702-706 can also be used for historical Merkle state trees.

[0157] Step 706: Cache at least some of the root nodes and intermediate nodes to a storage medium that supports overwrite data writing, so as to modify and update the at least some nodes in the storage medium; and generate a data record for recording the modification and update details of the at least some nodes, and write the data record and the other nodes in the root nodes, intermediate nodes and leaf nodes other than the at least some nodes into the database for persistent storage.

[0158] After converting the key-value pairs of the aforementioned blockchain data into root nodes, intermediate nodes, and leaf nodes in a logical tree structure, these root nodes, intermediate nodes, and leaf nodes can be stored in a database.

[0159] It should be noted that in practical applications, the root node, intermediate node and leaf node mentioned above are usually written to the database for persistent storage. However, in this specification, in order to alleviate the write amplification effect caused by writing the root node and intermediate node to the database for persistent storage, a completely different storage strategy can be adopted when storing the root node and intermediate node than when storing the leaf node.

[0160] On the one hand, for at least some of the aforementioned root nodes and intermediate nodes, instead of writing them to the aforementioned database for persistent storage by default, they can be cached in the storage medium that supports overwrite data writing on the blockchain node device, and the aforementioned at least some nodes can be modified and updated in the aforementioned storage medium.

[0161] In one example, the storage medium supporting overwrite data writing can specifically be the memory on the node device in the blockchain. Of course, besides memory, the storage medium can also be other forms of storage media supporting overwrite data writing, and this specification does not specify a particular type. For example, in practical applications, the storage medium can also be a solid-state drive (SSD).

[0162] On the other hand, for the root node, intermediate nodes, and leaf nodes other than at least some of the nodes mentioned above, the default method of writing them to the database for persistent storage is still used. In addition, data records can be generated to record the modification and update details of at least some of the nodes, and then these data records, along with the other nodes, can be written to the database for persistent storage.

[0163] For example, in practical applications, after all transactions in a latest block have been executed, the execution of these transactions often causes changes to the data stored in some nodes of the logical tree structure. At this point, it is usually necessary to recalculate the hash value of the root node of the logical tree structure (i.e., the root hash), fill this root hash value 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 a commit operation for the logical tree structure. In this specification, specifically, when performing a commit operation for this logical tree structure, this data record can also be written to the database along with the other nodes mentioned above for persistent storage.

[0164] In one embodiment shown, the aforementioned at least some nodes may specifically be the root node and intermediate nodes, including nodes with multiple slots for storing characters from the keys of the blockchain data. Of course, in practical applications, the aforementioned at least some nodes may also implicitly include all the root nodes and intermediate nodes in the tree structure described above.

[0165] For example, in one instance, if the tree structure of the above logic is an MPT tree, then at least some of the nodes mentioned above can be branch nodes on the MPT tree. In this case, since only branch nodes on the MPT tree have multiple slots, only the branch nodes on the MPT tree can be cached on the storage medium mentioned above (i.e., only the root node and the branch nodes in the intermediate nodes of the MPT tree are cached on the storage medium mentioned above).

[0166] In another example, if the tree structure of the above logic is an FDMT tree, then at least some of the nodes mentioned above can be the tree nodes of the first N levels of the FDMT tree. In this case, since each tree node of the first N levels of the FDMT tree has multiple slots, only the tree nodes of the first N levels of the FDMT tree can be cached in the above storage medium. (That is, the root node and intermediate nodes of the FDMT tree are all cached in the above storage medium).

[0167] Accordingly, the aforementioned data records may specifically be data records used to record the modification and update details of each slot in at least some of the aforementioned nodes.

[0168] The specific form of the aforementioned data records is not specifically limited in this specification.

[0169] In one embodiment shown, the aforementioned data record can specifically be a WAL (write-ahead log). WAL logging technology is a highly efficient logging algorithm. In a storage system with WAL mode enabled, all data modifications to the storage system are first written to the WAL log before being committed to the storage system; then, through periodically triggered or user-manually triggered checkpoint events, the data modifications stored in the WAL log file are written to the storage system.

[0170] In this scenario, if at least some of the nodes cached in the aforementioned storage medium experience data loss due to device malfunction (e.g., device endpoint), data recovery can be performed on the at least some of the nodes cached in the aforementioned storage medium based on the WAL logs persistently stored in the database.

[0171] For example, if a device malfunction causes data loss in at least some of the cached nodes, the user can recover the cached data in the storage medium using an anomaly recovery command. The node device in the blockchain can receive the user's anomaly recovery command for the cached at least some nodes in the storage medium, and then, in response to the command, can recover the data from the cached at least some nodes based on the WAL logs stored in the database.

[0172] In one embodiment shown, a persistent storage condition can be set for the at least some nodes cached in the storage medium. Specifically, the persistent storage condition refers to the condition that the at least some nodes cached in the storage medium are written to the database for persistent storage.

[0173] In this scenario, it can be determined whether at least some of the nodes cached in the storage medium meet the persistent storage conditions. For example, in practical applications, it can be determined periodically, based on a preset period, whether at least some of the nodes cached in the storage medium meet the persistent storage conditions. If at least some of the nodes cached in the storage medium meet the persistent storage conditions, then at least some of the nodes cached in the storage medium can be further written into the database for persistent storage.

[0174] The conditions for persistent storage mentioned above are not specifically limited in this specification, and can be flexibly set based on actual storage needs in practical applications.

[0175] For example, in one embodiment shown, the conditions for persistent storage described above may specifically include one or more of the conditions shown below:

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

[0177] In this case, when the number of data records that can be persistently stored in the database reaches a threshold, it will trigger the writing back of at least some of the cached nodes to the database on disk for persistent storage.

[0178] Condition 2: The storage capacity of persistently stored data records in the above database reaches the threshold.

[0179] In this case, when the storage capacity of the aforementioned data records that can be persistently stored in the aforementioned database reaches a threshold, it will trigger the writing back of at least some of the cached nodes to the database on disk for persistent storage.

[0180] Condition 3: Receive a persistent storage instruction from the user for at least some of the nodes stored in the aforementioned storage medium.

[0181] In this case, upon receiving a persistent storage instruction from a user for at least some of the nodes stored in the aforementioned storage medium, the cached at least some of the nodes can be written back to the database on disk for persistent storage.

[0182] In one embodiment, after successfully writing the at least some nodes cached in the storage medium into the database for persistent storage, in order to improve the storage space utilization of the storage medium, the at least some nodes cached in the storage medium can be further deleted. Alternatively, after successfully writing the at least some nodes cached in the storage medium into the database for persistent storage, based on the same consideration, in order to improve the storage space utilization of the database, the data records corresponding to the at least some nodes that are persistently stored in the database can be further deleted.

[0183] In this specification, a completely different storage strategy is adopted when storing the root node, intermediate node, and leaf node of the above-described logical tree structure compared to related technologies. For example, as mentioned above, unlike related technologies, at least some of the root node and intermediate node in the above-described logical tree structure will not be persistently stored in the database by default, but will be cached in the above-described storage medium. Therefore, when reading the root node, intermediate node, and leaf node of the above-described logical tree structure, a reading method can be adopted that reads from the above-described storage medium and the above-described database respectively.

[0184] For example, in one embodiment shown, when a node device in the blockchain receives a read instruction for a node in the tree structure of the above logic, it can first read the node from the storage medium by default, and if the node is not read from the storage medium, then it can further read the node from the database.

[0185] In the above technical solution, by caching at least some of the root nodes and intermediate nodes of the above logical tree structure in a storage medium that supports overwrite data, and modifying and updating the at least some nodes in the storage medium, the write amplification effect caused by repeatedly writing the root nodes and intermediate nodes of the above logical tree structure into the database can be alleviated, thereby improving the storage performance of the above database.

[0186] For example, taking the tree structure of the above logic as an example, since only the branch node in the traditional MPT tree contains the slots of the 16 characters in the key used for blockchain data, although the write amplification effect will also occur when the nodes in the MPT tree are persistently stored in the database, the write amplification effect is usually not obvious.

[0187] The FDMT tree is significantly different from the traditional MPT tree.

[0188] Because the first N levels of a FDMT tree's tree node contain multiple blocks for storing characters from the keys in the blockchain data, and each position contains multiple slots for storing characters from the keys in the blockchain data, a tree node in an FDMT tree typically has more slots than a branch node in an MPT tree. For example, if a tree node contains 16 blocks, and each block contains 16 slots, then a tree node will contain 256 slots, a number far greater than that of a branch node in an MPT tree.

[0189] Having more slots means that a tree node in an FDMT tree will have a larger data capacity compared to a branch node in an MPT tree. In this case, the write amplification effect of writing a tree node from an FDMT tree to a database for persistent storage will be more pronounced than that of an MPT tree. For example, if the data in any one of the 256 slots of a tree node in an FDMT tree is updated, the write bandwidth consumed when rewriting that entire tree node (containing 256 slots) to the database for persistent storage is significantly greater than the write bandwidth consumed when writing the entire branch node (containing only 16 slots) of an MPT tree to the database.

[0190] If the storage scheme described in the above embodiments is adopted, the tree nodes of the first N levels of the FDMT tree are cached in memory and modified and updated in memory, which can avoid repeatedly writing the tree nodes of the first N levels of the FDMT tree to the database on disk, thereby alleviating the write amplification effect caused by this.

[0191] Corresponding to the above method embodiments, this application also provides embodiments of the apparatus.

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

[0193] The embodiments of the blockchain data storage device described in this specification can be applied to electronic devices. These device embodiments can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of the electronic device loading the corresponding computer program instructions from non-volatile memory into memory for execution.

[0194] From a hardware perspective, such as Figure 8 The diagram shown is a hardware structure diagram of an electronic device containing the blockchain data storage device described in this specification. (Except for...) Figure 8 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device is located in the embodiment may also include other hardware depending on the actual function of the electronic device, which will not be described in detail here.

[0195] Figure 9 This is a block diagram illustrating an exemplary embodiment of a blockchain data storage device.

[0196] Please refer to Figure 9 The blockchain data storage device 90 can be applied in the aforementioned Figure 8 In the illustrated electronic device, the key-value pairs of the blockchain data are stored in a database in the form of a root node, intermediate nodes, and leaf nodes in a logical tree structure; the root node and intermediate nodes are used to store characters in the key of the blockchain data; the leaf nodes are used to store the value of the blockchain data; any node in the tree structure is linked to the node in the previous layer through its hash value; the device 90 includes:

[0197] Module 901 retrieves the key-value pairs of the blockchain data to be stored.

[0198] 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.

[0199] Storage module 903 caches at least some of the root node and intermediate nodes to a storage medium that supports overwrite data writing, so as to modify and update the at least some nodes in the storage medium; and generates a data record for recording the modification and update details of the at least some nodes, and writes the data record and the other nodes in the root node, intermediate nodes and leaf nodes other than the at least some nodes into the database for persistent storage.

[0200] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

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

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

[0203] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0204] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0205] The foregoing has described 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 may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0206] 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 scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

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

[0208] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A blockchain data storage method, wherein key-value pairs of the blockchain data are stored in a database in a logical tree structure of root nodes, intermediate nodes and leaf nodes; the root nodes and the intermediate nodes are used to store characters in keys of the blockchain data. The leaf node is used to store the value of the blockchain data; Any node on the tree structure is linked to the node of the previous layer through its hash value; the method comprises: Obtaining the key-value pair of the 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 on a logical tree structure; Caching at least part of the root node and the intermediate node to a storage medium supporting overlay writing data, to modify and update the at least part of the node in the storage medium; and generating a data record for recording the modification and update details of the at least part of the node, and writing the data record and other nodes except the at least part of the node in the root node, the intermediate node and the leaf node into the database for persistent storage; wherein the at least part of the node includes a plurality of slots for storing 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 data record is used to record the modification and update details of each slot in the at least part of the node.

2. The method of claim 1, wherein the logical tree structure comprises a Merkle tree that integrates a tree structure of a trie.

3. The method of claim 2, wherein the blockchain data comprises account state data corresponding to a blockchain account on the blockchain; The Merkle tree generated based on the key-value pair of the account state data corresponding to each blockchain account in the blockchain comprises: A current Merkle state tree generated based on the latest account state data of the each blockchain account; And a historical Merkle state tree organized based on the historical account state data of the each blockchain account; the logical tree structure is the current Merkle state tree.

4. The method of claim 2, wherein the logical tree structure comprises 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 the at least part of the node is the branch node on the MPT tree.

5. The method of claim 2, wherein the logical tree structure comprises an FDMT tree; wherein The root node and the intermediate node on the FDMT tree each comprise a plurality of positions for storing characters in the key of the blockchain data; each position further comprises a plurality of slots for storing characters in the key of the blockchain data; the slot is used to store the hash of the node of the next layer linked to the node; and the at least part of the node is the root node and the intermediate node on the FDMT tree.

6. The method of claim 1, further comprising: Determining whether the at least part of the node cached in the storage medium meets the persistent storage condition; If the at least part of the nodes cached in the storage medium satisfy a persistent storage condition, write the at least part of the nodes cached in the storage medium into the database for persistent storage. 7.The method of claim 6, further comprising: after successfully writing the at least part of the nodes cached in the storage medium into the database for persistent storage, further deleting the at least part of the nodes cached in the storage medium. 8.The method of claim 6, further comprising: after successfully writing the at least part of the nodes cached in the storage medium into the database for persistent storage, further deleting the data records corresponding to the at least part of the nodes in the database for persistent storage. 9.The method of claim 6, wherein the persistent storage condition comprises any one or a combination of the following: a number of data records stored in the database for persistent storage reaches a threshold value; a storage capacity of the data records stored in the database for persistent storage reaches a threshold value; a persistent storage instruction for the at least part of the nodes stored in the storage medium is received. 10.The method of claim 1, further comprising: in response to a read instruction for a node on the logical tree structure, reading the node from the storage medium, and further reading the node from the database when the node is not read from the storage medium. 11.The method of claim 1, wherein the data records comprise a WAL log. 12.The method of claim 11, further comprising: receiving an abnormal recovery instruction for the at least part of the nodes cached in the storage medium; in response to the abnormal recovery instruction, performing data recovery on the at least part of the nodes cached in the storage medium based on the WAL log stored in the database. 13.The method of claim 1, wherein the storage medium comprises a memory.

14. A blockchain data storage device, 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 nodes, intermediate nodes are used to store characters in the key of the blockchain data; the leaf node is used to store a value of the blockchain data; any node on the tree structure is linked to a node of a previous layer through a hash value of the node; and the apparatus comprises: an obtaining module, configured to obtain a key-value pair of the blockchain data to be stored; a converting module, configured to convert the key-value pair of the blockchain data into a root node, an intermediate node and a leaf node on a logical tree structure. The storage module caches at least part of the root node, intermediate node and leaf node to a storage medium supporting overlay writing data, to perform modification update for the at least part of the nodes in the storage medium; and generates a data record for recording modification update details for the at least part of the nodes, and writes the data record and other nodes except the at least part of the nodes in the root node, intermediate node and leaf node to the database for persistent storage; wherein the at least part of the nodes include a plurality of slot positions for storing characters in keys of the blockchain data; the slot positions are used to store hash values of the next layer nodes linked with the nodes; and the data record is used to record modification update details for each slot position in the at least part of the nodes. 15.An electronic device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor, by running the executable instructions, implements steps of the method of any one of claims 1-13. 16.A computer readable storage medium having stored thereon computer instructions that, when executed by a processor, implement steps of the method of any one of claims 1-13.

Images