Transaction execution method and node in a blockchain system

Abstract

A transaction execution method and a blockchain node in a blockchain system, a plurality of states in the blockchain system are stored in a storage device, the node stores verification data, the verification data corresponds to the plurality of states, and the method comprises: reading a first state from the storage device according to a first transaction to be executed; verifying the first state based on the verification data; in the case where the verification is passed, executing the first transaction based on the first state to obtain a second state to be written into the storage device; and updating the verification data based on the second state.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction execution method and 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 has received increasing attention and application. In a blockchain system, full nodes are generally used as the minimum requirement for participating in consensus; a full node needs to include all data to support the consensus function. Summary of the Invention

[0003] The purpose of this invention is to provide a lightweight consensus node and consensus scheme in a blockchain system, which can greatly save storage resources in the blockchain system and improve system efficiency.

[0004] This specification provides a transaction execution method in a blockchain system, executed by nodes in the blockchain system, wherein multiple states of the blockchain system are stored in a storage device, and the nodes store verification data corresponding to the multiple states. The method includes:

[0005] Based on the first transaction to be executed, read the first state from the storage device;

[0006] The first state is verified based on the verification data;

[0007] If the verification is successful, the first transaction is executed based on the first state to obtain a second state to be written to the storage device;

[0008] The verification data is updated based on the second state.

[0009] A second aspect of this specification provides a node in a blockchain system, wherein multiple states of the blockchain system are stored in a storage device, the node stores verification data, and the verification data corresponds to the multiple states. The node includes:

[0010] A read unit is used to read a first state from the storage device based on the first transaction to be executed;

[0011] A verification unit is used to verify the first state based on the verification data;

[0012] An execution unit is configured to execute the first transaction based on the first state if the verification is successful, thereby obtaining a second state to be written to the storage device;

[0013] An update unit is used to update the verification data based on the second state.

[0014] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0015] The fourth aspect of this specification provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0016] The scheme in the embodiments of this specification stores only the verification data in each LVP and maintains the state in the storage device. This allows the LVP to verify the state read from the storage device based on the verification data, thereby participating in the consensus and transaction execution process. This greatly saves the hardware and time costs of data storage in the blockchain system and improves the performance and efficiency of the blockchain system. Attached Figure Description

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

[0018] Figure 1 A blockchain architecture diagram in one embodiment is shown;

[0019] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0020] Figure 3 This is a schematic diagram of the blockchain data storage structure of consensus nodes in related technologies;

[0021] Figure 4 This is a schematic diagram of the MPT tree structure;

[0022] Figure 5 This is a schematic diagram of the state hash tree and storage hash tree in the LVP of the embodiments of this specification;

[0023] Figure 6 This is a schematic diagram of the state hash value tree in the embodiments of this specification;

[0024] Figure 7This is a schematic diagram of another verification data tree in the LVP of the embodiments of this specification;

[0025] Figure 8 This is a schematic diagram of another verification data tree in the LVP of the embodiments of this specification;

[0026] Figure 9 This is a flowchart of the transaction execution method in the embodiments of this specification;

[0027] Figure 10 This is an architecture diagram of a node in a blockchain system according to an embodiment of this specification. Detailed Implementation

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

[0029] 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 transmission between nodes.

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

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

[0032] 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 1 In 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.

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

[0034] The consensus mechanism in blockchain is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. In various consensus algorithms, consensus on a consensus proposal is typically determined after a predetermined number of consensus nodes reach agreement on the data to be agreed upon. Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated; that is, consensus is considered successful when 2f+1 out of N consensus nodes reach agreement. In related technologies, to achieve consensus, the entire ledger is stored on the consensus nodes, storing the state of all blocks and all accounts. Thus, each node in the blockchain can produce the same state in the blockchain by executing the same transaction, so that each node in the blockchain stores the same state database.

[0035] Figure 2This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2 As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can proceed to the commit phase. For example, if... Figure 2 As shown, after receiving the signatures from nodes n2 and n3, node n1 verifies that both signatures are correct for the consensus proposal, thus determining that the preparation phase is complete. Similarly, after receiving and verifying the signatures from node n3 and node n1 (from the preparation phase), node n2 determines that the preparation phase is complete. In the commit phase, each consensus node signs the consensus proposal and sends it to the other consensus nodes. Each consensus node, after receiving the commit phase signatures from 2f = 2 other consensus nodes, determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures from nodes n2 and n3, node n1 determines that the commit phase is complete. Therefore, node n1 can execute the multiple transactions according to the consensus proposal, generate and store a block (e.g., block N) including the multiple transactions, update the world state based on the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, update the world state based on the execution results of the multiple transactions, and generate and store block N. Through the above process, storage consistency is achieved among nodes n1, n2, and n3. In other words, even with the presence of a malicious node, nodes n1 through n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block.

