Management method of state data in block chain system and block chain node

Abstract

A method for managing state data in a block chain system and a block chain node, the block chain system organizes state data corresponding to a block N through a tree structure divided into a plurality of logic pages, the method comprises: receiving an update request initiated for a first state variable due to execution of a transaction sequence of a block N + 1; storing an update record corresponding to the update request in a first memory page corresponding to a first logic page to which a first leaf node belongs, wherein the first leaf node corresponds to a first state variable; in response to completion of execution of the transaction sequence, determining a target value of the first state variable in the state data corresponding to the block N + 1 according to an update record in a second memory page, the second memory page being the first memory page or a logic page split / shrunk on the basis of the first logic page; and writing the target value into the persistent storage medium, and updating the position information of the value of the first state variable in the persistent storage medium into the position information of the target value in the persistent storage medium in the first leaf node.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of computer technology, and particularly relate to a method for managing state data in a blockchain system and a blockchain node. Background Art

[0002] A blockchain system is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chain-like data structure in a sequential connection manner according to the time sequence, and a distributed ledger that is tamper-proof and non-forgeable is guaranteed by cryptographic means. Due to the characteristics of decentralization, information immutability, and autonomy of the blockchain system, the blockchain system has received more and more attention and applications. Summary of the Invention

[0003] The purpose of the present invention is to provide a method for managing state data in a blockchain system and a blockchain node, which can ensure the atomicity of the state data version update process in the blockchain system and improve the access efficiency of the state data in the blockchain system.

[0004] In a first aspect, a method for managing state data in a blockchain system is provided. The blockchain system organizes the state data corresponding to block N through a tree structure divided into multiple logical pages. A key of a state variable is stored in a leaf node of the tree structure, and the position information of the value of a state variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure. The method includes: receiving an update request initiated for a first state variable due to the execution of the transaction sequence of block N+1; storing an update record corresponding to the update request in a first memory page corresponding to a first logical page to which the first leaf node belongs, and the key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure; in response to the completion of the execution of the transaction sequence, determining a target value of the first state variable in the state data corresponding to block N+1 according to the update record related to the first state variable in a second memory page, where the second memory page is the first memory page, or the second memory page corresponds to a logical page obtained by splitting or shrinking on the basis of the first logical page; writing the target value to the persistent storage medium, and in the first leaf node, updating the position information of the value of the first state variable in the persistent storage medium to the position information of the target value in the persistent storage medium.

[0005] Second aspect, a blockchain node in a blockchain system is provided. The device includes: the blockchain system organizes the state data corresponding to block N through a tree structure divided into multiple logical pages. A key of a state variable is stored in a leaf node of the tree structure, and the position information of the value of a state variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure. The blockchain node includes: a receiving unit configured to receive an update request initiated for a first state variable due to executing the transaction sequence of block N+1; a record processing unit configured to store an update record corresponding to the update request in a first memory page corresponding to a first logical page to which the first leaf node belongs, and the key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure; a state determination unit configured to, in response to completing the execution of the transaction sequence, determine a target value of the first state variable in the state data corresponding to block N+1 according to the update record related to the first state variable in a second memory page, where the second memory page is the first memory page or the second memory page corresponds to a logical page split or shrunk based on the first logical page; a storage processing unit configured to write the target value to the persistent storage medium, and in the first leaf node, update the position information of the value of the first state variable in the persistent storage medium to the position information of the target value in the persistent storage medium.

[0006] Third aspect, a computing device is provided, including a memory and a processor. A computer program is stored in the memory. When the processor executes the computer program, the method described in the first aspect is implemented.

[0007] Fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computing device, the computing device executes the method described in the first aspect or the second aspect.

[0008] In the technical solution provided by the embodiments of this specification:

[0009] During the process of executing the transaction sequence included in block N+1, the update records corresponding to the update requests initiated for the relevant state variables due to executing the transaction sequence included in block N+1 are cached through relevant memory pages, and the tree nodes corresponding to the relevant state variables are not directly updated; when it is necessary to query the updated value of the state variable, the updated value of the state variable may be obtained according to the respective update records related to the state variable cached in the relevant memory pages, thereby ensuring the atomicity of the state data version update process in the blockchain system and improving the access efficiency of the state data in the blockchain system. Description of the Drawings

[0010] To more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0011] Figure 1 It is an architecture diagram of a blockchain system exemplarily provided in the embodiments of this specification;

[0012] Figure 2 It is one of the schematic diagrams of a tree structure exemplarily provided in the embodiments of this specification;

[0013] Figure 3 It is a schematic diagram of generating an incremental page and a base page for a logical page including multiple tree nodes exemplarily provided;

[0014] Figure 4 It is a flowchart of a method for managing state data in a blockchain system provided in the embodiments of this specification;

[0015] Figure 5 It is another schematic diagram of a tree structure exemplarily provided in the embodiments of this specification;

[0016] Figure 6 It is yet another schematic diagram of a tree structure exemplarily provided in the embodiments of this specification;

[0017] Figure 7 It is a schematic diagram of the structure of a blockchain node provided in the embodiments of this specification. Detailed implementation manners

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all of them. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0019] Figure 1 It is an architecture diagram of a blockchain system exemplarily provided in the embodiments of this specification. The blockchain system may include N blockchain nodes, where Figure 1 8 blockchain nodes such as Node 1 - Node 8 are exemplarily shown. The connections between the nodes schematically represent the connections between the nodes, and the aforementioned connections are used to support data transmission between different nodes.

[0020] A blockchain system can provide the function of smart contracts. Smart contracts in a blockchain system are contracts that can be triggered and executed by transactions. Smart contracts can be defined in the form of contract code. Invoking a smart contract in a blockchain system is to initiate a transaction pointing to the contract address of the smart contract, enabling each node in the blockchain system to run the corresponding contract code distributively.

[0021] In various blockchain systems that introduce smart contracts, accounts can generally be divided into two types:

[0022] Contract account (CA): mainly used to store the contract code of the corresponding smart contract and the values of the state variables defined in the smart contract, and usually can only be activated by being called by an external account;

[0023] Externally owned account (EOA): an account registered by an external user in the blockchain system.

