Method for reading world state of tree structure, and computer device

Abstract

A method for reading a world state of a tree structure, and a computer device. The method comprises: receiving a read state key and a version; on the basis of the state key and the version, matching a version and a page ID in a page identifier of a memory page in lexicographic order, and after matching, if the memory page comprises at least two layers of tree nodes, continuing to match a version and a node ID of a tree node below the uppermost layer of tree nodes in lexicographic order until a leaf node is found, the page ID comprising lexicographic content from a root node of the tree structure to an upper-layer tree node in the memory page, and the node ID comprising lexicographic content from the root node to the tree node; and reading a state in the leaf node.

Description

Method for reading world state of tree structure and computer device

[0001] The present application claims priority to the Chinese patent application No. 2024109808629, filed on July 19, 2024, and entitled "Method for reading world state of tree structure and computer device", 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 for reading world state of tree structure and a computer device. 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 non-tamperable and non-forgable by cryptography. Due to the characteristics of decentralization, information non-tamperability, and autonomy, blockchain has received more and more attention and application.

[0004] SUMMARY

[0005] The purpose of the present application is to provide a method for reading world state of tree structure and a computer device, comprising:

[0006] A method for reading world state of tree structure, comprising:

[0007] Receiving a state key and a version for reading;

[0008] According to the state key and the version, matching the version and the page ID in the page identifier of the memory page in a lexicographic order, if the memory page includes at least two layers of tree nodes, then continuing to match the version and the page ID of the tree nodes below the uppermost tree node in a lexicographic order until a leaf node is found; the page ID includes the lexicographic content from the root node of the tree structure to the upper tree node in the memory page; the node ID includes the lexicographic content from the root node to the tree node;

[0009] Reading the state in the leaf node.

[0010] A computer device, comprising:

[0011] A processor;

[0012] and a memory having a program stored therein, wherein when the processor executes the program, the operations of any one of the above methods are performed.

[0013] The above embodiment describes a tree structure world state according to the Page cutting scheme, which divides the tree structure into LogicalPage, manages MemoryPage / BasePage / DeltaPage inside LogicalPage, optimizes each state tree modification into multiple version modifications with LogicalPage as the granularity, and reduces the overall write amplification. For the current version, it can be directly obtained through the memory page, and for the historical version, it can be read and replayed by reading BasePage and associated DeltaPage. Caching the entire MemoryPage in memory does not affect the contract execution performance. BRIEF DESCRIPTION OF DRAWINGS

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

[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] Figure 12 is a diagram illustrating reading state data in conjunction with a tree structure in an embodiment;

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

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

[0029] Figure 15 is a diagram illustrating a block storage structure in an embodiment;

[0030] Figure 16 is a diagram illustrating a block storage structure in an embodiment;

[0031] Figure 17 is a diagram illustrating a block storage structure in an embodiment;

[0032] Figure 18 is a diagram illustrating a block storage structure in an embodiment;

[0033] Figure 19 is a diagram illustrating a block storage structure in an embodiment. DETAILED DESCRIPTION

[0034] In order to make persons skilled in the art 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 part of the embodiments of the specification, rather than all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by persons of ordinary skill in the art without creative labor should belong to the protection scope of the specification.

[0035] Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there are various combinations of these types, such as private blockchains + consortium blockchains, consortium blockchains + public blockchains, etc. Public blockchains offer the highest degree of decentralization. Represented by Bitcoin and Ethereum, public blockchains allow participants to read data records on the chain, participate in transactions, and compete for the right to record new blocks. Furthermore, participants (represented by nodes on the blockchain) can freely join and leave the network and perform related operations. Private blockchains, on the other hand, have write permissions controlled by a specific organization or institution, and data read permissions are regulated by that organization. Simply put, a private blockchain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for internal use within specific institutions. Consortium blockchains fall between public and private blockchains, achieving "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of stakeholders to jointly maintain the operation of the blockchain.

[0036] Whether it's a public, private, or consortium blockchain, besides supporting the transfer of native assets on the blockchain between accounts, such as transferring Bitcoin and Ethereum, it can also provide smart contract functionality. A smart contract on the blockchain is a contract that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0037] Taking Ethereum as an example, enabling users to create and invoke complex logic within the Ethereum network is the biggest challenge that distinguishes Ethereum from Bitcoin's blockchain technology. At the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), which can be run by every Ethereum node. The EVM is a Turing-complete virtual machine, meaning that various complex logics can be implemented through it. Users publishing and invoking smart contracts in Ethereum run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0038] For example, as shown in Figure 1, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, Node 1's EVM can execute this transaction and generate the corresponding contract instance. In Figure 1, "0x6f8ae93…" represents the address of this contract. The transaction's data field can store bytecode, and the transaction's to field is an empty account. After the nodes reach a consensus through the consensus mechanism, the contract is successfully created, and users can subsequently call this contract.

[0039] After the contract is created, a contract account corresponding to the smart contract is generated on the blockchain, and has a specific address, contract code and account storage which 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 on the blockchain which contains the contract code and the account storage (Storage).

[0040] As mentioned before, the data field of the transaction containing the creation of the smart contract can save the bytecode of the smart contract. The bytecode is composed of a series of bytes, and each byte can identify an operation. Based on development efficiency, readability and other aspects, the developer can not directly write the bytecode, but choose to write the 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.

[0041] Taking Solidity language as an example, the contract written in Solidity is very similar to the class (Class) in object-oriented programming language. In a contract, multiple members can be declared, including state variables, functions, function modifiers, events, etc. The state variable is the value stored in the account storage of the smart contract, which is used to save the state of the contract.

[0042] The following is an example 1 of a simple smart contract written in Solidity language:

[0043] 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 the transaction and generate the corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account initiating 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 ether in the transaction. After calling the smart contract, the value of storedData can change. Subsequently, a client can view the current value of storedData through a certain blockchain node (for example, node 6 in FIG. 2).

