Blockchain data storage, update, reading method and device, electronic device

Abstract

A blockchain data storage method includes: obtaining key-value pairs of blockchain data to be stored; converting the key-value pairs of the blockchain data into root nodes, intermediate nodes, and leaf nodes on a logical tree structure; the nodes on the logical tree structure are linked to the nodes on the upper layer via their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the root node and the intermediate node are used to store the characters in the key of the key-value pair corresponding to the blockchain data; the leaf node is used to store the value of the key-value pair corresponding to the blockchain data; the root node, the intermediate node, and the leaf node are respectively stored in a database; and the nodes on the logical tree structure are respectively stored in at least multiple databases.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and device for storing, updating, and reading blockchain data, and an electronic device. Background Art

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

[0003] For blockchain node devices, the blockchain data that needs to be stored and maintained usually includes block data and account status data corresponding to blockchain accounts in the blockchain; and block data can further include block header data, block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, etc.

[0004] When storing the various blockchain data shown above, the node device of the blockchain can usually organize the above blockchain data into a logical tree structure and store it in the database. Summary of the Invention

[0005] This specification proposes a blockchain data storage method, the method comprising:

[0006] Get the key-value pair of the blockchain data to be stored;

[0007] The key-value pairs of the blockchain data to be stored are converted into root nodes, intermediate nodes, and leaf nodes on a logical tree structure; the nodes on the logical tree structure are linked to the nodes on the upper layer through their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the next layer linked to the node and the database identifier of the database storing the node on the next layer; the root node and the intermediate node are used to store the characters in the key of the key-value pair corresponding to the blockchain data; the leaf node is used to store the value of the key-value pair corresponding to the blockchain data; determine a database for storing the root node, intermediate node, and leaf node, and store the root node, intermediate node, and leaf node in the determined database; wherein the nodes on the logical tree structure are stored in at least multiple databases respectively.

[0008] This specification also proposes a blockchain data update method, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, intermediate nodes, and leaf nodes for storing the blockchain data; wherein the nodes on the logical tree structure are stored in at least a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer via their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the method comprises:

[0009] Determine a root node, an intermediate node, and a leaf node on the logical tree structure for storing key-value pairs of the target blockchain data to be updated, and determine a database for storing the updated root node, intermediate node, and leaf node;

[0010] The leaf node determined based on the value of the key-value pair of the target blockchain data is updated. After the leaf node is updated, the hash value of the updated leaf node and the database identifier of the database determined for storing the updated leaf node are further written into the intermediate node of the upper layer linked to the leaf node to update the intermediate node;

[0011] After the update of the intermediate node is completed, the hash value of the updated intermediate node and the database identifier of the database determined for storing the updated intermediate node are further written into the node of the upper layer linked to the intermediate node to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node update on the logical tree structure is completed.

[0012] This specification also proposes a method for reading blockchain data, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, intermediate nodes, and leaf nodes for storing the blockchain data; wherein the nodes on the logical tree structure are stored in at least multiple databases respectively; the nodes on the logical tree structure are linked to the nodes on the upper layer through their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the method includes:

[0013] Reading a hash value of a root node of the logical tree structure and determining a database for storing the root node of the logical tree structure; using the hash value of the root node as a query index, querying the root node from the database, and loading the query root node into a memory;

[0014] Reading the hash value of the intermediate node in the next layer linked to the root node and the database identifier of the database storing the intermediate node stored in the root node, and using the hash value of the intermediate node as a query index, querying the intermediate node from the database corresponding to the database identifier, and loading the queried intermediate node into the memory;

[0015] Read the hash value of the node in the next layer linked to the intermediate node and the database identifier of the database storing the node in the next layer stored in the intermediate node, and use the hash value of the node in the next layer as the query index, query the node in the next layer from the database corresponding to the database identifier, and load the queried node in the next layer into the memory, and so on, until all leaf nodes in the logical tree structure are loaded into the memory.

[0016] This specification also proposes a blockchain data storage device, the device comprising:

[0017] An acquisition module obtains key-value pairs of blockchain data to be stored and determines a database for storing the blockchain data;

[0018] A conversion module converts the key-value pairs of the blockchain data into root nodes, intermediate nodes, and leaf nodes in a logical tree structure; wherein the nodes in the logical tree structure are linked to the nodes in the upper layer through their hash values; the storage content of the nodes in the logical tree structure includes the hash value of the node in the lower layer linked to the node and the database identifier of the database storing the node in the lower layer; the root node and intermediate nodes are used to store the characters in the key of the key-value pair corresponding to the blockchain data; and the leaf nodes are used to store the value of the key-value pair corresponding to the target blockchain data;

[0019] A storage module stores the root node, intermediate nodes and leaf nodes in a database respectively; wherein the nodes on the logical tree structure are stored in at least a plurality of databases respectively.

[0020] This specification also proposes a blockchain data update device, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, intermediate nodes, and leaf nodes for storing the blockchain data; wherein the nodes on the logical tree structure are stored in at least a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer via their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the device includes:

[0021] A determination module is configured to determine a root node, an intermediate node, and a leaf node on the logical tree structure for storing key-value pairs of target blockchain data to be updated, and to determine a database for storing the updated root node, intermediate node, and leaf node;

[0022] An update module updates the determined leaf node based on the Value of the key-value pair of the target blockchain data. After the leaf node is updated, the hash value of the updated leaf node and the database identifier of the database determined for storing the updated leaf node are further written into the intermediate node of the upper layer linked to the leaf node to update the intermediate node; after the intermediate node is updated, the hash value of the updated intermediate node and the database identifier of the database determined for storing the updated intermediate node are further written into the node of the upper layer linked to the intermediate node to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node of the logical tree structure is updated.

[0023] This specification also proposes a blockchain data reading device, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, intermediate nodes, and leaf nodes for storing the blockchain data; wherein the nodes on the logical tree structure are stored in at least a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer via their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the device includes:

[0024] a first reading module, which reads a hash value of a root node of the logical tree structure and determines a database for storing the root node of the logical tree structure; uses the hash value of the root node as a query index, queries the root node from the database, and loads the queried root node into a memory;

[0025] a second reading module, which reads the hash value of the intermediate node in the next layer linked to the root node and the database identifier of the database storing the intermediate node, uses the hash value of the intermediate node as a query index, queries the intermediate node from the database corresponding to the database identifier, and loads the queried intermediate node into the memory;

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

[0027] In the above technical solution, on the one hand, by storing the nodes of the logical tree structure woven from the key-value pairs of the blockchain data group in multiple databases, the performance problems faced by storing the blockchain data in a single database can be avoided, and the scalability of the database used to store blockchain data can be improved.

[0028] On the other hand, since the data structure of the nodes on the above-mentioned logical tree structure can include, in addition to the hash value of the node of the next layer linked to the node, the database identifier of the database storing the node of the next layer; therefore, in this way, even if the nodes on the above-mentioned logical tree structure are stored in different databases respectively, the nodes distributed in different databases can still be linked together according to the hash value of the node of the next layer stored in the node and the corresponding database identifier, so that the nodes distributed in different databases are still logically a whole, thereby still ensuring the integrity of the above-mentioned logical tree structure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 2This is a schematic diagram of an exemplary embodiment providing a method for organizing the account status data of each blockchain account in a blockchain into an MPT state tree in the form of key-value pairs;

[0031] Figure 3 This 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;

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

[0033] Figure 5 This is a structural diagram of a Tree node provided by an exemplary embodiment;

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

[0035] Figure 7 This is a flowchart of a blockchain data storage method provided by an exemplary embodiment;

[0036] Figure 8 An exemplary embodiment provides a Figure 1 Schematic diagram of the improved MPT tree structure based on the above;

[0037] Figure 9 An exemplary embodiment provides a Figure 4 Schematic diagram of the improved tree structure of the FDMT tree based on ;

[0038] Figure 10 This is a flowchart of a blockchain data update method provided by an exemplary embodiment;

[0039] Figure 11 This is a flowchart of a blockchain data reading method provided by an exemplary embodiment;

[0040] Figure 12 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

[0041] Figure 13 This is a block diagram of a blockchain data storage device provided by an exemplary embodiment;

[0042] Figure 14 This is a block diagram of a blockchain data updating device provided by an exemplary embodiment;

[0043] Figure 15 It is a block diagram of a blockchain data reading device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0044] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0045] 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, the method may include more or fewer steps than those 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 be combined into a single step for description in other embodiments.

[0046] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

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

[0048] 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 by calling an external account.

[0049] Externally owned account: An account directly controlled by a user, also known as a user account.

[0050] The design of external accounts and contract accounts is essentially a mapping of account addresses to account states. Account states are 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 typically changes as well.

[0051] In an example, the structure of an account usually includes fields such as Balance, Nonce, Codehash, and Storageroot. Among them:

[0052] The Balance field is used to maintain the current account balance of the account;

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

[0054] The Codehash field is used to maintain the contract code of the account. In actual applications, the Codehash field usually only maintains the hash value of the contract code.

[0055] The Storageroot field is used to maintain the storage content of the 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.

[0056] The contents of a contract account are typically stored as key-value pairs in an MPT (Merkle Patricia Trie) tree structure. The MPT tree is a logical tree structure used in the blockchain field to store and maintain blockchain data. This tree structure typically includes a root node, intermediate nodes, and leaf nodes.

[0057] The MPT tree constructed based on the storage content of the contract account is also commonly referred to as the Storage tree. The Storageroot field usually only maintains the hash value of the root node of the Storage tree. For external accounts, the field values ​​of the Codehash field and Storageroot field shown above are both empty.

[0058] For most blockchain models, Merkle trees are usually used; or logical tree structures such as Merkle tree variants designed based on the Merkle tree data structure are used to store and maintain data.

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

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