[0024] The design of external accounts and contract accounts is actually a mapping from account addresses to account states. The account state of any account usually includes fields such as nonce, balance, storageRoot, and codeHash. Among them, nonce and balance exist in both external accounts and contract accounts, and the codeHash and storageRoot attributes are generally only valid for contract accounts.

[0025] More specifically, for an external account, the value of nonce represents the number of transactions sent from the relevant account address; for a contract account, the value of nonce can represent the number of smart contracts created by the relevant account address. The value of balance represents the number of a certain digital resource / token owned by the relevant account address. The value of storage root is the hash value of the root node of a tree structure, such as an MPT tree, which is used to organize / manage the storage of the state variables of the relevant contract account. The value of codeHash represents the hash value of the contract code of the relevant smart contract. For an external account, since it does not include a smart contract, the values of the storageRoot and CodeHash fields can generally be an empty string / all 0 strings.

[0026] It should be noted that MPT, whose full name is Merkle Patricia Tree, is a tree structure that combines Merkle Tree and Patricia Tree (a more space-saving trie). Among them, the Merkle tree algorithm can calculate a Hash value for multiple transactions respectively, and then connect them in pairs and calculate the Hash again until the top-level Merkle root. In some blockchain systems, an improved MPT tree is usually adopted, such as a 16-ary tree structure, which is usually simply referred to as the MPT tree.

[0027] The system data that needs to be persistently stored in the blockchain system can be divided into two parts: block data and state data.

[0028] The block data includes one or more blocks in ascending order of block height (or block number). A single block can include a block header and a block body. The block header can include the block hash previous_Hash (or parent hash) of the previous block, timestamp Timestamp, block number BlockNum, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, and nonce, etc. The block body can include a transaction set and a receipt set.

[0029] A transaction in the blockchain system refers to a task unit that is executed and recorded in the blockchain system. A single transaction usually includes a sending field (From), a receiving field (To), and a data field (Data). The From field includes the account that initiates the transaction (i.e., the sender account), and the To field may include another account involved / pointed to by the transaction.

[0030] For any Nth block, multiple transactions included in the transaction set belonging to the Nth block can be executed in sequence according to the state data with block number (or version number) N - 1 to obtain the execution results of the multiple transactions. Then, the state data with version number N - 1 can be updated according to the execution results of the multiple transactions to obtain the state data with version number k.

[0031] In a blockchain system, state data can be managed through a tree structure, and different versions of state data will correspond to different tree structures. The location information of the variable value of a state variable is stored in a leaf node of the tree structure in a persistent storage medium, and the key of the state variable is stored in the directed path from the root node to the leaf node of the tree structure; the aforementioned state variable can be the account address of a contract account / external account, or can be a state variable in a smart contract. The tree structure can include, for example, MPT (Merkle Patricia Tree) or SMT (Sparse Merkle Tree), etc.

[0032] The tree structure for managing state data can include a state trie, and the hash value of the root node of the state trie is stored in State_Root in the block header. The location information of the account state of an external account / contract account is stored in a leaf node of the state trie, and in the directed path from the root node to a leaf node of the state trie, the account address of an external account / contract account, or part or all of the hash value calculated based on the account address is stored. As mentioned above, the account state of a single account usually can include fields such as Nonce, Balance, Storageroot, CodeHash, etc. Nonce and Balance exist in both external accounts and contract accounts, and CodeHash and Storage root are generally only valid for contract accounts.

[0033] The tree structure for managing state data can also include a storage trie. The hash value of the root node of the storage trie is stored in the storageroot field of the contract account corresponding to the relevant smart contract, so as to lock the contract state of the smart contract under the relevant contract account through the hash value. Similarly, the location information of the variable value of a state variable defined in the smart contract is stored in a leaf node of the storage trie, and in the directed path from the root node to a leaf node of the storage trie, the state key of a state variable defined in the relevant smart contract is stored. That is, part of the information in the directed path from the root node to the leaf node of the storage trie can be arranged in order to form the key of a state variable defined in the relevant smart contract, and the variable value of the state variable is stored in the location information in the persistent storage medium in this leaf node.

[0034] Based on the foregoing tree structure, the separation of data and indexes can be achieved in the blockchain system, 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 variable values of state variables (including account addresses or state variables in smart contracts) are stored in the data files; the index entries pointing to the data files are stored in the index files. The implementation principle is as follows: write the data content (the variable value of the state variable or the key-value pair of the state variable) into the data file, and record the location information of the data content in the data file (such as file identifier, address offset, data length, etc.); furthermore, create an index entry in the index file, and the index entry contains the retrieval key related to the data content and the foregoing location information. In this way, when querying the data content, after obtaining the retrieval key of the data content, the index entry containing the retrieval key can be found in the index file, the location information of the data content can be obtained from the index entry, and then the actual data content can be read from the corresponding data file according to the location information.

[0035] Exemplarily, referring to Figure 2As shown. For the tree structure corresponding to the state data with version number / block number N, in the upper-level MPT, that is, in the state trie, for the leaf node A1, in the root node A8 (Extension Node), the a7 of the shared nibble - slot 1 of the intermediate node A7 (Branch Node) - the 1335 of the key-end in the leaf node A1 are combined in sequence to form the key of a certain state variable: a711335. The value of this state variable is "Nonce=n1, Balance=45.0ETH". The data file for storing "Nonce=n1, Balance=45.0ETH" is file 5, the file identifier of file 5 is "5", the address offset of "Nonce=n1, Balance=45.0ETH" in file 5 is 600, and the data length of "Nonce=n1, Balance=45.0ETH" is 100. Then, in the leaf node A1, for example, through the locatione field, the location information (5, 600, 100) of the value "Nonce=n1, Balance=45.0ETH" in the persistent storage medium can be stored. Similar to the principle of the leaf node A1, in the leaf node A2, through the location field, the location information (3, 805, 150) of the value "Nonce=n2, Balance=1.00WEI" of the state variable with key a77d337 in the persistent storage medium can be stored; in the leaf node A3, through the location field, the location information (2, 100, 180) of the value "Nonce=n3, Balance=1.1ETH" of the state variable with key a7f9365 in the persistent storage medium can be stored; in the leaf node A4, through the location field, the location information P1 of the value "Nonce=n4, Balance=0.12ETH, CodeHash=c1, Storage root=s1" of the state variable with key a77d397 in the persistent storage medium can be stored. s1 can be the hash value H(A10) of the tree node A10, that is, the hash value of the root node A10 of the next-level tree. It should be noted that Figure 1 In order to illustrate the relationship between the next-level MPT and the upper-level MPT, in the leaf node A4, the variable value "Nonce=n4, Balance=0.12ETH, CodeHash=c1, Storage root=s1" is exemplified. In fact, in the leaf node A4, the location information P1 should be stored through the locaotion field. However Figure 2It is not shown in []. Among them, the leaf nodes A1, A2, and A3 correspond to external accounts, and the leaf node A4 corresponds to a contract account. For the contract account, it contains the next-level MPT, forming a Storage Trie, which is used to store the states of the state variables in the smart contract corresponding to the contract account.

