Transaction execution method in blockchain system, consensus node and blockchain system

Abstract

A transaction execution method in a blockchain system, a consensus node and the blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data, the state data comprising a plurality of states, the second consensus node storing verification data, the verification data being used for verifying the plurality of states, the method being performed by the second consensus node and comprising: receiving a consensus proposal from the first consensus node, the consensus proposal comprising a read set of a plurality of transactions to be executed and an arrangement order of the plurality of transactions, the read set comprising a first state read according to the plurality of transactions; executing the plurality of transactions according to the read set and the arrangement order in parallel while verifying the read set based on the verification data, to obtain a write set, the write set comprising a second state used for updating the state data; performing consensus on the consensus proposal according to a result of the verifying; and updating the verification data according to the write set in a case where the consensus is successful.

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, consensus node and blockchain system 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 transaction execution 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, the blockchain system including a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, and the method being executed by the second consensus node, including:

[0005] Receive a consensus proposal from the first consensus node. The consensus proposal includes a read set of multiple transactions to be executed and the order of the multiple transactions. The read set includes a first state read according to the multiple transactions.

[0006] While verifying the read set based on the verification data, the multiple transactions are executed in parallel according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data;

[0007] Based on the verification results, a consensus is reached on the consensus proposal;

[0008] If the consensus is successful, the verification data is updated according to the write set.

[0009] A second aspect of this specification provides a transaction execution method in a blockchain system, the blockchain system including a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, and the second consensus node storing verification data corresponding to the multiple states, the method comprising:

[0010] The first consensus node sends a consensus proposal to the second consensus node. The consensus proposal includes a read set of multiple transactions to be executed and the order in which the multiple transactions are arranged. The read set includes a first state read according to the multiple transactions.

[0011] While verifying the read set based on the verification data, the second consensus node executes the multiple transactions in parallel according to the read set and the order of arrangement to obtain a write set, the write set including a second state for updating the state data; consensus is reached on the consensus proposal based on the verification result; if the consensus is successful, the verification data is updated according to the write set.

[0012] A third aspect of this specification provides a blockchain system, including a first consensus node and a second consensus node. The first consensus node stores state data, which includes multiple states. The second consensus node stores verification data, which corresponds to the multiple states.

[0013] The first consensus node is used to send a consensus proposal to the second consensus node. The consensus proposal includes a read set of multiple transactions to be executed and the order of the multiple transactions. The read set includes a first state read according to the multiple transactions.

[0014] The second consensus node is used to verify the read set based on the verification data, and simultaneously execute the multiple transactions according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data; to reach consensus on the consensus proposal based on the verification result; and to update the verification data according to the write set if the consensus is successful.

[0015] This specification provides a consensus node in a blockchain system, the blockchain system including a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, and the second consensus node storing verification data corresponding to the multiple states, the second consensus node comprising:

[0016] A receiving unit is configured to receive a consensus proposal from the first consensus node, the consensus proposal including a read set of multiple transactions to be executed and the order of the multiple transactions, the read set including a first state read according to the multiple transactions;

[0017] A parallel processing unit is configured to, while verifying the read set based on the verification data, execute the multiple transactions in parallel according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data;

[0018] A consensus unit is used to reach a consensus on the consensus proposal based on the verification results.

[0019] An update unit is used to update the verification data according to the write set if the consensus is successful.

[0020] A fifth 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.

[0021] The sixth aspect of this specification provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first aspect.

[0022] In the embodiments of this specification, only state verification data is stored in LVP. LVP obtains a consensus proposal that includes a set of reads and their order from FVP, thereby enabling the simultaneous execution of multiple transactions while verifying the set of reads based on the verification data. This greatly saves on the hardware and time costs of data storage and improves the performance and efficiency of the blockchain system. Attached Figure Description

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

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

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

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

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

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

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

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

[0031] Figure 8 This is a flowchart of a transaction execution method in another embodiment of this specification;

[0032] Figure 9 This is a structural diagram of a lightweight consensus node in a blockchain system according to an embodiment of this specification. Detailed Implementation

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

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

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

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

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

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

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

[0040] Figure 2 This 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 2As 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.

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

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

[0043] 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 3 Account 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.

[0044] 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 4The 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".

[0045] 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):

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

[0047] 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 4 When 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.

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

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

[0050] 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 state tree shown, 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 ​​in the tree. 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.

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

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

[0053] Still referencing Figure 3 In 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.

