Data access method in blockchain system and blockchain node

Abstract

A data access method in a blockchain system and a blockchain node, the blockchain node storing a state tree, the state tree including account data of each account. The method includes: receiving a first access request for accessing a first variable in a first smart contract, the first access request including a contract address of the first smart contract and a first key of the first variable; determining, according to the contract address and the first key, a second key of the first variable in the state tree, the second key being used for uniquely identifying the first variable in the state tree; and performing, according to the second key, access to the first variable in the state tree.

Description

Technical Field

[0001] The embodiments in this specification pertain to the field of blockchain, and particularly relate to a data access method and a blockchain node in a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a data access method and a blockchain node in a blockchain system.

[0004] Firstly, a data access method is provided in a blockchain system. The method is executed by a blockchain node, which stores a state tree containing account data for each account. The method includes: receiving a first access request for accessing a first variable in a first smart contract, the first access request including the contract address of the first smart contract and a first key for the first variable; determining a second key for the first variable in the state tree based on the contract address and the first key, the second key being used to uniquely identify the first variable in the state tree; and accessing the first variable in the state tree based on the second key.

[0005] Secondly, a blockchain node in a blockchain system is provided, wherein the blockchain node stores a state tree, and the state tree includes account data for each account. The blockchain node includes: a request receiving unit configured to receive a first access request for accessing a first variable in a first smart contract, the first access request including the contract address of the first smart contract and a first key of the first variable; a request processing unit configured to determine a second key of the first variable in the state tree based on the contract address and the first key, the second key being used to uniquely identify the first variable in the state tree; and a request response unit configured to access the first variable in the state tree based on the second key.

[0006] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in any one of the first aspects.

[0007] In the embodiments of this specification, blockchain nodes can organize account data of each account and contract variable data defined in each smart contract using a state tree. When an access request for accessing a contract variable in a smart contract is received, the node can redetermine the key to uniquely identify the contract variable in the state tree based on the contract address of the smart contract and the key used to uniquely identify the contract variable in the smart contract included in the access request. Then, the node can access the contract variable in the state tree using the key that uniquely identifies the contract variable. Thus, blockchain nodes can store account data of each account and contract variable data defined in each smart contract in the blockchain system using a first-level state tree, eliminating the need for a more complex second-level state tree. Furthermore, it allows blockchain nodes to accurately access contract variables in the first-level state tree in the same way they access contract variables in the second-level state tree. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used 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 those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is an architecture diagram of a blockchain system provided in the embodiments of this specification;

[0010] Figure 2 This is a schematic diagram of a blockchain data storage structure.

[0011] Figure 3 This is one of the flowcharts for a data access method in a blockchain system provided in the embodiments of this specification;

[0012] Figure 4 This is one of the schematic diagrams of a blockchain node provided in the embodiments of this specification;

[0013] Figure 5 This is a schematic diagram of a blockchain data storage structure provided in the embodiments of this specification;

[0014] Figure 6 This is a second flowchart of a data access method in a blockchain system provided in the embodiments of this specification;

[0015] Figure 7This is a flowchart illustrating the method for obtaining the state root hash of the state tree corresponding to block N+1 in the embodiments of this specification;

[0016] Figure 8 This is the second schematic diagram of the structure of a blockchain node in a blockchain system provided in the embodiments of this specification. Detailed Implementation

[0017] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0018] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transfer between nodes. These nodes can store the entire ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transactions, and each node can store the same state database.

[0019] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0020] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0021] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0022] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0023] In various blockchain networks that have introduced smart contracts, Ethereum, for example, typically categorizes accounts into two types:

[0024] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0025] Externally owned account: A user's account, such as an Ethereum owner's account.

[0026] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as nonce, balance, storageRoot, and codeHash. Nonce and balance exist in both external and contract accounts. The codeHash and storageRoot attributes are generally only valid for contract accounts.

[0027] nonce: A counter. For external accounts, this number represents the number of transactions sent from the account address; for contract accounts, it is the number of contracts created by the account.

[0028] balance: The amount of Ether held by this address.

[0029] storageRoot: The hash of the root node of an MPT tree that organizes the storage of state variables for contract accounts.

[0030] codeHash: The hash value of the smart contract code. For contract accounts, this is the code of the smart contract that has been hashed and stored; for external accounts, since the smart contract is not included, the codeHash field can be an empty string or a string of all zeros.