[0044] 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 blockchain saves the transaction voucher which cannot be tampered with and will not be lost.

[0045] As mentioned before, the 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, such as Ethereum, an account can generally include two types:

[0046] Contract account: stores the executed smart contract code and the values of the states in the smart contract code, which can usually only be activated by an external account call;

[0047] Externally owned account: an account of a user, such as an Ethereum owner account.

[0048] The design of external accounts and contract accounts is actually a mapping of account addresses to account states. The state of an account generally 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.

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

[0050] Balance: the number of ethers owned by this address.

[0051] Storage root: a hash of the root node of an MPT tree, which organizes the storage of state variables of a contract account.

[0052] CodeHash: hash value of the smart contract code. For contract accounts, this is the hash value of the smart contract; for external accounts, since it does not include a smart contract, the CodeHash field can generally be an empty string / 0 string.

[0053] MPT, which stands for Merkle Patricia Tree, 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 at a time to calculate the Hash again, all the way to the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

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

[0055] A contract account is used to store the state related to a smart contract. After a smart contract is deployed on a blockchain, a corresponding contract account is generated. This contract account generally has some states, which are defined by 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 a blockchain environment, which can automatically execute clauses. Once an event triggers the clauses in the contract (satisfies the execution condition), the code can be automatically executed. 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 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 state address to state value. The address of a state is stored in the leaf node of the storage trie tree in the order of part of the information from the root node to the leaf node, and the value of the state is stored in the leaf node.

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

[0057] 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 that a key-value pair is formed. 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.

[0058] 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 Nodes and / or Leaf Nodes.

[0059] 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 Nodes and / or Leaf Nodes. For an Extension Node, it typically can have 1 child node, which can be a Branch Node or a Leaf Node.

[0060] 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 the value of storedData in the aforementioned contract code example, its key is sha3(the declaration position of storedData, i.e., the 2nd line of the code), and its value is s (for brevity, the encoding format of the value is omitted here, such as RLP, and the like will not be repeated). The value of the key is sequentially distributed from the root node to the leaf node (i.e., Leaf Node Variable N) of the storage trie.

[0061] 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 mentioned earlier, 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 sequentially distributed from the root node to the leaf node (i.e., Leaf Node Variable C) of the state Trie.

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

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

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

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

[0066] 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:

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

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

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

[0070] As shown in FIG. 6, one blockchain node 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 in the persistent storage device, such as Table 1. 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.

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

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

[0073] 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 the Append-Only mode 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 the 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.

[0074] In the disk, the KVDB stores a plurality of SST (Sorted String Table, SSTable) files in multiple levels. The SST is derived from the paper of 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 the 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.

[0075] 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 smaller 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.

[0076] 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, is <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 level of Level 2, Level 3,... is similar, that is, each SST in each level has a size order relationship in the value of k, and the multiple SSTs in each level have a size relationship in the range of k.

[0077] 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 full generally has 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.

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

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

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

[0081] 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 can also be performed by compaction, such as deleting data marked for deletion.

[0082] 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).

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

[0084] 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 sets the balance of account A to (a-f) and the balance of account B to (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.

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

[0086] 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).

[0087] In addition, the tree building 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 building 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 building 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). The dirty data can be written to the 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.

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

[0089] 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 built 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.

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

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

[0092] For example, in FIG. 10, the location index is represented by location. 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 the 750KB of "file 2", and the length is 210KB. As shown in the data file at the lower left corner of FIG. 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.

[0093] As shown in FIG. 9, this embodiment includes:

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

[0095] As shown in the foregoing FIG. 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 in the process of executing a 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.

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

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

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

[0099] If the leaf node to be searched does not exist in the memory of the tree module, it needs to be 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.

[0100] If the leaf node to be searched does not exist in the memory of the tree module, it needs to be 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.

[0101] Table 2, actual storage of tree nodes k-v in the database

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

[0103] In this way, the found leaf node tree node k-v 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.

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

[0105] 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> can be loaded into the memory and the state data therein can be read, that is, the data from the starting position 750KB to the length of 210KB in the file 2 in the data file is loaded into the memory, so as to read the state data therein, that is, "Zhang San_A=20".

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

[0107] 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 persistent storage SST file, and the process of multiple binary searches in the SST is avoided.

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

[0109] 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:

[0110] Table 3: Actual stored tree nodes k-v in the database

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

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

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

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

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

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

[0117] Z1: Zhang San_A = 20

[0118] Z2: Li Si_B = 50

[0119] Z3: Wang Wu_A = 35

[0120] Z4: storedData = s

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

[0122] 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, i.e., all the state keys. 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 fixed expansion of the intermediate node, there are 8 layers from C* to C13D* to M* at 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 intermediate nodes above a certain or certain leaf node can be less than 8.

[0123] 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 at the bottom layer of the one-layer tree structure, rather than being gathered under the contract account to which they belong. In fact, in the one-layer tree structure, the account state and the contract state are dispersed in the leaf nodes at the bottom layer.

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

[0125] 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 in order from the previous layer of tree nodes, 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.

[0126] 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).

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

[0128] 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).

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

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

[0131] In another implementation, the full state key or the corresponding full state key can be stored in the leaf node. For example, as shown in FIG. 14, the key-full field of the leaf node can store the full key of the corresponding state. The key-value of the leaf node stored in the database has the key as the full key of the state corresponding to the leaf node. In this way, when searching for a state key, the key of the leaf node in the database can be directly matched 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 FIGS. 10-13, the full state key can also be used as the key of the leaf node.

[0132] In the above 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 in 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 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.

[0133] As described above, the state root in the block header stores the hash value of the tree root of the anchored lower MPT tree. This hash value is actually obtained by calculating the hash 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 of the tree structure in the memory through the tree construction module. Specifically, in addition to the leaf node in the above FIGS. 12-14, the intermediate node and the root node are also included, as described above in the above tables 2-5.