[0036] Figure 3 This is a schematic diagram of the blockchain data storage structure for consensus nodes in related technologies. Figure 3 In the blockchain data storage shown, each block's header includes several fields, such as the previous block hash (prev Hash 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, a block number (Block Num), a state tree root hash (State_Root), a transaction tree root hash (Transaction_Root), and a receipt tree root hash (Receipt_Root). The Prev Hash in the header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the block hash value of the previous block (i.e., the hash value of the block header). 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 state trie, which consists of the states of all accounts in the current block. This state trie can be, for example, an MPT tree (Merkle Patricia Tree).

[0037] MPT trees are tree structures that combine Merkle trees and Patricia trees (compressed prefix trees, a more space-efficient trie tree). The Merkle tree algorithm calculates a hash value for each leaf node, then joins each node pairwise and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, which is, for example, a 16-ary tree structure.

[0038] The state tree contains key-value pairs representing the stored content for each account on the Ethereum network. The "key" in the state tree can be a 160-bit identifier (the address of the Ethereum account), and the characters in this address are distributed across nodes along the path from the root node to a leaf node of the state tree. (See reference) Figure 3 As shown, the leaf nodes of the MPT state tree (e.g., nodes t4 and t5) also include the values ​​for each account. Specifically, when the account is a user account (also known as an external account), for example... Figure 3 Account A in the context of the database has a Value that includes a Nonce and a Balance. When the account is a contractual account, for example... Figure 3Account B in the context of the database has a Value that includes a Nonce, a Balance, a CodeHash, and a Storage_root hash. The Nonce represents the number of transactions sent from the account address for external accounts, and the number of contracts created by the account for contract accounts.

[0039] The nodes in the state tree are connected by hashes. Specifically, a hash value can be generated based on the data in the child nodes of the parent node, and the generated hash value is stored in the parent node. Figure 4 This is a schematic diagram of the MPT tree structure. Assume... Figure 4 The node labeled "t2" corresponds to Figure 3 In the state tree, node t2 corresponds to the node labeled "t4". Figure 3 The leaf node t4 in the state tree. For example... Figure 4 As shown, Figure 4 The states contained in each leaf node are represented as state1, state2, state3, and state4, respectively, and each state is also the value of each account. Figure 4 The characters in the left-hand box of each node are used to index the account. The characters in each node along the path from the leaf node to the root node are concatenated to form the account address corresponding to that leaf node. For example, the nodes from the leaf node containing state1 to the root node include the characters "f", "5", and "324", so the account address corresponding to state1 is "f5324".

[0040] exist Figure 4 In the example, the child nodes of the node containing "5" include leaf nodes. When calculating the hash(324,74) contained in this node, it can be calculated using the following formula (1):

[0041] hash(324,74)=hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)