[0031] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0032] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (the address of the Ethereum account), distributed across the storage from the root node to the leaf nodes. The "value" in the state trie is generated by encoding the information of the Ethereum account using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, the value includes nonce and balance; for contract accounts, the value includes nonce, balance, codehash, and storageroot.

[0033] A contract account is used to store the state of a smart contract. Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has several states, defined by state variables within the smart contract and updated with new values ​​during the contract's creation and execution. A smart contract is usually a contract defined digitally in a blockchain environment that can automatically execute its terms. Once an event triggers a clause in the contract (meeting the execution conditions), the code can execute automatically. In the blockchain, the contract's state is stored in a storage trie. The hash value of the storage trie's root node is stored in the aforementioned storage root, thus locking all the contract's states to that contract account via hash. The storage trie is also an MPT tree structure, storing a key-value mapping from state addresses to state values. From the root node to the leaf node of the storage trie tree, the address of a state is stored; each leaf node stores the value of a state.

[0034] Figure 2 This is a schematic diagram of a blockchain data storage structure. Figure 2In some blockchain data storage examples, the block header of each block includes several fields, such as the previous block hash (prevHash in the diagram), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled), a timestamp, the previous block number (Block Num), the state root hash (State_Root), the transaction root hash (Transaction_Rooth), and the receipt root hash (Receipt_Rooth). The Prev Hash in the block header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block. In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block; that is, pointing to state_root is an MPT-form state tree (state trie). The root node of this MPT tree is typically an extension node or a branch node, and `state_root` usually stores the hash value of this root node. A subset of values ​​from each node from the root to the leaf nodes are concatenated sequentially to form an account address, which serves as the key. The account information stored in the leaf nodes is the value corresponding to this account address, thus forming a key-value pair. Specifically, the key can be SHA3 (Address), i.e., the hash value of the account address (using a hash algorithm such as SHA3), and the stored value can be RLP (Account), i.e., 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, generally only the nonce and balance fields are present, while the storageRoot and codeHash fields default to storing empty strings / strings of all zeros. That is to say, external accounts do not store contracts or the state variables generated after contract execution. A contract account typically includes nonce, balance, storageRoot, and codeHash. Nonce is the transaction counter for that contract account; balance is the account balance; storageRoot corresponds to another MPT (Multi-Level Transmission), which links to contract-related state information; and codeHash is the hash value of the contract code. Whether it's an external account or a contract account, its account information is generally located in a single leaf node.From the root node's ExtensionNode / Branch Node to each account's Leaf Node, it may pass through several branch nodes and extension nodes.

[0035] The state trie can be an MPT (Multi-Level Tree) structure, typically a 16-ary tree, with a maximum of 16 child nodes per level and a maximum depth of 64 levels. Extension Nodes, used to store common prefixes, generally have one child node, which can be a Branch Node. Branch Nodes can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes. Such an MPT tree can have a maximum depth of 64 levels. When the number of accounts in the blockchain reaches a certain threshold, this MPT tree may approach or reach a depth of 64 levels.

[0036] For a contract account within a state trie, its `storage_root` points to another tree, also in MPT form, which stores data related to contract variables / state variables involved in contract execution. This MPT-form tree pointed to by `storage_root` is a Storage Trie, specifically the hash value of the root node. Generally, this Storage Trie also stores key-value pairs. Data stored along the path from the root node to a leaf node is concatenated to form the key, and the leaf node stores the value. As mentioned earlier, this Storage Trie can also be an MPT-form tree, typically a 16-ary tree. This means that a Branch Node can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes. An Extension Node typically has one child node, which can be a Branch Node. This Storage Trie tree can have a maximum depth of 64 levels.

[0037] As described above in the section on blockchain data storage in related technologies, for blockchain nodes in a blockchain system that supports smart contracts, the state data corresponding to blocks is essentially organized through a two-level state tree consisting of state tries and several storage tries. Since different smart contracts may define contract variables with the same key, any two storage tries may store key-value pairs with the same key. Based on this, a blockchain node can access the account information of a relevant account in the state trie based on an external account or contract account. When accessing a contract variable within a smart contract is required, it needs to provide both the key that uniquely identifies the contract variable in the smart contract and the contract address of the smart contract to which the contract variable belongs. Then, based on the smart contract's contract address, the corresponding storage root can be found in the state trie, and the contract variable can be accessed in the storage trie pointed to by the corresponding storage root based on the contract variable's key.

