State data management method in block chain system and block chain node

Abstract

A state data management method in a block chain system and a block chain node, the method comprising: according to execution results of a plurality of transactions included in a to-be-generated first block, generating a revocation log of the first block, the execution results at least indicating a to-be-updated first state variable and an update type thereof, the target variable indicating updating in the log, the updating type of the target variable and / or the target variable value of the target variable in second state data corresponding to the second block are / is cancelled, the target variable is the first state variable or a member variable of the first state variable, and the second block is a previous block of the first block; according to the execution result, updating second state data corresponding to the second block in the first data storage system to first state data corresponding to the first block; and, in the second data storage system, storing the revocation log of the first block.

Description

Technical Field

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

[0002] The blockchain system is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of decentralization, information cannot be tampered with, and autonomy, the blockchain system has received more and more attention and application.

[0003] In the blockchain system, state data can be managed through a tree structure, and the aforementioned tree structure may include but is not limited to MPT (Merkle Patricia Tree) and SMT (Sparse Merkle Tree), etc. A leaf node in the tree structure stores the value of a state variable, and part of the information in the directed path from the root node to the leaf node of the tree structure constitutes the key of the state variable. The data storage system can store the key-value pairs of the tree node itself in the tree structure; based on the tree structures corresponding to different versions of state data, different state root (State_Root) hashes can be calculated, and the state root hash can be used as the identifier of the corresponding version of the state data and anchored to the corresponding block header.

[0004] Based on the characteristics of the tree structure, the blockchain system can store multiple versions of state data corresponding to multiple generated blocks in an append-only manner with a relatively small amount of data storage. However, with the large increase in the number of state data versions, the amount of state data stored in the blockchain system will still increase significantly, and it is necessary to continuously prune / manage the key-value pairs of the tree nodes stored in the data storage system to delete the earlier versions of the state data. Summary of the invention

[0005] The purpose of the present invention is to provide a state data management method and a blockchain node in a blockchain system.

[0006] In a first aspect, a state data management method in a blockchain system is provided, the method comprising: generating an undo log of a first block to be generated according to execution results of multiple transactions included in a first block to be generated, the execution result indicating at least a first state variable to be updated and its update type, the undo log indicating a target variable to be updated, and the update type of the target variable and / or a target variable value of the target variable in second state data corresponding to a second block, the target variable being the first state variable or a member variable of the first state variable, and the second block being a previous block of the first block; updating the second state data corresponding to the second block in a first data storage system to the first state data corresponding to the first block according to the execution result; and storing the undo log of the first block in the second data storage system.

[0007] In a second aspect, a blockchain node in a blockchain system is provided, the blockchain node comprising: a log management unit, configured to generate an undo log of a first block to be generated according to execution results of multiple transactions included in a first block to be generated, the execution result at least indicating a first state variable to be updated and its update type, the undo log indicating a target variable to be updated, and the update type of the target variable and / or the target variable value of the target variable in second state data corresponding to a second block, the target variable being the first state variable or a member variable of the first state variable, and the second block being a previous block of the first block; a data update unit, configured to update the second state data corresponding to the second block in a first data storage system to the first state data corresponding to the first block according to the execution result; the log management unit is further configured to store the undo log of the first block in the second data storage system.

[0008] In a third aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores a computer program / instructions, and when the processor executes the computer program / instructions, the method described in the first aspect is implemented.

[0009] According to a 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.

[0010] In the technical solution provided in the embodiments of this specification, when the blockchain system generates a new block, based on the execution results of multiple transactions included in the new block, the undo log corresponding to the new block is stored in the second data storage system, and the undo log indicates the target variable that is updated due to the need to generate the new block, as well as the update type of the target variable and / or the target variable value before the update, while only one version of the status data corresponding to the latest generated block is always stored in the first data storage system; when the user needs to access the status data corresponding to a target block other than the latest generated block, the status data stored in the first data storage system and the undo logs corresponding to each block located after the target block in the second data storage system can be used to restore the status data corresponding to the target block, which is conducive to meeting the user's access needs to multiple versions of status data without directly storing multiple versions of status data. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0012] Figure 1 This is an architectural diagram of a blockchain system exemplarily provided in the embodiments of this specification;

[0013] Figure 2 This is one of the schematic diagrams of the data storage structure exemplarily provided in the embodiments of this specification;

[0014] Figure 3 This is a second schematic diagram of a data storage structure exemplarily provided in an embodiment of this specification;

[0015] Figure 4 A schematic diagram of the structure of an MPT tree exemplarily provided in the embodiments of this specification;

[0016] Figure 5 This is one of the flowcharts of a state data management method in a blockchain system provided in an embodiment of this specification;

[0017] Figure 6 A schematic diagram of the relationship between the revocation log and the status data provided exemplarily in the embodiments of this specification;

[0018] Figure 7 This is a second flowchart of a state data management method in a blockchain system provided in an embodiment of this specification;

[0019] Figure 8 This is a schematic diagram of the structure of a state data management device in a blockchain system provided in an embodiment of this specification. DETAILED DESCRIPTION

[0020] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0021] Figure 1 This is an architectural diagram of a blockchain system provided exemplarily in the embodiments of this specification. The blockchain system may include N blockchain nodes, where Figure 1 8 blockchain nodes, i.e., node 1 to node 8, are shown as examples. The lines between the nodes schematically represent the connection between the nodes, and the aforementioned connection is used to support data transmission between different nodes.