[0036] As Figure 2 shown in the example of [], in the next-level MPT (i.e., storage trie), for the leaf node A11, through the slot 3 in the root node A10 (Branch Node) - the 35b2e4 of key-end in the leaf node A11, they are sequentially combined to form the key of a certain state variable: 335b2e4. The value of this state variable is "Zhang San_A = 20". "Zhang San_A = 20" means, for example, that the share of digital assets of type A defined in the contract belonging to Zhang San is 20, that is, the balance of Zhang San's type A assets is 20. The data file used to store the value "Zhang San_A = 20" is file 2, the file identifier of file 2 is "2", the address offset of "Zhang San_A = 20" in file 2 is 7500, the data length of the value "Zhang San_A = 20" is 210. In the leaf node A11, for example, through the locatione field, the location information (2, 750, 210) of "Zhang San_A = 20" in the persistent storage medium can be stored. Similar to the principle of the leaf node A11, in the leaf node A12, through the location field, the location information (3, 350, 210) of the value "Li Si_B = 50" of the state variable with key 7c25988 in the persistent storage medium can be stored. "Li Si_B = 50" means, for example, that the share of digital assets of type B defined in the contract belonging to Li Si is 50, that is, the balance of Li Si's type B assets is 50; in the leaf node A15, through the location field, the location information (5, 760, 140) of the value "storedData = s" of the state variable with key fa6be33 in the persistent storage medium can be stored; in the leaf node A16, through the location field, the location information (5, 170, 210) of the value "Wang Wu_A = 35" of the state variable with key fa99365 in the persistent storage medium can be stored.

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

[0038] In the above node composition, the hash value of the overall content of the next tree node is filled into the corresponding position of the previous tree node.

[0039] Based on the tree structure of the above example, the key-value pairs of the tree nodes in the tree structure can be obtained. The key of a tree node can be the result obtained by performing a hash operation on the overall content of the tree node (i.e., the value of the tree node). In this way, the key-value pairs of the tree nodes can be used as index entries and stored in the corresponding index file. For example, for the Figure 2 example in the previous text, Figure 2 the key-value pairs of the tree nodes of the example of the tree structure in the index file can be stored as index entries as shown in Table 1 below.

[0040]

[0041]

[0042] Table 1

[0043] In Table 1 above, 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 is obtained, and this root hash is locked into the state root field of the block header. Assume that the k-v pairs in Table 1 are saved on disk as index entries in the index file and the LSM structure is adopted. In this way, after querying the root node of the state trie and matching the key of the state variable to be searched with the shared nibble(s) field (for Extension Node) or slot (for Branch Node) of the root node from the beginning, the hash of the next layer of the tree node can be read from the matching position, and then the next InternalNode pointed to by this hash value can be found; after unlocking the Internal Node, continue to match the remaining part of the key of the state variable to be read from front to back in it. If there is a match, after reading the hash value from the matching position, jump to the next-level tree node pointed to by this hash value. This process is continuously repeated, unlocking the Internal Node level by level and matching the remaining part of the key of the state variable to be read from front to back. The matched hash value is used as the basis for the next search for the intermediate node or leaf node until the Leafnode is matched, so as to read the location information of the value of the state variable in the persistent storage medium from the Leaf node. Exemplarily, for example, finally, the content in the value of the leaf node A11, that is, "prefix:2,Key-end:35b2e4,location:(2,750,210)", can be loaded into the memory, so as to obtain the location information "2,750,210" of the value "Zhang San_A = 20" of the state variable with the key 335b2e4 in the persistent storage medium. Then, according to the location information "2,750,210", the data content between the 750KB and 960KB in File 2 can be read, and finally the value "Zhang San_A = 20" of the state variable with the key 335b2e4 can be obtained.

[0044] When the key-value pair of a tree node is directly used as an index entry, the key of the tree node is used as the retrieval key. Alternatively, the key-value pair of the tree node may not be directly used as an index entry. For example, for any tree node, the key of the state variable stored in the directed path from the root node to the tree node or a component of the key of the state variable, that is, the key of the lexicographical content distribution from the root node through the intermediate nodes to the tree node (hereinafter referred to as the node ID or node ID), is combined with the version number / block number of the state data to form a retrieval key. The position information of the value of the state variable included in the value of the tree node in the persistent storage medium is combined with the retrieval key to obtain an index entry corresponding to the tree node.

[0045] Based on the tree structure of the foregoing example, the entire tree structure, i.e., the Merkle trie, can also be divided into multiple logical pages. Specifically, according to the node association relationship of the tree structure, several adjacent tree nodes above and below are aggregated into a LogicalPage. For example, 256 child nodes with 2 levels and 16 branches of the trie are aggregated into a LogicalPage. Among them, there are multiple layers of LogicalPages from the root node to the leaf node of the tree structure, and there are parent-child and sibling relationships between the LogicalPages, thus forming a complete tree structure. In this way, at least one tree node is included in a logical page, the tree nodes included in different logical pages are different, and the tree node corresponding to the currently latest version of the state data can be maintained in the logical page.