[0038] This specification provides a data access method and a blockchain node in a blockchain system. The blockchain node can organize account data and contract variable data defined in smart contracts using a state tree. When it receives an access request for a contract variable in a smart contract, it can re-determine the key to uniquely identify the contract variable in the state tree based on the smart contract address and the key used to uniquely identify the contract variable within that smart contract, as included in the access request. Then, it can access the contract variable in the state tree using this unique key. In this way, the blockchain node stores account data and contract variable data defined in smart contracts using a first-level state tree, eliminating the need for a more complex second-level state tree. Furthermore, it allows the blockchain node to accurately access contract variables in the first-level state tree in the same way it accesses them in the second-level state tree.

[0039] In addition, because contract variables have a key that uniquely identifies them in the state tree, blockchain nodes can store the state tree either through a single storage node / storage engine or through a distributed storage service containing multiple storage nodes. That is, the state tree stored by a blockchain node can be split into multiple state subtrees, and these subtrees can be stored correspondingly on multiple storage nodes included in the distributed storage service.

[0040] Figure 3This is a flowchart illustrating a data access method in a blockchain system provided in the embodiments of this specification. The method can be executed by a blockchain node in the blockchain system, which stores a state tree. This state tree includes account data for each account and data including contract variables defined by several smart contracts deployed in the blockchain system. More specifically, the state tree is constructed, for example, based on key-value pairs of external accounts, key-value pairs of contract accounts, and key-value pairs of contract variables in the smart contracts, wherein the key of the contract variable in the state tree is used to uniquely identify the contract variable within the state tree. See also... Figure 3 As shown, the method may include some or all of the following steps S31 to S35.

[0041] In step S31, an access request Q1 is received for accessing a first variable in smart contract C1. The access request Q1 includes the contract address of smart contract C1 and a first key used to uniquely identify the first variable in smart contract C1.

[0042] The aforementioned first variable refers to the contract variable defined in smart contract C1. Access request Q1 may include the first key of one or more first variables defined in smart contract C1. Access request Q1 may be initiated by a blockchain node during the execution of a transaction, such as transaction Tx1, which calls smart contract C1; in this case, access request Q1 can specifically be used to request reading the value of the first variable. Alternatively, access request Q1 may be initiated by a blockchain node after completing the execution of multiple transactions belonging to any block N+1, including a transaction such as transaction Tx1 used to call smart contract C1; in this case, access request Q1 can specifically be used to request updating the value of the first variable.

[0043] A blockchain node typically includes multiple services, each responsible for different tasks during the generation of any block N. See also Figure 4As shown, a single blockchain node may include, for example, a storage service, a block management service (block_server), and several computing services (computing_server). The computing services are primarily used to execute transactions within the blockchain system. During transaction execution, they may initiate corresponding access requests as needed to retrieve account data or contract variable values ​​from the state tree stored through the storage service. The block management service is mainly used to call the computing services to execute transactions. After completing the execution of multiple transactions belonging to any block N+1, it initiates corresponding access requests based on the execution results of these transactions to request updates to the account data or contract variable values ​​of external accounts in the state tree stored through the storage service. In other words, access request Q1 may be initiated by the computing service or the block management service within the blockchain node and received by the storage service within the blockchain node.

[0044] For example, the block management service can call the computation service to execute transaction Tx1 belonging to the block N+1 to be generated. The "to" field of transaction Tx1 includes the contract address of smart contract C1, and the "data" field of transaction Tx1 includes several parameters that need to be passed to the smart contract. Then, during the execution of transaction Tx1, the computation service may execute the contract code of smart contract C1 based on the parameters included in the "data" field of transaction Tx1. During this process, it may initiate an access request Q1 to request to read the value of a first variable. In this case, the access request Q1 initiated by the computation service includes at least the contract address of smart contract C1 and the first key in smart contract C1 used to uniquely identify the first variable. It may also include the state root in the block header of block N. Taking the computing service initiating access request Q1 in the manner of accessing data in the secondary state tree as an example: Access request Q1 may include multiple parameters such as prefix, key, and state Root. The value of the stateRoot parameter is the state Root in block N, the value of the key parameter is the first key of several first variables, and the value of the prefix parameter indicates that access request Q1 is requesting access to contract variables; it is, for example, concatenated from the predefined string default_state_prefix and the contract address of smart contract C1. When access request Q1 is used to request an update to the value of a first variable, the access request also includes the value of the first variable.

