Method for constructing world state based on merkle patricia tree, and computer device

Abstract

A method for constructing a world state based on a Merkle Patricia Tree, which method is applied to a storage module of a blockchain node, the storage module constructing a tree-structured world state in a memory. The method comprises: receiving a state key-value; on the basis of a lexicographical order rule of the Merkle Patricia Tree, generating a leaf node of the tree structure, and storing the state value in a data file of a persistent storage medium, wherein the leaf node comprises a location index of the state value in the data file in the persistent storage medium; and calculating a hash value of the leaf node on the basis of the content in the leaf node, and storing the hash value of the leaf node in an upper-level tree node thereof.

Description

A method and computer device for constructing a world state based on a Merkle dictionary tree

[0001] The present application claims priority to the Chinese patent application No. 2024109696604, filed on July 18, 2024, and entitled "A method and computer device for constructing a world state based on a Merkle dictionary tree", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The embodiments of the present specification belong to the technical field of blockchain technology, and particularly relate to a method and computer device for constructing a world state based on a Merkle dictionary tree. BACKGROUND

[0003] Blockchain is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In a blockchain system, data blocks are combined into a chain-like data structure in a sequential manner according to time sequence, and are guaranteed to be tamper-proof and unforgeable by cryptography. Due to the characteristics of decentralization, information tamper-proof, autonomy, etc., blockchain has also received more and more attention and application.

[0004] SUMMARY

[0005] The purpose of the present application is to provide a method and computer device for constructing a world state based on a Merkle dictionary tree, comprising:

[0006] A method for constructing a world state based on a Merkle dictionary tree, applied to a storage module of a blockchain node, the storage module constructs a tree-structured world state in memory, and the method comprises:

[0007] Receiving a state key-value;

[0008] According to the lexicographic rule of the Merkle dictionary tree, generating a leaf node of the tree structure, storing the state value in a data file of a persistent storage medium, and including the location index of the state value in the data file of the persistent storage medium in the leaf node;

[0009] According to the content of the leaf node, calculating the hash value of the leaf node, and storing the hash value of the leaf node in the upper layer of the tree node.

[0010] A computer device, comprising:

[0011] A processor;

[0012] and a memory having stored therein a program, wherein the operations of the above-described method are performed by the processor when executing the program.

[0013] In the above embodiments, the above scheme of the present application is used to provide integrated Merkle state data implementation, which is no longer divided into two-level structure of upper Merkle tree and bottom general KVDB, but is a whole MerkleDB, and the index and data in the DB are separated. The merkle tree is used as the index, and the contract state data is used as the data, so as to shorten the read-write process of the state data and reduce the overall write amplification and read amplification. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0015] Fig. 1 is a schematic diagram of deploying a smart contract in an embodiment;

[0016] Fig. 2 is a schematic diagram of calling a smart contract in an embodiment;

[0017] Fig. 3 is a schematic diagram of a block storage structure in an embodiment;

[0018] Fig. 4 is a schematic diagram of a block storage structure in an embodiment;

[0019] Fig. 5 is a schematic diagram of an MPT tree in an embodiment;

[0020] Fig. 6 is a schematic diagram of the modules involved in the transaction processing process and the relationship between CPU, memory and disk in an embodiment;

[0021] Fig. 7 is a schematic diagram of the modules involved in the transaction processing process and the relationship between CPU, memory and disk in an embodiment;

[0022] Fig. 8 is a schematic diagram of the logical relationship of the state database in an embodiment;

[0023] Fig. 9 is a flowchart of reading state data in an embodiment;

[0024] Fig. 10 is a schematic diagram of reading state data in combination with a tree structure in an embodiment;

[0025] Fig. 11 is a schematic diagram of reading state data in combination with a tree structure in an embodiment;

[0026] Fig. 12 is a schematic diagram of reading state data in combination with a tree structure in an embodiment;

[0027] FIG. 13 is a diagram illustrating reading state data in conjunction with a tree structure in an embodiment;

[0028] FIG. 14 is a diagram illustrating reading state data in conjunction with a tree structure in an embodiment;

[0029] FIG. 15 is a diagram in conjunction with a tree structure in an embodiment;

[0030] FIG. 16 is a diagram in conjunction with a tree structure in an embodiment.

[0031] FIG. 17 is a diagram in conjunction with a tree structure in an embodiment. DETAILED DESCRIPTION

[0032] In order to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only some of the embodiments of the specification, not all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the specification.