[0046] Such as Figure 3As shown, within each LogicalPage, a memory page (MemoryPage) can be maintained to represent the content of all tree nodes corresponding to the current latest version of the logical page. Further, the content of the tree nodes maintained by the logical page can be generated into a base page (BasePage) and a delta page (DeltaPage) according to consecutive version updates based on generation / modification actions. Specifically, the BasePage and DeltaPage are generated according to generation / modification actions. For example, for consecutive state changes, such as in version N including state variables a = 5, b = 8, c = 3, the a = 5, b = 8, c = 3 can be the content in the base page BasePage. For a = 6 in version N + 1 and a = 8 in version N + 2, assuming b and c remain unchanged, the a = 6 in version N + 1 and the a = 8 in version N + 2 can be used as the DeltaPage, such as DeltaPage1, on the basis of this BasePage, and the cases where b and c remain unchanged are not included in DeltaPage1. For a = 11 in version N + 3 and a = 15 in version N + 4, the a = 11 in version N + 3 and the a = 15 in version N + 4 can be used as the DeltaPage, such as DeltaPage2, on the basis of this BasePage. Again, assuming b and c remain unchanged, b and c are not included in DeltaPage2, and so on. It should be noted specifically that the BasePage and DeltaPage can be the smallest units of the in-memory structure of the tree structure. In addition, the BasePage can be the smallest unit of disk persistence of the tree structure. On this basis, the DeltaPage can also be the smallest unit of disk persistence of the tree structure.

[0047] For the BasePage, a new BasePage can be generated every time the state is modified a predetermined number of times (such as m times). As in the previous example, for the state variable a = 5 in version N, the a = 5 can be the content in the base page BasePage1. For a = 6 in version N + 1 and a = 8 in version N + 2, the a = 6 in version N + 1 and the a = 8 in version N + 2 are used as the delta page DeltaPage1 on the basis of this BasePage. For a = 11 in version N + 3 and a = 15 in version N + 4, the a = 11 in version N + 3 and the a = 15 in version N + 4 can be used as the delta page DeltaPage2 on the basis of this BasePage. For a = 20 in version N + 5, assuming the modification reaches the predetermined number of times 5, the value a = 20, as well as b = 8 and c = 3, can be the content in the new base page BasePage2.

[0048] For DeltaPage, it describes several version modifications of LogicalPage. Multiple modifications are aggregated into a set. For example, a DeltaPage is generated every M modifications, and a new DeltaPage is created to collect subsequent version modification operations. As mentioned above, 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 are used as the incremental page DeltaPage1 based on this BasePage. For a = 11 in version N + 3 and a = 15 in version N + 4, then a = 11 in version N + 3 and a = 15 in version N + 4 can be used as the incremental page DeltaPage2 based on this BasePage. It can be seen that a DeltaPage is generated every 2 modifications.

[0049] For each modification of BasePage and DeltaPage, corresponding dirty data is generated in memory. Usually, when the memory occupied by BasePage and DeltaPage reaches a predetermined share, BasePage and DeltaPage are batch disk-persisted, so as to avoid persisting all dirty data for each modification and continuously occupying memory and CPU resources.

[0050] The previous text described DeltaPage and BasePage in terms of the changes in the values of the state variables in LogicalPage. However, what is maintained in the logical page is the content of the tree nodes. According to the continuous version updates of the state data, DeltaPage and BasePage are generated according to the generation / modification behavior. What is described in DeltaPage and BasePage are still the key-value pairs of the tree nodes associated with the version numbers.

[0051] Similar to the node ID, the logical page can have a page ID. The page ID can be the lexicographical content from the root node to the topmost tree node in this logical page (i.e., the memory page), that is, the page ID can be the key of the state variable or a component of the key of the state variable with the lexicographical content distribution from the root node through the intermediate nodes to the topmost tree node in this LogicalPage.

[0052] DeltaPage and BasePage can also have versions. Generally, a BasePage corresponds to a memory page and contains all the tree nodes in a memory page, including the global state variables. Therefore, it can have the same version as the corresponding memory page. A DeltaPage can correspond to one or more memory pages and contains the tree nodes in one or more consecutive versions of the memory pages that have changed relative to the previous adjacent DeltaPage / BasePage, including the changed state variables, which are generally not global state variables. Therefore, the version of the delta page can be the lowest or highest version among the one or more memory pages it corresponds to.

[0053] Exemplarily, a BasePage with version 4 contains state variables a = 1, b = 2, c = 3, as well as the corresponding intermediate nodes and root nodes. In a DeltaPage generated after this BasePage, it can include a = 2 with version 5 and the corresponding intermediate nodes and root nodes, a = 1 with version 6 and the corresponding intermediate nodes and root nodes, and b = 4 with version 7 and the corresponding intermediate nodes and root nodes. In this case, although a = 1 with version 6 is the same as the state variable a = 1 contained in this BasePage, it is different from a = 2 with version 5 of the previous adjacent one. Therefore, a = 1 with version 6 and the corresponding intermediate nodes and root nodes are also included in the DeltaPage. In addition, for the latter DeltaPage, that is, the DeltaPage after the DeltaPage corresponding to versions 5, 6, and 7, for example, the DeltaPage containing tree nodes with versions 7, 8, and 9, it is actually relative to the immediately previous DeltaPage and the tree nodes of the versions in turn. Thus, the tree nodes with versions 5, 6, and 7 respectively correspond to the memory pages with versions 5, 6, and 7. The DeltaPage containing the tree nodes with versions 5, 6, and 7 can have its own version as 5 or 7, that is, it can be the lowest or highest version among the corresponding multiple memory pages.

[0054] Moreover, a page type can be set for the DeltaPage and the BasePage respectively to distinguish between the DeltaPage and the BasePage.

[0055] Combined with the index entry determination based on tree nodes described above, for example, using the key-value pairs of tree nodes as index entries. When persisting the aforementioned BasePage and DeltaPage, in fact, an index file corresponding to the BasePage / DeltaPage can be specifically stored in the persistent storage medium. The index file can include the key-value pairs of all tree nodes in the BasePage / DeltaPage. Moreover, the page ID of the logical page corresponding to the BasePage / DeltaPage, the page type of the BasePage / DeltaPage, and the version of the BasePage / DeltaPage can form the file identifier of the index file corresponding to the BasePage / DeltaPage. In addition, based on the multiple key-value pairs (i.e., index entries) included in the index file, the data file usage information of the index file can be determined, and the data file usage information can be stored in the corresponding index file.

[0056] When storing state data in a data-separated-from-index manner, it means that for the value of a certain state variable in the state data of any version, after writing it into the persistent storage medium, the location information of the value of the state variable in the persistent storage medium can be obtained, and then the tree node corresponding to the state variable can be updated according to the location information.