[0045] In step S33, a second key is determined based on the contract address and the first key to uniquely identify the first variable in the state tree.

[0046] The contract address of smart contract C1 and the first key of a single first variable can be concatenated, and the concatenated result can be used as the second key to uniquely identify the first variable in the state tree. More specifically, for example, the contract address of smart contract C1 can be extracted from the value of the parameter prefix included in the access request Q1, and the contract address and the first key of a single first variable can be concatenated in sequence to obtain the second key to uniquely identify the first variable in the state tree.

[0047] The aforementioned step S33 can be executed by a storage service in a blockchain node, for example. The storage service can store the complete state tree through a single storage node, or it can be a distributed storage service including an interface program and multiple storage nodes such as storage nodes 0 to m. Multiple storage nodes can store multiple state subtrees that make up the state tree. The interface program is responsible for receiving access requests Q1 from the computing service or block management service. That is, the aforementioned steps S31 and S33 can be executed by the interface program.

[0048] In step S35, the first variable is accessed in the state tree according to the second key.

[0049] The storage service / interface program can provide a data reading interface for the computing service to call. This interface handles access requests from the computing service to read the value of an account and / or the value of a contract variable. It completes the process via a remote procedure call protocol, reading the value of the relevant account and / or the value of the relevant contract variable from the state subtree stored through the relevant storage nodes according to the received access request. The storage service / interface program can also provide a data update interface for the block management service to call. This interface handles access requests from the block management service to update the value of an account and / or the value of a contract variable. It completes the process via a remote procedure call protocol, updating / storing the value of the relevant account and / or the value of the relevant contract variable in the state subtree stored through the relevant storage nodes according to the received access request.

[0050] The state tree stored by blockchain nodes differs from the aforementioned Figure 2 The example shows a two-level state tree consisting of a State trie and a Storage trie. See, for example, [link to example]. Figure 5As shown, the state tree stored by a blockchain node can be an MPT-style tree. Because the contract variables Variable A and Variable B defined in the smart contract corresponding to the contract account Account B each have a key in the state tree that can be used to uniquely identify them, the key-value pairs of Variable A and Variable B can share the same parent node as accounts such as external Account A and contract account Account B; for example, their parent node might be the same Branch Node. It should be noted that because the blockchain node does not store the Storage Trie corresponding to the contract account such as Account B, the account data of the contract account such as Account B stored by the blockchain node through the state tree may not include the Storage_root field.

[0051] When a blockchain node stores the state tree corresponding to any block N through a distributed storage service that includes an interface program and multiple storage nodes, that is, when the state tree corresponding to block N is composed of multiple state subtrees stored on multiple storage nodes, for the second key corresponding to each of the first variables in access request Q1, the first storage node corresponding to each second key can be determined from the multiple storage nodes. Then, an access request Q2 corresponding to access request Q1 is provided to each first storage node, so that each first storage node can access the relevant first variables in its stored state subtree according to the second keys included in the access request Q2 and corresponding to that first storage node.

[0052] For example, in a distributed storage service, multiple storage services can be numbered sequentially starting from sequence number 0 with a step size of 1. The interface program of the distributed storage service can perform a salted hash algorithm on the second key of a single first variable, take the predetermined i-th byte from the processing result, and then send an access request Q2 corresponding to the value of the i-th byte to the storage node with the sequence number Q1 through various possible communication protocols, including remote procedure call protocols. The access request Q2 includes the second key of the first variable, so that the storage node receiving the access request Q2 can access the relevant first variable in its stored state subtree according to the second key of the first variable included in the received access request Q2, such as reading or updating / storing the value corresponding to the second key included in the access request Q2 in its stored state subtree.