[0134] Moreover, the chain data structure of the blockchain is realized by anchoring the hash of the next block to the Prev Hash of the previous block, as shown in FIGS. 3 and 4, and the blocks with different block numbers exist on the blockchain. These block numbers are also called versions. The tree structure corresponding to different versions of blocks can change.

[0135] Those skilled in the art know that the essence of a blockchain is a chain structure composed of a series of data blocks (blocks) associated by hashing. Each block has a corresponding world state of the block, but each block does not necessarily contain a complete world state, but in most cases contains a reference to the previous world state. The following explains this:

[0136] In the block structure of Ethereum, when the value of a key-value pair changes, the content of the leaf node of the corresponding MPT tree changes. Correspondingly, the relevant hash values stored in a series of intermediate nodes and the root node above the leaf node will also change. In the structure shown in Table 1, the changed leaf nodes and intermediate nodes, root nodes will also be added at the end of Table 1. At the same time, the values of many state variables in the contract storage may not change.

[0137] As shown in the Ethereum block structure diagram of FIG. 15, the difference between FIG. 15 and FIG. 3 is that the root node of the two-level Merkle tree under the State Root in the N+1 block references the state variables in the N block that do not change. For example, in the contract storage of a contract, the value of the same state variable changes from 29 in the N block to 45 in the N+1 block, assuming that other state variables do not change, then in the N+1 block, in addition to the leaf node storing the changed value 45 and the related intermediate nodes and intermediate nodes, the other unchanged leaf nodes and intermediate nodes in the N+1 block directly reference the same leaf node and intermediate node in the N block. Here, N and N+1 are two adjacent blocks. It can be understood that for the block structure of a plurality of consecutive blocks on the blockchain, the unchanged leaf nodes and intermediate nodes in the N+1 block relative to the previous block all reference the same leaf node and intermediate node that was last updated to the value in the N+1 block. The same leaf node and intermediate node that was last updated to the value, for example, is the same leaf node and related intermediate node that was last updated to the value in the N-1 block, the same leaf node and related intermediate node that was last updated to the value in the 5 block, and so on. The different blocks here can also be referred to as different versions, and the block number can be the version number. Here, the reference is achieved by recording the hash value of the lower layer node by the upper layer node. The advantage is obvious, that is, the unchanged leaf nodes and intermediate nodes are not stored repeatedly in the underlying database.

[0138] Here still take the same contract storage in N+1 version as an example, for example, the content of a certain tree node has changed, and its hash will also change accordingly. The MPT takes the hash as the index in the database, so that for each value, there is a definite record in the database. The MPT is associated with the parent and child nodes according to the node hash, so when the content of a node changes, the only thing that changes for the parent node is a hash index value; the content of the parent node also changes, resulting in a new parent node at a higher level, recursively passing on the impact to the root node. Ultimately, a change corresponds to the creation of a new path from the changed node to the root node, and the old node can still be accessed according to the old root node through the old path.

[0139] As shown in FIG. 15, when the content of a node in the MPT changes from 29 in N version to 45 in N+1 version, assuming that other states in the contract state do not change in the two versions before and after, the changed 45 in the world state of N+1 version corresponds to the creation of a new path to the contract root node (Storage root). And the other leaf nodes and intermediate nodes that do not change reuse the leaf nodes and / or intermediate nodes in the previous version (i.e., the version of block number N) through the hash pointer, thereby constructing a new MPT tree for the contract storage in N+1 version, while still retaining its old path. As shown in FIG. 18, in the same contract storage, the leaf nodes / intermediate nodes whose values do not change in N+1 version relative to N version include V, U, T, S, etc., so in the storage of the contract in N+1 version, in addition to creating a new path from 45 to Storage root, the Storage root in N+1 version is indexed to V, U, T, S in N version through hash, but does not include the leaf node with value 29 and the related intermediate nodes. Assuming that the contract is deployed in N version, the CodeHash is similar, and the contract code corresponding to the CodeHash exists in the state database (StateDB) corresponding to N version, and the CodeHash in N+1 version also points to the contract code in N version.

[0140] In addition to the contract storage, similarly, other account storages (including external account and contract account storages) can also be in a similar manner, as shown in FIG. 15, for the account storage that does not change in N+1 version relative to N version, the State Root in the N+1 block header points to the storage of external accounts or contract accounts L, M, N, P, Q, R, etc. in N version, and only the changed leaf nodes and related intermediate nodes are stored in the account storage corresponding to N+1 version, which is not described in detail.

[0141] All the states under the current block, in fact, many of them are likely to be updated in the previous block and continue to the current block without change. Similar to Ethereum, this is also called the current state, stored in the currentDB. The currentDB is used to store the latest "current state" data, such as the latest account state, contract code, and contract storage. Moreover, as the block grows, the data in the currentDB can be constantly modified.

[0142] As described in the foregoing figure 3 and the contents of the above figure 15, it is highly redundant to establish a global MPT tree of all states for each block, and to reference the same leaf node and intermediate node in the previous block that was last updated to this value is an efficient data storage method. Moreover, the changed state in each block is likely to be part of the global state. This is also similar to Ethereum, also known as the history state, stored in the historyDB. The historyDB is used to store historical state data, thereby providing a complete historical view of the entire chain.

[0143] The present application provides a method for constructing a tree structure-based world state, comprising:

[0144] S170: Receive state key-value.

[0145] S172: According to the construction rule of the tree structure, generate the leaf node of the tree structure corresponding to the state key-value pair; calculate the hash value of the leaf node according to the content in the leaf node, and generate or update the upper tree node according to the hash value of the leaf node and the state key, until the root node of the tree.

[0146] Among them, the leaf node can be in the form of the foregoing data file, or in the form of the foregoing KVDB. For the form of the foregoing data file, the leaf node can be to generate a position index of the state value in the data file in the persistent storage medium and a hash value of the state value content.