[0054] This specification provides a Light Validating Peer (LVP) in its embodiments. The LVP only stores partial state data, such as hash value data in the state tree and storage tree, but does not store the value (i.e., each state) of each account or variable in the state tree and storage tree. At the same time, the blockchain also includes a Full Validating Peer (FVP) that is the same as the consensus node in related technologies. 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 6The 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. In this way, Figure 5 The data contained in the state hash tree and the storage hash tree, excluding the leaf nodes, are related to... Figure 3 The corresponding nodes in the state tree and the storage tree are consistent, therefore Figure 5 The root hash value of node t1 in the data is... Figure 3 The root hash value of node t1 in the array is consistent.

[0055] Figure 5 and Figure 6 The state hash tree and storage hash tree shown can be used to verify reads received from the FVP; therefore, these 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, for verifying the read set, may include at least the hash values ​​of the states of the state tree and the leaf nodes of the storage tree in the verification data. 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. The following will use... Figures 3-6 The status data and verification data shown are used as examples to describe the consensus and transaction execution schemes in the embodiments of this specification.

[0056] In a blockchain system based on FVP and LVP, the transaction execution scheme provided in the embodiments of this specification stores only state verification data in the light consensus node. The full consensus node sends the read set of the transaction to be executed to the light consensus node, which can then verify the read set based on the state verification data. After successful verification, the transaction can be executed based on the read set, and the locally stored verification data can be updated based on the transaction execution result. This can greatly save storage resources in LVP and reduce the storage cost of the blockchain system.

[0057] Figure 7 This is a flowchart of the transaction execution method in the embodiments of this specification. This method can be implemented by an FVP (Fault-Version Virtualization Provider) acting as the master node in a blockchain system. Figure 7 (Illustrated by FVP) and one or more LVPs are executed. Figure 7 The diagram illustrates an LVP as an example. In this example, the blockchain system may include at least one FVP, which can collectively determine one FVP as the master node. Other nodes in the blockchain system besides the master node are slave nodes. The master node can initiate a consensus proposal to reach a consensus with the slave nodes on that proposal.

[0058] like Figure 7 As shown, firstly, in step S701, FVP obtains the read sets corresponding to multiple transactions.

[0059] Assuming FVP1 is the master node in the blockchain system, the following description uses FVP1 as an example. FVP1 can receive transactions sent by users from user clients or other FVPs. These transactions can be transfer transactions or transactions that invoke contracts, etc. After receiving a certain number of transactions, FVP1 can select several transactions from the received transactions for consensus to generate a new block.

[0060] After selecting multiple transactions, FVP1 obtains the corresponding read sets for those transactions. These read sets include the states of account and / or contract variables read from the state data based on the read operations included in the transactions. In other words, these read sets represent the states of account and / or contract variables that the transactions need to read from the state data when executed. The state data includes, for example, the states of the account and / or contract variables read from the state data. Figure 3 The state tree and storage tree are shown in the diagram.

[0061] Specifically, FVP1 can acquire read sets from multiple transactions and then merge these read sets. Specifically, it selects the key-value pairs of each variable (including account and contract variables) read from the state data during the initial read of each variable from the individual read sets of each transaction, thus obtaining the read sets corresponding to multiple transactions. Assuming one of the multiple transactions involves updating the balance of account A (e.g., reducing a preset amount), this transaction, when executed, first needs to read the value of account A (i.e., including Nonce and Balance). Then, based on the read value of account A, it obtains the new value of account A. For example, the transaction increments the Nonce value by 1 and reduces the Balance value by a preset amount, obtaining the updated Nonce and Balance values ​​of account A, which constitute the updated value of account A. Therefore, the read set of this transaction includes the read key-value pairs of account A, and the write set of this transaction includes the written key-value pairs of account A. The read set of these multiple transactions includes key-value pairs for account A read from the status data, where the key is the account address of account A and the value is the status of account A, which includes the Nonce value and Balance value in the leaf node corresponding to account A.

[0062] Suppose one of these multiple transactions includes an update operation on variable 'a' in the contract corresponding to account B. Since writing to variable 'a' will update the Storage_root in account B, this transaction also includes a write operation to account B. To write to account B and variable 'a', the read set of this transaction needs to include the key-value pair for account B and the key-value pair for variable 'a'. Assuming this transaction's read of account B and variable 'a' is the first read from the state data, the read set of multiple transactions will also include the key-value pair for account B and the key-value pair for variable 'a' read from the state data based on this transaction. Specifically, in the key-value pair for account B, the key is the account address of account B, and the value is the state of account B, which includes the values ​​of the Nonce, Balance, CodeHash, and Storage_root fields in the leaf node corresponding to account B. In the key-value pair for variable 'a', the key is the variable name of variable 'a', and the value is the state value of variable 'a'. Based on the read set of the multiple transactions, when writing to account B during the execution of the transaction, the updated Storage_root can be calculated based on the updated value of variable a, and then merged with the Nonce, Balance, and CodeHash of account B in the read set to obtain the updated value of account B. The updated value of variable a and the updated value of account B will be recorded in the write set of the transaction for use in updating state data.