[0053] Storage nodes can also store the state root hash (State_Root) of the state tree. For example, if the latest block generated by a blockchain node is block N, during the generation of block N+1, the state tree stored by the blockchain node should be the state tree corresponding to block N. Multiple storage nodes in the distributed storage service can each store the state root hash (State_Root) of the state tree corresponding to block N. When the computing service or block management service initiates an access request Q1 in the form of accessing the secondary state tree, the corresponding access request Q2 should also include the state root hash (State_Root) of the state tree corresponding to block N. In this case, the storage node receiving access request Q2 can verify whether the state root hash (State_Root) included in access request Q2 is the same as the state root hash (State_Root) of the state tree corresponding to block N stored in its own storage. If they are the same, it continues to access the relevant first variable in its stored state subtree according to the second key included in the received access request Q2.

[0054] For a storage node that receives access request Q2, after accessing the relevant first variable in its stored state subtree according to the second key included in the received access request Q2, it can also return a corresponding response message. If access request Q1 is used to request reading the values ​​of several first variables, the response message includes the values ​​of the relevant first variables, and this response message will be returned to the service that initiated access request Q1, such as the computing service in the blockchain node; if access request Q1 is used to request updating / storing the values ​​of several first variables, the response message includes confirmation information, and this response message will be returned to the service that initiated access request Q1, such as the block management service.

[0055] When a blockchain node stores the state tree through a distributed storage service comprising multiple storage nodes, the process is similar to handling the aforementioned access request Q1 for accessing several first variables, see [link to relevant documentation]. Figure 6 As shown, the blockchain node can also access the account data of the account registered in the blockchain system through the following steps S61 to S67.

[0056] In step S61, an access request Q3 for accessing the second variable is received. The access request Q3 includes the key of the second variable, wherein the key of the second variable is an account registered in the blockchain system, which can be an external account or a contract account.

[0057] Access request Q3 can be initiated by a blockchain node during the execution of a transaction, such as transaction Tx2. In this case, access request Q3 is specifically used to request the reading of the values ​​of several second variables, i.e., to request the reading of account data for one or more accounts. Alternatively, access request Q3 can be initiated by a blockchain node after completing the execution of multiple transactions belonging to any block N+1, based on the execution results of those multiple transactions. In this case, access request Q3 is specifically used to request the updating of the values ​​of one or more second variables, i.e., to request the updating of account data for one or more accounts.

[0058] When a blockchain node stores a state tree through a distributed storage service that includes an interface program and multiple storage nodes, the blockchain node can also perform the following step S63 through the interface program.

[0059] In step S63, the corresponding second storage node is determined from multiple storage nodes based on the key of the second variable.

[0060] Taking the computing service / block management service initiating access request Q3 in the manner of accessing data in the secondary state tree as an example: For the key of a single second variable in access request Q3, the interface program can extract the predetermined string default_state_prefix from the value of the parameter prefix included in access request Q3, concatenate the predetermined string default_state_prefix with the key of the second variable, process the concatenation result with a salted hash algorithm, and take the i-th byte in the processing result. The storage node with the value of the i-th byte is the second storage node corresponding to the second variable.

[0061] Access request Q3 may include one or more keys of second variables. Correspondingly, in step S53, multiple different second storage nodes may be determined for multiple different keys of second variables in access request Q3.

[0062] In step S65, an access request Q4 corresponding to access request Q3 is provided to the second storage node, so that the second storage node can access the second variable in its stored state subtree according to the key of the second variable.

[0063] For each second storage node determined in step S63, an access request Q4 corresponding to access request Q3 can be sent to the second storage node using various possible communication protocols, including remote procedure call protocols. The access request Q4 received by the second storage node includes the keys of various second variables corresponding to that second storage node. The second storage node can access the relevant second variables in its stored state subtree based on the keys of the various second variables included in the received access request Q4. For example, it can read or update the value corresponding to the relevant second variable in its stored state subtree, i.e., read or update the account data of the relevant external account / contract account.

[0064] Referring to the previous text, storage nodes can also store the state root hash (State_Root) of the state tree. For example, if the latest block generated by a blockchain node is block N, the state tree stored by the blockchain node during the generation of block N+1 should be the state tree corresponding to block N. Multiple storage nodes in the distributed storage service can all store the state root hash (State_Root) of the state tree corresponding to block N. When the computing service or block management service initiates access request Q3 in the form of accessing the secondary state tree, access request Q4 should also include the state root hash (State_Root) of the state tree corresponding to block N. In this case, the second storage node receiving access request Q4 can verify whether the state root hash included in access request Q4 is the same as the state root hash of the state tree corresponding to block N stored in its own storage. If they are the same, it will access the relevant second variable in its stored state subtree based on the key of the second variable included in the received access request Q4.