[0033] Blockchain is generally divided into three types: public chain (Public Blockchain), private chain (Private Blockchain) and consortium chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + consortium chain, consortium chain + public chain, and different combination forms. Among them, the highest degree of decentralization is the public chain. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the right to account for new blocks, etc. Moreover, each participant (represented by the participant's node on the blockchain) can freely join and exit the network and perform related operations. The private chain is the opposite, and the write permission of the network is controlled by an organization or institution, and the data reading permission is subject to the organization's regulations. In simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for use within a specific institution. Consortium chain is a blockchain between public chain and private chain, which can achieve "partial decentralization". Each node in the consortium chain usually has a corresponding entity organization or organization; participants join the network by authorization and form an interest-related alliance to jointly maintain the operation of the blockchain.

[0034] No matter it is public chain, private chain or consortium chain, in addition to supporting the transfer of native assets on the blockchain between accounts, such as transferring Bitcoin, Ethereum, etc., it can also provide the function of smart contract. The smart contract on the blockchain is a contract that can be triggered by a transaction to execute on the blockchain system. The smart contract can be defined in the form of code.

[0035] For example, Ethereum supports users to create and call some complex logic in the Ethereum network, which is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology. The core of Ethereum as a programmable blockchain is Ethereum Virtual Machine (EVM), and each Ethereum node can run EVM. EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it. The user publishing and calling a smart contract in Ethereum is actually running on EVM. In fact, the virtual machine directly runs the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The smart contract deployed on the blockchain can be in the form of bytecode.

[0036] For example, as shown in FIG. 1, after Bob sends a transaction containing information for creating a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. "0x6f8ae93…" in FIG. 1 represents the address of the contract, and the data field of the transaction can save the bytecode, and the to field of the transaction is an empty account. After the nodes reach an agreement through the consensus mechanism, the contract is successfully created, and subsequent users can call the contract.

[0037] After the contract is created, a contract account corresponding to the smart contract is generated on the blockchain, and has a specific address, and the contract code and account storage will be saved in the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract causes the generation of a virtual account containing the contract code and the account storage (Storage) on the blockchain.

[0038] As mentioned earlier, the data field of the transaction containing the creation of the smart contract can save the bytecode of the smart contract. Bytecode is composed of a series of bytes, and each byte can identify an operation. Based on development efficiency, readability and other considerations, developers can not directly write bytecode, but choose to write smart contract code in a high-level language. The smart contract code written in a high-level language is compiled by a compiler to generate bytecode, and then the bytecode can be deployed to the blockchain. Ethereum supports many high-level languages, such as Solidity, Serpent, LLL language, etc.

[0039] For example, in Solidity, a contract can declare multiple members, including state variables, functions, function modifiers, events, etc. State variables are values stored in the account storage of the smart contract, which are used to save the state of the contract.

[0040] The following is a simple smart contract written in Solidity language Code Example 1:

[0041] In addition, as shown in FIG. 2, still taking Ethereum as an example, after Bob sends a transaction containing the information of calling the smart contract to the Ethereum network, the EVM of node 1 can execute this transaction and generate the corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account that initiates the call to the smart contract, and the "0x6f8ae93..." in the to field represents the address of the called smart contract. The data field of the transaction saves the method and parameters of calling the smart contract. In addition, the value field can also be included to represent the value of the transaction in ethers. After calling the smart contract, the value of storedData may change. Subsequently, a client can view the current value of storedData through a certain blockchain node (for example, node 6 in FIG. 2).

[0042] The smart contract can be executed independently in a specified manner in each node of the blockchain network, and all execution records and data are saved on the blockchain, so when such a transaction is completed, the transaction voucher is saved on the blockchain and cannot be tampered with or lost.

[0043] As mentioned earlier, storedData in the above example is a state variable, which is stored in the account storage of the smart contract. In various blockchain networks that introduce smart contracts, for example, in Ethereum, an account usually includes two types:

[0044] Contract account: stores the executed smart contract code and the state value in the smart contract code, which can usually only be activated by calling an external account;

[0045] Externally owned account (Externally owned account): user's account, such as an Ethereum owner account.

[0046] The design of external accounts and contract accounts is actually a mapping from account address to account state. The state of an account usually includes fields such as Nonce, Balance, Storage root, CodeHash, etc. Nonce and Balance exist in both external accounts and contract accounts. CodeHash and Storage root attributes are generally only valid on contract accounts.

[0047] Nonce: Counter. For external accounts, this number can represent the number of transactions sent from the account address; for contract accounts, it can be the number of contracts created by the account.

[0048] Balance: The number of ethers owned by this address.

[0049] Storage root: A hash of the root node of an MPT tree that organizes the storage of the state variables of the contract account.

[0050] CodeHash: Hash value of the smart contract code. For contract accounts, this is the hash value of the smart contract; for external accounts, since no smart contract is included, the CodeHash field can generally be an empty string / 0 string.

[0051] MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (a more space-saving Trie tree, dictionary tree). The Merkle Tree algorithm calculates a Hash value for each transaction, then connects two by two to calculate the Hash again, all the way to the top layer of the Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is usually simply referred to as an MPT tree.

[0052] The data structure of Ethereum MPT tree includes a state trie. The state trie contains key and value pairs corresponding to the storage content of each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (e.g., a part of the hash value of the address of an Ethereum account or the address of the account, hereinafter referred to as the account address), which is distributed in the storage from the root node of the state trie to the leaf node. The "value" in the state trie is generated by encoding the information of the Ethereum account (using the Recursive-Length Prefix encoding (RLP) method). As mentioned earlier, for external accounts, the value includes nonce and balance; for contract accounts, the value includes nonce, balance, codehash and storageroot.

[0053] The contract account is used to store the state related to the smart contract. After the smart contract is deployed on the blockchain, a corresponding contract account is generated. This contract account generally has some states, which are defined by the state variables in the smart contract and generate new values when the smart contract is created and executed. The smart contract generally refers to a contract defined in the form of code in the blockchain environment that can automatically execute clauses. Once an event triggers the clauses in the contract (satisfies the execution condition), the code can automatically execute. In the blockchain, the relevant state of the contract is saved in the storage trie, and the hash value of the root node of the storage trie is stored in the storageroot, thereby locking all the states of the contract to the contract account through hash. The storage trie is also an MPT tree structure, which stores the key-value mapping of the state address to the state value. The address of a state is stored in the leaf node of the storage trie tree in the order of the part of the information from the root node to the leaf node, and the value of the state is stored in the leaf node.

[0054] In some blockchain data storage as shown in Fig. 3, the block header of each block includes several fields, such as previous block hash previous_Hash (Prev Hash in the figure), nonce Nonce (this nonce is not a random number in some blockchain systems, or the nonce in the block header is not enabled in some blockchain systems), timestamp Timestamp, block number Block Num, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, etc. Among them, the Prev Hash in the block header of the next block (such as block N+1) points to the previous block (such as block N), that is, the hash value of the previous block. In this way, the next block on the blockchain realizes the locking of the previous block through the block header. Among them, State_Root, Transaction_Root and Receipt_Root lock the state set, transaction set and receipt set respectively. The state set, transaction set and receipt set organize the state, transaction and receipt in the form of a tree respectively. Generally, it can be the same tree structure, or it can be different tree structures. For example, in Ethereum, the same MPT structure is used. In the tree structure of some state sets including smart contracts in Ethereum and the like, two levels of MPT structures are included: the leaf nodes of the upper level of MPT structure include two types of external accounts and contract accounts; each contract account in it includes the next level of MPT structure, and the leaf nodes of the next level include the values of the states in the contract account.

[0055] Figure 4 is a structural diagram of a blockchain data storage. Still taking Ethereum as an example, as shown in Figure 3, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, i.e., state_root points to a state tree state trie in the form of MPT. The root node of this MPT tree is generally an extension node (Extension Node) or a branch node (Branch Node), and state_root generally stores the hash value of this root node. The root node can be connected to one or more layers of Extension Node / Branch Node, and these multiple layers of tree nodes can be collectively referred to as Internal Node. A part of the value in each node from the root node of this MPT to the leaf node can be concatenated in order to form an account address as a key, and the account information stored in the leaf node is the value corresponding to this account address, so as to form a key-value pair. This key can also be a part of the hash value of the account address (the hash algorithm can be, for example, sha3 algorithm), and the value stored can be rlp(Account), i.e., the rlp encoding of the account information. The account information is a four-tuple of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, for external accounts, generally only nonce and balance are stored, and storageRoot and codeHash fields store empty strings / strings of all 0s by default. That is, external accounts do not store contracts, nor do they store state variables generated after contract execution. Contract accounts generally include Nonce, Balance, Storage root, CodeHash. Nonce is the transaction counter of the contract account; Balance is the account balance; Storage root corresponds to another MPT, and through Storage root, the information of the state related to the contract can be linked; CodeHash is the hash value of the contract code. Whether it is an external account or a contract account, the account information is generally located in a separate leaf node (Leaf Node). From the Extension Node / Branch Node of the root node to the Leaf Node of each account, there can be several branch nodes and extension nodes in between.

[0056] The state trie can be a tree in the form of MPT, typically a 16-ary tree, i.e. each level can have at most 16 child nodes. For an Extension Node, which is used to store common prefix, it typically has 1 child node, which can be a Branch Node. For a Branch Node, it can have at most 16 child nodes, which can include Extension Node and / or Leaf Node.

[0057] For a contract account in the state trie, its storage_Root points to another tree in the form of MPT, which stores data of state variables involved in the execution of the contract. The MPT form tree pointed by the storage_Root is a Storage Trie, i.e. the hash value of the root node of the Storage Trie. Typically, the Storage Trie also stores key-value pairs. The key indicates the address of a state variable, which can be the result of processing the location of the state variable declaration (value counted from 0) by certain rules, e.g. sha3(location of state variable declaration), or sha3(contract name + location of state variable declaration). The value is used to store the value of the state variable (e.g. RLP encoded value). The part of data stored on the path from the root node to the leaf node forms the key, and the value is stored in the leaf node. As mentioned before, the Storage trie can also be a tree in the form of MPT, typically a 16-ary tree, i.e. for a Branch Node, it can have at most 16 child nodes, which can include Extension Node and / or Leaf Node. For an Extension Node, it typically can have 1 child node, which can be a Branch Node or a Leaf Node.

[0058] For example, Leaf Node Account P in state Trie in Fig. 4, which is a contract account, its Storage Root locks all the states in the contract storage. These states are organized as an MPT tree, and the tree structure is the linked Storage trie of the Storage Root. For example, Leaf Node State Variable N in the linked Storage trie, for example, the value of storedData in the aforementioned contract code example, its key is sha3(the declaration position of storedData, i.e., the second line of the code), and its value is s (for brevity, the encoding format of the value is omitted here, for example, RLP, and the like will not be repeated). The value of the key is distributed in the root node to the leaf node (i.e., Leaf Node Variable N) of the storage trie.

[0059] For another example, Leaf Node Account C in state Trie in Fig. 4, which is an external account, its key is sha3(Address C), i.e., the hash value of the address of account C (the hash algorithm uses the sha3 algorithm, for example), and its stored value value can be (Account). As described above, since Account C is an external account, its account information is nonce and balance (codehash and storage root are omitted here, and the like below). For example, an external account with nonce 20 and balance 4550, Leaf Node State Variable C stores nonce = 20 and balance = 4550 in this leaf node. The address of Account C is the key, and the value is distributed in the root node to the leaf node (i.e., Leaf Node Variable C) of the state Trie.

[0060] These states, including the k-v of the external account and the k-v of the contract account, are finally stored in the database. The storage in the database does not directly store the states of these accounts, i.e., does not directly store the k-v of these accounts, but stores the k-v value of each tree node itself.

[0061] As shown in the example of FIG. 5, in the MPT structure of the previous level, for leaf node Al, the key of the leaf node is sequentially composed of a7 in the shared nibble of root node A8 (Extension Node) - slot 1 of intermediate node A7 (Branch Node) - 1335 of key-end in leaf node Al, i.e., a711335, in which Balance = 45.0 ETH and Nonce = nl are stored. For leaf node A2, the key of the leaf node is sequentially composed of a7 in the shared nibble of root node A8 (Extension Node) - slot 7 of intermediate node A7 (Branch Node) - d3 in the shared nibbles of node A6 (Extension Node) - slot 3 of intermediate node A5 (Branch Node) - 7 of key-end in leaf node A2, i.e., a77d337, in which Balance = 1.00 WEI and Nonce = n2 are stored. For leaf node A3, the key of the leaf node is sequentially composed of a7 in the shared nibble of root node A8 (Extension Node) - slot f of intermediate node A7 (Branch Node) - 9365 of key-end in leaf node A3, i.e., a7f9365, in which Balance = 1.1 ETH and Nonce = n3 are stored. For leaf node A4, the key of the leaf node is sequentially composed of a7 in the shared nibble of root node A8 (Extension Node) - slot 7 of intermediate node A7 (Branch Node) - d3 in the shared nibbles of node A6 (Extension Node) - slot 9 of intermediate node A5 (Branch Node) - 7 of key-end in leaf node A4, i.e., a77d397, in which Balance = 0.12 ETH, Nonce = n4, and CodeHash = cl are stored, and Storage root = sl. sl can be H(A10), i.e., the hash of root node A10 of the next level tree. Among them, the leaf nodes of Al, A2, and A3 store the information of external accounts, and the leaf node of A4 stores the information of a contract account. For a contract account, it contains the next level MPT, which constitutes a Storage Trie, used to store the state variables in the contract account.

[0062] As shown in the example of FIG. 5, in the next level of MPT structure, for leaf node A11, the key of the leaf node is composed of the slot 3 in the root node A10 (Branch Node) and the key-end 35b2e4 in the leaf node A11, i.e. 335b2e4, and the "Zhang San_A=20" is stored in the leaf node, for example, indicating that the share of the A type digital asset defined in the contract belonging to Zhang San is 20, i.e. the balance of the A type asset of Zhang San is 20. For leaf node A12, the key of the leaf node is composed of the slot 7 in the root node A10 (Branch Node) and the key-end c25988 in the leaf node A12, i.e. 7c25988, and the "Li Si_B=20" is stored in the leaf node, for example, indicating that the share of the B type digital asset defined in the contract belonging to Li Si is 50, i.e. the balance of the B type asset of Li Si is 50. For leaf node A15, the key of the leaf node is composed of the slot f in the root node A10 (Branch Node), the shared nibble a in the intermediate node A13 (Extension Node), the slot 6 in the intermediate node A14 (Branch Node) and the key-end be33 in the leaf node A15, i.e. fa6be33, and the "storedData=s" is stored in the leaf node. For leaf node A16, the key of the leaf node is composed of the slot f in the root node A10 (Branch Node), the shared nibble a in the intermediate node A13 (Extension Node), the slot 9 in the intermediate node A14 (Branch Node) and the key-end 9365 in the leaf node A16, i.e. fa99365, and the "Wang Wu_A=35" is stored in the leaf node, for example, indicating that the share of the A type digital asset defined in the contract belonging to Wang Wu is 35, i.e. the balance of the A type asset of Wang Wu is 35.

[0063] In the above node composition of MPT tree, the prefix is used to represent the type of tree node, for example, 0 represents an Extension Node containing even number of shared nibbles, 1 represents an Extension Node containing odd number of shared nibbles, 2 represents a Leaf Node containing even number of nibbles, and 3 represents a Leaf Node containing odd number of nibbles.

[0064] In the above node structure, the hash value of the overall content of the next tree node is filled into the corresponding position of the previous tree node. In the database, the key-value mapping of each tree node is actually stored, where the value includes the content stored in the tree node, and the corresponding key is the hash value of the overall content of the tree node. In this way, the actual tree node k-v stored in the database is as follows:

[0065] Table 1, actual tree node k-v stored in the database

[0066] In the above table 1, H() represents hash calculation. In this way, the hash value of the next tree node is anchored in the previous tree node. Through such layer-by-layer hash, the root hash of the entire state trie tree is obtained, and the root hash is locked into the state root field of the block header.

[0067] In some blockchain systems, the code of the blockchain platform can include a P2P (Peer to Peer) module, a consensus module, an execution module and a storage module. P2P is a way of organizing computer networks, unlike the common web network, P2P is decentralized and decentralized. The P2P module can complete the distributed propagation of data. For blockchain nodes, through the P2P module, receipts can be propagated and received in a peer-to-peer manner. Different participants can establish a distributed blockchain network through the deployed nodes. The ledger constructed by the chain block structure is saved on each node (or most nodes, such as consensus nodes) in the distributed blockchain network, which is also called a decentralized (or called multi-centralized) distributed ledger. Such a blockchain system needs to solve the consistency and correctness of the ledger data on each node of the decentralized (or multi-centralized) distributed ledger. Each node runs the same blockchain platform program, and under certain fault tolerance requirements, through the consensus module, all loyal nodes can be ensured to have the same transaction, so that the execution results of all loyal nodes on the same transaction are consistent, and the transaction and execution result are packaged to generate a block. The current mainstream consensus mechanism includes: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc. The consensus module can also generate the timestamp of the block corresponding to the current transaction set during the consensus process. The execution module can execute transactions, including ordinary transfer transactions and transactions involving contracts, which can be before or after the consensus module completes the consensus. For transactions involving contracts, the execution module can introduce a virtual machine to execute the code of the smart contract, such as Ethereum Virtual Machine (EVM), so as to shield the differences in hardware configuration and software environment of each node through EVM, so as to ensure that the process and result of executing the smart contract on each node are the same, and through the sandbox environment, the execution of the smart contract avoids affecting the blockchain platform code, other programs or operating system on the host. For one case of a consortium chain, the transaction content and transaction order in a transaction set can be determined by the consensus module between nodes, and then a deterministic transaction set of the consensus result is output to the execution module. The execution module generates an execution result by executing ordinary transfer transactions / transactions involving contracts, and sends it to the storage module. The storage module can be responsible for storing the execution result in the persistent storage medium of the node local.

[0068] As shown in one of the blockchain nodes in FIG. 6, it physically includes CPU, memory and disk, etc. The blockchain platform code executed by this blockchain node can include P2P module, consensus module, execution module and storage module. The functions of P2P module, consensus module and execution module generally need the participation of CPU and memory. The storage module can include tree construction module, block header generation module, WAL (Write Ahead Log) module and state database module. Among them, the tree construction module is used to construct a tree (such as MPT tree) based on the state k-v input by the execution module, such as the state trie and storage trie described above, so as to obtain the k-v of the tree node, which generally needs the participation of CPU and memory. The block header generation module is used to generate the block header according to the root node of the tree constructed by the tree construction module and other data (such as the hash of the previous block, timestamp, block number, etc.), which generally needs the participation of CPU and memory. The WAL module is used to persistently store the leaf node k-v of the tree generated by the tree construction module before the leaf node k-v is written into the state database module, so as to prevent data loss due to power failure, etc. during the process of writing the leaf node k-v of the tree generated by the tree construction module into the state database module, and to recover the data when such a situation occurs, which generally needs the participation of CPU, memory and disk. The state database module is used to store the tree node k-v constructed by the tree construction module, such as in Table 1, on the persistent storage device; since the tree node data will eventually be written to the persistent storage medium (such as the disk in the figure), the state database module generally needs the participation of disk in addition to CPU and memory.

[0069] From the storage structure, the above Merkle tree structure, such as the MPT of Ethereum, the SMT (Sparse Merkle Tree) of Libra (similar to MPT), can be located in the tree construction module in the form of the corresponding relationship in the above table 1 and stored in the memory. Among them, the upper Merkle tree is a prefix tree (dictionary tree), which can realize the organization of data and obtain a unique Merkle root for the organized data. The leaf node can save the state Value, and the root node to the intermediate node to the leaf node realizes the lexicographic index of the state key. These tree nodes are encoded as Key according to certain rules, and their contents are encoded as Value, and finally stored in the lower database. The database mostly adopts the NoSQL Key-Value DB (DataBase; Key-Value DB is also referred to as KVDB) of the LSM (Log-Structured Merge-Tree) structure, which is located in the state database module and finally saved in the disk. Specifically, the database is, for example, the levelDB of Ethereum and the RocksDB of Libra. Both of these two KVDBs are based on the LSM storage engine.

[0070] The LSM storage engine is a layered, ordered and disk-oriented storage engine, which draws on the characteristics of Log continuous appending (rather than modification), and the core idea is to fully utilize the characteristics that the sequential writing of disk batch is much more efficient than random writing, and abandon part of the reading efficiency to maximize the writing operation efficiency. Generally speaking, the use mode that maximizes the characteristics of the disk is to read or write a fixed size of data at a time, and to reduce random addressing operations as much as possible. The design idea of LSM is based on the characteristics of the disk, and assumes that the memory is sufficient, and does not need to write data to the disk every time there is data update, but first resides the latest data in the memory, and when the data volume accumulates to be enough, the data in the memory is merged with the data in the disk in the way of merge sorting, and is appended to the disk in batches.

[0071] The storage process of the state data module is further described below with reference to FIG. 7. After the tree node k-v data generated by the tree construction module is sent to the storage module, the k-v data is first written in the WAL in an append-only manner and stored on the disk. Then, the tree node k-v data is transmitted to the state database module. As described above, writing in the WAL first can prevent data loss in the process of writing the tree node k-v data generated by the tree construction module into the state database module due to power failure or the like, and restore the data when such a situation occurs. After receiving the tree node k-v data, the state database module first stores the data in the memory, which can be a MemTable in the memory. The MemTable can provide concurrent read and write operations. There can be multiple MemTables in the memory. When the amount of data in the MemTable reaches a certain threshold, for example, 256 MB, the data in the MemTable can be flushed to the disk. In order to avoid the operation of writing the MemTable from causing congestion to the flushing, the MemTable is converted into an Immutable Memtable, that is, the Immutable Memtable is set to read-only, and a new MemTable is generated to receive newly transmitted tree node k-v data. The new MemTable can provide concurrent read and write operations (e.g., the New MemTable in the figure). The storage engine writes the data in the Immutable MemTable to the disk.

[0072] In the disk, the KVDB stores a plurality of SST (Sorted String Table, SSTable) files in multiple levels. The SST is derived from a paper on Google Bigtable. BigTable is a distributed data storage system designed by Google to handle massive amounts of data in a non-relational database. The SST can be used for storage of internal data files of Bigtable and is a high-efficiency key-value type file storage format. The content stored in the persistent storage medium can also be referred to as a file.

[0073] The SSTs can include multiple levels, for example, 3 levels, 4 levels, 5 levels, 6 levels, 7 levels or more. In FIG. 7, the case of 3 levels is shown, i.e., level 0, level 1, level 2. Generally, the total capacity of SSTs of a previous level is significantly less than the next level. As an example, the total capacity of SSTs of level 0 is 1 GB, the total capacity of SSTs of level 1 is 10 GB, and the total capacity of SSTs of level 2 is 100 GB. Assume the capacity of a MemTable is 256 MB. The tree nodes k-v corresponding to one or more blocks can be written into the tree building module, and then into the MemTable. After the tree k-v corresponding to one or more blocks is written into the MemTable, the space occupancy of the MemTable can reach 256 MB. Then, this MemTable is converted into an Immutable MemTable, and the data in the Immutable MemTable can be flushed to the disk. Specifically, the data in the MemTable can be flushed to the SSTs of level 0 on the disk. On the other hand, as described above, a new MemTable is generated to receive new incoming tree nodes k-v, and to provide concurrent read and write operations.

[0074] As described above, in the disk storage of each level, i.e., in the disk storage of each level, a plurality of SST files can be included. The kv stored in the SSTs of level 1 and lower levels are generally stored in order of keys, and the key values in different SSTs of the same level also have a size relationship and are not repeated. For example, level 1 includes 3 SSTs, the left SST 11 includes 1000 k-v, for example, <k1-v1> <k2-v2> <k3-v3> ... <k1000-v1000>and arranged in ascending order of k, for example, kl = 10b43c032a46, k2 = 1118d46f41el, k3 = 1b44942a3d6e,..., k1000 = 2018df9326a7. It can be seen that kl < k2 < k3 <... < k1000 in the left SST 11, but kl, k2, k3,... k1000 are not necessarily consecutive. Similarly, the middle SST 12 includes, for example, 800 k-v, <k1-v1> <k2-v2> <k3-v3> ... <k800-v800>and arranged in order of increasing k, e.g., k1=21a514c0a7e1, k2=21b46b994214, k3=21b489571b6d,..., k800=284a5df3fca7. It can be seen that the middle SST 12 contains k1 < k2 < k3 <... < k800, but, again, the k1, k2, k3,... k800 are not necessarily consecutive. Similarly, the right SST 13 contains, for example, 1100 k-v, <k1-v1> <k2-v2> <k3-v3> ... <k1100-v1100>wherein k is arranged in ascending order, for example, kl=3a5e55ac3fe1, k2=3a5e55ac3fe2, k3=3afb8ed31526,..., k1100=400a51ef1405. It can be seen that the k contained in the right SST 13 is kl<k2<k3<...<k1100, but similarly, kl, k2, k3,... k1100 are not necessarily consecutive. Moreover, overall, the minimum value of k of the left SST 11 < the maximum value of k of the left SST 11 < the minimum value of k of the middle SST 12 < the maximum value of k of the middle SST 12 < the minimum value of k of the right SST 13 < the maximum value of k of the right SST 13. Each of the Level 2, Level 3,... also has a similar relationship, that is, each SST in each layer has a size order relationship in the value of k, and the multiple SSTs in each layer have a size relationship in the range of k.

[0075] The k-v in one SST in Level 0 can be sorted according to the size relationship of k, and the k between multiple SSTs can have no size relationship in the range. This is because the MemTable generally stores multiple k-v corresponding to each block in the order from old to new (or the block number from small to large, because the block number of the new block is larger, and the block number of the old block is smaller), and these k are hash values of tree nodes, and the change of the content of the tree node will probably cause the hash value (i.e. k value) of the tree node to be very different. The k-v in one SST in Level 0 can be sorted according to the size of k, and such sorting in memory is efficient and feasible; of course, it is also possible not to sort according to the size of k, which is not excluded here. Taking sorting as an example, when the capacity of the MemTable reaches 256MB, it may store multiple k-v corresponding to multiple blocks. This MemTable is converted into an Immutable MemTable. The k-v in the Immutable MemTable can be sorted according to the order of k and written into the left SST of Level 0. There may be multiple different Immutable MemTables written into the same SST, and the left SST01 of Level 0 is filled, and then SST02 on the right of Level 0 can be written in a similar manner. Although the k-v of a single Immutable MemTable written into a certain SST in Level 0 is sorted, the k-v set written by different Immutable MemTables in the same SST in Level 0 generally has no size sorting, and the k-v between different SSTs (such as left and right SSTs) also has no size sorting, that is, the range of k in the left and right SSTs in Level 0 may have intersection / overlap. Similarly, since the k-v written in one SST in Level 0 can be written by multiple MemTables after storage, and the range of k-v in the writing process after multiple MemTables are stored will generally overlap, therefore, the multiple k-v stored in each SST in Level 0 generally also has no specific order, and the SSTs in Level 0 generally also have no specific range order. Of course, if a single SST in Level 0 is written by an Immutable MemTable, and the k-v is sorted when the Immutable MemTable is written into the SST, then the k-v stored in the SST is also sorted according to k.

[0076] Further, when the storage capacity of Level 0 reaches or approaches the upper limit, data in Level 0 is written into Level 1 through a process called "compaction". In this compaction process, k-v in each SST in Level 0 and k-v in some or all SSTs in Level 1 are first transferred into memory, and after sorting in memory, written into SSTs in Level 1. Since sorting is performed in the compaction process, SSTs in Level 1 have a size order relationship in the value of k, and SSTs in Level 1 have a size relationship in the range of k. In other words, in each SST in Level 1, k-v is sorted in ascending order of k, and SSTs in Level 1 are sorted in ascending order of the range of k. <k1-v1> <k2-v2> <k3-v3> ... <kn-vn>The k values of the SSTs are arranged in ascending order, and k1 < k2 < k3 <... < kn, but the k values are not necessarily continuous. In general, for two adjacent SSTs, the minimum value of k of the left SST < the maximum value of k of the left SST < the minimum value of k of the right SST < the maximum value of k of the right SST. As shown in FIG. 8.

[0077] In the compaction process, the k-v of the SSTs in Level 0 and the k-v of some SSTs in Level 1, which have range overlap with the k-v in Level 0, can be transferred into the memory to complete sorting. Specifically, for example, in the above example, Level 1 includes three SSTs, SST11 has a key range of 10b43c032a46-2018df9326a7, SST12 has a key range of 21a514c0a7e1-284a5df3fca7, and SST13 has a key range of 3a5e55ac3fe1-400a51ef1405. For example, the key range of the SSTs in Level 0 is 18c49a405e32-24d35f39ab56. It can be seen that SST11 and SST12 in Level 1 have range overlap with the key range in Level 0. Thus, in the compaction process, the k-v of the SSTs in Level 0 and the k-v of SST11 and SST12 in Level 1 can be transferred into the memory to complete sorting, and then the sorted results are written into the SSTs in Level 1.

[0078] Similarly, when the storage capacity of Level 1 reaches the upper limit, the data in Level 1 is written into Level 2 through the compaction process. Similarly, in this compaction process, the k-v of the SSTs in Level 1 and the k-v of some or all SSTs in Level 2 can be first transferred into the memory, and then written into the SSTs in Level 2 after sorting in the memory. Similarly, if there is Level 3 below Level 2, when the storage capacity of Level 2 reaches the upper limit, the data in Level 2 is written into Level 3 through the compaction process. Similarly, in this compaction process, the k-v of the SSTs in Level 2 and the k-v of some or all SSTs in Level 3 can be first transferred into the memory, and then written into the SSTs in Level 3 after sorting in the memory. The same applies.

[0079] In this way, overall, the data stored in the SST of the upper layer is newer than the lower layer. The newest data is stored in the memory, the second newest data is stored in Level 0, and the oldest data is stored in the SST in the bottommost level. In addition, garbage collection (Garbage Collection) can also be performed by compaction, such as deleting data marked for deletion.

[0080] The sorted kv can be efficiently searched, for example, by binary search for efficient search. Binary search is also called dichotomic search, and the algorithm is as follows: define left as the leftmost element position of the ordered table, right as the rightmost element position of the ordered table, and define mid = (left + right) / 2, that is, the middle position of the ordered table; compare the value to be searched with the value at the position of mid; since the list is ordered, if the value to be searched is smaller than mid, only the first half of the table needs to be searched, otherwise only the second half of the table needs to be searched (if the two values are equal after the first comparison, the current value is returned directly). In this way, the value to be searched is found or it is determined that the value to be searched is not in the list (i.e., the search fails).

[0081] Such a storage engine has read amplification and write amplification problems when reading and writing data, which are described in detail below.

[0082] The blockchain system using the above storage engine may need to read some existing state during the execution of the transaction execution module. For example, for a normal transfer transaction, external account A transfers a certain amount (for example, f) of assets to external account B, and then the account balance is increased or decreased. Assuming that before the transaction is executed, the balance of account A is a, and the balance of account B is b, then the execution of the transaction is to set the balance of account A to the value of (a-f), and the balance of account B to the value of (b+f). Then this transaction needs to read the values of the two state variables a and b when it is executed. For example, a transaction that calls a contract, external account C initiates a call to contract D, then C initiates a transaction pointing to the address of contract account D, and indicates the called function and input parameters in the data field of the transaction. Assuming that the logic of the called function in contract D includes judging the value of a global state d in the contract, and assuming that the value of d is a boolean type, the judgment logic includes executing branch 1 if it is true, and executing branch 2 if it is false. Then this transaction needs to read the value of the state d when it is executed.

[0083] In the transaction execution process, whether the values of the state variables a and b are read or the value of the state variable d is read, the execution module can first search for the value of the state variable in the memory of the execution module. If the value does not exist, a read instruction is sent to the storage module. The read instruction can include the address of the state to be read, that is, the key value of the state. After the storage module receives the read instruction, the root node of the state tree is found in the tree module, and the state key value to be searched is matched with the shared nibble (s) field (for Extension Node) or slot (for Branch Node) of the root node from the beginning. After the matching, the hash of the next layer tree node (which can be an Internal Node or a Leaf Node, and an Internal Node is taken as an example for illustration) is read from the matching position, and then the hash is searched in the memory of the tree module. If the hash is still not found, it is searched in the memory of the state database module. If the hash is still not found, it needs to be searched in the file of the state database module. Specifically, the SST in Level 0 can be searched first, and if the hash is still not found, the SST in Level 1 can be searched, and the hash can be searched in the SST in the lower level according to the same rule until the next Internal Node pointed by the hash value is found. After the Internal Node is resolved, the remaining part of the state address key value to be read is matched from the front. If the matching is successful, the hash value is read from the matching position, and then the next tree node pointed by the hash value is jumped to. Thus, the Internal Node is continuously resolved and the remaining part of the state address key value to be read is matched from the front, and the hash value at the matching position is used as the basis for searching the next node or leaf node. Until the Leaf node is matched, the value of the state is read from the Leaf node. In this process, the k-v of each level of tree node may not exist in the memory of the tree module, but in the state database module. Therefore, it may be necessary to read from the state database module to the memory. The key can be searched in the MemTable or Immutable MemTable of the state database module first. If the key does not exist, the SST files on the disk need to be further searched. For the Internal Node and Leaf node existing on the disk, they need to be loaded into the memory and decoded (deserialized) to obtain the content therein. Specifically, for example, the sst file in level 0 is searched one by one. If each SST in Level 0 is sorted, a binary search can be performed in each SST according to the hash value of the Internal Node / Leaf Node. After the search, the v is loaded into the memory and decoded and matched.If not found in Level 0 SST, further binary search in Level 1 SST based on the hash value of the intermediate / leaf node, and binary search in Level 2 SST if not found. If found, load the corresponding v of k into memory and decode. Repeat until the leaf node is found and the value of v is read. Since the SSTs in each level are sorted, binary search can be done in each level.

[0084] From the above process of reading a state k-v, it can be seen that the reading process needs to do binary search in multiple SSTs in different levels based on the hash value of the tree node, which may require reading a large number of files in multiple SSTs and loading them into memory, which brings the problem of read amplification. Assuming that the database includes Level 0, Level 1, Level 2,..., Level M-1, a total of M layers, then in the worst case, reading the data of a state requires at least M times of access to the disk (more than M because in the worst case, the N SSTs of Level 0 layer may need to be searched more than once and less than or equal to N times).

[0085] In addition, the tree construction module can also need to do a binary search from Level 0, Level 1, Level 2, etc. if it lacks the k-v of a certain tree node in the process of constructing the k-v of all tree nodes on the path to the root node according to the state k-v. The principle is similar to the above process. In the above transaction example, after the transaction is executed, the value of the execution result (a-f) / the value of (b+f) / the value of the contract state d needs to be written into the state database. For the above values to be written into the database, the execution module calls the storage interface of the storage module to output the key-value value of the state to the storage module. The tree construction module in the storage module generates the tree node k-v of the tree root to the intermediate node and the leaf node of the tree structure according to the state k-v, and also writes these tree node k-v to the WAL module, and then writes this series of tree node k-v to the MemTable of the state database module and marks it as dirty data. Dirty data generally refers to data that has been written into the MemTable but has not yet been written into the persistent storage (such as SSTable). Dirty data can be written to disk in the flush process described above. The state database module further writes some k-v including the tree node k-v to the SST file on the disk. Once the MemTable is persisted to the SSTable, the data in it is no longer dirty data, i.e. becomes "clean" data. As can be seen, the above process of persisting a state k-v is relatively complex, consumes a lot of computing and memory resources, and causes the write amplification problem.

[0086] The complexity of the above read process and write process and the read amplification and write amplification problems pose challenges to the high performance requirements and large-scale applications of blockchains.

[0087] The present application provides a method embodiment for reading blockchain state data. The method embodiment can be applied to a storage module of a blockchain node. The storage module has a tree structure of the world state constructed in the memory. The leaf node of the tree structure can include the content of the state data or the location index of the state data in the data file of the persistent storage medium.

[0088] In one example, the tree structure as a whole can be as shown in FIG. 10, which is also similar to FIG. 5 to some extent. In particular, if there is state data in the leaf node in the memory, the location index of the state data in the data file can be used as shown in FIG. 5, for example, the leaf node A11 in FIG. 5 has state data in the memory, i.e. Zhang San_A = 20. If there is no state data in the leaf node in the memory, the location index of the state data in the data file can be used.

[0089] In this application, the actual data and the index are separated, which helps to improve the flexibility and performance of the system. The basic concepts involved here include data files and index files. Among them, the data file is a file that stores the actual content; the index file is a file that stores the index pointing to the location of the data file. The working principle is that the data content is written into the data file, and the location of the data in the file (such as the file name, offset, and length) is recorded; then, an entry is created in the index file, which contains: the key (a unique identifier for searching) points to the reference of the data file (file name, offset, etc.). In this way, during data retrieval, the data location can be quickly located through the index file, and then the actual content can be read from the data file according to the location information. The advantages of such a way are: ① flexibility, data and index can be independently managed and optimized; ② performance, index is usually small and can be loaded into memory to speed up query; ③ space efficiency: avoid storing a large amount of duplicate data in the index; ④ update efficiency: when modifying data, only the location information in the index needs to be updated.

[0090] For example, in Figure 10, the location is used to represent this location index. Still taking the A11 node as an example, if there is no state data in the memory, the location field included therein can be used to store the location index of the state data in the data file, which is, for example, <2, 750, 210>. This <2, 750, 210> can indicate that the state data is located in "file 2" in the data file, the starting position is "750KB" of "file 2", and the length is 210KB. As shown in the data file at the lower left corner of Figure 10, assuming that the size of each file is 1024KB, the logical address range of the index is 0KB-1023KB. In this way, the state data of A11 actually occupies the range from 750KB to 959KB in file 2.

[0091] As shown in Figure 9, this embodiment includes:

[0092] S910: The storage module of the blockchain node receives an instruction to find a state key, and finds the leaf node corresponding to the state key on the tree structure in the memory.

[0093] As shown in the foregoing Figure 6, the execution module can generate an execution result by executing a normal transfer transaction / transaction involving a contract, and send it to the storage module. Specifically, for example, the value of a state variable needs to be read during the execution of the contract. The execution module can first find whether the value of the state variable exists in the memory of the execution module, and if not, send a read instruction to the storage module. The read instruction can include the address of the state to be read, i.e., the key value of the state.

[0094] The storage module includes a tree construction module. The tree construction module constructs a tree structure of the world state in the memory. If it is a cold start of the blockchain node, i.e., there is no tree structure of the world state in the memory, each tree node of the tree structure can be loaded from the disk and organized into a tree in the memory, and this process also involves loading the leaf nodes in the tree structure. Here, an example is given for the case where there is an incomplete tree structure in the tree construction module, and the cold start loading case is similar. Since the capacity of the memory is generally limited, the LRU (Least Recently Used, a commonly used page replacement algorithm that selects the least recently used page to be discarded) algorithm is generally used to discard the tree nodes that have not been accessed for a long time from the memory. In this way, each leaf node on the tree structure constructed by the tree construction module in the memory has a certain possibility of being discarded. For the leaf nodes of the world state tree, some may be in the memory and some may not be in the memory. In addition, for the content in the tree node, such as the state data in the leaf node, a similar discard mechanism can also be used, or the memory can also not maintain the state data.

[0095] For the state key to be found, if the memory of the tree construction module has the leaf node corresponding to the state key, it can be found directly in the memory. This case can be referred to in FIG. 5, the key corresponding to the leaf node is found directly in the memory, so that the value is read from it. Further, the state data can be read from the value. If the memory of the tree construction module does not have the leaf node corresponding to the state key, or although it has the leaf node, but there is no state data to be found in it, further search is needed in the state database module. For the case of using the LSM tree for the state database, as described above, the search can be first in the MemTable, and if not found, the search can be in the file in the disk.

[0096] S920: Obtain the position index contained in the leaf node corresponding to the tree node key, the position index pointing to the position in the data file in the persistent storage medium.

[0097] If the leaf node to be searched does not exist in the memory of the tree module, it needs to be further searched and loaded from the state database module. As mentioned above, if the state data does not exist in the memory, the location field included in the state data can be used, and the content of the location field is, for example, <2, 750, 210> in the location field of the leaf node A11 in FIG. 10. The <2, 750, 210> is a position index, which indicates that the state data is located in the file 2 of the data file, the starting position is the 750 KB, and the length is 210 KB. As shown in the data file in the lower left corner of FIG. 10, assuming that the size of each file is 1024 MB, the logical address range of the index is 0 KB-1023 KB. In this way, the state data of A11 actually occupies the range from the 750 KB to the 959 KB in the file 2.

[0098] If the leaf node to be searched does not exist in the memory of the tree module, it needs to be further searched and loaded from the state database module. As mentioned above, if the state data does not exist in the memory, the location field included in the state data can be used, and the content of the location field is, for example, <2, 750, 210> in the location field of the leaf node A11 in FIG. 10. The <2, 750, 210> is a position index, which indicates that the state data is located in the file 2 of the data file, the starting position is the 750 KB, and the length is 210 KB. As shown in the data file in the lower left corner of FIG. 10, assuming that the size of each file is 1024 MB, the logical address range of the index is 0 KB-1023 KB. In this way, the state data of A11 actually occupies the range from the 750 KB to the 959 KB in the file 2.

[0099] Table 2, k-v of the tree node actually stored in the database

[0100] In Table 2 above, similar to Table 1, H() represents the hash calculation. In this way, the hash value of the next tree node is anchored in the previous tree node. Through such layer-by-layer hashing, the root hash of the entire state trie tree is obtained, and the root hash is locked into the state root field of the block header. Assuming that the k-v pairs in the table are stored in the underlying state database module, saved on the disk, and adopt a similar LSM structure. In this way, similar to the foregoing, after the storage module receives a read instruction, the root node of the state tree node can be found in the tree construction module, and the state key value to be searched is matched with the shared nibble(s) field (for Extension Node) or slot (for Branch Node) of the root node from the beginning, and then the hash of the next layer tree node is read from the matching position, and then the hash is preferentially searched in the memory of the tree construction module. If it is not found, it is searched in the memory of the state database module, and if it is still not found, it needs to be searched in the file of the state database module. Specifically, the SST in Level 0 can be preferentially searched, and if it is still not found, it can be searched in the SST of Level 1, and so on, until the next Internal Node pointed to by the hash value is found; after the Internal Node is resolved, the remaining part of the state address key value to be read is matched from the front, and if the matching is successful, the hash value is read from the matching position, and then the next tree node pointed to by the hash value is jumped to. Thus, the Internal Node is continuously resolved and the remaining part of the state address key value to be read is matched from the front, and the hash value at the matching position is used as the basis for searching the next node or leaf node, until the Leaf node is matched, and thus the value of the state is read from the Leaf node. In this process, the k-v of each level of tree node may not exist in the memory of the tree construction module, but in the state database module. Therefore, it may need to be read from the state database module. The key can be first searched in the MemTable or Immutable MemTable of the state database module, and if it does not exist, it needs to be further searched in the SST file on the disk. For the Internal Node and Leaf node existing on the disk, it needs to be loaded into the memory and decoded (deserialized) to obtain the content therein. Specifically, for example, the sst file in level 0 is first searched, and if each SST in Level 0 is sorted, a binary search can be performed in each SST according to the hash value of the intermediate node / leaf node, and after the search is found, the v is loaded into the memory and decoded and matched.If not found in Level 0 SST, further binary search in Level 1 according to the hash value of the intermediate node / leaf node, if not found, binary search in Level 2. If found, load the corresponding v of k into memory and decode. In this way, until the leaf node of the tree structure is matched and the value of the value is read. The above search in Level 1, Level 2 and lower Level, because the overall SST in these levels is sorted, so generally one binary search can be done in this level.

[0101] In this way, the tree node k-v of the found leaf node can be loaded into memory. For example, A11, load the contents of the leaf node value prefix:2, Key-end:35b2e4, location: (2, 750, 210) into memory. <2, 750, 210> in it is the location index of the value content in the file.

[0102] S930: Load the value value of the data file position in the persistent storage medium pointed by the location index into memory and read the state data therein.

[0103] Still taking A11 as an example, the location index <2, 750, 210> points to the position in the data file in the persistent storage medium. In this way, the value value of the data file position in the persistent storage medium pointed by the location index <2, 750, 210> is loaded into memory and the state data therein is read, that is, the data from the start position 750KB, length 210KB in file 2 in the data file is loaded into memory, so as to read the state data therein, that is, "Zhang San_A=20".

[0104] Through the location index, the position in the data file can be directly located, so that the data file therein can be directly loaded and the state data can be read therefrom.

[0105] For the case where the memory of the tree module does not have the state data although it has the leaf node to be searched, it can be directly read in the corresponding data file according to the location in the leaf node in the memory. In this way, the k-v of the leaf node is stored in the SST file of the persistent storage, and the process of multiple binary searches in the SST is avoided.

[0106] For the case that the tree module does not have the leaf node to be searched in the memory, and needs to search and load the leaf node from the state database module, in fact, a certain amount of content needs to be read from the disk to the memory for searching. In the implementation mode corresponding to Table 1, the k-v of the tree node is stored in the disk, and the value of the leaf node includes the state data, for example, H(11) in Table 1 corresponds to the content Zhangsan_A=20, H(12) corresponds to the content Lisi_B=20, H(15) corresponds to the content storedData=s, and H(16) corresponds to the content Wangwu_A=20. Generally, the state data occupies a large space, which accounts for more than 90% of the total space of a k-v. In the implementation mode corresponding to Table 2, the index and data are separated, and the index stores the location of the data file where the state data is located instead of the state data itself, for example, H(11) in Table 2 corresponds to the content location(2, 750, 210), H(12) corresponds to the content (3, 350, 210), H(15) corresponds to the content (5, 760, 140), and H(16) corresponds to the content location:(5, 170, 210). The actual state is stored in the corresponding location in the data file, as shown in the data file and state data in FIG. 10. In the process of searching for the leaf node, only the index file can be searched, so that more index files can be loaded into the memory per unit of space for searching. The searching efficiency of the memory is obviously higher than that of the disk, and generally, the searched content is loaded into the memory for searching. In the implementation mode of Table 2, more indexes can be loaded into the memory per unit of memory space, and the leaf node can be found faster than in the implementation mode of Table 1. In the implementation mode of Table 1, for example, if a batch of k-v is read into the memory and the leaf node is not found, another batch of k-v needs to be read into the memory for searching again. Since the state content occupies a large space, the number of k-v per unit of memory space is relatively small, so the number of times of reading from the disk is generally more frequent, and the reading speed of the disk is much slower than that of the memory. Therefore, the searching efficiency of the implementation mode of Table 1 is low.

[0107] The above describes the specific process of the embodiment of the method of Figure 9 in combination with Figure 10. In Figure 10, the structure of the two-level MPT tree is still used, and the structure of the intermediate nodes in each level of the tree includes two types of tree nodes, Extension Node and Branch Node. In a variant, the tree node such as Branch Node can be used as the intermediate node and the root node of the tree, as shown in Figure 11. In this way, from the root node of the tree to the leaf node through the intermediate node, the order combination of the slot positions in the branch nodes passed through in the middle can constitute part of the content in the state key. The hash value of the next level node can be stored in the slot position of the previous level node. In Figure 11, the structure of the two-level tree is still used, and the leaf nodes in the upper level tree can store the account state (including the state of the external account and the contract account), and the leaf nodes in the lower level tree store the state of the contract. In the leaf nodes storing the state of the external account, the state of the contract account or the state of the contract, a position index can be used. For example, the leaf nodes of the upper level tree include the account state as follows: H(M1), H(M2), H(M3), and H(M4) in the following table:

[0108] Table 3: Tree nodes k-v actually stored in the database

[0109] Through the position index, the position in the data file can be directly located, so that the data file therein can be directly loaded, and the state data can be read therefrom. Further, the leaf nodes of the lower level tree include the contract state as follows: H(Z1), H(Z2), H(Z3), and H(Z4) in the following table.

[0110] The data file is shown in Figure 11, for example, and the content in the data file is as follows, for example:

[0111] M1: Nonce: n1, balance: 45.0 ETH

[0112] M2: Nonce: n2, balance: 1.00 WEI

[0113] M3: Nonce: n3, balance: 1.1 ETH

[0114] M4: Nonce: n1, balance: 0.12 ETH, codehash: c1, storage: s1

[0115] Z1: Zhang San_A = 20

[0116] Z2: Li Si_B = 50

[0117] Z3: Wang Wu_A = 35

[0118] Z4: storedData = s

[0119] No matter the upper level tree or the lower level tree, the location in the leaf node can quickly locate the position in the data file. In this way, the k-v of the leaf node stored in the SST file of the persistent storage is avoided, and the process of multiple binary search in the SST according to the key (hash value of the content) of the leaf node is avoided. In the example of FIG. 11, the blockchain state data is read in the manner of FIG. 9, and the position in the data file can be directly located according to the location index, so the content located in the corresponding position in the data file can be directly loaded into the memory, thereby avoiding the read amplification problem caused by reading a large number of files in multiple SSTs and loading them into the memory. As the leaf node A4 of the upper level tree, it can be stored in the manner shown in FIG. 10, or in the manner shown in FIG. 11.

[0120] The external account, the contract account, and the contract state can each have a key in the form of a fixed-length string. For example, the key of the external account and the contract account can be an account address, and the key of the contract state can be a string of the same length. For another example, the key of the external account and the contract account can be a hash value of an account address, e.g., a hash value obtained by applying a hash algorithm such as the sha3 algorithm, and the key of the contract state can be sha3(contract name + position of state variable declaration). The external account, the contract account, and the contract state are collectively referred to as state keys, which are strings of the same length and format. For example, the length of the state key can be 4 bytes, i.e., 32 bits. In this case, assuming that each of the root node (B0), the intermediate nodes (..., C5,..., C13,..., C5D1,..., C5D9,..., C5D14,..., C13D2,..., C13D10,...), is a 16-ary tree, on the one hand, each slot of the intermediate node (e.g., 0, 1, 2,..., d, e, f, which are 16 slots in B0) can be filled with a hash value of a next tree node, and on the other hand, the position of the slot of the root / intermediate node can represent 4 bits of the key. 4 bits constitute a nibble, so that 8 layers of the root node and the intermediate node can be accommodated in 32 bits, i.e., 8 bytes, which is the total length of the state key. The 32 bits of the state key can be stored in a nibble at each level from the top-level intermediate node to the bottom-level intermediate node and the leaf node, from top to bottom. In this case, for the fixed expansion of the intermediate node, the last 4 bits of the key can be stored in the leaf node. In the case of the fixed expansion of the intermediate node, there are 8 layers from C* to C13D* to M* in the bottom layer in FIG. 11. In another case, the prefix, the infix, and / or the suffix can be used, so that the number of layers of some or all of the leaf nodes and the intermediate nodes above the leaf nodes can be less than 8.

[0121] In addition, the account state and the contract state can also be stored in a one-layer tree structure, as shown in FIG. 12. Since the key of the contract state is a hash value, based on the discrete characteristics of the hash algorithm, the state keys of different contract states can be paths from the root node to different leaf nodes in the one-layer tree structure. In this case, the values of different states of the same contract can exist in different leaf nodes in the bottom layer of the one-layer tree structure, rather than being gathered under the contract account to which the states belong. In fact, in the one-layer tree structure, the account state and the contract state are dispersed in the leaf nodes in the bottom layer.

[0122] In addition, on the basis of Fig. 12, prefix and / or infix can be compressed, as shown in Fig. 13. In the case of infix compression, for example, the tree node key of Ml is 0x52d1479e (0x means each bit is represented by a hexadecimal number), and the tree node key of Zl is 0x52d9ab36, then Ml and Zl have a common infix 2d, so in the tree node C5, in addition to the 16-way tree separated 1 and 9, C5 can also have the compressed infix 2d, as shown in the shared nibbles field in Fig. 13. In the case of suffix compression, for example, represented by key-end, then the key-end in the tree node Ml is, for example, 479e, and the key-end in the tree node Zl is, for example, 36. With prefix and / or infix compression, the number of layers of the tree can be reduced.

[0123] Regardless of whether compression is performed, for a lookup state key, the path of the state key can be matched from the root node of the tree structure, segment by segment, until the leaf node of the tree structure corresponding to the lookup state key is found. In one approach, the storage of the root node and the intermediate nodes is in the form of key-value, where the key is the hash value of the value, similar to the structure in Table 3. In this way, the hash of the path of the state key can be matched from the previous layer of tree nodes in order, and the next layer of tree nodes can be found according to the hash, until the leaf node of the tree structure corresponding to the state key is found.

[0124] In addition, the key of the tree node k-v actually stored in the database can also not be the hash value of the value, but a part of the value on the path of the state key, for example, the value of the part of the key from the root node to the current tree node (without compression of the prefix / infix, as shown in Table 4, in combination with Fig. 12), or the value of the part of the key after the previous tree node (with compression of the prefix / infix, as shown in Table 5, in combination with Fig. 13).

[0125] Table 4, tree node k-v actually stored in the database

[0126] According to Table 4, for example, the state key for lookup is 0x59...36 (leaf node Z1), starting from the root node of the tree structure, the left 1st bit 5 of the state key can be matched to the tree node with key 0x5 in the database (h(C5) in the value of the tree node with key 0x5 can be used to verify the hash value on slot 5 in the root node, and if the same, it means that the tree node with key 0x5 is the child node of slot 5 in the tree node with key 0x); further, the left 2nd bit 9 of the state key can be matched to the tree node with key 0x9 in the database (h(C5D9) in the value of the tree node with key 0x9 can be used to verify the hash value on slot 9 in the parent node, and if the same, it means that the tree node with key 0x9 is the child node of the tree node with key 0x5); and so on. Finally, the last bit 6 of the state key can be matched to the tree node with key 0x6 in the database (h(Z1) in the value of the tree node with key 0x6 can be used to verify the hash value on slot 6 in the parent node, and if the same, it means that the tree node with key 0x6 is the child node of the parent node).

[0127] Table 5, tree nodes k-v actually stored in the database

[0128] According to Table 5, for example, the state key for lookup is 0x52d9...36 (leaf node Z1), starting from the root node of the tree structure, the left 1st bit 5 of the state key can be matched to the tree node with key 0x5 in the database, if no same key is matched, or the hash value in the value of the tree node with key is inconsistent with h(C5) in the root node, then the left 1st-2nd bit 52 of the state key is matched to the database, and so on, until a match is made. When the left 1st-3rd bit 52d of the state key is matched to the tree node with key 0x52d in the database, and H(C5) in the value of the tree node is the same as the hash value on slot 5 in the root node, it means that a match is made. Further, the left 1st-4th bit 52d9 of the state key can be matched to the database, if no same key is matched, or the hash value in the value of the tree node with key is inconsistent with h(C5) in the root node, then the left 1st-2nd bit 52 of the state key is matched to the database, and if a match is made, and H(C5D9) in the value of the matched tree node is the same as the hash value on slot 9 in the parent node, it means that a match is made. Further, the left 1st-5th bit of the state key is matched to the database, the left 1st-6th bit of the state key is matched to the database, and so on, until the leaf node is matched.

[0129] In another implementation, the complete state key or the corresponding complete state key can be stored in the leaf node. Taking the example of storing the complete state key in the leaf node, as shown in FIG. 14, the key-full field of the leaf node can store the complete key corresponding to the state. The key-value of the leaf node stored in the database has the key that is the complete key of the state corresponding to the leaf node. In this way, when searching for a state key, the key of the leaf node can be directly matched in the database according to the key, without the need to match the key of the intermediate node. Obviously, such a search method is extremely efficient for query operations. In fact, in the above-mentioned FIGS. 10-13, the complete state key can also be used as the key of the leaf node.

[0130] In the above-mentioned embodiments of FIGS. 9-14, the location index stored in the leaf node can be used to quickly locate the position of the value of the leaf node in the data file after the leaf node is found. In this way, the content of the corresponding position in the data file can be directly loaded into the memory, which also avoids the read amplification problem caused by reading and loading a large number of files into the memory in multiple levels of SST. This also avoids the process of storing the k-v of the leaf node in the SST file of the persistent storage and performing multiple binary search operations in the SST according to the key (hash value of the value content) of the leaf node. Moreover, similarly, for the memory of the tree construction module that does not have the leaf node to be searched, the above-mentioned embodiments can only search the index file, so that more index files can be loaded into the memory in a unit of space for searching, and the leaf node can be found faster.

[0131] As mentioned above, the state root in the block header stores the hash value of the tree root of the anchored lower layer MPT tree. This hash value is actually obtained by calculating the hash value from the leaf node to the upper layer according to the rules, as described above. Generally, the storage module of the blockchain node constructs the world state in the form of a tree structure in the memory. The present application provides a method for constructing a world state based on a Merkle dictionary tree, comprising:

[0132] S160: receiving a state key-value.

[0133] S162: generating a leaf node of the tree structure according to the dictionary order rule of the Merkle dictionary tree, and storing the state value in the data file of the persistent storage medium, wherein the leaf node includes a location index of the state value in the data file of the persistent storage medium.

[0134] The process of S162 can be referred to the foregoing content, which is briefly described again as follows:

[0135] As in Ethereum, when a storage module receives a write state key-value pair (k-v) request, it first hashes the key (k) (e.g., Keccak-256). Alternatively, the state key in S162 can also be the state key received in S160, i.e., without hashing. Next, the key is used to search in the MPT. The search starts from the root of the MPT and proceeds down the tree following the lexicographical order of the key. In this process, the key is compared with the stored path in the nodes bit by bit (or nibble by nibble, where a nibble is a hexadecimal number of one bit). During the search and matching, three types of nodes can be encountered: branch nodes (if the path forks at some point), extension nodes (if there is a shared prefix), and leaf nodes (storing the final value). Branch nodes are used to fork in the tree, extension nodes are used to optimize storage (by path compression), and leaf nodes store the actual values. If the complete lexicographical path of the matching key is found during the search, a leaf node is reached. At this point, the value (v) stored in this leaf node can be updated. If the search and matching process only finds a partial path, new nodes (which can be branch nodes, extension nodes, or leaf nodes) can be created to complete the remaining path and eventually reach a leaf node, where the value is stored or updated.

[0136] Once the leaf node is updated or created, a backtracking process is also started. This process starts from the modified leaf node and re-computes the hash value of this node. Then, it moves up to the parent node, updates the relevant reference (which can be the direct content of the child node or the hash value of the child node content, depending on the size of the child node) in the parent node, and re-computes the hash value of the parent node. This process continues until the root of the MPT is reached.

[0137] Finally, when the backtracking process reaches the root node, the root hash value of the entire MPT is updated. This new root hash value represents the new state of the entire state tree, which will be included in the block header of the next block as the new state root. In this way, each block not only contains transaction information but also saves the hash value of the global state after executing these transactions through the state root.

[0138] As described above, in order to reduce the read amplification and speed up the lookup efficiency, the location stored in the leaf node refers to the position in the data file in the persistent storage medium. For the distributed system of the blockchain, different blockchain nodes store the same value locally, and it is likely that the same value is stored in the position of a specific data file in the local persistent storage medium, i.e., the same value corresponding to the same key stored by different blockchain nodes is located in the position of different data files in each local, i.e., the location is different. In order to enable each blockchain node to construct the same tree structure, thereby obtaining the same tree root and the same block hash, and to provide the SPV capability, it is necessary to design a certain anchoring rule between the tree nodes.

[0139] Specifically, the scheme provided by the present application can be as shown in FIG. 15. In addition to the position index of the state value in the data file in the persistent storage medium, the leaf node can also include the hash value of the corresponding state value content.

[0140] S164: Calculate the hash value of the leaf node according to the content in the leaf node, and store the hash value of the leaf node in the tree node at the upper layer.

[0141] The hash value of the leaf node is calculated according to the content in the leaf node, including the hash value of the state value content, but excluding the position index of the state value in the data file in the persistent storage medium. For example, for the leaf node numbered A11 in FIG. 15, in addition to the location, the valuehash is also included, which corresponds to the hash value of the state value content, i.e., the hash value of the value content in the data file in the persistent storage medium pointed by the location.

[0142] In addition, for the intermediate node A10, the hash value of the leaf node A11 stored in the slot 3 is calculated according to the content including the valuehash, but excluding the position index of the state value in the data file in the persistent storage medium, i.e., the location. For example, the hash value of the leaf node A11 stored in the slot 3 is calculated according to the sequential splicing of the prefix, Key-end and valuehash in the leaf node A11, but the calculation of the hash value does not include the location.

[0143] In this way, on the one hand, the different positions of different blockchain nodes in storing the value content in the above data file manner can be avoided to cause different tree structures, and on the other hand, the support for SPV capability is realized in a hash-locked manner.

[0144] In the above method, the state data is written to modify the corresponding Merkle tree node, and when the modified Merkle tree node reaches a certain threshold, the content of the node can be written into an index file, as shown in FIG. 16. In addition, after the Merkle tree runs for a period of time, a plurality of modified tree nodes can also be periodically written into an index file in batches in the background according to a set time threshold.

[0145] The data file and the index file can be logically managed separately and physically stored in different files.

[0146] As described above, since the upward backtracking process needs to recalculate the hash value of the modified leaf node, the present application can also update the hash value change of the intermediate node caused by the leaf node to the tree node above the intermediate node.

[0147] As shown in FIG. 15, the data file is no longer sorted by key, and after the location is obtained, the value is directly read from the location, without the need to search for the data position in a plurality of sst files at multiple levels as in the general KVDB, so as to reduce the read amplification.

[0148] By using the above scheme of the present application, an integrated Merkle state data implementation is provided, which is no longer divided into two-level structures of an upper Merkle tree and a lower general KVDB, but is an overall MerkleDB, with the index and data separated in the DB. The merkle tree is used as the index, and the contract state data is used as the data, so as to shorten the read-write process of the state data and reduce the overall write amplification and read amplification.

[0149] The entire MerkleState is used as a special DB, which only stores Merkle state data, and the data and the index are separated in the DB (key-value separation), and is no longer divided into two layers of an upper Merkle tree and a lower general KVDB. In this way, for a large number of data files, compaction can be performed without being divided into levels, but the garbage ratio of the data file is maintained, and garbage recovery is performed in the background according to the garbage ratio. All historical state data on the chain needs to be retained, and garbage is generated only when the data is rolled back. The garbage recovery is a low-frequency operation, thereby avoiding the repeated rewrite of data caused by compaction in the general KVDB and reducing the write amplification.

[0150] Figure 17 is a complete diagram of another embodiment of the present application. Figure 17 is similar to Figure 14 as a whole, the main difference being that, for example, the intermediate node with reference C5 and the intermediate nodes thereunder with references C5D1, C5D9, C5D14 jointly constitute a LogicalPage, and in the leaf nodes M1, M2, M3, M4, the key-end is stored instead of the key-full, and in the leaf nodes, in addition to the position index contained, the hash value of the corresponding state value content is also contained. Of course, in this embodiment, as mentioned above, the leaf nodes M1, M2, M3, M4 can also be key-full.

[0151] The leaf node can also include the hash value of the state value content and the key-end field, wherein the hash value of the leaf node is calculated according to the content in the leaf node, including being calculated according to the hash value of the state value content in the leaf node and the key-end field, but excluding the position index of the state value in the data file in the persistent storage medium.

[0152] The leaf node can also include the hash value of the state value content and the key-full field, wherein the hash value of the leaf node is calculated according to the content in the leaf node, including being calculated according to the hash value of the state value content in the leaf node and the key-full field, but excluding the position index of the state value in the data file in the persistent storage medium.

[0153] The present application also provides a blockchain node, comprising a storage module, the storage module comprising a tree construction module and a persistent storage medium, the persistent storage medium comprising an index file and a data file; the storage module further comprising a lookup unit, a reading unit; the leaf node of the tree structure comprises a position index of state data in the data file in the persistent storage medium;

[0154] The tree construction module is used to construct a tree structure of the world state in the memory;

[0155] The lookup unit receives an instruction to find a state key, finds the leaf node corresponding to the state key on the tree structure in the memory, and obtains the position index contained in the leaf node, the position index pointing to the position in the data file in the persistent storage medium;

[0156] The reading unit loads the value value of the data file position in the persistent storage medium pointed to by the position index into the memory and reads the state data therein.

[0157] The finding unit matches the path of the state key from the root node of the tree structure step by step until the leaf node of the tree structure corresponding to the state key is found.

[0158] The finding unit matches the hash of the path of the state key from the last layer tree node in sequence, and finds the next layer tree node according to the hash until the leaf node of the tree structure corresponding to the state key is found.

[0159] The finding unit matches the key of the path of the state key from the last layer tree node in sequence, and finds the next layer tree node according to the matched key until the leaf node of the tree structure corresponding to the state key is found.

[0160] When the state data does not exist in the leaf node in the memory, the position index contained in the leaf node is obtained.

[0161] When the leaf node does not exist in the memory, the tree node key of the leaf node is found from the index file in the persistent storage, the value in the data file corresponding to the key is loaded into the memory, and the position index is obtained from the value.

[0162] The tree node key of the leaf node of the tree structure corresponds to the state key, so when the leaf node does not exist in the memory, the tree node key of the leaf node is found from the persistent storage,

[0163] When the leaf node does not exist in the memory, the finding unit finds the tree node key of the leaf node in the index file of the persistent storage according to the state key.

[0164] The tree structure includes a one-layer tree structure or a two-layer tree structure.

[0165] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it themselves, without having to ask a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented using "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is also written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0166] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0167] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not rule out that with the development of future computer technologies, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0168] While one or more embodiments of this specification provide the steps of operation for the methods described in the embodiments or flowcharts, more or fewer steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0169] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0170] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0171] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart or flowsheets and / or block or blocks of the block diagrams.

[0172] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart or flowsheets and / or block or blocks of the block diagrams.

[0173] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0174] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) about which the computer stores information about an operating system or application programs, e.g., DRAM, SRAM, etc. The memory is an example of computer readable media.