[0061] The following uses the MPT tree to store blockchain data as an example.

[0062] In one example, the blockchain data that needs to be stored and maintained in a blockchain typically includes account state data, transaction data, and receipt data. Therefore, in practical applications, these account state data, transaction data, and receipt data can be organized into three MPT trees: the MPT state tree (i.e., world state), the MPT transaction tree, and the MPT receipt tree, in the form of key-value pairs. These trees can then be stored and maintained separately.

[0063] In addition to the three MPT trees above, the contract data stored in the storage space corresponding to the contract account is usually also 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.

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

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

[0066] The MPT receipt tree is a transaction (receipt) corresponding to each transaction generated after the execution of transactions in the block. It is organized into an MPT tree in the form of key-value pairs.

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

[0068] The MPT transaction tree and MPT receipt tree are both block-specific, meaning each block has its own MPT transaction tree and MPT receipt tree. The MPT state tree, on the other hand, is a global MPT tree that doesn't correspond to a specific block but instead encompasses the account status data of all accounts in the blockchain. With each new block generated and the execution of transactions in that block, the account status of the associated accounts (either external accounts or contract accounts) in the blockchain typically changes accordingly.

[0069] For example, when a "transfer transaction" in a block is executed, the balances of the transferor and transferee accounts associated with the "transfer transaction" (i.e., the values ​​of the Balance fields of these accounts) will typically change accordingly. After a node device executes a transaction in the latest block generated by the blockchain, since the account status in the current blockchain has changed, the node device needs to build an MPT state tree based on the current account status data of all accounts in the blockchain to maintain the latest status of all accounts in the blockchain.

[0070] Whenever a new block is generated in the blockchain and the transactions in that block are executed, resulting in changes to the account status of some accounts in the blockchain, node devices must rebuild an MPT state tree based on the latest account status 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 status of all accounts in the blockchain after the transactions in that block are executed.

[0071] See Figure 1 , Figure 1 This is a tree structure diagram of an MPT tree shown in this specification.

[0072] Among them, it should be noted that Figure 1 The connection relationship between the nodes is only for reference.

[0073] The MPT tree is a more traditional and improved variant of the Merkle tree, which combines the advantages of the Merkle tree and the Trie dictionary tree (also known as the prefix tree).

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

[0075] Extension nodes and branch nodes, collectively referred to as character nodes, store the character prefix portion of the string corresponding to the key (i.e., account address) of account status data. For the MPT tree, this character prefix portion is typically referred to as a shared character prefix (shared nibbles). A shared character prefix is ​​a prefix consisting of one or more characters that are common to all account status data keys (i.e., blockchain account addresses). 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., specific account status data).

[0076] Extension node, used to store one or more characters in the shared character prefix of the account address (i.e. Figure 1 The shared nibble shown), and the hash value of the node in the next layer to which the extended node is linked (i.e. Figure 1 Next node shown in the figure). A branch node contains 17 slots. The first 16 slots correspond to the 16 possible hexadecimal characters in the key, with one character corresponding to a nibble. Each of the first 16 slots represents a character in the shared character prefix of an account address. These slots are used to fill the hash value of the node in the next layer linked by the branch node. The last slot is the value slot and is generally empty.