[0022] The blockchain system can provide the function of smart contracts. Smart contracts in the blockchain system are contracts that can be triggered and executed by transactions. Smart contracts can be defined in the form of contract code. Calling a smart contract in the blockchain system is to initiate a transaction pointing to the contract address of the smart contract, so that each node in the blockchain system can run the corresponding contract code in a distributed manner.

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

[0024] Contract account (CA): mainly used to store the contract code of the corresponding smart contract and the value of the state variable in the smart contract. It can usually only be activated by calling an external account.

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

[0026] The design of external accounts and contract accounts is actually a mapping from account addresses to account status. The account status 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 codeHash and storageRoot attributes are generally only valid on contract accounts.

[0027] More specifically, for external accounts, the value of nonce represents the number of transactions sent from the relevant account address; for contract accounts, 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 certain digital resources / tokens owned by the relevant account address. The value of Storage root is a tree structure such as the hash value of the root node of an MPT tree, which is used to organize / manage the storage of 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 external accounts, since smart contracts are not included, the values ​​of the storageRoot and CodeHash fields can generally be empty strings / all-0 strings.

[0028] It should be noted that MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (a compressed prefix tree, a more space-saving dictionary tree). The Merkle tree algorithm can calculate a hash value for multiple transactions, and then connect them two by two to calculate the hash again until the top Merkle root. Some blockchain systems usually use an improved MPT tree, such as a hexadecimal tree structure, which is usually referred to as the MPT tree.

[0029] A tree structure is usually used in blockchain systems to manage the state data corresponding to a block. A leaf node of the tree structure stores the value of a state variable, and the directed path from the root node to the leaf node of the tree structure stores the key of the state variable. It should be noted that the state variable mentioned here can be a state variable in an external account, a contract account, or a smart contract. The type of the tree structure is, for example, MPT or SMT (Sparse Merkle Tree).

[0030] The tree structure used to manage state data may include a state trie. The state trie contains key-value pairs (also written as key-value, abbreviated as kv or kv) of the storage content corresponding to each account in the blockchain system. The "key" in the state trie can be the account address of an external account / contract account in the blockchain system, or part or all of the hash value of the account address, collectively referred to as the account address below. The account addresses are distributed in the directed path from the root node to the leaf node of the state tree. The "value" in the state tree is generated by encoding the state of the account, such as recursive-length prefix encoding (RLP). For external accounts, the "value" includes the values ​​of nonce and balance; for contract accounts, the "value" includes the values ​​of nonce, balance, codehash and storageroot.

[0031] The tree structure used to manage state data can also include storage trie, which is used to manage the contract status of smart contracts deployed in the blockchain system. The hash value of the root node of the storage trie is stored in the above storageroot, so that the state of the smart contract is locked to the relevant contract account through the hash. Similarly, storagetrie stores the key-value mapping from the state address to the state value; 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 sequence to form the key of a state variable, and the leaf node stores the value of the state variable.

[0032] Reference Figure 2As shown, in some blockchain systems, the block header of each block may include several fields, such as the previous block hash previous_Hash (Prev Hash in the figure), random number Nonce (in some blockchain systems, this Nonce is not a random number, or in some blockchain systems, the Nonce in the block header is not enabled), 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), which is the hash value of the previous block. In this way, the next block on the blockchain is locked to 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 different tree structures. For example, in some blockchain systems, the same MPT structure can usually be used. In blockchain systems that support smart contracts, the tree structure used to manage state data usually includes two levels of MPT structures: the leaf nodes of the upper-level MPT structure include the state of external accounts or contract accounts; the contract account includes the lower-level MPT structure, and the lower-level leaf nodes include the values ​​of state variables in the contract account.

[0033] Reference Figure 2 and Figure 3As shown in the figure, state_root is the hash value of the root node of the MPT tree composed of the states of all accounts in the current block, that is, the state trie pointing to state_root is a state tree 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 the hash value of this root node is generally stored in state_root. The root node can be connected to one or more layers of Extension Node / Branch Node below, and these multi-layer tree nodes can be collectively referred to as intermediate nodes (Internal Node). From the root node of this MPT to the leaf node, a part of the value in each node can be connected in sequence to form an account address and serve as a key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a part of sha3(Address), that is, a part of the hash value of the account address (the hash algorithm adopts the sha3 algorithm, for example), and the value stored can be rlp(Account), that is, the rlp encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, for external accounts, there are usually only two items, nonce and balance, and the storageRoot and codeHash fields store empty strings / all zero strings by default; for contract accounts, they usually include Nonce, Balance, Storage root and CodeHash. The Storage root corresponds to another MPT at the next level, and the contract status of the relevant smart contract can be linked to the Storage root. Whether it is an external account or a contract account, its account information is generally located in a separate leaf node (LeafNode). The directed path from the Extension Node / Branch Node of the root node to the Leaf Node of each account may pass through several branch nodes and extension nodes in the middle.

[0034] As mentioned above, the state trie can be an MPT tree, which is generally a 16-way tree, that is, each layer can have up to 16 child nodes. For Extension Node, which is used to store common prefixes, it generally has 1 child node, which can be a Branch Node. For Branch Node, it can have up to 16 child nodes, which may include ExtensionNode and / or Leaf Node.