[0042] In other words, in calculation Figure 4 When calculating the hash value of leaf node t4 (hash(324, hash(state1)), the hash value of "324" in node t4 is concatenated with the hash value of state1 (hash(state1),) and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. Figure 4When hashing a non-leaf node (e.g., a node containing "74") using hash(74, hash(a, c)), the data in that node is directly concatenated, and then the hash value is calculated from the concatenated data. It can be understood that the hash value of a node in the state tree is calculated based on all the data of that node. The hash value of a non-leaf node, and a non-root node, is obtained by concatenating the hash values ​​of all its child nodes and then taking the hash value.

[0043] This allows us to calculate the hash value included in each node between the leaf node and the root node in the state tree from bottom to top, thus ultimately allowing us to obtain the calculated hash value. Figure 3 The hash value of node t2 is concatenated with the hash value of node t3, and the hash of the concatenated data is then taken to generate the hash value of node t1. The hash value of node t1 is the state root of this state tree and is recorded in the State_Root field of block N.

[0044] In one variant of the MPT tree, branch nodes may be included. Each branch node can connect to multiple child nodes, and each branch node includes the hash value of the data in each of its connected child nodes. That is, each branch node includes multiple hash values ​​corresponding to multiple master nodes. Leaf nodes are connected after the branch nodes. This variant also includes extension nodes, which can be connected before or after the branch nodes. Each extension node has one child node and includes the hash values ​​of all the data in its connected child nodes. Similarly, in this MPT tree variant, the hash value of the root node can be recursively obtained based on the nodes at each level. The embodiments described in this specification are also applicable to this MPT tree variant.

[0045] The state tree can also include, for example, a sparse Merkle Tree (SMT). In an SMT tree, multiple subtrees correspond to multiple blocks. The version number of the root node of each subtree corresponds to the block number. The hash value of the root node of the state tree can be obtained by hashing the hash values ​​of the root nodes of the multiple subtrees. Each leaf node in a subtree includes the node's state version number, the corresponding key, and the state value. In the subtree with the largest version number of the root node, the version numbers of each leaf node represent the latest version of the account or variable corresponding to that leaf node. In an SMT tree, a state can be uniquely identified based on the version number and key. Similarly, the hash value of the root node can be recursively obtained based on the nodes at each level in this SMT tree. The embodiments in this specification are also applicable to this type of SMT tree.

[0046] Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has some state, which is defined by state variables within the smart contract and generates new values ​​during the creation and execution of the smart contract. For example... Figure 3 As shown, the contract's relevant state is stored in a storage trie. Figure 3 The diagram illustrates the storage tree of the contract corresponding to account B. The hash value of the root node st1 is stored in the aforementioned storage_root, thus locking all states of the contract to the Value (i.e., account state) of the contract account in the state tree through the root hash. The storage tree can also have an MPT tree structure, similar to... Figure 4 Similarly, in the illustrated state tree, each node on the path from the root node to a leaf node can include characters used to address variable names, and the leaf nodes store the values ​​of the variables, thus storing a key-value mapping from variable names (also called state addresses) to state values. For example, see [reference]. Figure 3 The storage tree in the storage tree has leaf nodes st2 and st3, which include, for example, the value of variable a and the value of variable b. Taking variable a as an example, the characters included in each node in the node path from the root node to the leaf node st2 in the storage tree constitute the variable name of variable a. This variable name can be similarly composed of hexadecimal characters.

[0047] The calculation of the hash value of each node in the storage tree can refer to the method for calculating the hash value of nodes in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash value of a portion of the key included in the leaf node and the hash value of the state in the leaf node are concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. When calculating the hash value of a non-leaf node and a non-root node in the storage tree, the data in the node is directly concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of that node.

[0048] In summary, an FVP node includes tree-like state data. The leaf nodes of this state data include the state of an account or contract variable. Each node in the path from the root node to the leaf node in the state data includes the key of the state. The parent node in the state data includes a hash value calculated based on the data in its child nodes.

[0049] Still referencing Figure 3In a blockchain, after executing block N, nodes reach a consensus on the next batch of transactions. Once consensus is reached, they execute block N+1, generating state data corresponding to block N+1, similar to the process of executing block N. This state data includes a state tree and storage trees for each contract. Data in block N+1 that overlaps with the state data of block N can reference data from block N without needing to be stored repeatedly. However, storing complete block and state data at each consensus node would require significant storage space.

[0050] This specification provides a Light Validating Peer (LVP) in its embodiments. The LVP only stores the verification data of the state, such as the hash value data in the state tree and storage tree, but does not store the value of each account or variable in the state tree and storage tree (i.e., each state). At the same time, the value of each account or variable in the state tree and storage tree is stored in a storage device outside the blockchain system. In this way, the blockchain system can still achieve consensus by including multiple LVPs, and execute transactions based on the state read from the storage device after the consensus is successful. Figure 5 This is a schematic diagram of the state hash tree and storage hash tree in the LVP of the embodiments of this specification. Figure 5 As shown, in the state hash tree and storage hash tree of LVP, with Figure 3 Compared to the state tree and storage tree in FVP, the state in the leaf nodes of the state tree and storage tree is replaced with the hash value of that state. For example, state1 in node t4 of the state tree is replaced with hash(state1) in node t4 of the state hash tree, and state5 in node st2 of the storage tree is replaced with hash(state5) in node st2 of the storage hash tree. Figure 6 for Figure 5 A schematic diagram of the state hash tree in the image. (See diagram below.) Figure 6 As shown, in the state hash tree, the leaf nodes include the last character of the account address and the state hash value of the corresponding leaf node in the state tree. For example, leaf node t4 in the state hash tree includes the hash(state1) of "state1" in leaf node t4 of the state tree. The hash values ​​included in each node in the state hash tree, except for the leaf nodes and the root node, can be generated using the same calculation method as in the state tree. For example, Figure 6 The hash(324,74) of the node containing "5" can be calculated using the formula (1) above. The storage hash tree can also have... Figure 6 The structure shown is similar to the structure shown.

[0051] Figure 5and Figure 6 The state hash tree and storage hash tree shown can be used to verify the state read from the storage device; therefore, this data can be collectively referred to as verification data. It is understood that verification data is not limited to including, for example, […]. Figure 5 or Figure 6 The structure shown, for example, allows the verification data to include at least the hash values ​​of the states of the state tree and the leaf nodes of the storage tree for verifying the read set. For the MPT tree variant described above, simply deleting the states from the leaf nodes of the MPT tree variant allows the resulting hash value tree to be used as the verification data in the LVP node.

[0052] Figure 7 This is a schematic diagram of another verification data tree in the LVP implementation of this specification. Figure 7 As shown, the leaf nodes in the verification data can include a Content-ID (CID) for the state, used for state verification. The hash values ​​included in each parent node of this verification data tree are generated based on the data of all its child nodes. For example, hash(324, 74) = hash(hash(324, CID(state1)), hash(74, hash(a, c))). This verification data tree can be applied to scenarios where state is stored in a decentralized network such as IPFS, where the state CID can be associated with the state, allowing the state to be retrieved from IPFS based on the state CID.

[0053] Figure 8 This is a schematic diagram of another verification data tree in the LVP implementation of this specification. Figure 8 As shown, this validation data tree corresponds to the SMT tree. Each node in this tree includes a version number, which indicates the number of times the data in that node has been updated. Similar to the SMT tree, this validation data tree can also include multiple subtrees. Figure 8 The image shows a subtree in the validation data tree, where... Figure 8 Node s1 is the root node of this subtree. Node s1 includes a version number and a hash value. Each node under the root node of the subtree includes a version number, an index character, and a hash value. The hash value included in the parent node of this verification data tree is also generated based on the data of all its child nodes, for example:

[0054] hash(324,74)=hash(hash(50,324,hash(state1)),hash(70,74,hash(a,c))).

[0055] Leaf node s4 includes the version number 50 of state1, the index data of state1 (i.e., the characters in the key) 324, and the hash value of state1, hash(state1). Assuming the version number 100 of the root node corresponds to the current maximum block number, the version numbers in each leaf node of this subtree represent the latest version of the state of that account or variable. For example, version number 50 in leaf node s4 represents the latest version of the state1 of account f5324, meaning that account f5324 has been written to 50 times in 100 blocks. This verification data tree can be applied to scenarios where state is stored in centralized networks such as NAS, where the state version number and state key can be associated with the state, allowing the state to be read from the NAS based on the version number and key.

[0056] Figure 9 This is a flowchart of the transaction execution method in the embodiments of this specification. This method can be executed by multiple LVPs and storage devices in a blockchain system. Assume that LVP1 is the master node among the multiple LVPs, and the other LVPs in the blockchain system are slave nodes. The master node is responsible for initiating a consensus proposal to reach consensus with the slave nodes on the proposal, and the master node can write state to the storage device. Slave nodes can read state from the storage device but do not write data to the storage device; other operations of the slave nodes (including steps S903, S905, and S907) are the same as those of the master node. The following description uses LVP1 as an example.

[0057] like Figure 9 As shown, firstly, in step S901, LVP1 reads the first state from the storage device.

[0058] LVP1 can receive transactions sent by users from user clients or other FVPs. These transactions can be transfers or transactions that invoke contracts, etc. After receiving a certain number of transactions, LVP1 can select several transactions from the received transactions for consensus to generate new blocks.

[0059] LVP1 can generate a consensus proposal for reaching a consensus on the order of multiple transactions. In one implementation, the consensus proposal may include a transaction list of the multiple transactions, which includes the transaction bodies of the multiple transactions arranged in sequence. In another implementation, the consensus proposal may include transaction identifiers (such as the hash values ​​of each transaction) of the multiple transactions arranged in sequence. Furthermore, LVP1 can broadcast the transaction bodies of each transaction to other nodes, thereby reducing the data size of the consensus proposal and saving computational resources used for signing during the consensus process.

[0060] After each LVP successfully reaches consensus on a consensus proposal, it can execute the multiple transactions according to the order in which they are arranged in the consensus proposal. For example, when LVP1 executes each of the multiple transactions, it can read the state from the storage device based on the read operation included in the transaction (to distinguish it from the state written below, the read state is referred to as the first state and the state written to the storage device is referred to as the second state) for use in executing the transaction.

[0061] Suppose that transaction Tx1, one of the multiple transactions, includes updating the balance of account A (e.g., reducing a preset amount). When this transaction is executed, it first needs to read the value of account A (i.e., including the Nonce and Balance). Then, based on the read value of account A, it obtains the new value of account A. For example, according to the transaction, the Nonce value is incremented by 1, and the Balance value is reduced by a preset amount, resulting in the updated Nonce and Balance values ​​of account A, which constitute the updated value of account A. Therefore, LVP1 needs to read the state of account A when executing this transaction. Simultaneously, the write set of this transaction also includes writes to account A. Suppose that LVP1's reading of the state of account A in transaction Tx1 is the first time it has read the state of account A during the execution of multiple transactions. That is, LVP1 does not have the previously read state of account A cached locally, and LVP1 needs to read the state of account A from the storage device.

[0062] Specifically, in one implementation, LVP1 stores as follows: Figure 6 The verification data shown is stored in the storage device with the state hash value associated with the state. LVP1 can retrieve it from... Figure 6 The state hash value hash(state1) corresponding to account A is obtained from the leaf node corresponding to account A in the verification data shown. Then, LVP1 can send a read request to the storage device, which includes hash(state1), to read state1 corresponding to hash(state1) from the storage device.

[0063] In one implementation, LVP1 stores, for example, Figure 7 The verification data shown is stored in the storage device with the CID of the state associated with the state. LVP1 can retrieve it from... Figure 7 The CID(state1) corresponding to account A is obtained from the leaf node corresponding to account A in the verification data shown. Then, LVP1 can send a read request to the storage device, which includes the CID(state1), to read the state1 corresponding to the CID(state1) from the storage device.

[0064] In one implementation, LVP1 stores, for example, Figure 8The verification data shown indicates that the storage device associates the version number of the latest state (state1) of account A with the key of account A and stores it in association with state1. LVP1 can retrieve the data from the storage device. Figure 8 The latest state of account A is obtained from the leaf node corresponding to account A in the verification data shown. Then, LVP1 can send a read request to the storage device, which includes the version number (50) and the key of account A (i.e., f5324), to read state1 corresponding to the version number (50) and the key of account A (i.e., f5324) from the storage device.

[0065] Suppose that transaction Tx2 in these multiple transactions includes an update operation on variable 'a' in the contract corresponding to account B. Since writing to variable 'a' will result in an update to Storage_root in account B, this transaction also includes a write operation to account B. To write to account B and variable 'a', this transaction needs to read the key-value pairs of account B and variable 'a' during execution. Assuming that this transaction's read of account B and variable 'a' is the first read of account B and variable 'a' during the execution of multiple transactions, LVP1 can similarly read the state of account B and the state of variable 'a' from the storage device. The state of account B includes the values ​​of the Nonce, Balance, CodeHash, and Storage_root fields of account B. The state of variable 'a' includes the state value of variable 'a'.

[0066] In step S903, LVP1 verifies the first state based on the verification data.

[0067] In one implementation, LVP1 stores the hash values ​​of each state in the blockchain system, along with index data (e.g., account address or variable name) to that hash value as verification data, such as hash(state1) mentioned above. After reading the state1 of account A, LVP1 can use hash(state1) from the verification data to verify the read state1.

[0068] In another implementation, the LVP stores, for example... Figure 5The state hash tree and storage hash tree shown serve as verification data. After retrieving the state from the storage device, LVP can perform Simplified Payment Verification (SPV) on each read state based on the state hash tree and storage hash tree. For example, if the read state includes the value of account A, LVP can calculate the hash value (e.g., hash1) of the read account A value. Based on the values ​​of other leaf nodes in the state hash tree (i.e., state hash values) and hash1, it calculates the hash values ​​of each node layer by layer upwards until it calculates the root hash value (e.g., root1). It then determines whether root1 matches the root hash value of the state hash tree stored in LVP. If they match, the read account A value is considered correct. Similarly, when LVP1 reads the value of account B and the value of variable a from the storage device, LVP1 can perform SPV verification on the account B value and the variable a value based on the state hash tree and storage hash tree.

[0069] In one implementation, when the verification data corresponding to the above-mentioned MPT tree variant is stored in LVP1, since the verification data similarly includes the hash values ​​of each state in the MPT tree variant, and the nodes of each layer in the verification data are connected by hashes, the read state can be similarly verified based on the verification data, which will not be elaborated here.

[0070] In another implementation, LVP1 stores, for example... Figure 7 The verification data shown can similarly include verification data trees corresponding to the state tree and storage tree, respectively. After LVP reads, for example, the state of account A from the storage device, it can calculate the state CID of account A based on the read state of account A, and use the CID (state1) in the verification data to verify the calculated state CID of account A, thereby verifying the read state of account A. Similarly, LVP1 can also be based on... Figure 7 The verification data shown is used to perform SPV verification on the calculated CID of account A in order to verify the read status of account A.

[0071] In another implementation, LVP1 stores, for example... Figure 8 The verification data shown can similarly include verification data trees corresponding to the state tree and storage tree, respectively. After LVP reads, for example, the state of account A from the storage device, it can use the leaf node corresponding to account A in the verification data (i.e., Figure 8The hash(state1) in node s4) verifies the state of account A. Similarly, LVP1 can also verify the state of account A based on the hash(state1) in node s4. Figure 8 The verification data shown is used to perform SPV verification on the status of the read account A.

[0072] In addition, LVP can also store the block headers of each block, such as Figure 3 As shown, the block header may include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree. The block header can be used to perform SPV verification on data such as transactions and receipts, and can also be used to generate the block header of the next block.

[0073] In step S905, LVP1 executes the transaction according to the first state and obtains the written second state.

[0074] When executing a transaction, LVP1 verifies the state read from the storage device and then executes the transaction based on the read state of the account or variable. Based on the write operations on the account or contract variable within the transaction, it obtains a write set for the transaction. This write set includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables, used to update the state of the corresponding account or contract variable. After reading the state of an account or contract variable from the storage device, LVP1 can cache this state and update the cached state of the account or contract variable when performing a write operation, for use in subsequent reads of the account or contract variable's state during transaction execution.

[0075] Specifically, assuming that transaction Tx1 among the multiple transactions mentioned above includes updating the balance of account A, and assuming that LVP1 reads the value of account A from the storage device as V1, LVP1 updates V1 according to the transaction to obtain the updated value of account A (assuming this value is V2), where V2 includes the updated Nonce value and the updated Balance value, so that the updated key-value pair of account A can be written into the write set of transaction Tx1, and the state value of account A in the cache can be updated.

[0076] As described above, transaction Tx2 in multiple transactions includes writing to variable 'a' in the contract corresponding to account B. LVP1 reads the value of account B from the storage device as V3 and the value of variable 'a' as V4. Based on this transaction, V4 is processed to obtain the updated value of variable 'a' (let's say V5). The hash value of V5 is calculated and substituted into... Figure 5The storage hash tree in the data is used to calculate the hash value of the root node st1. The hash value of the root node st1 is used as the storage_root for the update of account B. Combined with the Nonce, Balance and CodeHash of account B read from the storage device, the updated value of account B (let's assume it is V6) is calculated. Thus, the key-value pair for the update of account B and the key-value pair for the update of variable a can be included in the write set of transaction Tx2.

[0077] Optionally, after multiple LVPs in the blockchain system have completed the execution of the multiple transactions as described above, they can reach a consensus on the execution results of the multiple transactions.

[0078] Consensus nodes (i.e., LVP) can similarly pass through Figure 2 The consensus process shown achieves consensus on the execution results of multiple transactions. Specifically, after executing multiple transactions and obtaining the write sets and receipts for each transaction, each consensus node calculates the state tree root hash value, transaction tree root hash value, and receipt tree root hash value corresponding to each transaction based on the transaction bodies, write sets, and receipts. Based on the state tree root hash value, transaction tree root hash value, receipt tree root hash value, and the block hash of the previous block (i.e., the block header hash value, such as...),... Figure 3 The Prev Hash (as shown in the diagram) calculates the block hash (i.e., the block header hash of block B1) of the block corresponding to these multiple transactions. LVP1 can send a consensus proposal to other consensus nodes during the PP phase, which includes the block hash of block B1. After receiving this consensus proposal, other LVPs can compare the block hash received from LVP1 with their own calculated block hash of block B1. If they match, they sign the block hash and send it to the other consensus nodes. This completes the process. Figure 2 After the PP, P, and C phases, consensus on the block hash is achieved. Once the consensus nodes have reached a consensus on the block hash, it ensures that the execution results of multiple transactions are consistent across all nodes, allowing each node to update its verification data based on the execution results of multiple transactions.

[0079] In step S907, LVP1 updates the verification data according to the second state.

[0080] Specifically, after obtaining the write sets of each transaction, LVP1 generates a corresponding write set (e.g., wset1) based on these write sets. This wset1 includes key-value pairs of accounts used to update the state of the blockchain system, or key-value pairs of contract accounts and contract variables, based on the write operations of the multiple transactions. The updated state in wset1 is then stored in a storage device. After successful consensus on the execution results of the multiple transactions, each LVP (including LVP1) can update its verification data based on the states (i.e., second states) in wset1.

[0081] In one implementation, the verification data in an LVP includes hash values ​​of the states of each account and each contract variable. Taking LVP1 as an example, assuming that write set wset1 includes key-value pairs for account A that will be written to storage, LVP1 can find the storage location of the hash value corresponding to the key in the verification data based on the key of account A in wset1, calculate the state hash value of account A in wset1, and write the hash value of the state of account A to the storage location. It is understood that other LVPs also update their local verification data in a similar manner to LVP1.

[0082] Assuming the write set wset1 contains key-value pairs for account B and variable a, LVP1 first calculates the updated state hash based on the updated value of variable a and updates the state hash of variable a in the verification data. Then, LVP calculates the updated state hash based on the updated value of account B and updates the state hash of account B in the verification data.

[0083] In another implementation, the verification data in LVP includes, for example: Figure 5 The diagram shows the state hash tree and the storage hash tree. Taking LVP1 as an example, LVP1 can first update the state hash values ​​in the leaf nodes corresponding to multiple states in the write set in the state hash tree and the storage hash tree, as described in the previous embodiment. Then, based on the updated leaf nodes, the hash values ​​included in each level of nodes in the state hash tree and the storage hash tree can be updated upwards until the hash value of the root node of the state hash tree and the storage hash tree is updated.

[0084] In another implementation, the verification data in LVP includes, for example: Figure 7 The verification data is shown below. For example, LVP1 can first calculate the CID of each state in the write set wset1, and update the CID in the leaf nodes of the verification data corresponding to each state in the write set. Then, based on the updated leaf nodes, the hash values ​​included in each level of nodes in the verification data can be updated upwards until the hash value of the root node of the verification data is updated.

[0085] In another implementation, the verification data in LVP includes, for example: Figure 8 The verification data is shown below. For example, LVP1 can first calculate the hash value of each state in the write set wset1, and update the state hash value in the leaf node corresponding to each state in the write set in the verification data. Then, based on the updated leaf node, the hash values ​​included in each level of nodes in the verification data can be updated upwards until the hash value of the root node of the verification data is updated.

[0086] In addition, after reaching consensus on the block hash, each LVP can store the block header of the generated block for SPV verification and for generating the next block.

[0087] In step S909, LVP1 stores the second state to the storage device.

[0088] The storage device can be a decentralized storage system, such as the InterPlanetary File System (IPFS). In IPFS, states can be stored in association with their CIDs. Therefore, when LVP1 stores... Figure 7 In the scenario of the verification data shown, the generated state CID can be stored in the storage device in association with the state. Thus, when LVP1 reads the state, it can obtain the CID corresponding to the state from the verification data and read the state from the storage device based on the CID.

[0089] The storage device shown can also be a centralized storage system, such as Network Attached Storage (NAS). In NAS, the corresponding... Figure 8 The verification data shown can store the state version number and key in association with the state in a storage device.

[0090] It is understood that storage devices are not limited to the methods described above; for example, corresponding to Figure 6 The verification data shown can also be stored in the storage device by associating the hash value of the state with the state, or by associating the key of the state with the state, etc.

[0091] In addition, LVP1 will also store the generated blocks in the storage device.

[0092] The scheme in the embodiments of this specification stores only the verification data in each LVP and maintains the state in the storage device. This allows the LVP to verify the state read from the storage device based on the verification data, thereby participating in the consensus and transaction execution process. This greatly saves the hardware and time costs of data storage in the blockchain system and improves the performance and efficiency of the blockchain system.

[0093] Figure 10 This is an architecture diagram of a node in a blockchain system according to an embodiment of this specification. Multiple states in the blockchain system are stored in a storage device. The node stores verification data, which corresponds to the multiple states. The node is used to execute... Figure 9 The method shown includes:

[0094] Reading unit 101 is used to read a first state from the storage device according to the first transaction to be executed;

[0095] Verification unit 102 is used to verify the first state based on the verification data;

[0096] Execution unit 103 is configured to execute the first transaction based on the first state when the verification is successful, thereby obtaining a second state to be written to the storage device;

[0097] The update unit 104 is used to update the verification data based on the second state.

[0098] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 9 The method shown.

[0099] This specification also provides a node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements, as described above. Figure 9 The method shown.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0113] 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, for system embodiments, since they are basically similar to method embodiments, 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. Moreover, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate different embodiments or examples and features described in this specification. The above descriptions are merely embodiments of one or more embodiments of this specification and are not intended to limit the scope of one or more embodiments of this specification. For those skilled in the art, various modifications and variations can be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A transaction execution method in a blockchain system, executed by nodes in the blockchain system, wherein multiple states in the blockchain system are stored in a storage device outside the blockchain system, and the nodes store verification data corresponding to the multiple states, the method comprising: Based on the first transaction to be executed, read the first state from the storage device; The first state is verified based on the verification data; If the verification is successful, the first transaction is executed based on the first state to obtain a second state to be written to the storage device; The verification data is updated based on the second state.