[0063] In one implementation, FVP1 can perform static analysis on each transaction, analyzing the transaction body and the contract code of the contracts called within the transaction, thereby determining the account and / or variable names (keys) that each transaction needs to read during execution. Using the obtained keys, the value corresponding to the key is read from the state data, thus generating a read set corresponding to the multiple transactions. In another implementation, FVP1 can pre-execute the multiple transactions. FVP1 can pre-execute the multiple transactions according to a preset order, or FVP1 can pre-execute the multiple transactions according to the order in which they are received, and determine the order of the multiple transactions in the consensus proposal based on the pre-execution order of the transactions.

[0064] When FVP1 pre-executes multiple transactions, upon first reading the value of an account or contract variable, it reads it from the state data and generates a read set for the multiple transactions based on that initial read value. Simultaneously, FVP1 caches the initially read values ​​of these account or contract variables. When these values ​​are updated during the pre-execution of the multiple transactions, the cached values ​​are updated. When these values ​​are read again during the pre-execution of the multiple transactions, the cached values ​​are read instead. The values ​​of these re-read account or contract variables do not need to be written to the read set for the multiple transactions.

[0065] In step S703, FVP sends a consensus proposal to LVP, which includes a read set of the plurality of transactions.

[0066] FVP1 can generate a consensus proposal for reaching a consensus on the order of the 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. Additionally, the consensus proposal may include a read set of the multiple transactions obtained above. By including a read set in the consensus proposal, reference... Figure 2 The consensus process shown can verify the read set during the PP stage, that is, determine whether FVP1 is malicious during the PP stage. If FVP1 is determined to be malicious during the PP stage, the consensus process can be terminated early, thus eliminating the need for subsequent preparation and commit stages, saving computing resources and improving the system efficiency in the blockchain.

[0067] In another implementation, the consensus proposal may include transaction identifiers (such as hash values ​​of each transaction) of multiple transactions arranged in sequence and the aforementioned read set. Meanwhile, FVP1 or other FVPs that receive transactions from user equipment can broadcast the transaction bodies of multiple transactions to other consensus nodes, thereby reducing the data size of the consensus proposal and saving the computational load used for signing during the consensus process.

[0068] In step S705, LVP verifies whether the read set is correct based on the verification data.

[0069] In one implementation, the LVP stores Figure 3The LVP uses the hash values ​​of each state in the state tree and storage tree, along with the index data (e.g., account address or variable name) to that hash value, as verification data. After obtaining a read set of multiple transactions as described above, the LVP can use the hash values ​​of each state to verify each state in the read set. For example, if the read set includes the value of account A, the LVP can obtain the state hash value of account A from the verification data and use it to verify the value of account A. That is, it verifies whether the value of account A in the read set corresponds to the state hash value of account A in local storage. If they correspond, it can be determined that the value of account A in the read set is the correct state. If the read set includes the value of account B and the value of variable a, the LVP can obtain the state hash values ​​of account B and variable a from the verification data to verify the value of account B and the value of variable a in the read set respectively.

[0070] In another implementation, the LVP stores, for example... Figure 5 The state hash tree and storage hash tree shown serve as verification data. After obtaining the read set from the consensus proposal, LVP can perform Simplified Payment Verification (SPV) on each state in the read set based on the state hash tree and storage hash tree. For example, if the read set includes the value of account A, LVP can calculate the hash value (e.g., hash1) of the value of account A in the read set. 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) of the state hash tree. It then determines whether root1 matches the root hash value of the state hash tree stored in LVP. If they match, the value of account A in the read set is considered correct. If the read set includes the value of account B and the value of variable a, LVP can similarly perform SPV verification on the value of account B and the value of variable a based on the state hash tree and storage hash tree.

[0071] In one implementation, when the LVP stores verification data corresponding to the above-mentioned MPT tree variant, 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 set can be similarly verified based on the verification data, which will not be elaborated further here.

[0072] In addition, LVP can also store the block headers of each block, such as Figure 3As 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] While executing step S705, LVP executes step S707 in parallel, performing multiple transactions based on the read set.