[0035] For a contract account in the state trie, its storage_Root can point to the next-level MPT, which stores the data of the state variables involved in the contract execution. The next-level MPT tree pointed to by this storage_Root is the Storage Trie, that is, the hash value of the root node of the Storage Trie. The Storage Trie tree also stores the key-value pairs of state variables. The key indicates the address of the state variable, and its value can be the result obtained after the position of the state variable declaration in the contract (the value counting from 0) is processed by certain rules, such as sha3 (the position of the state variable declaration) or sha3 (contract name + the position of the state variable declaration). The value is used to store the value of the state variable (such as the value encoded by RLP). A part of the data stored in the directed path from the root node through the intermediate node to the leaf node is connected to form the key, and the value is stored in the leaf node.

[0036] As mentioned above, the Storage trie can also be an MPT tree, which is also a 16-way tree. That is, for a Branch Node, it can have up to 16 child nodes, which may include Extension Nodes and / or Leaf Nodes. For an Extension Node, it can generally have 1 child node, which can be a Branch Node or a Leaf Node.

[0037] Reference Figure 3 The Leaf Node Account P of the state trie shown in the figure is a contract account, and the Storage Root of this account locks all states in the contract storage. These states are organized into an MPT tree, such as the Storage trie to which the Storage Root is linked. In this linked Storage trie, taking Leaf Node StateVariable N as an example, for example, the value of the state variable storedData in the smart contract, its key is sha3 (the declaration position of storedData, that is, the second line of the code), and its value is s (for the sake of simplicity, the encoding format of the value is omitted here, such as RLP, which will be similar in the future and will not be repeated). Among them, the key values ​​are distributed sequentially from the root node to the leaf node (that is, Leaf Node Variable N) of the storage trie.

[0038] For example, refer to Figure 3The Leaf Node Account C in the state Trie shown in the figure is an external account, and its key is sha3 (Address C), that is, the hash value of the address of account C (the hash algorithm adopts the sha3 algorithm, for example), and its stored value value can be (Account), where the account information Account is a tuple consisting of [nonce, balance]. As mentioned above, since Account C is an external account, its account information is two items, nonce and balance (codehash and storage root are omitted here, and the following are similar). For example, an external account, whose nonce is 20 and Balance is 4550, then the Leaf Node State Variable C stores nonce = 20, balance = 4550. The address of Account C is the key, and its values ​​are sequentially distributed from the root node to the leaf node (i.e., Leaf Node Variable C) of the state Trie.

[0039] The data storage system does not directly store the KV of the account or the KV of the state variable in the contract. In fact, it stores the key-value mapping of each tree node. The value of the tree node includes all the contents stored in the tree node, and the key of the tree node may include but is not limited to the hash value of all the contents stored in the tree node.

[0040] like Figure 4As shown in the example, in the upper-level MPT structure, for leaf node A1, the key of the leaf node is composed of a7 of the shared nibble in the root node A8 (Extension Node)—slot 1 of the intermediate node A7 (Branch Node)—1335 of the key-end in the leaf node A1, which is a711335. Balance=45.0ETH and Nonce=n1 are stored in the leaf node. For leaf node A2, the key of the leaf node is composed of a7 of the shared nibble in the root node A8 (Extension Node)—slot 7 of the intermediate node A7 (Branch Node)—d3 of the shared nibbles in the node A6 (Extension Node)—slot 3 of the intermediate node A5 (Branch Node)—7 of the key-end in the leaf node A2, which is a77d337. Balance=1.00WEI and Nonce=n2 are stored in the leaf node. For leaf node A3, the key of the leaf node is composed of a7 of the shared nibble in root node A8 (Extension Node), slot f of intermediate node A7 (Branch Node), and 9365 of key-end in leaf node A3, which is a7f9365. Balance = 1.1ETH and Nonce = n3 are stored in the leaf node. For leaf node A4, the key of the leaf node is composed of a7 of the shared nibble in root node A8 (Extension Node), slot 7 of intermediate node A7 (Branch Node), d3 of the shared nibbles in node A6 (Extension Node), slot 9 of intermediate node A5 (Branch Node), and 7 of key-end in leaf node A4, which is a77d397. Balance = 0.12ETH, Nonce = n4, CodeHash = c1, and Storage root = s1 are stored in the leaf node. s1 can be H(A10), which is the hash of the root node A10 of the next tree layer. The leaf nodes of A1, A2 and A3 store the information of external accounts, and the leaf node of A4 stores the information of contract accounts. For contract accounts, it contains the next level MPT, forming a Storage Trie, which is used to store the state variables in the contract account.

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

[0042] In the node structure of the above MPT tree, the prefix prefix is ​​used to indicate the type of tree node, for example, 0 indicates an Extension Node containing an even number of shared nibbles, 1 indicates an Extension Node containing an odd number of shared nibbles(s), 2 indicates a Leaf Node containing an even number of nibbles, and 3 indicates a Leaf Node containing an odd number of nibbles(s). In the node structure of the above MPT tree, the hash value of the entire content of the next tree node is filled in the corresponding position of the previous tree node.