2. The method according to claim 1, wherein the node is the master node, and the method further includes: The second state is stored in the storage device.

3. The method according to claim 2, wherein the plurality of states are stored in a storage device in association with their respective Content Identifiers (CIDs), the verification data includes a plurality of CIDs corresponding to the plurality of states respectively, and the step of reading the first state from the storage device according to the first transaction to be executed includes: Based on the first transaction to be executed, the first CID is read from the position corresponding to the first state in the verification data, and the first state is read from the storage device based on the first CID.

4. The method according to claim 3, wherein updating the verification data based on the second state comprises: Generate a second CID corresponding to the second state, and update the CID in the verification data at the position corresponding to the second state to the second CID.

5. The method according to claim 4, wherein the verification data is tree-structured data, the multiple leaf nodes of the verification data respectively include the multiple CIDs, the parent node in the verification data includes a hash value generated based on the data of its various child nodes, and updating the verification data based on the second state further includes: Update at least a portion of the hash value in the verification data based on the second CID.

6. The method according to claim 5, wherein verifying the first state based on the verification data includes: Calculate the third CID of the first state read, obtain the first CID from the verification data at the position corresponding to the first state, and determine whether the first CID and the third CID are consistent.

7. The method according to claim 6, wherein verifying the first state based on the verification data further comprises: SPV verification is performed on the third CID based on the verification data.

8. The method according to claim 2, further comprising: A block is generated based on the execution results of multiple transactions, including the first transaction. The execution results of the multiple transactions include a second state to be written to the storage device. The block header of the block is stored locally, and the block is stored in the storage device.

9. The method according to claim 2, wherein updating the verification data based on the second state includes updating the data in the verification data at the position corresponding to the second state to the version number, index address, and hash value of the second state, and storing the second state in a storage device includes: The second state is stored in association with its version number and index address.

10. The method according to claim 8, wherein updating the verification data based on the second state comprises: To reach a consensus with other nodes on the hash value of the block; After the consensus is successful, the verification data is updated based on the second state.

11. The method according to claim 1 or 2, wherein the storage device is a decentralized storage device or a centralized storage device.

12. A node in a blockchain system, wherein multiple states in the blockchain system are stored in a storage device outside the blockchain system, the node stores verification data, the verification data corresponding to the multiple states, the node comprising: A read unit is used to read a first state from the storage device based on the first transaction to be executed; A verification unit is used to verify the first state based on the verification data; An execution unit is configured to execute the first transaction based on the first state if the verification is successful, thereby obtaining a second state to be written to the storage device; An update unit is used to update the verification data based on the second state.

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-11.

14. A node in a block system, comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-11.

Images