[0065] After a blockchain node completes the execution of multiple transactions belonging to any block N+1, if any of these transactions involve calling a smart contract, the blockchain node can typically initiate two types of access requests sequentially. The first type of access request could be, for example, the aforementioned access request Q1, specifically requesting the updating of the value of one or more contract variables in the state tree; the second type of access request could be, for example, the aforementioned access request Q3, specifically requesting the updating of account data for one or more accounts. For the second type of access request Q3, after updating / storing the account data of one or more accounts in one or more second storage nodes through steps S61 to S65, it can continue to execute, such as..., through the distributed storage service interface program. Figure 7 Some or all of the steps S71 to S75 of the method shown below.

[0066] In step S71, response messages are received from each of the second storage nodes. The response messages are initiated by the second storage nodes after they update the key-value pairs of the corresponding second variables in their stored state subtrees according to the access request Q4 they received. The second storage nodes are determined based on the keys of each second variable included in the transaction request Q3. The access request Q3 is initiated by the blockchain node after it completes the execution of multiple transactions belonging to block N+1, based on the execution results of those multiple transactions.

[0067] As described above, access request Q3 can be initiated by a blockchain node (e.g., a block management service) after completing the execution of multiple transactions belonging to any block N+1, based on the execution results of those transactions. Specifically, access request Q3 is used to request updates to the value of one or more second variables, i.e., to request updates to the account data of one or more accounts. Correspondingly, each second storage node mentioned in step S71 can be one or more second storage nodes determined by the interface program through the aforementioned step S63 after receiving access request Q3.

[0068] In step S73, in response to the response messages from each of the second storage nodes, a commit request is sent to multiple storage nodes, causing the multiple storage nodes to calculate and return the root node hash corresponding to their respective stored state subtrees.

[0069] Storage nodes can organize account data of several accounts and contract variable data stored through the storage node in the form of an MPT tree as described above. That is, the state subtree stored by the storage node can also be an MPT tree. Correspondingly, the storage node can calculate the root node hash of its own stored state subtree / MPT tree.

[0070] In step S75, the state root hash of the state tree corresponding to block N+1 is calculated based on the root node hashes from multiple storage nodes. The state root hash of the state tree corresponding to block N+1 is used to support the blockchain node in generating block N+1.

[0071] Merkle Trees or Merkle Patricia Trees, which combine Merkle Trees and Patricia Trees, can be constructed using the root node hashes from multiple storage nodes. The hash value corresponding to the top-level root node of the Merkle Tree or Merkle Patricia Tree is the state root hash of the state tree corresponding to block N+1.

[0072] The state root hash of the state tree corresponding to block N+1 can, for example, be returned to the block management service, causing the block management service to generate block N+1, which includes the state root hash of the state tree corresponding to block N+1. The state root hash of the state tree corresponding to block N+1 can also be provided to multiple storage nodes, allowing these nodes to change the state root hash of their stored state trees from the state root hash of the state tree corresponding to block N to the state root hash of the state tree corresponding to block N+1.

[0073] Based on the same concept as the aforementioned method embodiments, this specification also provides a blockchain node in a blockchain system, wherein the blockchain node stores a state tree, and the state tree includes account data for each account. For example... Figure 8 As shown, the blockchain node includes: a request receiving unit 81, configured to receive a first access request for accessing a first variable in a first smart contract, the first access request including the contract address of the first smart contract and a first key of the first variable; a request processing unit 83, configured to determine a second key of the first variable in the state tree based on the contract address and the first key, the second key being used to uniquely identify the first variable in the state tree; and a request response unit 85, configured to access the first variable in the state tree based on the second key.

[0074] In one possible implementation, the state tree is constructed based on key-value pairs of external accounts, key-value pairs of contract accounts, and key-value pairs of contract variables in the smart contract, wherein the key of the contract variable in the state tree is used to uniquely identify the contract variable in the state tree.