[0043] In this way, the tree node kv actually stored in the data storage system can be shown in the following Table 1:

[0044]

[0045]

[0046] Table 1

[0047] In Table 1 above, H() is used to represent hash calculation. The hash value of the next tree node is anchored in the previous tree node. Through layer-by-layer hashing, the root hash of the entire state trie tree is obtained, and the root hash is locked in the state root field of the block header.

[0048] The data storage system usually adopts a NoSQL Key-Value DB (DataBase, database; Key-Value DB is also referred to as KVDB) with an LSM (Log-Structured Merge-Tree) structure. Specifically, the data storage system may include levelDB or RocksDB, for example. Both KVDBs are based on the LSM storage engine.

[0049] According to the characteristics of the tree structure for managing state data, such as the aforementioned state trie and / or storage trie, the blockchain system can store multiple versions of state data corresponding to the most recently generated blocks in an append-only form with a relatively small amount of data storage. However, with the large increase in blocks, the state data versions will increase significantly, which will in turn lead to a significant increase in the amount of state data stored in the blockchain system. Therefore, it is necessary to continuously prune / data manage the key-value pairs of the tree nodes stored in the data storage system to delete the earlier versions of the state data.

[0050] Reference Figure 4As shown, in the state data corresponding to block N, for the external account with key a77d397, that is, the external account with account address a77d397, the value of its member variable balance is 0.12ETH. Here, it is assumed that in the state data corresponding to block N+1, the value of the member variable balance in the external account with account address a77d397 is updated to 0.11ETH. Then based on the relationship between the tree nodes in the tree structure of the above example, the value of the member variable balance in tree node A4 is changed to 0.11ETH, which will cause the hash value of tree node A4 to change. Because the hash value of the next tree node in the tree structure is anchored to the previous tree node, it is necessary to update all tree nodes in the directed path between tree node A8 and tree node A4, that is, it is necessary to update A8, A7, A6, A5, and A4 to obtain the statetrie for managing the state data corresponding to block N+1.

[0051] For the data storage system, the state data corresponding to block N will not be deleted directly, that is, the key-value pairs of tree nodes A1 to A16 shown in Table 1 above will not be deleted from the data storage system. Instead, the updated key-value pairs of tree nodes A8, A7, A6, A5, and A4 will be stored in the data storage system in the form of append-only. In the subsequent process, the state data in the data storage system can be pruned / data managed to delete the key-value pairs from the data storage system. Figure 4 The key-value pairs of the tree nodes A9, A8, A7, A6, A5, and A4 in the example above are used to delete the state data corresponding to block N from the data system. However, the process of pruning / data governance of state data in a data storage system is extremely complicated.

[0052] In the embodiments of this specification, at least one state data management method and a blockchain node in a blockchain system are provided. According to the execution results of multiple transactions included in the first block to be generated, a revocation log of the first block can be generated, the execution result at least indicates the first state variable to be updated and its update type, the revocation log indicates the target variable to be updated, and the update type of the target variable and / or the target variable value of the target variable in the second state data corresponding to the second block, the target variable is the first state variable or a member variable of the first state variable, and the second block is the previous block of the first block; then, according to the execution result, the second state data corresponding to the second block in the first data storage system is updated to the first state data corresponding to the first block; and in the second data storage system, the revocation log of the first block is stored.

[0053] In this way, when the blockchain system generates a new block, based on the execution results of multiple transactions included in the new block, the undo log corresponding to the new block is stored in the second data storage system, and the undo log indicates the target variable that is updated due to the need to generate the new block, as well as the update type of the target variable and / or the target variable value before the update, while only one version of the status data corresponding to the latest generated block is always stored in the first data storage system; when the user needs to access the status data corresponding to a target block other than the latest generated block, the status data stored in the first data storage system and the undo logs corresponding to each block after the target block in the second data storage system can be used to restore the status data corresponding to the target block, which is conducive to meeting the user's access needs to multiple versions of status data without directly storing multiple versions of status data.

[0054] Moreover, the user's access needs for multi-version state data are usually sporadic, for example, the user only has access needs for state data corresponding to a small number of blocks before the latest generated block, and does not have access needs for state data corresponding to a large number of historical blocks before the latest generated block. The technical solution provided in the embodiments of this specification can support the on-demand recovery of state data corresponding to relevant historical blocks according to the actual access needs of users, and does not directly store a large number of versions of state data corresponding to a large number of historical blocks, which can save a lot of storage resources.

[0055] In addition, since there is no need to store multiple versions of state data in the same data storage system in an append-only manner, there is no need to continuously use complex pruning / data governance processes to manage multiple versions of state data, which is conducive to improving the management efficiency of state data.

[0056] Figure 5 This is one of the flowcharts of a state data management method in a blockchain system provided in an embodiment of this specification. The method can be executed by a blockchain node in a blockchain system. The method exemplarily describes the process of obtaining the first state data and the undo log corresponding to the first block when the blockchain system generates the first block.

[0057] See also Figure 5 As shown, the method may include but is not limited to part or all of the following steps S501 to S505.

[0058] Step S501, generating an undo log of the first block according to the execution results of multiple transactions included in the first block to be generated, wherein the execution result at least indicates the first state variable to be updated and its update type, and the undo log indicates the target variable to be updated, and the update type of the target variable and / or the target variable value of the target variable in the second state data corresponding to the second block; wherein the target variable is the first state variable or a member variable of the first state variable, and the second block is the previous block of the first block.