[0057] During the execution of any block, such as block N + 1, in the blockchain system, the values of the same or different state variables may be requested to be accessed in the state data corresponding to block N multiple times. During this process, if the tree node corresponding to the state variable is directly updated when receiving an update request for the state variable, it may be necessary to frequently access the persistent storage medium, affecting the access efficiency of the state data; if the tree node corresponding to the state variable is not directly updated when receiving an update request for the state variable, the problem of how to support correct access to the updated value of the state variable in the subsequent process needs to be solved.

[0058] In view of this, embodiments of the present specification provide a method for managing state data in a blockchain system, a blockchain node, a computing device, and a computer-readable storage medium. The blockchain system organizes the state data corresponding to block N through a tree structure divided into multiple logical pages. A key of a state variable is stored in a leaf node of the tree structure, and the position information of the value of a state variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure; when an update request for a first state variable is received due to the execution of the transaction sequence of block N + 1, an update record corresponding to the update request can be stored in the first memory page corresponding to the first logical page to which the first leaf node belongs, without directly updating the first leaf node according to the update request, where the key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure; when the execution of the transaction sequence of block N + 1 is completed, the target value of the first state variable in the state data corresponding to block N + 1 is determined according to the update record related to the first state variable in the second memory page, and the second memory page is the first memory page, or the second memory page corresponds to a logical page obtained by splitting or shrinking on the basis of the first logical page; finally, the target value is written to the persistent storage medium, and in the first leaf node, the position information of the value of the first state variable in the persistent storage medium is updated to the position information of the target value in the persistent storage medium.

[0059] In this way, during the process of executing the transaction sequence included in block N + 1, the update records corresponding to the update requests for the relevant state variables initiated due to the execution of the transaction sequence included in block N + 1 are cached through the relevant memory pages, and the tree nodes corresponding to the relevant state variables are not directly updated; when it is necessary to query the updated value of the state variable, the updated value of the state variable may be obtained according to the respective update records related to the state variable cached in the relevant memory pages, so as to ensure the atomicity of the state data version update process in the blockchain system and improve the access efficiency of the state data in the blockchain system.

[0060] Figure 4 It is a flowchart of a method for managing state data in a blockchain system provided in an embodiment of the present specification.

[0061] The blockchain system organizes the state data corresponding to block N through a tree structure divided into multiple logical pages. A key of a state variable is stored in a leaf node of the tree structure, and the position information of the value of a state variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure. Exemplarily, referring to Figure 5 as shown, the tree structure for organizing the state data corresponding to block N, for example, includes Figure 5The tree nodes A1 to A13 shown in the figure are divided into multiple logical pages such as page 0, Page 1, leaf Page 2, leaf Page 3, leaf Page 11, and leaf Page 12 according to a certain rule. Among them, the tree nodes A4, A5, A10, A11, A12, and A13 are all leaf nodes. In node A4, the location information of the value of the state variable with key a7x1b2c4d3e5 in the persistent storage medium can be stored. In node A10, the location information of the value of the state variable with key a7x1f1c1d1e1 in the persistent storage medium can be stored. In node A11, the location information of the value of the state variable with key a7x1f1c1d13a in the persistent storage medium can be stored. In node A12, the location information of the value of the state variable with key a7x1f1c1d146 in the persistent storage medium can be stored. In node A13, the location information of the value of the state variable with key a7x1f15ad2e4 in the persistent storage medium can be stored. In node A5, the location information of the value of the state variable with key a7y233c5d6e5 in the persistent storage medium can be stored.

[0062] This method exemplarily describes the process of updating the tree structure in a blockchain system's blockchain node based on the tree structure for organizing the state data corresponding to block N and due to the execution of the transaction sequence included in block N + 1.

[0063] Refer to Figure 4 As shown, this method may include, but is not limited to, some or all of the following steps S401 to step S419.

[0064] Step S401, receive an update request for the first state variable due to the execution of the transaction sequence of block N + 1.

[0065] When the transaction execution module of a blockchain node, such as a blockchain node, executes the transaction sequence included in block N + 1, it may initiate multiple access requests for one or more state variables multiple times. In other words, the transaction execution module of the blockchain node may initiate multiple access requests for the state data of the blockchain system at the current moment due to the execution of the transaction sequence included in block N + 1. The types of access requests usually include two types: query requests and update requests. Query requests are used to request the value of a certain state variable at the current moment, and update requests are used to request writing the value of a certain state variable at the current moment.

[0066] Exemplarily, the transaction sequence includes Tx1, Tx2, Tx3, and Tx4. During the execution of transaction Tx1, a query request may be initiated to request the variable value of the state variable with key a7x1f1c1d1e1 (hereinafter denoted as k10) at the current moment, and then an update request is initiated to request writing the new variable value of k10 (denoted as v1); during the execution of transaction Tx2, a query request may be initiated to request the variable value of the state variable with key a7x1f15ad2e4 (hereinafter denoted as k13) at the current moment, and then an update request is initiated to request writing the new variable value of k13 (denoted as v3); during the execution of transaction Tx3, a query request may be initiated to request the variable value of k10 at the current moment (i.e., v1), and then an update request is initiated to request writing the new variable value of k10 (denoted as v2); during the execution of transaction Tx4, an update request may be initiated, and this update request is used to request deleting the state variable with key a7x1f1c1d146 (denoted as k12).

[0067] For query requests and update requests, they are usually sent by the transaction execution module of the blockchain node to the storage processing module.

[0068] In this article, the process of how to process update requests in the storage processing module of the blockchain node will be described exemplarily first.

[0069] After receiving the update request, it will first query in the tree structure whether there is a first leaf node. The key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure. If the first leaf node already exists in the tree structure, the following step S405 can be directly executed; otherwise, step S403 needs to be executed first, and then step S405.

[0070] In step S403, when the first leaf node does not exist in the tree structure, determine the first logical page that allows the addition of the first leaf node, and initialize the first leaf node in the first memory page corresponding to the first logical page.

[0071] The target tree node that allows the first leaf node to be its child node can be determined from the tree structure. When the logical page to which the target tree node belongs is a leaf page, the logical page to which the target tree node belongs can be determined as the first logical page that allows the addition of the first leaf node; when the logical page to which the target tree node belongs is not a leaf page, a new first logical page can be added.