[0074] In an LVP, steps S705 and S707 can be executed in parallel by two threads or two processes. Alternatively, an LVP may include a storage device and an execution device, which execute steps S705 and S707 in parallel. This implementation will be referred to below. Figure 8 Provide a detailed description.

[0075] LVP can execute multiple transactions in a consensus proposal based on the read set and its order. Specifically, when LVP needs to read the state of an account or variable during transaction execution, if it is the first read of that account or variable, it can find the state of the account or variable in the read set and execute the transaction based on that state. Based on the write operations on the account or contract variable in the transaction, it obtains the write set of the transaction, which includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables, used to update the state in the state data. After reading the state of an account or contract variable from the read set, LVP can cache that state and update the state of the account or contract variable in the cache when performing a write operation, for subsequent reads of the state of the account or contract variable during transaction execution. Since the state of the account or variable in the read set has been verified as the correct current state of the account or variable, the execution result obtained by executing a transaction based on the state in the read set is consistent with the execution result obtained by FVP based on the state in the state data.

[0076] Specifically, assuming that one of the multiple transactions mentioned above includes updating the balance of account A, LVP first reads the value of account A from the read set of multiple transactions (assuming the read value is V1), updates V1 according to the transaction, and obtains the updated value of account A (assuming the 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 to the write set of the transaction.

[0077] As described above, if one of the multiple transactions includes writing to variable 'a' in the contract corresponding to account B, LVP first reads the value of account B (let's say V3) and the value of variable 'a' (let's say V4) from the read set of multiple transactions. Based on this transaction, it processes V4 to obtain the updated value of variable 'a' (let's say V5), calculates the hash value of V5, and substitutes it into... Figure 5 The 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 in the read set of the transaction, the updated value of account B (let's assume it is V6) is calculated. Thus, the updated key-value pair of account B and the updated key-value pair of variable a can be included in the write set of the transaction.

[0078] While LVP executes multiple transactions based on the read set, if FVP1 has previously pre-executed multiple transactions, as mentioned earlier, the order in which FVP1 pre-executes these transactions corresponds to the order of transactions in the consensus proposal. Therefore, FVP1's reading, updating, and writing of the state during pre-execution of multiple transactions are consistent with its execution of multiple transactions. Consequently, the write set obtained from pre-executing multiple transactions can be used as the write set for executing those transactions, and receipts for the multiple transactions can be obtained from this write set. If FVP1 has not previously pre-executed multiple transactions, it can execute those transactions according to the read set or by reading the state from the state data, following the order of transactions in the consensus proposal. In both methods, the write set and receipts for the multiple transactions obtained by FVP1 are consistent with the write set and receipts for LVP's execution of multiple transactions.

[0079] In step S709, the consensus nodes (including FVP and LVP) complete the consensus process for multiple transactions.

[0080] LVP verifies the read set received from FVP using verification data stored locally. If verification passes, meaning the read set is confirmed as correct, LVP can subsequently perform node functions similar to FVP based on this read set, such as executing transactions and generating blocks. After successful verification, LVP can complete the consensus process for multiple transactions, including completing tasks such as... Figure 2 The diagram illustrates the PP, P, and C phases. If verification fails, it indicates the master node may be malicious. LVP can then terminate the consensus process early and begin the process of replacing the master node, thereby improving the efficiency of the blockchain system.

[0081] In step S711, after each consensus node (including FVP and LVP) in the blockchain system completes the execution of the multiple transactions, consensus can be reached on the execution results of the multiple transactions.

[0082] Consensus nodes 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. FVP1 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, LVP compares the block hash received from FVP1 with its own calculated block hash of block B1. If they match, LVP signs the block hash and sends it to all other consensus nodes. This completes the process. Figure 3 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 storage based on the execution results of multiple transactions.

[0083] In step S713, LVP updates the verification data based on the write set of multiple transactions.

[0084] Specifically, after obtaining the write sets of each transaction, LVP generates a corresponding write set (e.g., wset1) based on these write sets. This wset1 includes key-value pairs of accounts or key-value pairs of contract accounts and contract variables used to update state data based on the write operations of the multiple transactions. After successful consensus on the execution results of the multiple transactions, LVP can update the verification data in LVP based on the hash values ​​of each state in wset1.

[0085] In one implementation, the verification data in LVP includes hash values ​​of the states of each account and each contract variable. Assuming that write set wset1 includes key-value pairs for account A to be written, LVP 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, and write the hash value of the state corresponding to the key in wset1 to the storage location.

[0086] Assuming the write set wset1 contains key-value pairs for account B and variable a, the LVP 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, the 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.

[0087] In another implementation, the verification data in LVP includes, for example: Figure 5 As shown in the state hash tree and storage hash tree, LVP can first update the state hash values ​​in the leaf nodes corresponding to multiple states in the write set, 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 storage hash tree can be updated upwards until the hash value of the root node of the state hash tree and storage hash tree is updated.

[0088] Additionally, after LVP reaches consensus on the block hash, it can store the block header of the generated block. For example... 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.

[0089] While LVP updates the storage, FVP1 also updates the storage based on the execution results of multiple transactions. Specifically, FVP1 updates the storage based on the write sets of multiple transactions, such as... Figure 3 The diagram shows the state tree and storage tree, as well as block B1 storing the multiple transactions. This block includes a block header and a block body, which contains data such as the transaction bodies and receipts of the multiple transactions. After both LVP and FVP in the blockchain system update their storage based on the execution results of the multiple transactions, the verification data in LVP still corresponds to the state data in FVP, so as to continue consensus on the next batch of multiple transactions.

[0090] The scheme in the embodiments of this specification only stores lightweight storage in LVP. LVP obtains a consensus proposal including a read set and its order of multiple transactions from FVP, thereby enabling the parallel execution of multiple transactions while verifying the read set based on verification data. This greatly saves the hardware and time costs of data storage and improves the performance and efficiency of the blockchain system.

[0091] Figure 8This is a flowchart of a transaction execution method according to another embodiment of this specification. In this embodiment, LVP may include a consensus device, a storage device, and an execution device. The consensus device, storage device, and execution device may be separate units within a single computing device, or they may be multiple separate computing devices. The storage device stores verification data and block headers, among other data, from the LVP.

[0092] like Figure 8 As shown, in step S801, FVP acquires the read sets corresponding to multiple transactions. This step can be referred to the description of step S701 above, and will not be repeated here.

[0093] In step S803, FVP sends a consensus proposal to the consensus device of LVP, which includes the aforementioned read set.

[0094] In step S805, the consensus device sends the read set to the storage device.

[0095] In step S807, the consensus device sends the transaction list and read set to the execution device, wherein the transaction list includes the transaction bodies of multiple transactions arranged in sequence.

[0096] In step S809, the storage device verifies whether the read set is correct based on the verification data. The verification process in this step can be referred to the description of step S705 above, and will not be repeated here.

[0097] While the storage device executes step S809, the execution device executes step S811 in parallel, performing multiple transactions based on the read set.

[0098] The execution device can obtain the execution results of each transaction by executing each transaction according to the read set. The execution results include, for example, the write set and receipt of each transaction.

[0099] In step S813, if the verification is successful, the storage device returns the successful verification result to the consensus device.

[0100] In step S815, the consensus devices of each consensus node (including FVP and LVP) complete the consensus on the consensus proposal.

[0101] In step S817, the execution device returns the execution results of multiple transactions to the consensus device.

[0102] In step S819, the consensus device generates block hash values ​​corresponding to multiple transactions based on the execution results of multiple transactions. This step can be referred to the relevant description in the description of step S711 above, and will not be repeated here.

[0103] In step S821, the consensus nodes (including FVP and LVP) reach a consensus on the block hash value. That is, the consensus devices of each consensus node reach a consensus on the block hash value.

[0104] In step S823, if consensus on the block hash value is successful, the consensus device sends the generated block header and updated verification data to the storage device. The updated verification data may include, for example, […]. Figure 5 The state hash tree and the updated node values ​​in the storage hash tree are shown.

[0105] In step S825, the storage device stores the block header and updates the verification data.

[0106] Figure 9 This is a structural diagram of a lightweight consensus node in a blockchain system according to an embodiment of this specification. The blockchain system includes a first consensus node and a second consensus node. The first consensus node stores state data, which includes multiple states. The second consensus node stores verification data, which corresponds to the multiple states. The second consensus node includes:

[0107] The receiving unit 91 is configured to receive a consensus proposal from the first consensus node, wherein the consensus proposal includes a read set of multiple transactions to be executed and an order of arrangement of the multiple transactions, and the read set includes a first state read according to the multiple transactions;

[0108] The parallel processing unit 92 is configured to, while verifying the read set based on the verification data, execute the multiple transactions in parallel according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data;

[0109] Consensus unit 93 is used to reach a consensus on the consensus proposal based on the verification results;

[0110] Update unit 94 is used to update the verification data according to the write set if the consensus is successful.

[0111] 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 7 or Figure 8 The method shown.

[0112] This specification also provides a consensus node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 7 or Figure 8 The method shown.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0127] 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 transaction execution method in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, the method being executed by the second consensus node, comprising: Receive a consensus proposal from the first consensus node. The consensus proposal includes a read set of multiple transactions to be executed and the order of the multiple transactions. The read set includes a first state read according to the multiple transactions. While verifying the read set based on the verification data, the multiple transactions are executed in parallel according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data; Based on the verification results, a consensus is reached on the consensus proposal; If the consensus is successful, the verification data is updated according to the write set.