[0059] In the process of generating the first block, the blockchain system will execute multiple transactions belonging to the first block to obtain the execution results of the multiple transactions, and the execution results may indicate one or more first state variables to be updated and their corresponding update types. The first state variable mentioned here may be the account address of an external account / contract account registered in the blockchain system, or may be a state variable defined in a smart contract deployed in the blockchain system.

[0060] The first state variable can be directly used as the target variable to be updated. Alternatively, the first state variable defined in the smart contract can be directly used as the target variable to be updated; for the contract address of an external account or contract account, it may include multiple member variables / fields such as nonce, bablance, storageRoot and codeHash. The update of the account address of the external account or contract account may only update some of the member variables / fields it contains. Therefore, in order to save storage costs as much as possible, when the first state variable is an account address, the member variables to be updated can be determined from the first state variable, and then the member variables that are actually updated can be used as the target variable to be updated.

[0061] As mentioned above, the blockchain system can manage state data through a tree structure. A leaf node in the tree structure stores the value of a state variable, and the directed path from the root node to the leaf node of the tree structure stores the key of the state variable; accordingly, the first data storage system stores the key-value pairs of the tree nodes in the tree structure.

[0062] In a possible implementation, when the update type of the first state variable is modification, the first state variable is an account address including multiple member variables, and the execution result also includes the first variable value of the first state variable in the first state data, the value of the target leaf node can be obtained from the first data storage system according to the key of the target leaf node corresponding to the first state variable in the tree structure; the second variable value of the first state variable can be obtained from the value of the target leaf node; based on the first variable value and the second variable value, the modified target variable can be determined from the member variables included in the first state variable, and the target variable value of the target variable can be obtained from the second variable value.

[0063] In one possible implementation, when the update type of the first state variable is modification or deletion, the value of the target leaf node is obtained from the first data storage system according to the key of the target leaf node corresponding to the first state variable in the tree structure; the second variable value of the first state variable is obtained from the value of the target leaf node; the first state variable is used as the target variable, and the second variable value of the first state variable is used as the target variable value of the target variable.

[0064] In a possible implementation, when the update type of the first state variable is new addition, the first state variable is used as the target variable, and the update type of the target variable is set to new addition.

[0065] For example, refer to Figure 6As shown, here we first assume that in the state data corresponding to block K, the value of the state variable Contract1_A defined in the smart contract Contract1 is X1; the value of the account address Dave is X2; the value of the account address Alice is X3, where X3 includes the value of the member variable nonce 5 and the value of the member variable banlance 10; the value of the account address Lisa is X4, where X4 includes the value of the member variable nonce 3 and the value of the member variable banlance 20; the value of the account address Zeus is X5, where X5 includes the value of the member variable nonce 3 and the value of the member variable banlance 20. In addition, we continue to assume that block K+1 includes: transaction Tx1, which is used to transfer a digital resource with a share of 5 from the account address Alice to the account address Bob, where the account address Bob does not exist in the state data corresponding to block K; transaction Tx2, which is used to call the aforementioned smart contract Contract1 to delete the state variable Contract1_A; transaction Tx3, which is used to transfer a digital resource with a share of less than 10 from the account address Lisa to the account address Zeus. In the execution results obtained by executing transactions Tx1, Tx2 and Tx3, Contract1_A, Alice, Bob, Lisa, Zeus and their corresponding update types can be indicated. The update types corresponding to Contract1_A, Alice, Bob, Lisa and Zeus are delete, modify, add, modify and modify. In addition, the execution structure or can also indicate the variable values ​​of Alice, Bob, Lisa and Zeus in the state data corresponding to block K+1. The variable values ​​of Alice, Bob, Lisa and Zeus in the state data corresponding to block K+1 are X6, X7, X8 and X9, respectively, where: X6 includes the value 6 of member variable nonce and the value 5 of member variable balance; X7 includes the value 0 of member variable nonce and the value 5 of member variable balance; X8 includes the value 4 of member variable nonce and the value 10 of member variable balance; X9 includes the value 3 of member variable nonce and the value 30 of member variable balance.

[0066] Correspondingly, in the undo log corresponding to block K+1 generated based on the execution results of transactions Tx1, Tx2 and Tx3, it can be indicated that the updated target variables include Contract1_A, Alice, Bob, Lisa, and Zeus, indicating the target variable values ​​X1, X3, X4, and X5 of Contract1_A, Alice, Lisa, and Zeus in the state data corresponding to block K, and indicating that the update type of the target variable Bob is new addition. Alternatively, in order to save storage costs as much as possible, for the state variable Zeus to be updated in the execution result, by comparing the value X5 of Zeus in the state data corresponding to block K and the value X9 of Zeus in the state data corresponding to block K+1, it can be found that the member variables updated in Zeus only include balance but not the member variable nonce. Therefore, in the aforementioned undo log, Zeus may not be used as the target variable, but the member variable balance updated in Zeus (denoted as Zeus_balance) may be used as the target variable, and the value 20 of the member variable balance updated in Zeus in the state data corresponding to block K may be used as the target variable value of Zeus_balance.