[0147] S174: According to the logical page structure of the division, generate the corresponding memory page of the generated / updated tree node, and the memory page is used to represent the content of all tree nodes corresponding to the logical page.

[0148] In the present application, the entire Merkle tree structure can be divided into multiple LogicalPages (logical pages), which can be aggregated according to the node association relationship of the tree structure to form a LogicalPage by aggregating several adjacent tree nodes above and below, such as aggregating 16 child nodes of the 2-level dictionary tree to form a LogicalPage. Among them, there are multiple layers of LogicalPages from the root node to the leaf node of the Merkle tree, and the LogicalPages have parent-child and sibling relationships, thereby forming a complete Merkle tree. In this way, the tree structure can be divided into multiple logical pages, each of which contains at least one tree node, and each logical page contains different tree nodes, and the logical page maintains the content of the corresponding tree node of the current latest version.

[0149] As shown in FIG. 16, inside each LogicalPage, a MemoryPage can be maintained to represent the content of all tree nodes in the corresponding logical page of the current latest version. Further, the content of the tree nodes maintained by the logical page can be generated into a BasePage and a DeltaPage according to continuous version updates and generation / modification behaviors. Specifically, a BasePage and a DeltaPage are generated according to generation / modification behaviors, for example, for continuous state changes, such as including state variables a=5, b=8, and c=3 in version N, a=5, b=8, and c=3 can be used as the content in the BasePage. For a=6 in version N+1, a=8 in version N+2, and assuming that b and c do not change, a=6 in version N+1 and a=8 in version N+2 can be used as the DeltaPage based on the BasePage, such as DeltaPage1, and b and c are not included in DeltaPage1. For a=11 in version N+3 and a=15 in version N+4, a=11 in version N+3 and a=15 in version N+4 can be used as the DeltaPage based on the BasePage, such as DeltaPage2, and assuming that b and c do not change, b and c are not included in DeltaPage2. Similarly, BasePage and DeltaPage can be used as the smallest unit of the memory structure of the tree. In addition, BasePage can be used as the smallest unit of disk persistence of the tree. On this basis, DeltaPage can also be used as the smallest unit of disk persistence of the tree.

[0150] It is noted that the BasePage here is a checkpoint of the whole LogicalPage content, which can contain the full content of the LogicalPage at that time, such as all contained tree node information. Checkpoint is generally a snapshot of a certain state saved in a computer system, so as to continue execution from the saved state when the system fails or fails. In many cases, checkpoint is used for long-running computing tasks, safety-critical systems, distributed systems, and database systems, etc.

[0151] [According to Rule 91 correction 25.12.2024] For BasePage, the state modification can be generated once BasePage for every predetermined number of times (such as m times), as shown by basepage2 on the right side of the lower right gray box in Figure 17. As in the previous example, the state variable a = 5 in version N, which can be used as the content in the base page BasePage1, a = 6 in version N+1, a = 8 in version N+2, a = 6 in version N+1 and a = 8 in version N+2 can be used as the DeltaPage1 based on this BasePage. For a = 11 in version N+3 and a = 15 in version N+4, a = 11 in version N+3 and a = 15 in version N+4 can be used as the DeltaPage2 based on this BasePage, and for a = 20 in version N+5, assuming that the modification reaches the predetermined number of 5, the values a = 20, b = 8 and c = 3 in version N+5 can be used as the content in this BasePage2.

[0152] Similarly, DeltaPage describes several version modifications of LogicalPage, and aggregates multiple modifications into a set, such as generating a DeltaPage every M modifications, and creating a new DeltaPage to collect subsequent version modification operations. As in the previous example, for a = 6 in version N+1 and a = 8 in version N+2, a = 6 in version N+1 and a = 8 in version N+2 can be used as the DeltaPage1 based on this BasePage, for a = 11 in version N+3 and a = 15 in version N+4, a = 11 in version N+3 and a = 15 in version N+4 can be used as the DeltaPage2 based on this BasePage, it can be seen that each DeltaPage sets up 2 version modification operations to create an incremental page.

[0153] For each modification of the BasePage and the DeltaPage, corresponding dirty data is generated in the memory. The BasePage and the DeltaPage can be batched for disk persistence when the memory occupied by the BasePage and the DeltaPage reaches a predetermined amount, so as to avoid persisting all dirty data each time the modification is made, and continuously occupying the memory and CPU resources. The memory generation and disk persistence of the BasePage and the DeltaPage can be performed in the background.

[0154] When the storage module persists the world state of the tree structure constructed in the memory through the structure of the logical page, the state data can be cached according to a predetermined strategy, such as an LRU strategy, according to the hot and cold characteristics of the state data and the logical page as a granularity. In this way, if the MemoryPage is discarded, the corresponding BasePage and DeltaPage are read, and the MemoryPage is replayed.

[0155] The above scheme provided in the present application describes a scheme of cutting the world state of a tree structure according to a Page, divides the tree structure into a LogicalPage, manages the MemoryPage / BasePage / DeltaPage in the LogicalPage, optimizes each state tree modification into multiple version modifications according to the LogicalPage as a granularity, and reduces the overall write amplification. For the current version, the MemoryPage can be directly obtained, and for the historical version, the BasePage and the associated DeltaPage can be read to obtain the replay. The entire MemoryPage is cached in the memory, and the contract execution performance is not affected.

[0156] In the above scheme, the MemoryPage / BasePage / DeltaPage is managed in the LogicalPage, and as described above, a plurality of adjacent tree nodes can be aggregated into a LogicalPage according to the node association relationship of the tree structure, such as 16 children nodes of 2 levels of a trie, which are aggregated into a LogicalPage. Among them, there are multiple layers of LogicalPages from the root node to the leaf node of the Merkle tree, and the LogicalPages have parent-child and sibling relationships, thereby forming a complete Merkle tree. In this way, the tree structure can be divided into a plurality of logical pages, each of which contains at least one tree node, and different logical pages contain different tree nodes, and the logical page maintains the content of the corresponding tree node of the current latest version.