2. The method according to claim 1, wherein the read set is generated by the first consensus node pre-executing the plurality of transactions, and the pre-executing order of the plurality of transactions corresponds to the arrangement order.

3. The method according to claim 1, further comprising: Consensus is reached with other consensus nodes in the blockchain system regarding the write set; The step of updating the verification data according to the write set includes: updating the verification data according to the write set if consensus on the write set is successful.

4. The method according to claim 1, further comprising: Based on the execution results of the multiple transactions, a block header corresponding to the multiple transactions is generated and the block header is stored.

5. The method according to claim 1, wherein the verification data includes the hash values ​​of each of the plurality of states.

6. The method according to claim 5, wherein the verification data comprises tree-structured hash value data, wherein each leaf node of the hash value data comprises the hash value of the respective states, and the verification of the read set based on the verification data comprises: SPV verification is performed on the first state based on the hash value data.

7. The method according to claim 1, wherein the second consensus node comprises a consensus device and a storage device, the storage device storing the verification data, and the verification of the read set based on the verification data comprises: The consensus device sends the read set to the storage device, and the storage device verifies the read set based on the verification data and returns the verification result to the consensus device.

8. The method according to claim 7, wherein the second consensus node further comprises an execution device, and the execution of the plurality of transactions according to the read set and the arrangement order comprises: The consensus device sends the plurality of transactions, the read set, and the order of arrangement to the execution device, and the execution device executes the plurality of transactions according to the order of arrangement and the read set; The step of updating the verification data according to the write set includes: the execution device sending the write set to the consensus device, and the consensus device instructing the storage device to update the verification data according to the write set.