[0072] Exemplarily, refer to Figure 5As shown below. Here, it is assumed that when transaction Tx2 is executed, the value of the state variable with key a7x1f15ad2e4 is not included in the state data of the blockchain system at the current moment. When the storage processing module receives the update request initiated by the transaction execution module due to the execution of transaction Tx2, and this update request is used to request writing the value v3 of the state variable with key a7x1f15ad2e4, the leaf node A13 may not exist in the tree structure. In this case, first, according to the key in the update request, that is, "a7x1f15ad2e4", the target tree node that allows the leaf node A13 to be its child node can be determined (including newly added or selected) in the tree structure. For example, the tree node A8 is determined as the target tree node. Since the logical page Page 1 to which the tree node A8 belongs is not a leaf page, a logical page Leaf page12 as a leaf page can be newly added, and the node A13 is initialized in the newly added logical page Leaf page 12. In the initialized node A13, since the value v3 of the state variable with key a7x1f15ad2e4 has not been stored in the persistent storage medium, the location information of the value of the state variable with key a7x1f15ad2e4 stored in the node A13 in the persistent storage medium is usually empty (i.e., Null).

[0073] Similarly, here it is assumed that when transaction Tx1 is executed, the value of the state variable with key a7x1f1c1d1e1 is not included in the state data of the blockchain system at the current moment. When the storage processing module receives the update request initiated by the transaction execution module due to the execution of transaction Tx1, and this update request is used to request writing the value v1 of the state variable with key a7x1f1c1d1e1, the leaf node A10 may not exist in the tree structure. In this case, the tree node A9 may be determined as the target tree node. Since the logical page Leaf page 11 to which the tree node A9 belongs is a leaf page, the logical page Leafpage 11 to which the tree node A9 belongs can be determined as the first logical page that allows the leaf node A10 to be added, and the tree node A10 is initialized in Leaf page 11.

[0074] Step S405, store the update record corresponding to the update request in the first memory page corresponding to the first logical page to which the first leaf node belongs. The key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure.

[0075] The update type corresponding to the update request can be indicated by a preset character in the update record. For example, the character Put is used to represent that the update type is writing the value of the state variable, and the character del is used to represent deleting the state variable. The key of the state variable to be updated can be indicated in the update record, and in addition, it may also include the value of the state variable expected to be written.

[0076] Continuing with the above example, for the update request initiated by the execution of transaction Tx1, the update record Put[k10, v1] can be stored in the data structure page log (i.e., Page log) maintained by the memory page corresponding to Leaf page 11; for the update request initiated by the execution of transaction Tx2, the update record Put[k13, v3] can be stored in the data structure page log (i.e., Page log) maintained by the memory page corresponding to Leaf page 12; for the update request initiated by the execution of transaction Tx3, the update record Put[k10, v2] can be stored in the data structure page log (i.e., Page log) maintained by the memory page corresponding to Leaf page 11; for the update request initiated by the execution of transaction Tx4, the update record del[k12] can be stored in the data structure page log (i.e., Page log) maintained by the memory page corresponding to Leaf page11.

[0077] It can be understood that multiple update records stored in the same memory page can be arranged in sequence according to the time sequence in which the update records are stored in the memory page, so as to determine the variable value of the relevant state variable at the current moment based on the update records.

[0078] Step S407: Mark the first memory page as a dirty child page in the memory page corresponding to the parent logical page of the first logical page.

[0079] Continuing with the above example, after Put[k10, v1] is stored in the memory page corresponding to Leaf page 11, Leaf page 11 can be marked as a dirty child page in the data structure Dirty child pages maintained by the memory page corresponding to Page 1, the parent logical page of Leaf page 11. Similarly, after Put[k13, v3] is stored in the memory page corresponding to Leaf page 12, Leaf page 12 can be marked as a dirty child page in the data structure Dirty child pages maintained by the memory page corresponding to Page 1.

[0080] When the aforementioned step 403 is executed, the following step S409 may also be executed.

[0081] Step S409, determining whether the first logical page satisfies a split condition. The split condition may generally be preset, for example, the split condition may include but is not limited to the cumulative number of leaf nodes included in the first logical page reaching a certain preset number.

[0082] If the first logical page meets the split condition, then continue to execute step S409, otherwise the current process ends.

[0083] Step S411: Divide the first leaf node into the new logical page obtained by splitting the first logical page, and migrate the update record from the first memory page to the memory page corresponding to the new logical page.

[0084] Considering that the situation of shrinking the logical page will be introduced later, and the process of splitting the logical page is essentially corresponding to the process of shrinking the logical page. For the convenience of understanding the splitting process, the shrinking process will be introduced in detail later and then the splitting process will be introduced.

[0085] Step S413: When the update request is used to request the deletion of the first status variable, delete the first leaf node from the first logical page, and determine whether the first logical page after deleting the first leaf node meets the shrinking condition.

[0086] The shrinking condition can usually be set in advance. Exemplarily, the shrinking condition can include, for example, but not limited to, that among multiple logical pages having the same parent logical page as the first logical page, the cumulative number of leaf nodes included is less than a preset number.

[0087] If the first logical page meets the shrinking condition, execute step S415; otherwise, end the current process.

[0088] Step S415: Shrink the leaf nodes in the first logical page into the parent logical page of the first logical page, and migrate the update records in the first memory page to the memory page corresponding to the parent logical page of the first logical page.

[0089] Exemplarily, referring to Figure 5 and Figure 6 as shown, when deleting node A12 from Leaf page 11, it may cause the cumulative number of leaf nodes included in Leaf page 11 and Leaf page 12 with Page 1 as the parent logical page to be less than a certain preset threshold, resulting in Leaf page 11 and Leaf page 12 meeting the shrinking condition. In this case, the leaf nodes in Leaf page11 and Leaf page 12 can be shrunk into Page 1, and the update records recorded in Leaf page 11 and Leaf page 12 can be migrated to the memory page corresponding to Page 1. After shrinking, the node relationships in Page 1, Leafpage 11, and Leaf page 12 will be reconstructed, for example, reconstructed into the node relationship shown in Figure 6 to optimize the tree structure.