[0075] In one possible implementation, the blockchain node includes multiple storage nodes, and the state tree includes multiple state subtrees, which are correspondingly stored in the multiple storage nodes; wherein, the request response unit 85 is specifically configured to determine a first storage node from the multiple storage nodes based on the second key; and provide the first storage node with a second access request corresponding to the first access request, so that the first storage node accesses the first variable in its stored state subtree based on the second key.

[0076] In one possible implementation, the first access request and the second access request include a first state root hash corresponding to the state tree in the latest first block generated by the blockchain node, such that the first storage node, upon verifying that its stored state root hash is the same as the first state root hash, accesses the first variable in its stored state subtree according to the second key.

[0077] In one possible implementation, the first access request includes a first variable value of a reference variable, which is formed by concatenating a predetermined string and the contract address of the smart contract. The first variable value is used to indicate that the first access request is for accessing contract variables.

[0078] In one possible implementation, the blockchain node includes multiple storage nodes, and the state tree includes multiple state subtrees, which are correspondingly stored in the multiple storage nodes. The request receiving unit 81 is further configured to receive a third access request for accessing a second variable, the third access request including the key of the second variable, where the key of the second variable is an account registered in the blockchain system. The request response unit 85 is further configured to determine a second storage node from the multiple storage nodes based on the key of the second variable; and to provide the second storage node with a fourth access request corresponding to the third access request, enabling the second storage node to access the second variable in its stored state subtree based on the key of the second variable.

[0079] In one possible implementation, the third access request further includes the value of the second variable. The third access request is used to request the storage of the value of the second variable in the state tree. The third access request is initiated by the blockchain node after completing the execution of multiple transactions belonging to the second block, based on the execution results of the multiple transactions. The blockchain node further includes: a state submission unit 87, configured to obtain a response message from the second storage node. The response message is initiated by the second storage node after completing the storage of the key-value pair of the second variable in its stored state subtree. In response to the response message, a submission request is sent to the multiple storage nodes, causing the multiple storage nodes to calculate and return the root node hash corresponding to their respective stored state subtrees. A second state root hash corresponding to the state tree is calculated based on each root node hash. The second state root hash is used to support the blockchain node in generating the second block.

[0080] This specification also provides a computer-readable storage medium storing a computer program, which, when executed in a computer, causes the computer to perform the method executed by the blockchain node in the aforementioned method embodiments.

[0081] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. 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 programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0082] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take 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 means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0083] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

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

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

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

[0087] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0088] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

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

[0091] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0092] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this 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.

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

[0094] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0095] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A data access method in a blockchain system, the method being executed by a blockchain node, the blockchain node storing a state tree, the state tree including account data for each account, the state tree being constructed based on key-value pairs of external accounts, key-value pairs of contract accounts, and key-value pairs of contract variables in smart contracts, wherein the key of the contract variable in the state tree is used to uniquely identify the contract variable in the state tree, the method comprising: Receive a first access request for accessing a first variable in a first smart contract, the first access request including the contract address of the first smart contract and the first key of the first variable; Based on the contract address and the first key, a second key is determined for the first variable in the state tree, and the second key is used to uniquely identify the first variable in the state tree; Access to the first variable is performed in the state tree based on the second key.

2. The method according to claim 1, wherein the blockchain node includes multiple storage nodes, the state tree includes multiple state subtrees, and the multiple state subtrees are correspondingly stored in the multiple storage nodes; in, The step of accessing the first variable in the state tree based on the second key specifically includes: The first storage node is determined from the plurality of storage nodes based on the second key; A second access request corresponding to the first access request is provided to the first storage node, so that the first storage node can access the first variable in its stored state subtree based on the second key.

3. The method according to claim 2, wherein the first access request and the second access request include the first state root hash corresponding to the state tree in the latest first block generated by the blockchain node, so that the first storage node, upon verifying that its stored state root hash is the same as the first state root hash, accesses the first variable in its stored state subtree according to the second key.

4. The method according to claim 1, wherein the first access request includes a first variable value of a reference variable, the first variable value being formed by concatenating a predetermined string and the contract address of the smart contract, and the first variable value being used to indicate that the first access request is for accessing contract variables.