[0067] Step S503: According to the execution result, the second state data corresponding to the second block in the first data storage system is updated to the first state data corresponding to the first block.

[0068] As mentioned above, the blockchain system manages state data through a tree structure, a leaf node in the tree structure stores the value of a state variable, and the directed path from the root node of the tree structure to the leaf node stores the key of the state variable; the first data storage system stores the key-value pairs of the tree nodes in the tree structure.

[0069] Correspondingly, according to the execution result, in the tree structure, several target tree nodes corresponding to the first state variable may be updated, and in the first data storage system, the key-value pairs of several target tree nodes may be updated. Figure 4As shown in Table 1 above, it is assumed that the key of the state variable Contract1_A whose update type is deletion in the execution result is 35b2e4, and the value of Contract1_A in the state data corresponding to block K / block N is stored in the target leaf node A11 of the tree structure. In this case, the target leaf node A11 needs to be deleted in the tree result, and the key-value pair of the target leaf node A11 needs to be deleted from the first data storage system. In addition, the hash value of the next tree node in the tree structure is anchored to the previous tree node, so the target tree nodes A10, A4, A5, A6, A7, and A8 need to be updated accordingly. For example, the hash value of A11 is deleted from A10, and the hash value of the updated node A10 is recalculated and updated in A4, and so on. Because the data content (the value of the tree node) stored in the target tree nodes A10, A4, A5, A6, A7, and A8 changes, it is also necessary to recalculate the keys of the updated tree nodes A10, A4, A5, A6, A7, and A8, and update the key-value pairs of the tree nodes A10, A4, A5, A6, A7, and A8 already stored in the first data storage system.

[0070] Step S505 : storing the undo log of the first block in the second data storage system.

[0071] Through the method provided in the aforementioned steps S501 to S505, when the blockchain system generates a new block, based on the execution results of multiple transactions included in the new block, the blockchain system stores the undo log corresponding to the new block in the second data storage system, wherein the undo log indicates the target variable that is updated due to the need to generate the new block, as well as the update type of the target variable and / or the target variable value before the update, while only one version of the status data corresponding to the latest generated block is always stored in the first data storage system; when it is necessary to access the status data corresponding to a target block other than the latest generated block, the status data stored in the first data storage system and the undo logs corresponding to each block located after the target block in the second data storage system can be used to restore the status data corresponding to the target block, which is conducive to meeting the user's query requirements for multiple versions of status data without directly storing multiple versions of status data.

[0072] Since users have less need to access the state data corresponding to blocks with earlier generation times, relevant update strategies can also be used to delete the undo logs corresponding to blocks with earlier generation times from the second database to save storage resources. For example, each time an undo log is stored in the second data storage system, it is detected whether the cumulative number of undo logs stored in the second data storage system reaches a preset threshold. If so, the undo log with the earliest storage time is deleted.

[0073] Figure 7 This is a flowchart of a state data management method in a blockchain system provided in an embodiment of this specification. The method can be executed by a blockchain node or an off-chain business system in a blockchain system. The method exemplarily describes a process of restoring the state data corresponding to a historical block before the latest generated block based on the state data corresponding to the latest generated block of the blockchain system and the undo logs corresponding to the latest generated one or more blocks.

[0074] Reference Figure 7 As shown, the method may include but is not limited to part or all of the following steps S701 to 707.

[0075] Step S701, determining a third block corresponding to the third state data to be restored.

[0076] Step S703: Obtain undo logs of a plurality of fourth blocks located after the third block from the second data storage system.

[0077] Step S705: Acquire fourth state data corresponding to the latest generated block from the first data storage system.

[0078] Step S707: restore the third state data according to the fourth state data and the undo logs of the fourth blocks.

[0079] The third state data can be restored recursively. Assuming that the latest generated block is K+2, the state data corresponding to block K+1 can be restored based on the state data and undo log corresponding to block K+2; and then the state data corresponding to block K can be further restored based on the state data and undo log corresponding to block K+1.

[0080] In the process of restoring state data, for two adjacent blocks, after obtaining the state data corresponding to the latter block (e.g., the aforementioned first block), at least the first state variable corresponding to the target variable and its update type can be determined based on the target variable indicated in the undo log of the latter block, and the update type of the target variable and / or the target variable value of the target variable in the state data corresponding to the previous block (e.g., the aforementioned second block), and then the state data corresponding to the latter block is updated to the state data corresponding to the previous block based on the first state variable and its update type.

[0081] As mentioned above, the blockchain system can manage state data through a tree structure. A leaf node in the tree structure stores the value of a state variable, and the directed path from the root node to the leaf node of the tree structure stores the key of the state variable; the first data storage system stores the key-value pairs of the tree nodes in the tree structure.

[0082] In a possible implementation, when the target variable is indicated in the next block and the update type of the target variable is new addition, the target variable can be directly determined as the first state variable updated between the next block and the previous block, and the update type of the first state variable is also new addition. The target leaf node corresponding to the first state variable can be deleted in the tree structure, and the key-value pair of the target leaf node can be deleted from the first state data; refer to Figure 6 As shown. The undo log corresponding to block K+1 indicates the target variable Bob and its update type "new". The target leaf node corresponding to Bob can be deleted in the tree structure, and the key-value pair of the target leaf node can be deleted from the first state data. Referring to the characteristics of the tree structure described above, after deleting the target leaf node, each target tree node between the root node and the target leaf node can also be updated accordingly, and the key-value pairs of each target tree node can be updated accordingly in the state data corresponding to the next block.