[0157] So, when constructing the world state based on the tree structure, in addition to generating the leaf node of the tree according to the state key-value, it will also cause changes from the generated leaf node to the intermediate node to the root node, as described in the hash value in the aforementioned S172. Moreover, the key of the state also needs to be designed, especially for the LogicalPage and the corresponding MemoryPage / BasePage / DeltaPage.

[0158] Therefore, the present application also proposes the following method for constructing the world state based on the tree structure, comprising:

[0159] S180: receiving a state key-value.

[0160] S182: generating a leaf node of a tree structure corresponding to the state key-value according to the construction rule of the tree structure; calculating the hash value of the leaf node according to the content in the leaf node, and generating or updating the upper tree node according to the hash value of the leaf node and the state key, until the root node of the tree.

[0161] Among them, the leaf node can be in the form of the aforementioned data file, or in the form of the aforementioned KVDB. For the form of the aforementioned data file, the leaf node can be to generate a position index of the state value in the data file in the persistent storage medium and a hash value of the state value content.

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

[0163] 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). In addition, the state key in S182 can also be the state key received in S180, i.e., it can not be hashed. Next, the key is used to search in the MPT. The search starts from the root of the MPT and follows the path in the tree according to 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 traversal and matching, three types of nodes can be encountered: branch nodes (if the path diverges at a certain point), extension nodes (if there is a shared prefix), and leaf nodes (which store the final value). Branch nodes are used to diverge 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 to exist during the search, a leaf node is reached. At this point, the value (v) stored in the leaf node can be updated. If the search and matching process finds that only part of the path is matched, new nodes (which can be branch nodes, extension nodes, or leaf nodes) can need to be created to complete the remaining path and eventually reach a leaf node, and the value in the leaf node can be stored or updated.

[0164] Once the leaf node is updated or created, a backtracking process is also started. This process starts from the modified leaf node and recalculates the hash value of this node. Then, it moves up to the parent node, updates the relevant reference in the parent node (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), and recalculates the hash value of the parent node. This process continues until the root of the MPT is reached.

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

[0166] S184: updating the version of the generated / updated tree node in the corresponding memory page according to the divided logical page structure, the memory page being used to represent the content of all tree nodes in the corresponding logical page, the logical page containing a page identifier, the page identifier including the lexicographical content and version of an upper tree node in the logical page.

[0167] It should be noted that the process of S184 can occur after S182 or during the process of S182.

[0168] Figure 18 is a complete diagram of another embodiment of the present application. Figure 18 is generally similar to Figure 13, the main difference being that, for example, the intermediate node with reference C5 and the intermediate nodes thereunder with references C5D1, C5D9, C5D14 together 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.

[0169] The leaf nodes 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 calculation 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.

[0170] The leaf nodes 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 calculation 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. Here, the valuehash in the leaf node in Figure 18 is omitted. In Figure 18, the data structure of the tree node is used instead of the graphical description in Figure 14.

[0171] In the foregoing S182, the tree node is generated / updated. The updated tree node is integrated into the corresponding memory page according to the logical page structure described above, representing the world state tree structure under the current block number. In the present application, a version number can be set for the logical page. The version number can typically be the block number. In addition to the block number, the version number can also be data such as block hash, timestamp, state root, transaction root, receipt root, consensus round number, which can uniquely identify a block. For simplicity, the block number is described below.

[0172] The version number of the logical page can be included in the page identifier of the logical page. In addition to the version number, the page identifier of the logical page can also include the lexicographic content of the contained tree nodes. Specifically, the page identifier can include the lexicographic content of the upper tree nodes in the logical page. As shown in FIG. 18, the upper tree node of the intermediate nodes with labels C5, C5D1, C5D9, and C5D14 together constitute a LogicalPage, and the upper tree node has a NodeID, such as 0xd2345 (0x represents hexadecimal), and the intermediate nodes C5D1, C5D9, and C5D14 each also have a NodeID. The PageID of the LogicalPage can be set to the NodeID of the upper tree node. These page IDs are the lexicographic content from the root node to the upper tree node in the LogicalPage (i.e., the memory page), i.e., the key distributed from the root node through the intermediate node to the lexicographic content of the upper tree node in the LogicalPage. Similarly, the NodeID is the lexicographic content from the root node to the tree node, i.e., the key distributed from the root node through the intermediate node to the lexicographic content of the tree node.

[0173] As described above, in the process of generating / updating the tree nodes of the current version, the changed tree nodes constitute dirty data. As described above, the base page and the incremental page can be generated based on the changes of the logical pages of consecutive versions. On this basis, the base page can be taken as the minimum unit of disk persistence of the tree, or the incremental page can be taken as the minimum unit of disk persistence of the tree. The base page can be generated once for every predetermined number of state modifications, or the incremental page can be generated once for every predetermined number of state modifications. When the base page and the incremental page occupy a certain amount of memory, the base page and the incremental page are batched for disk persistence.

[0174] The base page and the incremental page are persistent objects of the memory page corresponding to the logical page, and the memory page is the memory object of the logical page. The base page generally corresponds to the memory page and contains global state variables, and can have the same page ID as the corresponding memory page, and the memory page has the same page ID as the corresponding logical page. The incremental page can also correspond to the memory page and contain the tree nodes in one or more consecutive version memory pages that have changed relative to the previous adjacent base page / incremental page / version, i.e., contain the changed state variables, which are generally not global state variables, and the structure of the tree nodes in the incremental page generally does not change, so the page ID of the corresponding memory page can be the same as the NodeID of the upper tree node.