5. The method according to any one of claims 1-4, wherein the blockchain node comprises a plurality of storage nodes, the state tree comprises a plurality of state subtrees, and the plurality of state subtrees are correspondingly stored in the plurality of storage nodes; in, The method further includes: Receive a third access request for accessing a second variable, the third access request including the key of the second variable, the key of the second variable being an account registered in the blockchain system; The second storage node is determined from the plurality of storage nodes based on the key of the second variable; A fourth access request corresponding to the third access request is provided to the second storage node, so that the second storage node can access the second variable in its stored state subtree according to the key of the second variable.

6. The method according to claim 5, wherein the third access request further includes the value of the second variable, the third access request is used to request the storage of the value of the second variable in the state tree, and the third access request is initiated by the blockchain node after completing the execution of multiple transactions belonging to the second block based on the execution results of the multiple transactions; in, The method further includes: Receive a response message from the second storage node, the response message being initiated by the second storage node after it has finished storing the key-value pair of the second variable in its stored state subtree; In response to the response message, a commit request is sent to the plurality of storage nodes, causing the plurality of storage nodes to calculate and return the root node hash corresponding to their respective stored state subtrees. The second state root hash is calculated based on the hash of each root node and corresponds to the state tree. The second state root hash is used to support the blockchain node in generating the second block.

7. A blockchain node in a blockchain system, wherein the blockchain node stores a state tree, the state tree including account data for each account, the state tree being constructed based on key-value pairs of external accounts, key-value pairs of contract accounts, and key-value pairs of contract variables in smart contracts, wherein the key of the contract variable in the state tree is used to uniquely identify the contract variable in the state tree, the blockchain node comprising: The request receiving unit is configured to receive a first access request for accessing a first variable in a first smart contract, wherein the first access request includes the contract address of the first smart contract and the first key of the first variable; The request processing unit is configured to determine a second key of the first variable in the state tree based on the contract address and the first key, wherein the second key is used to uniquely identify the first variable in the state tree; The request-response unit is configured to access the first variable in the state tree based on the second key.

8. The blockchain node according to claim 7, wherein the blockchain node includes multiple storage nodes, the state tree includes multiple state subtrees, and the multiple state subtrees are correspondingly stored in the multiple storage nodes; in, The request response unit is specifically configured to determine the first storage node from the plurality of storage nodes based on the second key; A second access request corresponding to the first access request is provided to the first storage node, so that the first storage node can access the first variable in its stored state subtree based on the second key.

9. The blockchain node according to claim 8, wherein the first access request and the second access request include a first state root hash corresponding to the state tree in the latest first block generated by the blockchain node, such that the first storage node, upon verifying that its stored state root hash is the same as the first state root hash, accesses the first variable in its stored state subtree according to the second key.

10. The blockchain node according to claim 7, wherein the first access request includes a first variable value of a reference variable, the first variable value being composed of a predetermined string and the contract address of the smart contract, and the first variable value being used to indicate that the first access request is for accessing contract variables.

11. The blockchain node according to any one of claims 7-10, wherein the blockchain node comprises a plurality of storage nodes, the state tree comprises a plurality of state subtrees, and the plurality of state subtrees are correspondingly stored in the plurality of storage nodes; wherein, The request receiving unit is further configured to receive a third access request for accessing the second variable, wherein the third access request includes the key of the second variable, and the key of the second variable is an account registered in the blockchain system. The request response unit is further configured to determine a second storage node from the plurality of storage nodes based on the key of the second variable; A fourth access request corresponding to the third access request is provided to the second storage node, so that the second storage node can access the second variable in its stored state subtree according to the key of the second variable.

12. The blockchain node according to claim 11, wherein the third access request further includes the value of the second variable, the third access request being used to request that the value of the second variable be stored in the state tree, and the third access request being initiated by the blockchain node after completing the execution of multiple transactions belonging to the second block based on the execution results of the multiple transactions; wherein, The blockchain node further includes: a state submission unit configured to obtain a response message from the second storage node, the response message being initiated by the second storage node after it has completed storing the key-value pairs of the second variable in its stored state subtree; in response to the response message, sending a submission request to the plurality of storage nodes, causing the plurality of storage nodes to calculate and return the root node hash corresponding to their respective stored state subtrees; and calculating a second state root hash corresponding to the state tree based on each of the root node hashes, the second state root hash being used to support the blockchain node in generating the second block.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-6.

Images