[0077] Leaf nodes are used to store the character suffix of the account address (i.e. Figure 1 The key-end shown in the figure, 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 constitute a complete account address. The character suffix refers to the last suffix consisting of one or more characters excluding the shared character prefix of the account address.

[0078] See Figure 2 , Figure 2 This 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.

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

[0080]

[0081] Table 1

[0082] 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 the fourth row 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 hash value of the root node of the Storage tree composed of the storage content of the contract account.

[0083] Finally, the MPT state tree is organized according to the account state data in Table 1, as shown in Figure 3 shown.

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

[0085] exist Figure 2 In the prefix field, the prefix field is a prefix field shared by both the extension node and the leaf node. Different field values ​​of the prefix field can be used to represent different node types.

[0086] For example, a prefix field value of 0 indicates an extension node containing an even number of nibbles. As mentioned above, a nibble represents a half-byte, consisting of 4 bits of binary, and a nibble corresponds to a character that constitutes an account address. A prefix field value of 1 indicates an extension node containing an odd number of nibbles. A prefix field value of 2 indicates a leaf node containing an even number of nibbles. A prefix field value of 3 indicates a leaf node containing an odd number of nibbles. Branch nodes, however, do not have the above-mentioned prefix field because they are character nodes with parallel single nibbles.

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

[0088] The hexadecimal characters 0-f 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 in the MPT tree, the value field of the branch node can be empty. The 0-f field is used to fill in the hash value of the next layer of nodes.

[0089] The Key-end in a leaf node corresponds to the key value of the key-value pair contained in the leaf node, representing 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-mentioned Balance, Nonce, Code, and storage fields can be encoded and filled into the Value field of the leaf node.

[0090] See Figure 3 , Figure 3This is a schematic diagram of organizing the contract data stored in the storage space corresponding to the contract account into an MPT storage tree.

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

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

[0093]

[0094] Table 2

[0095] 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, the state variables can be organized in the form of key-value pairs as follows: Figure 3 For example, in one example, the account address of the contract account and the hash value of the storage location of the state variable in the contract account's account storage can be used as the key, and the variable value corresponding to the state variable can be used as the value.

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

[0097] Furthermore, whether Figure 2 The node on the MPT state tree shown is still as follows Figure 3 The nodes on the storage tree shown can be stored in the database in the form of Key-Value pairs for persistent storage.

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

[0099] The key in the Key-Value pair corresponding to a node on the MPT state tree or the storage tree may be a hash value of the data contained in the node; the Value in the key-value pair of the node may be the data contained in the node.

[0100] When storing a node in the MPT state tree or storage tree in a database, a hash value of the data contained in the node can be calculated (i.e., a hash calculation is performed on the entire node). This calculated hash value is used as the key, and the data contained in the node is used as the value to generate a key-value pair. This generated key-value pair is then stored in the database. To query a node in the MPT state tree or storage tree, content addressing can be performed using the hash value of the node's data as the key.

[0101] See Figure 4 , Figure 4 This is a tree structure diagram of an FDMT tree shown in this specification.

[0102] The above FDMT tree is also a Merkle tree variant that integrates the tree structure of the Trie dictionary tree.

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

[0104] like Figure 4 As shown, in the tree structure of the FDMT tree, the first N layers ( Figure 4 The three layers shown are for illustrative purposes only, and the last layer is a leaf node. Of the first N layers of tree nodes, the first layer serves as the root node, and the remaining layers serve as intermediate nodes.

[0105] Different from the MPT tree described above, each tree node (ie, the root node and the intermediate node) of the first N layers of the FDMT tree will adopt a unified data structure.

[0106] like Figure 4As shown, the first N tree nodes in the FDMT tree can each include multiple blocks, each representing a different character. These blocks are the "positions" for storing characters in blockchain data keys. Each block can further include multiple slots, each representing a different character. These slots are also used to store characters in blockchain data keys.

[0107] For example, Figure 4 It is shown that each Tree node includes N blocks; each block further includes N slots. Among them, the nodes of each layer on the above FDMT tree can still be linked to each other by filling the hash value (hash pointer) of the node of the next layer in the node of the previous layer. That is, the nodes in the above FDMT tree are linked to the nodes of the previous layer through their own hash values. Correspondingly, the above slots can be used to fill in the hash value of the node of the next layer to which the current Treenode is linked. The node of the next layer of the Tree node can still be a Tree node or a Leaf node.

[0108] What needs to be explained is that Figure 4 The link relationship between the nodes at each layer of the FDMT tree shown in FIG. 1 is merely illustrative and does not constitute a special limitation on the link relationship between the nodes at each layer of the FDMT tree.

[0109] Please continue to see Figure 4 , Figure 4 Each tree node on the FDMT tree shown above can be used to store at least part of the characters in the key of the blockchain data.

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

[0111] for Figure 4 The characters actually stored in each tree node on the FDMT tree shown above can be specifically a string generated by concatenating 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 slot in the block filled with the hash value (i.e., a non-empty slot).

[0112] It should be noted that, in actual applications, each block in the Tree node can only represent one character. Figure 4 The storage format of the tree node shown is as follows: each tree node actually stores a portion of the prefix of the key of the blockchain data, which is a string of 2 characters in length.

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

[0114] like Figure 5 As shown, the Tree node contains 16 blocks representing different hexadecimal characters; each block further includes 16 slots representing different hexadecimal characters ( Figure 5 Only the 16 slots in block6 are shown. Assume that block6 (representing the hexadecimal character 6) in the tree node is a non-empty block, and slot4 (representing the hexadecimal character 4), slot6 (representing the hexadecimal character 6), and slot9 (representing the hexadecimal character 9) in the block are non-empty slots filled with the hash values ​​of the next-level nodes linked to the tree node; then some of the characters in the character prefix of the key of the above blockchain data stored in the tree node are the hexadecimal strings "64", "66", and "69", respectively.

[0115] The number of blocks contained in the tree node and the number of slots contained in each block are not specifically limited in this specification. In practice, the number of sub-blocks contained in the 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 blockchain data key.

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

[0117] The number of tree node layers in the FDMT tree can be a fixed value. In practical applications, the value of N can be an integer greater than or equal to 1. In other words, the FDMT tree can be a Merkle tree that includes at least one layer of tree nodes and a relatively fixed number of tree node layers.

[0118] For example, let's assume that the blockchain data key is a blockchain account address. Assume that the blockchain account addresses supported by the blockchain system are designed so that the first 6 characters of the address can be the same. In this case, since the characters stored in the tree node are 2 characters long, the FDMT tree can be designed as a tree structure containing three layers of tree nodes.

[0119] Furthermore, for Figure 4 The tree nodes and leaf nodes in the FDMT tree shown above can also be persistently stored in the database in the form of key-value pairs. Specifically, the key in the key-value pair corresponding to the tree node or leaf node in the FDMT tree can be a 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.

[0120] When storing a tree node or leaf node on an FDMT tree in a database, you can also calculate the hash value of the data content contained in the tree node or leaf node (that is, perform a hash calculation on the node as a whole), use the calculated hash value as the key, and use the data content contained in the tree node or leaf node as the value to generate a key-value pair. Then, the generated key-value pair is stored in the database. When you need to query a node on the FDMT tree, you can use the hash value of the data content contained in the node as the key to perform content addressing.

[0121] It should be noted that Figure 4The illustrated FDMT tree structure can be used to store the account status data of each blockchain account in a blockchain, as well as the contract data stored in the storage space corresponding to a contract account. The FDMT tree used to store the account status data of each blockchain account in a blockchain can be referred to as the FDMT state tree. The FDMT tree used to store the contract data stored in the storage space corresponding to a contract account can be referred to as the FDMT storage tree. The root node of the FDMT storage tree can be linked to the leaf node corresponding to the contract account in the FDMT state tree via its hash value. The hash value of the root node of the FDMT storage tree can also be added to the storage root field of the account status stored in the leaf node corresponding to the contract account in the FDMT state tree. This description will not be repeated here.

[0122] It should be noted that, whether Figure 1 The MPT tree shown, or Figure 4 The data actually stored in the Leaf nodes of the FDMT tree shown in the figure usually has a larger data capacity than other types of nodes. For example, the value of the blockchain data actually stored in the Leaf nodes is usually the original content of the blockchain data. The original content of the blockchain data occupies a larger storage space than the character prefix of the blockchain data. Therefore, in order to ensure that the Leaf nodes can have a larger data capacity, whether it is Figure 1 The MPT tree shown, or Figure 4 The leaf nodes on the FDMT tree shown are usually designed in the form of large data blocks.

[0123] The specific form and storage structure of the above data blocks are not particularly limited in this specification.

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

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

[0126] like Figure 6 As shown, in the above bucket data bucket (i.e. Figure 6The bucket node shown in FIG) may include several data records. Each data record corresponds to a blockchain data, and the character suffix of the key used to store the blockchain data (i.e. Figure 6 In other words, a data record refers to a storage record that includes the key suffix and value of the blockchain data.

[0127] It should be noted that Figure 6 The structure of the bucket data bucket shown is specifically based on Figure 4 The Leaf node on the FDMT tree shown is used as an example for explanation. In actual application, Figure 6 The structure of the bucker node shown can also be used as Figure 1 The Leaf node of the MPT tree shown is not described in detail in this specification.

[0128] In practical applications, since the data size of blockchain data in the blockchain usually continues to grow, as the data size of blockchain data continues to grow, whether it is organizing blockchain data into Figure 1 The MPT tree shown is stored in the database and is organized into Figure 4 Storing the FDMT tree shown in the figure in a database may eventually cause the database to face performance problems.

[0129] For example, when the capacity of blockchain data stored in a database is overloaded, it often leads to a decrease in the database's read and write performance. Moreover, once a file in the database is damaged, it often takes a very long time to restore the database.

[0130] In view of this, this specification proposes a technical solution for storing the nodes in the logical tree structure in multiple databases without sacrificing the integrity of the logical tree structure.

[0131] During implementation, the nodes for storing blockchain data contained in the tree structure of the above logic can be stored in multiple databases respectively.

[0132] In addition, the data structure of the nodes on the above-mentioned logical tree structure can be expanded. In the storage content of the nodes on the above-mentioned logical tree structure, in addition to the hash value of the node of the next layer linked to the node, it can also include the database identifier of the database storing the node of the next layer.

[0133] By storing the nodes of a logical tree structure composed of key-value pairs based on blockchain data groups in multiple databases, the performance issues faced by storing blockchain data in a single database can be avoided, and the scalability of the database used to store blockchain data can be improved.

[0134] On the other hand, since the data structure of the nodes on the above-mentioned logical tree structure can include, in addition to the hash value of the node on the next layer linked to the node, the database identifier of the database storing the node on the next layer; therefore, in this way, even if the nodes on the above-mentioned logical tree structure are stored in different databases respectively, the nodes distributed in different databases can still be linked together according to the hash value of the node on the next layer stored in the node and the corresponding database identifier, so that the nodes distributed in different databases are still logically a whole, thereby still ensuring the integrity of the above-mentioned logical tree structure.

[0135] See Figure 7 , Figure 7 This is a flowchart of a blockchain data storage method provided by an exemplary embodiment. The method is applied to a node device in a blockchain; the method includes the following steps:

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

[0137] The aforementioned blockchain data to be stored may specifically include any type of data requiring persistent storage within the blockchain. In one illustrated embodiment, the aforementioned blockchain data to be stored may specifically include account status data corresponding to blockchain accounts on the blockchain. For example, as previously mentioned, in practical applications, blockchain accounts within a blockchain typically include external accounts and contract accounts. Therefore, the account status data corresponding to blockchain accounts on the blockchain may specifically include account status data corresponding to user accounts and contract accounts on the blockchain (e.g., account balance data), as well as state variable data stored within contract accounts on the blockchain (e.g., evidence data stored within smart contracts). Of course, in practical applications, the aforementioned 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 is completed, and so on.

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

[0139] 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, and the node device can directly obtain the key-value pairs of the blockchain data to be stored processed by the third party from the third party.

[0140] The key in a key-value pair of blockchain data may refer to the primary key of the blockchain data in the database. This primary key may serve as a query index. The value in a key-value pair of blockchain data may refer to the data content of the blockchain data.

[0141] It should be noted that for different types of blockchain data, the key in their key-value pairs may generally differ. For example, if the blockchain data is account status data corresponding to a blockchain account in a blockchain, the key in the key-value pair for the account status data may be the account address of the blockchain account. If the blockchain data is transaction data or receipt data corresponding to the transaction data in a blockchain, the key in the key-value pair for the transaction data or receipt data may be a transaction identifier. For example, in practical applications, the transaction identifier may be the hash value of the transaction, or the transaction ID assigned to the transaction during consensus.

[0142] Step 704: Convert the key-value pairs of the blockchain data into root nodes, intermediate nodes, and leaf nodes in a logical tree structure; wherein the nodes in the logical tree structure are linked to the nodes in the upper layer through their hash values; the storage content of the nodes in the logical tree structure includes the hash value of the node in the lower layer linked to the node and the database identifier of the database storing the node in the lower layer; the root node and intermediate node are used to store the characters in the key of the key-value pair corresponding to the blockchain data; the leaf node is used to store the value of the key-value pair corresponding to the blockchain data;

[0143] The key-value pairs of the blockchain data to be stored can be organized into a logical tree structure and stored in the database as nodes on this logical tree structure. 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.

[0144] For example, in practical applications, the aforementioned logical tree structure may include multiple layers of nodes, which may be stored in units of nodes in the underlying physical storage (e.g., disk) hosting the database. When blockchain data stored in the aforementioned logical tree structure is needed, the multiple layers of nodes stored in the database may be loaded into memory, and the tree structure may be logically restored in memory based on the link relationships between the nodes.

[0145] In practical applications, the above logical tree structure may 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 the key-value pairs of the blockchain data to be stored into the root node, intermediate nodes, and leaf nodes of the above logical tree structure.

[0146] For example, in one example, the node device may be equipped with a storage interface or storage service that can be used to convert key-value pairs of the blockchain data to be stored into nodes in a logical tree structure. After obtaining the key-value pairs of the blockchain data to be stored, the node device can call the storage interface or storage service to convert the key-value pairs of the blockchain data to be stored into the root node, intermediate nodes, and leaf nodes of the logical tree structure.

[0147] Nodes in the aforementioned logical tree structure can still be linked to nodes in the previous layer via their own hash values. The root node and intermediate nodes are specifically used to store at least one character of the key in a key-value pair of blockchain data. The leaf nodes are specifically used to store the value of the blockchain data (i.e., the specific content of the blockchain data). The number of intermediate nodes can be one or multiple layers, and is not specifically limited in this specification.

[0148] For example, in one example, the key of the blockchain data can still include a character prefix part (Shared nibble) and a character suffix part (key-end). In this case, the root node and intermediate nodes can be used to store the characters in the character prefix, while the leaf nodes can be used to store the character suffix and the value of the blockchain data.

[0149] On the one hand, because the root node and intermediate nodes in the above-mentioned logical tree structure can store the characters in the blockchain data key, the above-mentioned logical tree structure has the characteristics of a Trie dictionary tree. On the other hand, the nodes in the above-mentioned logical tree structure can be linked to the nodes in the upper layer through their own hash values; therefore, the above-mentioned logical tree structure also has the characteristics of a Merkle tree. In summary, the logical tree structure described in this specification is actually a Merkle tree variant that integrates the tree structure of a Trie dictionary tree, similar to an MPT tree or an FDMT tree.

[0150] Unlike conventional logical tree structures such as the traditional MPT tree and FDMT tree described in the above embodiments, in this specification, the data structure of the nodes in the above logical tree structure can be expanded. In addition to including a field for populating the hash value of the node linked to the node in the next layer, the data structure of the node in the expanded logical tree structure can also include a field for storing the database identifier of the database of the node in the next layer.

[0151] In this way, the nodes on the above logical tree structure can be filled with richer information. In addition to the hash value of the node in the next layer linked to the node, the database identifier of the database of the node in the next layer can also be stored.

[0152] In one embodiment shown, the logical tree structure can still be a Merkle tree that incorporates a trie structure. For example, in some examples, the logical tree structure can be an MPT tree or FDMT tree that is an improvement of the node data structure.

[0153] See Figure 8 , Figure 8 This specification shows a Figure 1 Schematic diagram of the improved tree structure of the MPT tree based on .

[0154] When the logical tree structure is an MPT tree, the root node of the logical tree structure may be an extension node on the MPT tree, and the intermediate node of the logical tree structure may be an extension node or a branch node on the MPT tree.

[0155] like Figure 8 As shown, in Figure 8In the improved MPT tree shown, the next node field in the extended node is further expanded into two fields, one of which is used to store the hash value of the node in the next layer linked to the extended node, and the other is used to store the database identifier of the database corresponding to the node in the next layer (i.e. Figure 8 The database corresponding to the node of the next layer refers to the database storing the node of the next layer.

[0156] Each branch slot in the branch node, which represents a different character, can also be further expanded into two fields. One field is used to store the hash value of the node in the next layer linked to the expanded node, and the other field is used to store the database identifier of the database corresponding to the node in the next layer (i.e. Figure 8 n shown in ).

[0157] For the leaf nodes of the MPT tree, a database identification field may also be expanded to store the database identification of the database of the next layer node linked to the leaf node.

[0158] For example, as mentioned above, the leaf nodes on the MPT tree can be specifically represented as follows: Figure 6 In the structure of the bucket data bucket shown, a leaf node on the MPT tree may specifically include several data records. In this case, each data record in the leaf node may be expanded to include the above-mentioned database identification field.

[0159] It should be noted that when a leaf node is not linked to the root node of another MPT tree, the database identification field in the leaf node can be a null value. When the leaf node is linked to the root node of another MPT tree, the database identification field in the leaf node can be used to store the database identifier corresponding to the database storing the root node of the other MPT tree. For example, Figure 8 The MPT tree shown may be the MPT status tree described above, and the another MPT tree may specifically be another MPT storage tree linked to a leaf node of the MPT status tree described above, which will not be described in detail.

[0160] See Figure 9 , Figure 9 This specification shows a Figure 4 Schematic diagram of the tree structure of the improved FDMT tree based on .

[0161] When the logical tree structure is an FDMT tree, the root node and the intermediate nodes of the logical tree structure may be tree nodes on the FDMT tree.

[0162] like Figure 9 As shown, in Figure 9 In the improved FDMT tree shown, each tree node can still include multiple blocks representing different characters. Each block can further include multiple slots representing different characters. The slot can be further expanded from one field to two fields, one of which is used to store the hash value of the node in the next layer linked to the tree node, and the other field is used to store the database identifier of the database corresponding to the node in the next layer (i.e. Figure 9 The database corresponding to the node of the next layer refers to the database storing the node of the next layer.

[0163] For the leaf nodes of the FDMT tree, a database identification field may also be expanded to store the database identification of the database of the next layer node linked to the leaf node.

[0164] For example, as mentioned above, the leaf nodes on the FDMT tree can also be specifically represented as follows: Figure 6 In the structure of the bucket data bucket shown, the leaf node on the FDMT tree may also include several data records. In this case, each data record in the leaf node may be expanded to have the above-mentioned database identification field.

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

[0166] For example, in practical applications, the account status data corresponding to the user accounts and contract accounts on the blockchain can be organized into an FDMT state tree, and the state variable data stored in each contract account on the FDMT state tree can be organized into an FDMT storage tree. Figure 9 The FDMT tree shown may be an FDMT state tree, and the aforementioned another MPT tree may specifically be a leaf node of the FDMT state tree, linked to another FDMT storage tree, which will not be described in detail.

[0167] In this specification, to avoid using a single database to store blockchain data, blockchain node devices may be equipped with multiple databases for storing blockchain data. When storing key-value pairs of the blockchain data to be stored in the database as nodes in the aforementioned logical tree structure, the blockchain node devices may store the nodes in the aforementioned logical tree structure in multiple databases.

[0168] In this case, in the process of converting the key-value pairs of the blockchain data to be stored into the root nodes, intermediate nodes and leaf nodes on the above-mentioned logical tree structure, the node devices in the blockchain also need to determine the database of the root nodes, intermediate nodes and leaf nodes corresponding to the key-value pairs of the blockchain data to be stored on the above-mentioned logical tree structure.

[0169] Among them, the specific method of determining the database used to store the above-mentioned root nodes, intermediate nodes and leaf nodes usually depends on the data storage strategy adopted when the node devices in the blockchain use multiple databases to store blockchain data, and is not specifically limited in this specification.

[0170] In one embodiment shown, the above-mentioned data storage strategy can specifically be a data storage strategy that uses blockchain data as the smallest storage unit and stores the root nodes, intermediate nodes, and leaf nodes corresponding to the blockchain data in a logical tree structure in the same database.

[0171] In this case, when the node device in the blockchain determines the database for storing the root node, intermediate node and leaf node corresponding to the logical tree structure of the blockchain data, it can first determine the database for storing the blockchain data, and then further determine the database for storing the blockchain data as a database for storing the above-mentioned root node, intermediate node and leaf node.

[0172] The method for determining the database used to store the blockchain data is not particularly limited in this specification.

[0173] In one implementation shown, a database for storing the blockchain data may be determined based on a block number of a block corresponding to the blockchain data.

[0174] For example, each of the aforementioned databases can be assigned a corresponding block number range, with each database storing only the blockchain data for the blocks within its corresponding block number range. In this case, each node in the blockchain can maintain a mapping table; this mapping table can specifically include a mapping between a database identifier and the block number range assigned to the database corresponding to the database identifier.

[0175] When a node device in the blockchain determines a database for storing blockchain data based on the block number of the block corresponding to the blockchain data, it can query the mapping table to determine the block number interval in which the block number of the block corresponding to the blockchain data is located, and then determine the database corresponding to the database identifier that has a mapping relationship with the block number interval as the database for storing the blockchain data.

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

[0177] It should be noted that, in one example, the mapping table maintained locally by each node device in the blockchain can specifically be a mapping table stored on the blockchain after consensus is reached by each node device using the blockchain's consensus mechanism. This approach ensures the consistency of the mapping tables maintained by each node device in the blockchain, and avoids the problem of blockchain forks caused by differences in the mapping tables maintained by each node device.

[0178] Of course, it should be emphasized that in addition to determining the database for storing blockchain data based on the block number of the blockchain data as described above, the database for storing blockchain data can also be determined in other ways; for example, the database for storing blockchain data can also be determined based on the type of blockchain data, the size of the blockchain data, or other factors, which will not be listed one by one in this manual.

[0179] In one embodiment shown, the above-mentioned data storage strategy can specifically be a data storage strategy that uses the nodes on the above-mentioned logical tree structure as the smallest storage unit, and stores the root nodes, intermediate nodes and leaf nodes corresponding to the blockchain data on the logical tree structure in different databases respectively.

[0180] In this case, when determining the databases for storing the root nodes, intermediate nodes, and leaf nodes corresponding to the blockchain data in the logical tree structure, the node devices in the blockchain can specifically determine databases for different node types. For example, a corresponding node type can be assigned to each of the aforementioned multiple databases, with each database only storing nodes corresponding to that node type. In this case, the root nodes, intermediate nodes, and leaf nodes corresponding to the blockchain data in the logical tree structure can be stored in different databases. For example, three databases can be set up, one for storing the root node, one for storing the intermediate nodes, and one for storing the leaf nodes.

[0181] In this specification, after the node device in the blockchain determines the database of the root node, intermediate node and leaf node corresponding to the key-value pair for storing the above blockchain data in the above logical tree structure, it is usually necessary to further fill the database identifier of the database for storing each node into the node of the upper layer linked to the node.

[0182] Among them, for the leaf nodes on the tree structure of the above logic, the nodes on the previous layer to which they are linked are usually intermediate nodes. Therefore, for the leaf nodes, the database identifier corresponding to the database used to store the leaf nodes needs to be further filled in the intermediate nodes on the previous layer to which the leaf nodes are linked. For the intermediate nodes on the tree structure of the above logic, the nodes on the previous layer to which they are linked are usually intermediate nodes or root nodes. Therefore, for the intermediate nodes, the database identifier corresponding to the database used to store the intermediate nodes needs to be further filled in the intermediate nodes on the previous layer to which the intermediate nodes are linked or the root nodes on the previous layer.

[0183] For the root node in the tree structure of the above logic, the nodes in the previous layer usually have the following two situations:

[0184] In one case, if the above-mentioned logical tree structure is a subtree extending from the leaf node of another logical tree structure, then the upper-level node of the root node on the logical tree structure is the leaf node of the other logical tree structure. Therefore, in this case, the database identifier of the database used to store the root node of the logical tree structure can be filled into the leaf node of the other logical tree structure.

[0185] For example, see Figure 8For example, if the logical tree structure is an MPT tree, the MPT state tree can be used, and the other logical tree structure can be an MPT storage tree. For the root node of the MPT state tree, the database identifier of the database storing the root node needs to be added to the database identifier field of the leaf node linked to it in the MPT storage tree.

[0186] In another case, if the above-mentioned logical tree structure is not a subtree extending from a leaf node of another logical tree structure, then the upper-level node of the root node of the logical tree structure is usually the block header of the block corresponding to the logical tree structure. Therefore, in this case, the database identifier of the database used to store the root node of the logical tree structure can be filled into the block header of the block corresponding to the logical tree structure.

[0187] It should be noted that, in some cases, if the above-mentioned logical tree structure is not a subtree extending from a leaf node of another logical tree structure, then the database identifier of the database used to store the root node of the logical tree structure may not be filled into the block header of the block corresponding to the logical tree structure.

[0188] For example, as previously mentioned, if the database used to store blockchain data is determined based on the block number of the blockchain data, the database used to store the root node in the logical tree structure can generally be determined based on the block number of the block corresponding to the logical tree structure. The block header of the block corresponding to the logical tree structure generally includes the block number of the block. Therefore, in this case, the database identifier of the database used to store the root node of the logical tree structure can be omitted from the block header of the block corresponding to the logical tree structure. The database used to store the root node of the logical tree structure can subsequently be determined by reading the block number in the block header based on the block number.

[0189] In this specification, the process by which a node device in a blockchain converts the key-value pairs of blockchain data to be stored into the root nodes, intermediate nodes, and leaf nodes of the above-mentioned logical tree structure generally refers to starting from the root node, traversing the existing logical tree structure to find the node corresponding to the blockchain data, and then adding and inserting a new node in the logical tree structure based on the found node to completely write the key-value pairs of the blockchain data into the logical tree structure.

[0190] For example, during implementation, starting from the root node, the characters stored in each node in the logical tree structure can be matched with the characters in the blockchain data key. If the characters stored in a node match the characters in the blockchain data key, then that node is the node corresponding to the blockchain data. Once the search is complete, the nodes corresponding to the blockchain data found may typically only store a portion of the characters in the blockchain data key. In this case, based on these found nodes, new nodes can be added to store the remaining characters in the blockchain data key, thereby completely writing the blockchain data key-value pairs into the logical tree structure.

[0191] Step 706: Store the root node, intermediate nodes, and leaf nodes in the determined database; wherein the nodes on the logical tree structure are stored in at least a plurality of databases respectively.

[0192] After the blockchain data to be stored is converted into the root node, intermediate node and leaf node in the above-mentioned logical tree structure, the above-mentioned root node, intermediate node and leaf node can be stored in the corresponding database respectively to complete the storage process for the blockchain data.

[0193] For example, if the aforementioned storage strategy uses blockchain data as the smallest storage unit, the root nodes, intermediate nodes, and leaf nodes corresponding to different blockchain data in the aforementioned logical tree structure will be stored in different databases. The root nodes, intermediate nodes, and leaf nodes corresponding to the same blockchain data will be stored in the same database.

[0194] If the storage strategy described above is adopted, which uses the nodes on the tree structure of the above logic as the smallest storage unit, then even the root nodes, intermediate nodes, and leaf nodes corresponding to the same blockchain data will be stored in different databases; for example, the root nodes, intermediate nodes, and leaf nodes can be stored in three different databases according to the node type.

[0195] In the above technical solution, by storing the nodes of the logical tree structure composed of key-value pairs based on the blockchain data group in multiple databases, the performance problems faced by storing blockchain data in a single database can be avoided, and the scalability of the database used to store blockchain data can be improved.

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

[0197] The specific process of updating the nodes on the above logical tree structure is described in detail below through specific embodiments.

[0198] See Figure 10 , Figure 10 is Figure 7 A flowchart of a blockchain data update method is provided based on the illustrated embodiment. The method is applied to a node device in a blockchain; the method includes the following steps:

[0199] Step 1002: Determine the root node, intermediate nodes, and leaf nodes on the logical tree structure for storing key-value pairs of the target blockchain data to be updated, and determine a database for storing the updated root node, intermediate nodes, and leaf nodes;

[0200] The tree structure of the above logic can also be a Merkle tree that integrates the tree structure of the dictionary tree. For example, the tree structure of the above logic can be the improved MPT tree shown in Figure 8, or it can be the improved MPT tree shown in Figure 9. Figure 9 The improved FDMT tree shown is not particularly limited in this embodiment.

[0201] The node device in the blockchain can synchronously update the root node, intermediate node and leaf node corresponding to the target blockchain data in the above logical tree structure stored in the database when the target blockchain data stored in the above logical tree structure is updated.

[0202] For example, in one example, assuming the target blockchain data is account status data corresponding to a blockchain account on the blockchain, a user can update the account status corresponding to a blockchain account on the blockchain by publishing a blockchain transaction on the blockchain. Upon receiving the transaction, the node device in the blockchain can execute the blockchain transaction on the blockchain, synchronously updating the root node, intermediate nodes, and leaf nodes corresponding to the account status data of the blockchain account in the logical tree structure stored in the database.

[0203] When the node devices in the blockchain update the root nodes, intermediate nodes, and leaf nodes of the key-value pairs in the above logical tree structure for storing the above target blockchain data:

[0204] On the one hand, the root node, intermediate node and leaf node of the key-value pair for storing the target blockchain data can be determined on the tree structure of the above logic.

[0205] Among them, it should be noted that when the node device in the blockchain updates the root node, intermediate node and leaf node of the key-value pair of the above-mentioned target blockchain data on the above-mentioned logical tree structure, it can specifically adopt the method of first loading the nodes in the above-mentioned logical tree structure from the database into the memory, and then updating the nodes corresponding to the key-value pairs of the above-mentioned target blockchain data in the memory, and then writing the updated nodes into the database.

[0206] In one embodiment shown, when a node device in a blockchain updates the root node, intermediate node, and leaf node of the key-value pair of the target blockchain data on the logical tree structure, it can specifically load the nodes in the logical tree structure from the database into the memory, then update the nodes corresponding to the key-value pairs of the target blockchain data in the memory, and then write the updated nodes into the database.

[0207] In this case, when determining the root node, intermediate node, and leaf node of the logical tree structure for storing the key-value pairs of the target blockchain data, the node device in the blockchain can first read the nodes of the logical tree structure from the database and load the read nodes into the memory; then, from the nodes of the logical tree structure loaded into the memory, further determine the root node, intermediate node, and leaf node for storing the target blockchain data. The detailed process of reading the nodes in the logical tree structure from the database is not repeated in this embodiment, and please refer to the following embodiment.

[0208] Of course, in actual applications, when the node devices in the blockchain update the root nodes, intermediate nodes and leaf nodes of the key-value pairs used to store the above-mentioned target blockchain data in the above-mentioned logical tree structure, they can also directly update the relevant nodes stored in the database, which is not specifically limited in this specification.

[0209] On the other hand, in addition to determining the root node, intermediate node and leaf node of the key-value pairs of the target blockchain data on the above-mentioned logical tree structure, the node device in the blockchain can also determine the database for storing the updated root node, intermediate node and leaf node.

[0210] Among them, the specific method of determining the database used to store the updated root node, intermediate node and leaf node is also generally dependent on the data storage strategy adopted when the node device in the blockchain uses multiple databases to store blockchain data, which will not be described in detail in this embodiment.

[0211] For example, as mentioned above, in one embodiment shown, if the above-mentioned data storage strategy, specifically a strategy that uses blockchain data as the smallest storage unit and stores the root nodes, intermediate nodes and leaf nodes corresponding to the blockchain data in the logical tree structure in the same database, then when the node device in the blockchain determines the database for storing the updated root nodes, intermediate nodes and leaf nodes, it can first determine the database for storing the target blockchain data, and then further determine the database for storing the target blockchain data as the database for storing the updated root nodes, intermediate nodes and leaf nodes.

[0212] In one implementation method shown, when determining the database for storing the target blockchain data, the database for storing the target blockchain data can still be determined based on the block number of the block corresponding to the target blockchain data.

[0213] For example, each of the aforementioned databases can be assigned a corresponding block number range, with each database storing only the blockchain data for the blocks within its corresponding block number range. In this case, each node in the blockchain can maintain a mapping table; this mapping table can specifically include a mapping between a database identifier and the block number range assigned to the database corresponding to the database identifier.

[0214] When a node device in a blockchain determines a database for storing target blockchain data based on the block number of the block corresponding to the target blockchain data, it may query the mapping table to determine the block number interval within which the block number of the block corresponding to the target blockchain data falls, and then determine the database corresponding to the database identifier that has a mapping relationship with the block number interval as the database for storing the target blockchain data. It should also be noted that, in one example, the mapping table locally maintained by each node device in the blockchain may specifically be a mapping table stored on the blockchain after consensus is reached by each node device using the blockchain's consensus mechanism.

[0215] In addition to determining the database for storing blockchain data based on the block number of the blockchain data, the database for storing blockchain data can also be determined in other ways; for example, the database for storing blockchain data can also be determined based on the type of blockchain data, the size of blockchain data, or other factors, which are not listed one by one.

[0216] Step 1004: Update the determined leaf node based on the value of the key-value pair of the target blockchain data. After the leaf node is updated, write the hash value of the updated leaf node and the database identifier of the database determined for storing the updated leaf node into the intermediate node of the upper layer linked to the leaf node to update the intermediate node.

[0217] Step 1006, after the update of the intermediate node is completed, the hash value of the updated intermediate node and the database identifier of the database determined for storing the updated intermediate node are further written into the node of the upper layer linked to the intermediate node, so as to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node update on the logical tree structure is completed.

[0218] After determining the root node, intermediate node and leaf node of the above-mentioned logical tree structure for storing the key-value pairs of the above-mentioned target blockchain data, the node devices in the blockchain can start from the leaf node and update the leaf node, intermediate node and root node of the above-mentioned logical tree structure for storing the key-value pairs of the above-mentioned target blockchain data in sequence according to the link relationship between each node.

[0219] Since the storage content of a node in the tree structure of the aforementioned logic includes not only the hash value of the node linked to the node in the next layer, but also the database identifier of the database storing the node in the next layer, the process of updating the determined root node, intermediate node, and leaf node is the process of populating the root node, intermediate node, and leaf node with the hash value of the node in the next layer to which it is linked and the database identifier of the database storing the updated node in the next layer.

[0220] In one implementation shown, a data update method is used as an example in which a node device of a blockchain first loads the nodes in the above-mentioned logical tree structure from a database into a memory, then updates the nodes corresponding to the key-value pairs of the above-mentioned target blockchain data in the memory, and then writes the updated nodes into the database. In this case, the node device in the blockchain determines the root node, intermediate node, and leaf node for storing the above-mentioned target blockchain data from the nodes on the above-mentioned logical tree structure loaded into the memory. First, the leaf node determined based on the Value pair of the key-value pair of the target blockchain data can be updated. After the update of the leaf node is completed, the hash value of the leaf node and the database identifier of the database for storing the updated leaf node previously determined are further written into the intermediate node of the upper layer linked to the leaf node to update the intermediate node.

[0221] When the intermediate node is updated, the hash value of the updated intermediate node and the database identifier of the database previously determined for storing the updated intermediate node can be further written into the node of the upper layer linked to the intermediate node to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node of the above-mentioned logical tree structure is updated.

[0222] In this embodiment, after the root node of the tree structure of the above logic is updated:

[0223] In one aspect, a node device in a blockchain may, in response to an instruction to store the updated root node, intermediate node, and leaf node in a database, store the updated root node, intermediate node, and leaf node in a database determined for the root node, intermediate node, and leaf node, respectively. For example, in one example, the instruction may specifically be a commit instruction to write the updated root node, intermediate node, and leaf node stored in memory to the database.

[0224] On the other hand, the node devices in the blockchain can also fill the hash value of the updated root node on the above logical tree structure into the node on the previous layer to which it is linked.

[0225] For example, if the logical tree structure is a subtree extending from a leaf node of another logical tree structure, and the node linked to the updated root node of the logical tree structure is a leaf node of the other logical tree structure, the hash value of the updated root node of the logical tree structure can be populated into the leaf node of the other logical tree structure linked to the root node of the logical tree structure.

[0226] If the logical tree structure is not a subtree extending from a leaf node of another logical tree structure, the node linked to the previous level by the updated root node of the logical tree structure is the block header of the block corresponding to the logical tree structure. In this case, the hash value of the updated root node of the logical tree structure can be added to the block header of the block corresponding to the logical tree structure. For example, assuming that the logical tree structure is the MPT state tree corresponding to block 100, the hash value of the root node of the MPT state tree can be added to the block header of the 100th block.

[0227] In the above embodiment, when updating a node in the tree structure of the above logic, in addition to filling the hash value of the node into the node in the previous layer to which the node is linked, the database identifier of the database used to store the node can also be filled into the node in the previous layer to which the node is linked. Therefore, in this way, even if the nodes in the tree structure of the above logic are stored in different databases, the nodes distributed in different databases can still be linked together based on the hash value and corresponding database identifier of the node in the next layer stored in the node, so that the nodes distributed in different databases are still logically a whole, thereby still ensuring the integrity of the tree structure of the above logic.

[0228] In this specification, as described above, when a target blockchain data stored in the above-mentioned logical tree structure is updated, when the root node, intermediate node and leaf node corresponding to the target blockchain data on the logical tree structure are updated, the nodes on the above-mentioned logical tree structure can usually be loaded from the database into the memory, and then the nodes corresponding to the key-value pairs of the above-mentioned target blockchain data are updated in the memory, and then the updated nodes are written to the database.

[0229] The following describes in detail the process of reading the nodes on the tree structure of the above logic from the database and loading them into the memory on the node device in the blockchain through a specific embodiment.

[0230] See Figure 11 , Figure 11 is Figure 7 and Figure 10 A flowchart of a blockchain data reading method is provided based on the illustrated embodiment. The method is applied to a node device in a blockchain; the method includes the following steps:

[0231] Step 1102: Read the hash value of the root node of the logical tree structure and determine a database for storing the root node of the logical tree structure; use the hash value of the root node as a query index to query the root node from the database, and load the query root node into memory;

[0232] The tree structure of the above logic can also be a Merkle tree that integrates the tree structure of the dictionary tree. For example, the tree structure of the above logic can be the improved MPT tree shown in Figure 8, or it can be the Figure 9 The improved FDMT tree shown is not particularly limited in this embodiment.

[0233] When a node device in the blockchain reads a node in the above-mentioned logical tree structure from a database, it can specifically start from the root node of the above-mentioned logical tree structure, and then read the root node, intermediate node and leaf node in the above-mentioned logical tree structure in sequence according to the link relationship between each node.

[0234] When a node device in the blockchain reads the root node in the above logical tree structure, it can first read the hash value of the root node.

[0235] In one embodiment, if the logical tree structure is a subtree extending from a leaf node of another logical tree structure, as previously described, the hash value of the root node of the logical tree structure is typically populated in the leaf nodes of the other logical tree structure to which the root node is linked. In this case, node devices in the blockchain can read the hash value of the root node from the leaf nodes of the other logical tree structure to which the root node of the logical tree structure is linked.

[0236] In one embodiment, if the logical tree structure is not a subtree extending from a leaf node of another logical tree structure, as previously described, the hash value of the root node of the logical tree structure is typically populated in the block header of the block corresponding to the logical tree structure. In this case, node devices in the blockchain can read the hash value of the root node from the block header of the block corresponding to the logical tree structure.

[0237] After reading the hash value of the root node of the logical tree structure above, the node device in the blockchain can further determine the database used to store the root node.

[0238] In one illustrated embodiment, if the aforementioned logical tree structure is a subtree extending from a leaf node of another logical tree structure, as previously described, the database identifier of the database storing the root node of the logical tree structure is typically populated in the leaf node of the other logical tree structure linked to the root node. In this case, a node device in the blockchain can read the database identifier of the database storing the root node of the logical tree structure from the leaf node of the other logical tree structure linked to the root node of the logical tree structure, and determine the database storing the root node of the logical tree structure based on the read database identifier.

[0239] In one embodiment shown, if the logical tree structure is not a subtree extending from a leaf node of another logical tree structure, determining a database for storing the root node of the logical tree structure generally includes the following two situations:

[0240] In one case, if the database identifier of the database used to store the root node of the logical tree structure is pre-filled into the block header of the block corresponding to the logical tree structure, the database identifier of the database used to store the root node of the logical tree structure can be read from the block header of the block, and the database used to store the root node of the logical tree structure can be determined based on the read database identifier.

[0241] In another case, if the method used to determine the database used to store blockchain data is based on the block number of the blockchain data, and the database identifier of the database used to store the root node of the logical tree structure is not pre-filled in the block header of the block corresponding to the logical tree structure, then the block number can be read from the block header of the block, and the database used to store the root node of the logical tree structure can be determined based on the read block number.

[0242] For example, each of the aforementioned databases can be assigned a corresponding block number range, with each database storing only the blockchain data for the blocks within its corresponding block number range. In this case, each node in the blockchain can maintain a mapping table; this mapping table can specifically include a mapping between a database identifier and the block number range assigned to the database corresponding to the database identifier.

[0243] When a node device in a blockchain determines the database for storing the root node in the logical tree structure based on a block number, it can query the mapping table to determine the block number interval in which the block number falls, and then determine the database corresponding to the database identifier that has a mapping relationship with the block number interval as the database for storing the root node in the logical tree structure. It should be noted that, in one example, the mapping table maintained locally by each node device in the blockchain can also be a mapping table stored on the blockchain after consensus is reached by each node device using the blockchain's consensus mechanism.

[0244] After reading the hash value of the root node of the tree structure of the above logic and further determining the database used to store the root node, the node device in the blockchain can use the hash value of the root node as a query index, query the root node from the database, and then load the queried root node into the memory.

[0245] Step 1104: Read the hash value of the intermediate node in the next layer linked to the root node and the database identifier of the database storing the intermediate node, use the hash value of the intermediate node as a query index, query the intermediate node from the database corresponding to the database identifier, and load the queried intermediate node into the memory;

[0246] Step 1106, read the hash value of the node of the next layer linked to the intermediate node stored in the intermediate node and the database identifier of the database storing the next layer node, and use the hash value of the node of the next layer as the query index, query the next layer node from the database corresponding to the database identifier, and load the queried next layer node into the memory, and so on, until all leaf nodes in the logical tree structure are loaded into the memory.

[0247] After the node device in the blockchain loads the root node of the above-mentioned logical tree structure into the memory, the node device can continue to read the hash value of the intermediate node in the next layer linked to the root node stored in the root node, as well as the database identifier of the database storing the intermediate node. The hash value of the intermediate node can then be used as a query index to query the intermediate node from the database corresponding to the database identifier, and the queried intermediate node can be loaded into the memory.

[0248] After a node device in a blockchain loads the intermediate node linked to the root node into memory, it can continue to read the hash value of the node linked to the next layer stored in the intermediate node, as well as the database identifier of the database storing the node in the next layer. It can then use the hash value of the node in the next layer as a query index to query the node in the next layer from the database corresponding to the database identifier, and load the queried node in the next layer into memory. For the node in the next layer loaded into memory, the same actions as before can be continued, continuing to load nodes in the layer below the node linked to the next layer into memory, and so on, until all leaf nodes of the above logical tree structure are loaded into memory.

[0249] After all nodes in the logical tree structure are loaded into memory, the node devices in the blockchain can operate on the nodes in the logical tree structure in memory. The types of operations performed on the nodes in the logical tree structure in memory are not specifically limited in this embodiment. For example, in one example, the nodes in the logical tree structure can be modified and updated in memory, and the modified and updated nodes can then be rewritten to the database.

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

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

[0252] The device embodiments of this specification can be applied to electronic devices. Device embodiments can be implemented through software, hardware, or a combination of software and hardware. For example, a device implemented in software, as a logical device, is implemented by a processor of the electronic device in which it is located, reading corresponding computer program instructions from non-volatile memory into internal memory and executing them.

[0253] From the hardware level, Figure 12 The figure shows a hardware structure diagram of the electronic device where the device of this manual is located, except Figure 12In 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 according to the actual function of the electronic device, which will not be described in detail.

[0254] Figure 13 This is a block diagram of a blockchain data storage device shown in an exemplary embodiment of this specification.

[0255] Please refer to Figure 13 The blockchain data storage device 1300 can be used in the aforementioned Figure 12 In the electronic device shown, the device 130 includes:

[0256] Acquisition module 1301, acquiring key-value pairs of blockchain data to be stored;

[0257] A conversion module 1302 converts the key-value pairs of the blockchain data into root nodes, intermediate nodes, and leaf nodes in a logical tree structure; wherein a node in the logical tree structure is linked to a node in a layer above it via its hash value; the storage content of a node in the logical tree structure includes a hash value of a node in a layer below the node and a database identifier of a database storing the node in the layer below the node; the root node and intermediate nodes are used to store the characters in the key of the key-value pair corresponding to the blockchain data; and the leaf nodes are used to store the value of the key-value pair corresponding to the blockchain data;

[0258] The storage module 1303 stores the root node, the intermediate node and the leaf node in a database respectively; wherein the nodes on the logical tree structure are stored in at least a plurality of databases respectively.

[0259] Figure 14 This is a block diagram of a blockchain data updating device shown in an exemplary embodiment of this specification.

[0260] Please refer to Figure 14 The blockchain data updating device 140 can also be used in the aforementioned Figure 12In the electronic device shown, the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, an intermediate node, and a leaf node for storing the blockchain data; the nodes on the logical tree structure are stored in at least a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer via their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the device 140 includes:

[0261] Determining module 1401, determining a root node, an intermediate node, and a leaf node for storing key-value pairs of target blockchain data to be updated on the logical tree structure, and determining a database for storing the updated root node, intermediate node, and leaf node;

[0262] The updating module 1402 updates the leaf node determined based on the Value of the key-value pair of the target blockchain data. After the leaf node is updated, the hash value of the updated leaf node and the database identifier of the database determined for storing the updated leaf node are further written into the intermediate node of the upper layer linked to the leaf node to update the intermediate node; after the intermediate node is updated, the hash value of the updated intermediate node and the database identifier of the database determined for storing the updated intermediate node are further written into the node of the upper layer linked to the intermediate node to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node of the logical tree structure is updated.

[0263] Figure 15 This is a block diagram of a blockchain data reading device shown in an exemplary embodiment of this specification.

[0264] Please refer to Figure 15 The blockchain data reading device 1500 can also be used in the aforementioned Figure 12In the electronic device shown, the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, intermediate nodes, and leaf nodes for storing the blockchain data; wherein the nodes on the logical tree structure are stored in at least a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer via their hash values; the storage content of the nodes on the logical tree structure includes the hash value of the node on the lower layer linked to the node and the database identifier of the database storing the node on the lower layer; the apparatus 1500 includes:

[0265] The first reading module 1501 reads the hash value of the root node of the logical tree structure and determines a database for storing the root node of the logical tree structure; uses the hash value of the root node as a query index to query the root node from the database, and loads the query root node into a memory;

[0266] The second reading module 1502 reads the hash value of the intermediate node in the next layer linked to the root node and the database identifier of the database storing the intermediate node, uses the hash value of the intermediate node as a query index, queries the intermediate node from the database corresponding to the database identifier, and loads the queried intermediate node into the memory;

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

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

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

[0270] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0271] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0272] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0273] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0274] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0275] 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 the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, first information may also be referred to as second information, 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..." or "when..." or "in response to determining."

[0276] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit 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 shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A blockchain data storage method, the method comprising: Get the key-value pair of the blockchain data to be stored; The key-value pairs of the blockchain data are converted into root nodes, intermediate nodes, and leaf nodes in a logical tree structure; wherein the nodes in the logical tree structure are linked to the nodes in the upper layer through their hash values; the storage content of the nodes in the logical tree structure includes the hash value of the node in the lower layer linked to the node and the database identifier of the database storing the node in the lower layer; the root node and intermediate node are used to store the characters in the key of the key-value pair corresponding to the blockchain data; the leaf node is used to store the value of the key-value pair corresponding to the blockchain data; and the database identifier is used to determine the database storing the blockchain data; The root node, the intermediate node and the leaf node are stored in a database respectively; wherein the nodes on the logical tree structure are stored in a plurality of databases respectively.

2. The method according to claim 1, further comprising: Determining a database for storing the blockchain data; The database determined for storing the blockchain data is determined to be a database for storing the root node, intermediate node, and leaf node corresponding to the key-value pairs of the blockchain data in the logical tree structure.

3. The method according to claim 2, determining a database for storing the blockchain data, comprising: Based on the block number of the block corresponding to the blockchain data, determine a database for storing the blockchain data.

4. According to the method of claim 3, the node devices in the blockchain respectively maintain a mapping table; wherein, The mapping table includes a mapping relationship between a database identifier and a block number interval configured for the database identifier; Determining a database for storing the blockchain data based on a block number of a block corresponding to the blockchain data includes: The mapping table is queried to determine the block number interval in which the block number of the block corresponding to the blockchain data lies, and the database corresponding to the database identifier that has a mapping relationship with the block number interval is determined as the database for storing the blockchain data.

5. According to the method of claim 4, the mapping table is stored on the blockchain after consensus is reached by each node device in the blockchain.

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

7. The method according to claim 6, wherein the logical tree structure comprises an MPT tree; the root node comprises an extension node on the MPT tree; and the intermediate node comprises the extension node or a branch node on the MPT tree. in, The next node field in the extension node is used to store the hash value of the node in the next layer linked to the extension node and the database identifier of the database storing the node in the next layer; Each branch slot in the branch node represents a different character and is used to store the hash of the node in the next layer linked to the branch node and the database identifier of the database storing the node in the next layer; The leaf node on the MPT tree includes a newly added database identification field; the database identification field is used to store the database identification of the database storing the root node of another MPT tree when the value of the blockchain data stored in the leaf node is linked to the root node of another MPT tree.

8. The method according to claim 7, wherein the logical tree structure comprises an FDMT tree; in, The root node and intermediate node of the FDMT tree each include multiple positions for storing characters in a string corresponding to a key of a key-value pair of the blockchain data; each position includes multiple slots for storing characters in a string corresponding to a key of a key-value pair of the blockchain data; the slots are used to store the hash of a node in the next layer linked to the node and the database identifier of the database storing the node in the next layer; The leaf node on the FDMT tree includes a newly added database identification field; the database identification field is used to store the database identification of the database storing the root node of another FDMT tree when the value of the blockchain data stored in the leaf node is linked to the root node of another FDMT tree.

9. The method of claim 1 , wherein the blockchain data comprises account status data corresponding to a blockchain account on the blockchain.

10. The method according to claim 9, wherein the account status data comprises: Account status data corresponding to user accounts and contract accounts on the blockchain; The state variable data stored in the contract account on the blockchain.

11. A method for updating blockchain data, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, intermediate nodes, and leaf nodes for storing the blockchain data; wherein, The nodes on the logical tree structure are respectively stored in a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer through their hash values; the storage content of the nodes on the logical tree structure includes the hash values ​​of the nodes on the lower layer linked to the nodes and the database identifiers of the databases storing the nodes on the lower layer; The database identifier is used to determine the database storing the blockchain data; the method includes: Determine a root node, an intermediate node, and a leaf node on the logical tree structure for storing key-value pairs of the target blockchain data to be updated, and determine a database for storing the updated root node, intermediate node, and leaf node; The leaf node determined based on the value of the key-value pair of the target blockchain data is updated. After the leaf node is updated, the hash value of the updated leaf node and the database identifier of the database determined for storing the updated leaf node are further written into the intermediate node of the upper layer linked to the leaf node to update the intermediate node; After the update of the intermediate node is completed, the hash value of the updated intermediate node and the database identifier of the database determined for storing the updated intermediate node are further written into the node of the upper layer linked to the intermediate node to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node update on the logical tree structure is completed.

12. The method according to claim 11, further comprising: In response to the completion of the update of the root node on the logical tree structure, filling the hash value of the updated root node on the logical tree structure into the block header of the block corresponding to the target blockchain data; Alternatively, the hash value of the updated root node of the logical tree structure is filled into a leaf node of another logical tree structure linked to the root node of the logical tree structure.

13. The method according to claim 11, before determining the root node, intermediate node, and leaf node of the logical tree structure for storing the key-value pairs of the target blockchain data, further comprising: Reading nodes on the logical tree structure from the database, and loading the read nodes into memory; Determining a root node, an intermediate node, and a leaf node for storing the key-value pairs of the target blockchain data on the logical tree structure includes: From the nodes on the logical tree structure loaded into the memory, determine a root node, an intermediate node, and a leaf node for storing the target blockchain data.

14. The method according to claim 13, further comprising: In response to an instruction to store the updated root node, intermediate node and leaf node in a database, the updated root node, intermediate node and leaf node stored in the memory are respectively stored in the corresponding database.

15. The method according to claim 13, wherein determining a database for storing the updated root node, intermediate nodes, and leaf nodes comprises: Determining a database for storing the target blockchain data; The database determined for storing the blockchain data is determined as a database for storing the updated root node, intermediate node, and leaf node.

16. The method according to claim 15, wherein determining a database for storing the target blockchain data comprises: Based on the block number of the block corresponding to the target blockchain data, determine a database for storing the target blockchain data.

17. The method according to claim 16, wherein the node devices in the blockchain respectively maintain a mapping table; wherein, The mapping table includes a mapping relationship between a database identifier and a block number interval configured for the database identifier; Determining a database for storing the target blockchain data based on the block number of the block corresponding to the target blockchain data includes: The mapping table is queried to determine the block number interval in which the block number of the block corresponding to the target blockchain data is located, and the database corresponding to the database identifier that has a mapping relationship with the block number interval is determined as the database for storing the target blockchain data.

18. The method according to claim 17, wherein the mapping table is stored on the blockchain after being agreed upon by each node device in the blockchain.

19. The method according to claim 11, wherein the logical tree structure comprises a Merkle tree combined with a tree structure of a dictionary tree.

20. The method according to claim 19, wherein the logical tree structure comprises an MPT tree; the root node comprises an extension node on the MPT tree; the intermediate node comprises the extension node or a branch node on the MPT tree; in, The next node field in the extension node is used to store the hash value of the node in the next layer linked to the extension node and the database identifier of the database storing the node in the next layer; Each branch slot in the branch node represents a different character and is used to store the hash of the node in the next layer linked to the branch node and the database identifier of the database storing the node in the next layer; The leaf node on the MPT tree includes a newly added database identification field; the database identification field is used to store the database identification of the database storing the root node of another MPT tree when the value of the blockchain data stored in the leaf node is linked to the root node of another MPT tree.

21. The method according to claim 19, wherein the logical tree structure comprises an FDMT tree; in, The root node and intermediate node of the FDMT tree each include multiple positions for storing characters in a string corresponding to a key of a key-value pair of the blockchain data; each position includes multiple slots for storing characters in a string corresponding to a key of a key-value pair of the blockchain data; the slots are used to store the hash of a node in the next layer linked to the node and the database identifier of the database storing the node in the next layer; The leaf node on the FDMT tree includes a newly added database identification field; the database identification field is used to store the database identification of the database storing the root node of another FDMT tree when the value of the blockchain data stored in the leaf node is linked to the root node of another FDMT tree.

22. The method of claim 11, wherein the target blockchain data comprises account status data corresponding to a blockchain account on the blockchain.

23. The method according to claim 22, wherein the account status data comprises: Account status data corresponding to user accounts and contract accounts on the blockchain; The state variable data stored in the contract account on the blockchain.

24. A method for reading blockchain data, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, an intermediate node, and a leaf node for storing the blockchain data; wherein, The nodes on the logical tree structure are respectively stored in a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer through their hash values; the storage content of the nodes on the logical tree structure includes the hash values ​​of the nodes on the lower layer linked to the nodes and the database identifiers of the databases storing the nodes on the lower layer; The database identifier is used to determine the database storing the blockchain data; the method includes: Reading a hash value of a root node of the logical tree structure and determining a database for storing the root node of the logical tree structure; using the hash value of the root node as a query index, querying the root node from the database, and loading the query root node into a memory; Reading the hash value of the intermediate node in the next layer linked to the root node and the database identifier of the database storing the intermediate node stored in the root node, and using the hash value of the intermediate node as a query index, querying the intermediate node from the database corresponding to the database identifier, and loading the queried intermediate node into the memory; Read the hash value of the node in the next layer linked to the intermediate node and the database identifier of the database storing the node in the next layer stored in the intermediate node, and use the hash value of the node in the next layer as the query index, query the node in the next layer from the database corresponding to the database identifier, and load the queried node in the next layer into the memory, and so on, until all leaf nodes in the logical tree structure are loaded into the memory.

25. The method according to claim 24, Reading the hash value of the root node of the logical tree structure includes: Reading a hash value of the root node of the logical tree structure from a leaf node of another logical tree structure linked to the root node of the logical tree structure; Alternatively, the hash value of the root node of the logical tree structure is read from the block header of the block corresponding to the logical tree structure; Determining a database for storing a root node of the logical tree structure includes: Reading a database identifier of a database for storing the root node of the logical tree structure from a leaf node of another logical tree structure linked to the root node of the logical tree structure, and determining the database for storing the root node of the logical tree structure based on the read database identifier; Alternatively, a block number corresponding to the block corresponding to the logical tree structure is read from a block header of the block, and a database for storing a root node of the logical tree structure is determined based on the block number.

26. The method according to claim 25, wherein the node devices in the blockchain respectively maintain a mapping table; wherein, The mapping table includes a mapping relationship between a database identifier and a block number interval configured for the database identifier; Determining a database for storing a root node of the logical tree structure based on the block number includes: The mapping table is queried to determine the block number interval in which the block number is located, and the database corresponding to the database identifier having a mapping relationship with the block number interval is determined as the database for storing the root node of the logical tree structure.

27. The method according to claim 26, wherein the mapping table is stored on the blockchain after being agreed upon by each node device in the blockchain.

28. The method according to claim 27, wherein the logical tree structure comprises a Merkle tree combined with a tree structure of a dictionary tree.

29. The method according to claim 28, wherein the logical tree structure comprises an MPT tree; the root node comprises an extension node on the MPT tree; and the intermediate node comprises the extension node or a branch node on the MPT tree. in, The next node field in the extension node is used to store the hash value of the node in the next layer linked to the extension node and the database identifier of the database storing the node in the next layer; Each branch slot in the branch node represents a different character and is used to store the hash of the node in the next layer linked to the branch node and the database identifier of the database storing the node in the next layer; The leaf node on the MPT tree includes a newly added database identification field; the database identification field is used to store the database identification of the database storing the root node of another MPT tree when the value of the blockchain data stored in the leaf node is linked to the root node of another MPT tree.

30. The method according to claim 28, wherein the logical tree structure comprises an FDMT tree; in, The root node and intermediate node of the FDMT tree each include multiple positions for storing characters in a string corresponding to a key of a key-value pair of the blockchain data; each position includes multiple slots for storing characters in a string corresponding to a key of a key-value pair of the blockchain data; the slots are used to store the hash of a node in the next layer linked to the node and the database identifier of the database storing the node in the next layer; The leaf node on the FDMT tree includes a newly added database identification field; the database identification field is used to store the database identification of the database storing the root node of another FDMT tree when the value of the blockchain data stored in the leaf node is linked to the root node of another FDMT tree.

31. The method of claim 28, wherein the blockchain data comprises account state data corresponding to a blockchain account on the blockchain.

32. The method of claim 31 , wherein the account status data comprises: Account status data corresponding to user accounts and contract accounts on the blockchain; The state variable data stored in the contract account on the blockchain.

33. A blockchain data storage device, comprising: Acquisition module, obtains the key-value pair of blockchain data to be stored; A conversion module converts the key-value pairs of the blockchain data into root nodes, intermediate nodes, and leaf nodes in a logical tree structure; wherein the nodes in the logical tree structure are linked to the nodes in the upper layer through their hash values; the storage content of the nodes in the logical tree structure includes the hash value of the node in the lower layer linked to the node and the database identifier of the database storing the node in the lower layer; the root node and intermediate node are used to store the characters in the key of the key-value pair corresponding to the blockchain data; the leaf node is used to store the value of the key-value pair corresponding to the blockchain data; and the database identifier is used to determine the database storing the blockchain data; A storage module stores the root node, intermediate nodes and leaf nodes in a database respectively; wherein the nodes on the logical tree structure are stored in multiple databases respectively.

34. A blockchain data updating device, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, an intermediate node, and a leaf node for storing the blockchain data; wherein, The nodes on the logical tree structure are respectively stored in a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer through their hash values; the storage content of the nodes on the logical tree structure includes the hash values ​​of the nodes on the lower layer linked to the nodes and the database identifiers of the databases storing the nodes on the lower layer; The database identifier is used to determine the database storing the blockchain data; the device includes: A determination module is configured to determine a root node, an intermediate node, and a leaf node on the logical tree structure for storing key-value pairs of target blockchain data to be updated, and to determine a database for storing the updated root node, intermediate node, and leaf node; An update module updates the determined leaf node based on the Value of the key-value pair of the target blockchain data. After the leaf node is updated, the hash value of the updated leaf node and the database identifier of the database determined for storing the updated leaf node are further written into the intermediate node of the upper layer linked to the leaf node to update the intermediate node; after the intermediate node is updated, the hash value of the updated intermediate node and the database identifier of the database determined for storing the updated intermediate node are further written into the node of the upper layer linked to the intermediate node to continue updating the node of the upper layer linked to the intermediate node, and so on, until the root node of the logical tree structure is updated.

35. A blockchain data reading device, wherein the key-value pairs of the blockchain data are stored in a database in the form of nodes on a logical tree structure; the logical tree structure includes a root node, an intermediate node, and a leaf node for storing the blockchain data; wherein, The nodes on the logical tree structure are respectively stored in a plurality of databases; the nodes on the logical tree structure are linked to the nodes on the upper layer through their hash values; the storage content of the nodes on the logical tree structure includes the hash values ​​of the nodes on the lower layer linked to the nodes and the database identifiers of the databases storing the nodes on the lower layer; The database identifier is used to determine the database storing the blockchain data; the device includes: a first reading module, which reads a hash value of a root node of the logical tree structure and determines a database for storing the root node of the logical tree structure; uses the hash value of the root node as a query index, queries the root node from the database, and loads the queried root node into a memory; a second reading module, which reads the hash value of the intermediate node in the next layer linked to the root node and the database identifier of the database storing the intermediate node, uses the hash value of the intermediate node as a query index, queries the intermediate node from the database corresponding to the database identifier, and loads the queried intermediate node into the memory; The third reading module reads the hash value of the node of the next layer linked to the intermediate node stored in the intermediate node and the database identifier of the database storing the next layer node, and uses the hash value of the node of the next layer as the query index, queries the next layer node from the database corresponding to the database identifier, and loads the queried next layer node into the memory, and so on, until all leaf nodes in the logical tree structure are loaded into the memory.

36. An electronic device comprising: processor; a memory for storing processor-executable instructions; The processor implements the steps of the method according to any one of claims 1 to 32 by running the executable instructions.

37. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the instruction is executed by a processor, the steps of the method according to any one of claims 1 to 32 are implemented.

Images