[0090] The shrinking process and splitting process of the logical page are corresponding. For example, here it is assumed that due to receiving a certain update request in Figure 6Adding / initializing node A12 in the shown Page 1 causes the cumulative number of leaf nodes included in Page 1 to reach a preset threshold, that is, it causes Figure 6 the shown Page 1 to meet the splitting condition, and assuming Figure 6 in the example of page 1, del[k12] is not stored, but other update records related to node A12 such as Put[k12, v4] are stored. In this case, corresponding to the shrinking process of the logical page in the foregoing example, Figure 6 Page 1 in the example may split, for example, split into Figure 5 the logical page Page 1, Leaf page 11, and Leaf page 12 in the example; Put[k10, v1], Put[k10, v2], and Put[k12, v4] are migrated to the memory page corresponding to Leaf page 11, and Put[k13, v3] is migrated to the memory page corresponding to Leafpage 11.

[0091] When the leaf nodes in the first logical page shrink to the parent logical page of the first logical page, the parent logical page of the first logical page can also be marked as a dirty child page in the memory page corresponding to the upper-layer logical page of the parent logical page of the first logical page, that is, the memory page corresponding to the grandparent logical page of the parent logical page. Based on a similar principle, after dividing the first leaf node into a new logical page obtained by splitting the first logical page through the foregoing step S411, the new logical page, which is the child logical page of the first logical page, can be marked as a dirty child page in the memory page corresponding to the first logical page.

[0092] Step S417, in response to completing the execution of the transaction sequence, determines the target value of the first state variable in the state data corresponding to block N + 1 according to the update record related to the first state variable in the second memory page, where the second memory page is the first memory page, or the second memory page corresponds to a logical page obtained by splitting or shrinking based on the first logical page.

[0093] When performing the foregoing step S407, before specifically performing step S417, the dirty child pages marked in the memory pages corresponding to the logical pages that are not leaf pages can also be used to determine several target memory pages to be updated. It can be understood that the second memory page belongs to the target memory pages. In this way, without traversing all the memory pages, it is possible to quickly know and locate which logical pages / memory pages specifically need to be updated in the current round of state data update process.

[0094] Refer to Figure 5As shown in Figure 5 or 6, through the dirty sub-pages marked in Page 1, the target logical page / target memory page involved in the current round of state data update process can be quickly determined, including Leaf page 11 and Leaf page 12. It is not necessary to traverse LeafPage 2 and Leaf Page 3 to know that they are not the target logical pages / target memory pages involved in the current round of state data update.

[0095] Exemplarily, based on the update records Put[k10, v1] and Put[k10, v2] stored in Leaf page 11 or Page 1, it can be known that the target value of the state variable with key a7x1f1c1d1e1 (i.e., k10) in the state data corresponding to block N + 1 is v2; similarly, based on the update records stored in Leaf page 12 or Page 1, it can be known that the target value of the state variable with key a7x1f15ad2e4 (i.e., k13) in the state data corresponding to block N + 1 is v3.

[0096] Step S419, write the target value to the persistent storage medium, and in the first leaf node, update the position information of the value of the first state variable in the persistent storage medium to the position information of the target value in the persistent storage medium.

[0097] The foregoing has focused on introducing the process of handling the update request initiated by the blockchain node due to executing the transaction sequence included in block N + 1. During the process of the blockchain node executing the transaction sequence included in block N + 1, a query request may also be initiated for a certain second state variable. In this case, it is possible to query whether there is an update record related to the second state variable in the third memory page corresponding to the second logical page to which the second leaf node belongs. If so, the query result is returned according to the update record related to the second state variable. Continuing with the foregoing example, when the transaction execution module of the blockchain node needs to query the variable value of the state variable with key a7x1f1c1d1e1 at the current moment during the execution of transaction Tx3, it can first determine the second leaf node corresponding to the state variable, that is, leaf node A10, and then query the update record Put[k10, v1] related to the state variable from the memory page corresponding to the logical page Leaf page 11 to which node A10 belongs, so as to return the variable value v1 in the update record as the query result to the transaction execution module, so that the transaction execution module can continue to execute Tx3 based on the query result.

[0098] It can be understood that after updating the leaf node in the relevant memory page, each tree node in the directed path from the root node to the updated leaf node will also be updated correspondingly. In addition, an incremental page / base page can be generated for the relevant memory page in the same way as generating an incremental page / base page based on the memory page in the foregoing example, so as to be used as an index of the status data.

[0099] Based on the same concept as the foregoing method embodiment, an embodiment of the present specification also provides a blockchain node 700 in a blockchain system. The blockchain system organizes the status data corresponding to block N through a tree structure divided into multiple logical pages. A key of a status variable is stored in a leaf node of the tree structure, and the position information of the value of a status variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure. Referring to Figure 7 As shown, the blockchain node 700 includes: a receiving unit 701 configured to receive an update request initiated for a first status variable due to executing the transaction sequence of block N + 1; a record processing unit 703 configured to store an update record corresponding to the update request in a first memory page corresponding to a first logical page to which the first leaf node belongs, and a key of the first status variable is stored in the directed path from the root node to the first leaf node of the tree structure; a status determination unit 705 configured to, in response to completing the execution of the transaction sequence, determine a target value of the first status variable in the status data corresponding to block N + 1 according to the update record related to the first status variable in a second memory page, where the second memory page is the first memory page or the second memory page corresponds to a logical page split or shrunk based on the first logical page; a storage processing unit 707 configured to write the target value to the persistent storage medium, and in the first leaf node, update the position information of the value of the first status variable in the persistent storage medium to the position information of the target value in the persistent storage medium.

[0100] An embodiment of the present specification also provides a computer-readable storage medium, on which a computer program / instructions are stored. When the computer program / instructions are executed on a computer, the computer is caused to execute the flowchart of a method for managing status data in a blockchain system provided in each of the foregoing embodiments.

[0101] An embodiment of the present specification also provides a computing device, including a memory and a processor. A computer program / instructions are stored in the memory. When the processor executes the computer program / instructions, the flowchart of a method for managing status data in a blockchain system provided in each of the foregoing embodiments is implemented.