[0175] In addition, the base page and the delta page can have a version. After the operation of S184, the base page and the delta page corresponding to the version of the change of the memory page based on the continuous version can be generated. Specifically, the base page generally corresponds to one memory page and contains all the tree nodes in the corresponding memory page, that is, contains the global state variable, so it can have the same version as the corresponding memory page. The delta page can correspond to one or more memory pages and contain the tree nodes in one or more continuous versions of the memory page that have changed relative to the previous adjacent base page / delta page, that is, contain the changed state variable, but generally not the global state variable, so the version of a delta page can be the lowest or highest version of the one or more memory pages corresponding to it.

[0176] For example, a base page with a version of 4 contains state variables a=1, b=2, c=3 and corresponding intermediate nodes and root nodes, and the subsequent delta page can include a=2 with a version of 5 and corresponding intermediate nodes and root nodes, a=1 with a version of 6 and corresponding intermediate nodes and root nodes, and b=4 with a version of 7 and corresponding intermediate nodes and root nodes. Among them, a=1 with a version of 6, although the same as the state variable a=1 in the base page, is different from the previous adjacent version a=2 with a version of 5, so a=1 with a version of 6 and corresponding intermediate nodes and root nodes are also included in the delta page. In addition, for the subsequent delta page, for example, the delta page containing tree nodes with versions of 7, 8 and 9, the actual tree nodes are sequentially relative to the previous adjacent delta page and version. The tree nodes with versions of 5, 6 and 7 correspond to memory pages with versions of 5, 6 and 7 respectively. This delta page containing tree nodes with versions of 5, 6 and 7 can have a version of 5 or 7, that is, the lowest or highest version of the corresponding multiple memory pages.

[0177] Moreover, a page type can also be set in the base page and the delta page to distinguish the base page and the delta page.

[0178] The above scheme is a multi-version Page splitting scheme of a Merkle state data dictionary tree, which switches the tree to a LogicalPage. Both the tree and the LogicalPage maintain a version (such as a block number). The internal management of MemoryPage / BasePage / DeltaPage is maintained according to the version. The BasePage / DeltaPage maintains the memory structure and file persistence according to the version. Through page aggregation, the overall write amplification is reduced. By using the ordered characteristics of the version, the compaction after the page is landed is avoided. The write amplification of the page landing can be reduced. By replaying based on the version, the state data reading and SPV function of any historical version are supported. In addition, in combination with the contents of the foregoing FIGS. 9-14, the state value can be stored in a data file of a persistent storage medium. The leaf node includes a position index of the state value in the data file of the persistent storage medium, so that the problem of write amplification can be further reduced.

[0179] Corresponding to the world state constructed in the above manner, the application also provides a reading method, comprising:

[0180] S190: receiving a read state key and version.

[0181] S192: according to the state key and version, matching the version and page ID in the page identifier of the memory page in the dictionary order. If the memory page includes at least two layers of tree nodes, then continue to match the version and page ID of the tree nodes below the uppermost tree node in the dictionary order until the leaf node is found.

[0182] For the received state key and version, the version and page ID in the page identifier of the memory page can be matched in the dictionary order. For example, for the intermediate node with the label C5 in FIG. 18 and the intermediate nodes below it with the labels C5D1, C5D9, and C5D14, which together constitute a LogicalPage, the corresponding memory page can be found first according to the version and page ID. Then, the received state key is used to further match the tree nodes below in the memory page.

[0183] For example, for the received state key is 0xd2345167890ab and the version is 20, the version + page ID of a memory page is 20 + 0xd2345, the intermediate node marked C5 in FIG. 18 and the intermediate nodes marked C5D1, C5D9, C5D14 thereunder jointly constitute a memory page constituted by a LogicalPage which can match (0xd2345, the first 5 bits of 0xd2345167890ab). Further, in the lower layer tree nodes in the memory page, it is assumed that the C5D1 tree node is matched, i.e., the NodeID in the C5D1 tree node is matched as 0xd23451; further, the lower layer memory page of the memory page can be continuously matched. As shown in FIG. 19, the lower layer memory page is continuously matched, and according to 0xd2345167890ab, the memory page with the same version and PageID of 0xd234516 is matched, and the memory page includes the upper and lower layer tree nodes E5 and E5F2, E5F7, E5F8. Further, in the lower layer tree nodes in the memory page, it is assumed that the E5F7 tree node is matched, i.e., the NodeID in the E5F7 tree node is matched as 0xd2345167. In this way, the version and the PageID in the page identifier of the memory page are matched in the dictionary order until the last memory page and the leaf node therein are matched, and the search is completed.

[0184] As described above, the memory page is the memory object of the logical page. However, based on the cache eviction policy in the memory, there can be no currently matched memory page. Meanwhile, as described above, based on the change of the logical page with the continuous version, the base page and the incremental page can be generated, and the base page and the incremental page are the persistent objects of the memory page corresponding to the logical page. Therefore, for the case that the memory page does not exist in the memory, the corresponding base page and the incremental page can be loaded from the persistent storage medium to the memory according to the page identifier, and the memory page can be obtained by playing back the loaded base page and the incremental page.

[0185] Specifically, for example, if the memory page with the same version and matching the remaining dictionary order content is not found in the memory, the corresponding base page and the incremental page matching the remaining dictionary order content can be found in the persistent storage medium according to the page identifier. As described above, since the base page and the incremental page also have a version, and the base page generally has the same version as the corresponding memory page, and the version of an incremental page can be the lowest version in one or more memory pages corresponding thereto, there are the following two cases:

[0186] 1. For the case that the base page with the same version is found in the persistent storage medium, the corresponding base page can be loaded from the persistent storage medium to the memory according to the page identifier, and then the loaded base page is restored to the memory page.

[0187] 2. If no base page with the same version is found in the persistent storage medium, load the corresponding base page and delta page to the memory according to the page identifier; and replay the loaded base page and delta page to obtain the memory page.

[0188] The page identifier of the base page and the delta page can further include a page type.