9. The method according to claim 8, wherein the second consensus node comprises an execution device and a storage device, and the step of simultaneously verifying the read set based on the verification data and executing the plurality of transactions in parallel according to the read set and the arrangement order comprises: While the storage device verifies the read set based on the verification data, the execution device executes the multiple transactions in parallel according to the read set and the arrangement order.

10. A transaction execution method in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, the method comprising: The first consensus node sends a consensus proposal to the second consensus node. The consensus proposal includes a read set of multiple transactions to be executed and the order in which the multiple transactions are arranged. The read set includes a first state read according to the multiple transactions. While the second consensus node verifies the read set based on the verification data, it executes the multiple transactions in parallel according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data; Based on the verification results, consensus is reached on the consensus proposal; if the consensus is successful, the verification data is updated according to the write set.

11. A blockchain system comprising a first consensus node and a second consensus node, wherein the first consensus node stores state data, the state data including multiple states, and the second consensus node stores verification data, the verification data corresponding to the multiple states. The first consensus node is used to send a consensus proposal to the second consensus node. The consensus proposal includes a read set of multiple transactions to be executed and the order of the multiple transactions. The read set includes a first state read according to the multiple transactions. The second consensus node is used to verify the read set based on the verification data, and simultaneously execute the multiple transactions according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data; Based on the verification results, consensus is reached on the consensus proposal; if the consensus is successful, the verification data is updated according to the write set.

12. A consensus node in a blockchain system, the blockchain system comprising a first consensus node and a second consensus node, the first consensus node storing state data including multiple states, the second consensus node storing verification data corresponding to the multiple states, the second consensus node comprising: A receiving unit is configured to receive a consensus proposal from the first consensus node, the consensus proposal including a read set of multiple transactions to be executed and the order of the multiple transactions, the read set including a first state read according to the multiple transactions; A parallel processing unit is configured to, while verifying the read set based on the verification data, execute the multiple transactions in parallel according to the read set and the arrangement order to obtain a write set, the write set including a second state for updating the state data; A consensus unit is used to reach a consensus on the consensus proposal based on the verification results. An update unit is used to update the verification data according to the write set if the consensus is successful.

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

14. A consensus node, 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-9.

Images