[0083] In a possible implementation, when a target variable and the target variable value of the target variable in the previous block are indicated in the next block, the target variable may be the first state variable updated between the next block and the previous block. The target variable can be used as the first state variable, and the target variable value can be used as the variable value of the first state variable in the previous block. According to the variable value of the first state variable in the previous block, a target leaf node corresponding to the first state variable is added or modified in the tree structure, and a key-value pair of the target leaf node is added or modified in the first state data. Exemplary, for example, reference can be made to Figure 6As shown: the undo log corresponding to block K+1 indicates the target variables Contract1_A, Alice, Lisa, Zeus and their respective corresponding target variable values ​​X1, X3, X4, X5. There may be only target leaf nodes corresponding to Alice, Lisa, and Zeus in the tree structure, but no target leaf node corresponding to Contract1_A. Therefore: according to Contract1_A and its corresponding target variable value X1, a target leaf node corresponding to Contract1_A can be added to the tree structure, and a key-value pair of the target leaf node can be added to the status data corresponding to block K+1. In addition, according to Alice, Lisa, Zeus and their respective corresponding target variable values ​​X3, X4, and X5, the target leaf nodes corresponding to Alice, Lisa, and Zeus can be modified in the tree structure, and the key-value pairs of the target leaf nodes corresponding to Alice, Lisa, and Zeus can be modified in the status data corresponding to block K+1. Referring to the characteristics of the tree structure described above, after adding or updating the target leaf node in the tree structure, each target tree node between the root node and the target leaf node should also be updated accordingly, and, in the status data corresponding to the subsequent block, the key-value pairs of each target tree node should be updated accordingly.

[0084] In one possible implementation, when a target variable and the target variable value of the target variable in a previous block are indicated in a later block, the target variable is a member variable of a first state variable that may be updated. After determining the first state variable described by the target variable, the value of the target leaf node can be obtained from the first data storage system according to the key of the target leaf node corresponding to the first state variable, and the first variable value of the first state variable can be obtained from the value of the target leaf node; the second variable value of the first state variable can be generated according to the first variable value and the target variable value; according to the second variable value of the first state variable, in a tree structure, several target tree nodes corresponding to the first state variable are updated, as well as the key-value pairs of several target tree nodes are updated. Exemplarily, refer to Figure 6As shown, the undo log corresponding to block K+1 indicates the target variable Zeus_balance and its target variable value 20. After determining that the first state variable to which the target variable belongs is Zeus, the first variable value X9 (3, 30) is obtained from the state data corresponding to block K+1. According to the first variable value X9 (3, 30) and the target variable value 20 of the member variable Zeus_balance, the second variable value X5 (3, 20) can be generated, so that in the tree structure, several target tree nodes corresponding to the first state variable Zeus can be updated, and the several target tree nodes include a target leaf node for storing the value of Zeus and each tree node on the directed path between the root node and the target leaf node, as well as key-value pairs for updating several target tree nodes.

[0085] The aforementioned Figure 5 to Figure 7 In the various embodiments described in detail, the key-value pairs of tree nodes are mainly described in the first data storage system. However, in specific technical scenarios, the key-value pairs of state variables can actually be directly stored. In this case, the value of the first state variable can be added, deleted, or modified in the first data storage system directly according to the key of the state variable, rather than adding, deleting, or modifying the key-value pairs of tree nodes in the first data storage system.

[0086] As mentioned earlier, Figure 7 The method shown can be executed on demand by the off-chain business system. The off-chain business system can obtain the state data corresponding to the latest generated block from the first data storage system; the off-chain business system can also load the tree structure for managing the state data according to the state root included in the block header of the latest generated block, so as to facilitate execution Figure 7 The method described.

[0087] Based on the same concept as the aforementioned method embodiment, the present specification embodiment also provides a blockchain node 800 in a blockchain system. Figure 8As shown, the blockchain node 800 includes: a log management unit 801, configured to generate a revocation log of a first block to be generated according to the execution results of multiple transactions included in the first block to be generated, wherein the execution result at least indicates the first state variable to be updated and its update type, and the revocation log indicates the target variable to be updated, and the update type of the target variable and / or the target variable value of the target variable in the second state data corresponding to the second block, the target variable is the first state variable or a member variable of the first state variable, and the second block is the previous block of the first block; a data update unit 803, configured to update the second state data corresponding to the second block in the first data storage system to the first state data corresponding to the first block according to the execution result; the log management unit 801 is also configured to store the revocation log of the first block in the second data storage system.

[0088] A computer-readable storage medium is also provided in an embodiment of the present specification, on which a computer program / instruction is stored. When the computer program / instruction is executed in a computer, the computer is caused to execute a state data management method in a blockchain system provided in each of the aforementioned embodiments.

[0089] A computing device is also provided in an embodiment of the present specification, including a memory and a processor, wherein the memory stores a computer program / instruction, and when the processor executes the computer program / instruction, a state data management method in a blockchain system provided in each of the aforementioned embodiments is implemented.