[0189] In this way, the loading of the corresponding base page to the memory according to the page identifier can be loading of a base page with a version no greater than the read version, a same page ID and a base page type from the persistent storage medium. For the case 1, i.e. the case where a base page with the same version is found in the persistent storage medium, the base page with the same version, the same page ID and the base page type can be loaded to the memory. For example, the version to be found is 20, and there is no memory page with the version 20 in the memory, and a base page with the same version 20 is found in the persistent storage medium, the base page with the same version 20, the same page ID and the base page type can be loaded to the memory. For the case 2, i.e. the case where no base page with the same version is found in the persistent storage medium, a base page with a version no greater than the read version, a same page ID and a base page type can be loaded to the memory from the persistent storage medium. For example, the version to be found is 20, and there is no memory page with the version 20 in the memory, and of course no base page with the same version 20 is found in the persistent storage medium, and actually, there is a BasePage1 with the version 17, a DeltaPage1 with the version 18, a DeltaPage2 with the version 20 and a BasePage2 with the version 22 in the persistent storage medium, the DeltaPage1 with the version 18 can include a tree node with the version 18 and a tree node with the version 19, and the DeltaPage2 with the version 20 can include a tree node with the version 20 and a tree node with the version 21, and a BasePage1 with a version no greater than 20, a same page ID and a base page type can be loaded to the memory, i.e. the version of the base page meeting the condition is 17.

[0190] For the case 1, i.e. the case where a base page with the same version is found in the persistent storage medium, the base page with the same version, the same page ID and the base page type can be loaded to the memory, and then the memory page with the same version can be recovered. For example, the version to be found is 20, and there is no memory page with the version 20 in the memory, and a base page with the same version 20 is found in the persistent storage medium, the base page with the same version 20, the same page ID and the base page type can be loaded to the memory, and then the loaded base page with the version 20 is recovered as the memory page with the same version 20.

[0191] For the case 2 above, i.e. the case that no base page with the same version is found in the persistent storage medium, the base page with the maximum version no greater than the read version, the same page ID and the base page type can be loaded from the persistent storage medium to the memory, and then the loaded base page and the delta page can be played back to obtain the memory page. The loaded base page and the delta page can be played back to obtain the memory page, specifically, the base page with the maximum version no greater than the read version, the same page ID and the base page type can be loaded from the persistent storage medium to the memory, and the delta page with the minimum version no less than the read version, the same page ID and the delta page type can be loaded from the persistent storage medium to the memory after the version of the base page. For example, the version to be found is 20, and there is no memory page with the version 20 in the memory, and of course no base page with the same version 20 is found in the persistent storage medium. In fact, there is BasePage1 with the version 17, DeltaPage1 with the version 18, DeltaPage2 with the version 20 and BasePage2 with the version 22 in the persistent storage medium, the DeltaPage1 with the version 18 can include the tree node with the version 18 and the tree node with the version 19, and the DeltaPage2 with the version 20 can include the tree node with the version 20 and the tree node with the version 21. The BasePage1 with the maximum version 17, the version no greater than 20, the same page ID and the base page type can be loaded to the memory, i.e. the version of this base page meeting the condition is 17, and the DeltaPage1 with the version 18 and the DeltaPage2 with the version 20, the minimum version no less than the read version 20, the same page ID and the delta page type can be loaded to the memory after the version 17 of the BasePage1, and then the loaded base page and the delta page can be played back to obtain the memory page.

[0192] For the case 2, in detail, the loaded base page and the loaded incremental pages can be played back in order of page type and version to obtain the memory page. Still according to the above example, the loaded base page is BasePage1 with version 17, and the loaded incremental pages include DeltaPage1 with version 18 and DeltaPage2 with version 20. The incremental pages can be played back in order of version, i.e., on the basis of BasePage1 with version 17, the incremental pages are played back in the order of DeltaPage1 with version 18→ DeltaPage2 with version 20, to obtain the memory page. Since DeltaPage2 with version 20 includes tree nodes with version 20 and tree nodes with version 21, when playing back the pages in order to the incremental page with the maximum version less than the read version, i.e., playing back to DeltaPage1 with version 18 which is loaded, when playing back in order to the loaded incremental page with the maximum version 20, all the tree nodes in DeltaPage2 are not played back, but the tree nodes in the loaded incremental page with the maximum version are played back in order until the same as the read version, i.e., playing back the tree nodes with version 20 in DeltaPage2, so as to obtain the memory page.

[0193] In another example, it is assumed that an incremental page includes a tree node with a version, i.e., the version of the incremental page is the same as the version of the tree node included therein. The incremental page can be played back in order of version based on the base page to the incremental page with the same version as the read version, to obtain the memory page.

[0194] The reason why the incremental page is played back from the base page to obtain the memory page is that the blockchain has the feature of de-trust, and not only data but also verifiable data need to be provided. In detail, based on the leaf nodes and all related intermediate nodes of the global state in the base page, the incremental page is played back in order, i.e., the leaf nodes, intermediate nodes and root nodes in the base page are updated according to the leaf nodes, intermediate nodes and root nodes included in the incremental page in order of version, so that all the tree nodes in the restored memory page can maintain the hash anchoring relationship from the leaf nodes to the intermediate nodes to the root nodes, such as storing the correct hash value of the lower tree node in the branch node slot, so as to realize the data verifiability.

[0195] It is mentioned above that the version of the incremental page can be the lowest or highest version in one or more memory pages corresponding to the incremental page. In the above example, the case that the version of the incremental page is the lowest version in the multiple memory pages corresponding to the incremental page is given. The case that the version of the incremental page is the highest version in the multiple memory pages corresponding to the incremental page is introduced below.