[0175] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as 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 technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0176] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0177] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0178] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" etc. means that the specific feature, structure, material or characteristic described in connection with that embodiment or example is included in at least one embodiment or example in the specification. Illustrative descriptions of the above terms in the specification do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine the features of different embodiments or examples and different embodiments or examples described in the specification, without contradiction.

[0179] The above only describes the embodiments of the one or more embodiments described in this specification and is not intended to limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the specification shall be included in the scope of the claims. < / k3-v3> < / k2-v2> < / k1-v1> < / k3-v3> < / k2-v2> < / k1-v1> < / k3-v3> < / k2-v2> < / k1-v1> < / k3-v3> < / k2-v2> < / k1-v1>

Claims

1.A method for constructing a Merkle dictionary tree based world state, applied to a storage module of a blockchain node, the storage module constructs a tree structured world state in memory, the method comprising: receiving a state key-value; generating a leaf node of the tree structure according to a lexicographic rule of the Merkle dictionary tree, storing the state value in a data file of a persistent storage medium, the leaf node including a location index of the state value in the data file of the persistent storage medium; calculating a hash value of the leaf node according to the content of the leaf node, and storing the hash value of the leaf node in a tree node at an upper layer of the leaf node. 2.The method of claim 1, wherein when a state data is written, a corresponding tree node is modified, and when the modified tree nodes reach a certain threshold, the contents of these nodes are written into an index file. 3.The method of claim 1, wherein when a state data is written, a corresponding tree node is modified, and according to a set time threshold, a plurality of modified tree nodes are periodically written into an index file. 4.The method of claim 2, wherein the data file and the index file are logically managed separately and physically stored in different files. 5.The method of claim 1, wherein the leaf node further includes a hash value of the content of the state value; wherein calculating a hash value of the leaf node according to the content of the leaf node includes calculating according to the hash value of the content of the state value in the leaf node, but excluding the location index of the state value in the data file of the persistent storage medium. 6.The method of any one of claims 1-5, further comprising updating the hash value changes of the intermediate nodes caused by the leaf node to the tree nodes at an upper layer of the intermediate nodes. 7.The method of any one of claims 1-5, wherein the leaf node further includes a hash value of the content of the state value and a key-end field, wherein calculating a hash value of the leaf node according to the content of the leaf node includes calculating according to the hash value of the content of the state value in the leaf node and the key-end field, but excluding the location index of the state value in the data file of the persistent storage medium. 8.The method of any one of claims 1-5, wherein the leaf node further includes a hash value of the content of the state value and a key-full field, wherein calculating a hash value of the leaf node according to the content of the leaf node includes calculating according to the hash value of the content of the state value in the leaf node and the key-full field, but excluding the location index of the state value in the data file of the persistent storage medium. 9.The method of any one of claims 1-5, wherein the intermediate node contains a compressed common prefix / infix in addition to the slot. 10.A computer device, comprising: a processor; and a memory, wherein a program is stored in the memory, and when the processor executes the program, the operations of any one of claims 1-6 are performed.

Images