[0090] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using 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 logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0091] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers 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 a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0092] The systems, devices, modules or units described in the above embodiments may be 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 exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0093] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

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

[0095] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a 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 instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0096] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0097] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

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

[0100] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic 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 temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0101] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may 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.) containing computer-usable program code.

[0102] One or more embodiments of the present specification may 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 the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0103] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, in the absence of mutual contradiction, a person 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.

[0104] The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims

1. A state data management method in a blockchain system, the method comprising: Generate an undo log of the first block according to the execution results of the multiple transactions included in the first block to be generated, wherein the execution result indicates the first state variable to be updated and its update type, and the undo log indicates the target variable to be updated, and the update type of the target variable and / or the target variable value of the target variable in the second state data corresponding to the second block, wherein the target variable is the first state variable or a member variable of the first state variable, and the second block is the previous block of the first block; According to the execution result, updating the second state data corresponding to the second block in the first data storage system to the first state data corresponding to the first block; as well as, In a second data storage system, an undo log of the first block is stored.

2. According to the method of claim 1, the blockchain system manages state data through a tree structure, a leaf node in the tree structure stores the value of a state variable, and the directed path from the root node to the leaf node of the tree structure stores the key of the state variable; the first data storage system stores the key-value pairs of the tree nodes in the tree structure; wherein, The updating, according to the execution result, of the second state data corresponding to the second block in the first data storage system to the first state data corresponding to the first block comprises: According to the execution result, in the tree structure, a number of target tree nodes corresponding to the first state variable are updated, and in the first data storage system, key-value pairs of the number of target tree nodes are updated.

3. The method according to claim 2, wherein generating a revocation log of the first block to be generated according to the execution results of the plurality of transactions included in the first block to be generated comprises: When the update type of the first state variable is modification, the first state variable is an account address including a plurality of member variables, and the execution result also includes a first variable value of the first state variable in the first state data, according to the key of the target leaf node corresponding to the first state variable in the tree structure, obtaining the value of the target leaf node from the first data storage system; Obtaining a second variable value of the first state variable from the value of the target leaf node; According to the first variable value and the second variable value, a target variable to be modified is determined from member variables included in the first state variable, and the target variable value is obtained from the second variable value.

4. The method according to claim 2, wherein generating a revocation log of the first block to be generated according to the execution results of the plurality of transactions included in the first block to be generated comprises: When the update type of the first state variable is deletion, according to the key of the target leaf node corresponding to the first state variable in the tree structure, obtaining the value of the target leaf node from the first data storage system; Obtaining a second variable value of the first state variable from the value of the target leaf node; The first state variable is used as a target variable, and the second variable value is used as a target variable value.

5. The method according to claim 2, wherein generating a revocation log of the first block to be generated according to the execution results of the plurality of transactions included in the first block to be generated comprises: When the update type of the first state variable is new addition, the first state variable is used as a target variable, and the update type of the target variable is set to new addition.

6. The method according to claim 1, further comprising: Determining a third block corresponding to the third state data to be restored; acquiring, from the second data storage system, undo logs of a plurality of fourth blocks located after the third block; Acquire, from the first data storage system, fourth state data corresponding to the latest generated fourth block; The third state data is restored according to the fourth state data and the undo logs of the plurality of fourth blocks.

7. The method according to claim 1, wherein the third block and the plurality of fourth blocks include the first block and the second block; wherein, The step of restoring the third state data according to the fourth state data and the undo logs of the plurality of fourth blocks includes: After obtaining the first state data, at least determining the first state variable and its update type according to the target variable indicated in the undo log of the first block, and the update type of the target variable and / or the target variable value of the target variable in the second state data corresponding to the second block; According to the first state variable and its update type, the first state data is updated to the second state data.

8. According to the method of claim 7, the blockchain system manages state data through a tree structure, a leaf node in the tree structure stores the value of a state variable, and the directed path from the root node to the leaf node of the tree structure stores the key of the state variable; the first data storage system stores the key-value pairs of the tree nodes in the tree structure; wherein, The updating of the first state data to the second state data according to the first state variable and its update type includes: When the update type of the first state variable is modification, the first state variable is an account address including a plurality of member variables, and the revocation log of the first block includes the target variable value of the target variable in the second state data, according to the key of the target leaf node corresponding to the first state variable, the value of the target leaf node is obtained from the first data storage system, and the first variable value of the first state variable is obtained from the value of the target leaf node; Generate the second variable value of the first state variable according to the first variable value and the target variable value; According to the second variable value of the first state variable, in the tree structure, a number of target tree nodes corresponding to the first state variable are updated, and key-value pairs of the number of target tree nodes are updated.

9. A blockchain node in a blockchain system, the blockchain node comprising: a log management unit configured to generate a revocation log of a first block to be generated according to execution results of a plurality of transactions included in the first block to be generated, wherein the execution result indicates a first state variable to be updated and its update type, the revocation log indicates a target variable to be updated, and the update type of the target variable and / or a target variable value of the target variable in second state data corresponding to a second block, the target variable being the first state variable or a member variable of the first state variable, and the second block being a previous block of the first block; A data updating unit configured to update the second state data corresponding to the second block in the first data storage system to the first state data corresponding to the first block according to the execution result; The log management unit is further configured to store the undo log of the first block in a second data storage system.

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

Images