[0196] For the aforementioned case 2, i.e. the case where no base page with the same version is found in the persistent storage medium, the base page with the maximum version no greater than the read version, the same page ID and the base page type can be loaded from the persistent storage medium to the memory. On this basis, the increment page with the minimum version no less than the read version, the same page ID and the increment page type can also be loaded from the persistent storage medium to the memory. For example, the version to be found is 20, and there is no memory page with the version 20 in the memory, and of course no base page with the same version 20 is found in the persistent storage medium. In fact, there is BasePage1 with the version 17, DeltaPage1 with the version 19, DeltaPage2 with the version 21 and BasePage2 with the version 22 in the persistent storage medium. The DeltaPage1 with the version 19 can include the tree node with the version 18 and the tree node with the version 19, and the DeltaPage2 with the version 21 can include the tree node with the version 20 and the tree node with the version 21. The BasePage1 with the maximum version 17, the version no greater than 20, the same page ID and the base page type can be loaded to the memory, i.e. the version of this base page meeting the conditions is 17, and the DeltaPage1 with the version 19 and the DeltaPage2 with the version 21, the minimum version 21 no less than the read version 20, the same page ID and the increment page type, can be loaded to the memory. Then the loaded base page and increment page are played back to obtain the memory page.

[0197] For the case 2, specifically, the loaded base page and the loaded incremental page can be played back in order of page type and version to obtain the memory page. Still according to the example, the loaded base page is BasePage1 with version 17, and the loaded incremental page includes DeltaPage1 with version 19 and DeltaPage2 with version 21, then the incremental page can be played back in order of version, i.e. on the basis of BasePage1 with version 17, in the order of DeltaPage1 with version 19→ DeltaPage2 with version 21, to obtain the memory page. Since DeltaPage2 with version 21 includes tree nodes with version 20 and tree nodes with version 21, when playing back the page in order to the incremental page with the maximum version less than the read version, i.e. to the loaded DeltaPage1 with version 19, when playing back in order to the loaded incremental page with the maximum version 21, all the tree nodes in the DeltaPage2 are not played back, but the tree nodes in the loaded incremental page with the maximum version are played back in order until the same as the read version, i.e. the tree nodes with version 20 in DeltaPage2 are played back, so as to obtain the memory page.

[0198] S194: reading the state in the leaf node.

[0199] As described before, the leaf node can be in the form of the data file as described before, or in the form of the KVDB as described before. For the form of the data file as described before, the leaf node can include the position index of the state value in the data file in the persistent storage medium and the hash value of the state value content. Thus, the position index contained in the leaf node can be obtained, the position index points to the position in the data file in the persistent storage medium, and then the value at the position of the data file in the persistent storage medium pointed by the position index can be loaded into the memory and the state data therein can be read. For the form of the KVDB, the hash value of the leaf node can be used to search in the cache, if not found in the cache, the state database module as shown in FIG. 7 can be searched, which can involve binary search in the sst of each Level, as described before, which will not be repeated here.

[0200] The application also provides a computer device, comprising:

[0201] a processor;

[0202] and a memory, wherein the memory has stored a program, and when the processor executes the program, the operation of any one of the above methods is performed.

[0203] 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 that implements the logical method flow can be easily obtained.

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

[0205] 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, electronic mail devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

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

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

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

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

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

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

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

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

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

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

[0216] The various embodiments described in this specification 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 various embodiments described in this specification 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.

[0217] The above description is only some 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 modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the specification shall be included in the scope of 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 of reading a world state of a tree structure, comprising: receiving a read state key and version; according to the state key and version, matching a version and a page ID in a page identification of a memory page in a lexicographic order, if the memory page includes at least two tree nodes, then continuing to match a version and a node ID of a tree node below an uppermost tree node in the lexicographic order until a leaf node is found; the page ID includes lexicographic content from a root node of the tree structure to an upper tree node in the memory page; the node ID includes lexicographic content from the root node to the tree node; reading a state in the leaf node. 2.The method of claim 1, wherein the reading a state in the leaf node comprises: obtaining a position index contained in the leaf node, the position index pointing to a position in a data file in a persistent storage medium; loading a value at the position pointed to by the position index in the persistent storage medium to a memory and reading a state data therein. 3.The method of claim 1, wherein, for a case that the memory page does not exist, the method further comprises: loading a corresponding base page from the persistent storage medium to the memory according to the page identification; restoring the loaded base page to the memory page; or, loading a corresponding base page and a delta page from the persistent storage medium to the memory according to the page identification; playing back the loaded base page and the delta page to obtain the memory page. 4.The method of claim 3, wherein the page identification of the base page and the delta page further includes a page type. 5.The method of claim 4, wherein the loading a corresponding base page from the persistent storage medium to the memory according to the page identification comprises: loading a base page with a maximum version no greater than the read version, a same page ID and a base page type from the persistent storage medium to the memory. 6.The method of claim 4, wherein the loading a corresponding base page and a delta page from the persistent storage medium to the memory according to the page identification comprises: loading a base page with a maximum version no greater than the read version, a same page ID and a base page type from the persistent storage medium to the memory; loading a delta page with a minimum version no less than the read version, a same page ID and a delta page type from the persistent storage medium to the memory after the version of the base page. 7.The method of claim 6, wherein the playing back the loaded base page and the delta page to obtain the memory page comprises: playing back the loaded base page and the delta page in a page type and version order to obtain the memory page with the read version. 8.The method of claim 7, wherein the playing back the loaded base page and the delta page in a page type and version order to obtain the memory page comprises: playing back the delta page in a version order to a delta page equal to the read version based on the base page to obtain the memory page. 9.The method of claim 7, wherein the playing back the loaded base page and the delta page in a page type and version order to obtain the memory page comprises: ​ Based on the base page, replaying the delta pages in version order to a maximum delta page less than the read version, and continuing to replay tree nodes in the loaded maximum delta page in order until the same as the read version, resulting in a memory page.

10. A computer device comprising: a processor; and a memory having stored therein a program, wherein the program, when executed by the processor, carries out the operations of any one of claims 1-9.

Images