[0102] In the 1990s, it was obvious to distinguish whether an improvement in a technology was an improvement in hardware (e.g., improvement in circuit structures such as diodes, transistors, switches, etc.) or an improvement in software (improvement in method flows). However, with the development of technology, many improvements in method flows today can be regarded as direct improvements in hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structures by programming the improved method flows into the hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented with a hardware entity module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device. Designers can program by themselves to "integrate" a digital system on a piece of PLD without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL), and there is not only one type of HDL, but many types, 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. Currently, the most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply making a little logical programming of the method flow with the above-mentioned several hardware description languages and programming it into the integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0103] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a 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 the controller 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. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to implement the same functions in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or the structures within the hardware component.

[0104] The systems, devices, modules, or units illustrated in 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, this application does not exclude that with the development of future computer technologies, the computers for implementing the functions of the above embodiments can be, for example, personal computers, laptop computers, in-vehicle human-machine interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0105] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When the actual device or terminal product is executed, it may be executed in the order of the method shown in the embodiments or the drawings or executed in parallel (for example, in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment). The term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, product or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device comprising the said elements. For example, if terms such as first and second are used to denote names, they do not denote any particular order.

[0106] For convenience of description, the above device is described by dividing it into various modules according to functions. Of course, when implementing one or more of this specification, the functions of each module may be implemented in the same or multiple software and / or hardware, or the modules implementing the same function may be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other may be through some interfaces. The indirect coupling or communication connection of the device or unit may be in electrical, mechanical or other forms.

[0107] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate a device for realizing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0108] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 specified in one block or multiple blocks.

[0109] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are performed on the computer or other programmable device to produce a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 specified in one block or multiple blocks.

[0110] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

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

[0112] Computer-readable media includes both permanent and non-permanent, removable and non-removable media and can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0113] Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0114] One or more embodiments of this specification can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification can also be practiced in a distributed computing environment where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0115] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0116] The above description is only for the embodiments of one or more embodiments of this specification and is not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification should be included within the scope of the claims.

Claims

1. A method for managing state data in a blockchain system, wherein the blockchain system organizes the state data corresponding to block N through a tree structure divided into multiple logical pages. A key of a state variable is stored in a leaf node of the tree structure, and the position information of the value of a state variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure. The method includes: Receiving an update request for a first state variable initiated due to the execution of the transaction sequence of block N+1; Storing the update record corresponding to the update request in the first memory page corresponding to the first logical page to which the first leaf node belongs, and the key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure; In response to completing the execution of the transaction sequence, determining the target value of the first state variable in the state data corresponding to block N+1 according to the update record related to the first state variable in the second memory page, where the second memory page is the first memory page, or the second memory page corresponds to a logical page obtained by splitting or shrinking based on the first logical page; Writing the target value to the persistent storage medium, and in the first leaf node, updating the position information of the value of the first state variable in the persistent storage medium to the position information of the target value in the persistent storage medium.

2. The method according to claim 1, further comprising: When the update request is used to request the deletion of the first state variable, deleting the first leaf node from the first logical page, and determining whether the first logical page after deleting the first leaf node satisfies the shrinkage condition; If so, shrinking the leaf nodes in the first logical page to the parent logical page of the first logical page, and migrating the update records in the first memory page to the memory page corresponding to the parent logical page of the first logical page.

3. The method according to claim 1, further comprising: When the first leaf node does not exist in the tree structure, determining the first logical page allowing the addition of the first leaf node, and initializing the first leaf node in the first memory page corresponding to the first logical page.

4. The method according to claim 3, wherein determining the first logical page allowing the addition of the first leaf node includes: Determining the target tree node allowing the first leaf node as its child node; When the logical page to which the target tree node belongs is a leaf page, determining the logical page to which the target tree node belongs as the first logical page allowing the addition of the first leaf node.

5. The method according to claim 4, wherein the determining the first logical page allowed to be added to the first leaf node further comprises: When the logical page to which the target tree node belongs is not a leaf page, adding a new first logical page.

6. The method according to claim 4, further comprising: Determining whether the first logical page satisfies the splitting condition; If so, dividing the first leaf node into a new logical page obtained by splitting the first logical page, and migrating the update record from the first memory page to the memory page corresponding to the new logical page.

7. The method according to any one of claims 1-6, the method further comprising: After storing the update record corresponding to the update request in the first memory page corresponding to the first logical page to which the first leaf node belongs, in the memory page corresponding to the parent logical page of the first logical page, mark the first memory page as a dirty child page; In response to completing the execution of the transaction sequence, determine a plurality of target memory pages to be updated according to the dirty child pages marked in the memory pages corresponding to the logical pages that are not leaf pages, and the second memory page belongs to the target memory pages.

8. The method according to any one of claims 1-6, the method further comprising: Receiving a query request for a second state variable initiated due to the execution of the transaction sequence of block N+1; In the third memory page corresponding to the second logical page to which the second leaf node belongs, query whether there is an update record related to the second state variable. If so, return a query result according to the update record related to the second state variable, and the key of the second state variable is stored in the directed path from the root node value of the tree structure to the second leaf node.

9. A blockchain node in a blockchain system, the blockchain system organizes the state data corresponding to block N through a tree structure divided into multiple logical pages, a key of a state variable is stored in a leaf node of the tree structure, and the position information of the value of a state variable in the persistent storage medium is stored in the directed path from the root node to a leaf node of the tree structure. The blockchain node includes: A receiving unit configured to receive an update request for a first state variable initiated due to the execution of the transaction sequence of block N+1; A record processing unit configured to store the update record corresponding to the update request in the first memory page corresponding to the first logical page to which the first leaf node belongs, and the key of the first state variable is stored in the directed path from the root node to the first leaf node of the tree structure; A state determination unit configured to, in response to completing the execution of the transaction sequence, determine the target value of the first state variable in the state data corresponding to block N+1 according to the update record related to the first state variable in the second memory page, and the second memory page is the first memory page, or the second memory page corresponds to a logical page obtained by splitting or shrinking on the basis of the first logical page; A storage processing unit configured to write the target value to the persistent storage medium, and in the first leaf node, update the position information of the value of the first state variable in the persistent storage medium to the position information of the target value in the persistent storage medium.

10. A computer-readable storage medium, on which a computer program is stored. When the computer program is executed in a computing device, the computing device executes the method according to any one of claims 1-8.

Images