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

Abstract

A transaction execution method, a node and a blockchain system in a blockchain system. A first node in the blockchain system can pre-execute a first transaction in its TEE, obtain resource consumption information and a pre-execution read-write set generated based on the resource consumption information; and after generating trusted data based on the resource consumption information in its TEE, send the trusted data and the pre-execution read-write set to a second node in the blockchain system. The second node can execute the first transaction based on the resource consumption information from the first node, obtain an execution read-write set of the first transaction; and verify whether the first node has been malicious in the process of pre-executing the first transaction according to the execution read-write set and the pre-execution read-write set of the first transaction, and if not, take an execution write set of the execution read-write set as state data of the first transaction.

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, 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 is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a transaction execution method, node, and blockchain system in a blockchain system.

[0004] In a first aspect, a transaction execution method is provided in a blockchain system, the blockchain system including a first node and a second node, the method being executed by the first node. The method includes: pre-executing a first transaction in a trusted execution environment (TEE) to obtain resource consumption information and a pre-execution read / write set generated based on the resource consumption information; generating trusted data in the TEE based on the resource consumption information; and sending the trusted data and the pre-execution read / write set to the second node.

[0005] Secondly, a transaction execution method in a blockchain system is provided, the blockchain system including a first node and a second node, the method being executed by the first node. The method includes: receiving trusted data and a pre-execution read / write set of a first transaction from the first node, the trusted data being generated by the first node in its TEE based on resource consumption information of the first transaction, the resource consumption information and the pre-execution read / write set being obtained by the first node pre-executing the first transaction in its TEE; executing the first transaction based on the resource consumption information to obtain an execution read / write set of the first transaction; determining whether the first node acted maliciously during the pre-execution of the first transaction based on the execution read / write set and the pre-execution read / write set, if not, using the execution write set of the execution read / write set as the state data of the first transaction.

[0006] Thirdly, a first node is provided in a blockchain system, which further includes a second node. The first node includes: a pre-execution process deployed in the TEE of the first node, configured to pre-execute a first transaction, obtain resource consumption information and a pre-execution read / write set generated based on the resource consumption information; and configured to generate trusted data based on the resource consumption information in the TEE; and a network process configured to send the trusted data and the pre-execution read / write set to the second node.

[0007] Fourthly, a second node is provided in a blockchain system, which further includes a first node. The second node comprises: a network process configured to receive trusted data and a pre-execution read / write set of a first transaction from the first node, wherein the trusted data is generated by the first node in its TEE based on resource consumption information of the first transaction, and the resource consumption information and the pre-execution read / write set are obtained by the first node pre-executing the first transaction in its TEE; a computing process configured to execute the first transaction based on the resource consumption information to obtain an execution read / write set of the first transaction; and configured to determine whether the first node acted maliciously during the pre-execution of the first transaction based on the execution read / write set and the pre-execution read / write set, and if not, to use the execution write set of the execution read / write set as the state data of the first transaction.

[0008] Fifthly, a blockchain system is provided, including a first node and a second node. The first node is configured to pre-execute a first transaction in a Trusted Execution Environment (TEE), obtaining resource consumption information and a pre-execution read / write set generated based on the resource consumption information; generate trusted data in the TEE based on the resource consumption information; and send the trusted data and the pre-execution read / write set to the second node. The second node is configured to execute the first transaction based on the resource consumption information, obtaining an execution read / write set for the first transaction; and determine whether the first node acted maliciously during the pre-execution of the first transaction based on the execution read / write set and the pre-execution read / write set; if not, the execution write set of the execution read / write set is used as the state data of the first transaction.

[0009] In the above embodiment, during the execution of a transaction, the second node does not need to recalculate the resource consumption information of the transaction. Instead, it uses the resource consumption information of the transaction from the first node to execute the transaction, that is, it uses the resource consumption information of the transaction from the first node to generate the execution write set of the transaction. When the second node determines that the execution read-write set and the pre-execution read-write set of the transaction indicate that node n1 has not acted maliciously during the execution of the transaction, it can use the execution write set of the transaction as the state data of the transaction to complete the execution of the transaction. In this way, the second node can complete the execution of the transaction more quickly because it does not need to recalculate the resource consumption information of the transaction. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of an exemplary blockchain system provided in the embodiments of this specification;

[0012] Figure 2 This is a schematic diagram of the structure of blockchain data storage provided as an example in the embodiments of this specification;

[0013] Figure 3 This is a schematic diagram of the structure of any two nodes in a blockchain system provided as an example in the embodiments of this specification;

[0014] Figure 4 This is a flowchart of a transaction execution method provided in the embodiments of this specification;

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

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

[0017] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0018] Figure 1 This is a schematic diagram of an exemplary blockchain system provided in the embodiments of this specification. Figure 1 As shown, a blockchain system is a distributed network built from multiple nodes. It involves peer-to-peer (P2P) communication between any two nodes at the application layer. For example, any two nodes from n1 to n5 can communicate at the application layer via a P2P network. The blockchain system utilizes a chain-like block structure to construct a decentralized (or multi-centralized) distributed ledger, which is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Therefore, the blockchain system needs to address the consistency and correctness of the ledger data across these decentralized (or multi-centralized) nodes. Accordingly, each node in the blockchain system runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions. Transactions are packaged into blocks, and the world state is updated based on the execution results of the same transactions. The current mainstream consensus mechanisms include, but are not limited to: Proof of Work (POW), Proof of Stake (POS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

[0019] Accounts in a blockchain system are typically categorized into two types: user accounts / externally owned accounts and contract accounts. Contract accounts store smart contract code and related state values ​​within that code, and are generally only accessible through external accounts. The design of external and contract accounts essentially maps account addresses to account states. Account states typically include, but are not limited to, fields such as nonce, balance, storage_Root, and codeHash. Nonce and balance exist in both external and contract accounts, while codeHash and storage_Root are usually only valid for contract accounts. Among these fields, nonce represents a counter; for external accounts, it represents the number of transactions sent from the account address; for contract accounts, it represents the number of contracts created by the account. Balance represents the amount of digital resources owned by the corresponding external account. Storage_Root represents the hash of the root node of an MPT (Merkle Patricia Tree), which is used to organize the storage of contract account state variables. codeHash represents the hash value of the smart contract code. For the contract account, it is the code of the smart contract that has been hashed and stored. For external accounts, since it does not include the smart contract, it can be an empty string or a string of all zeros.

[0020] MPT is a tree structure that combines Merkle Tree and Patricia Tree (a more space-efficient Trie tree). Merkle Tree algorithms calculate a hash value for each transaction, then concatenate pairs and calculate the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a hexadecimal structure, often simply referred to as an MPT tree. The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs representing the storage content for each account in Ethereum. The "key" in the state trie can be a 160-bit identifier (the Ethereum account address), distributed across the storage from the root node to the leaf nodes. The "value" in the state trie is generated by encoding the Ethereum account information using Recursive-Length Prefix (RLP) encoding. As mentioned earlier, for external accounts, the values ​​include nonce and balance; for contract accounts, the values ​​include nonce, balance, codehash, and storage_Root, etc.

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

[0022] Please see Figure 2 An exemplary schematic diagram of a blockchain data storage structure is provided. (Example provided) Figure 2As shown, the block header of a single block can include several fields, such as the previous block hash (prevHash in the diagram, or parent hash), a nonce (in some blockchain systems, this nonce is not random, or the nonce in the block header is not enabled in some blockchain systems), a timestamp, a block number (BlockNum), a state root hash (State_Root), a transaction root hash (Transaction_Root), and a receipt root hash (Receipt_Root). The PrevHash in the block header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block. In this way, the blockchain achieves locking of the previous block by the next block through the block header. It is important to note that state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block; that is, pointing to state_root is a state tree in MPT form. The root node of this MPT tree can be an extension node or a branch node. The `state_root` typically stores the hash value of this root node. A subset of values ​​from each node from the root to the leaf nodes are concatenated sequentially to form an account address, which serves as the key. The account information stored in the leaf nodes is the value corresponding to this account address, thus forming a key-value pair. The key can be SHA3 (Address), i.e., the hash value of the account address (using a hash algorithm such as SHA3), and the stored value can be RLP (Account), i.e., the RLP encoding of the account information. The account information can be a four-tuple consisting of [nonce, balance, storage_root, codeHash]. As mentioned earlier, for external accounts, generally only the `nonce` and `balance` fields are present, while the `storage_root` and `codeHash` fields default to storing empty strings / strings of all zeros. For contract accounts, the contract account can include `nonce`, `balance`, `storage_root`, `codeHash`, etc. Furthermore, regardless of whether it's an external account or a contract account, its account information is generally located in a single leaf node. The path from the root node's extension / branch nodes to each account's leaf node may involve several branch nodes and extension nodes.

[0023] For a single contract account in the state tree, its `storage_Root` points to another tree, also in MPT form, which stores data related to the state variables involved in contract execution. This MPT-form tree pointed to by `storage_Root` is the storage tree, specifically the hash value of the root node. Generally, this storage tree also stores key-value pairs. A portion of the data stored along the path from the root node to a leaf node is concatenated to form the key, and the leaf node stores the value. As mentioned earlier, this storage tree can also be an MPT-form tree, typically a 16-ary tree. This means that a branch node can have a maximum of 16 child nodes, which may include extension nodes and / or leaf nodes. An extension node typically has one child node, which can be a branch node. This storage tree can have a maximum depth of 64 levels.

[0024] Referring to the previous descriptions of storage trie and state trie, it's clear that the state data generated by a node in a blockchain system after executing multiple transactions belonging to a certain block may include contract state data related to the storage trie and world state data related to the state trie. Therefore, during the process of submitting state data, a node typically needs to first submit contract state data to obtain the storage_root of the contract account, then update the storage_root of the relevant contract account in the state trie, and finally submit the obtained world state data to obtain the state_root of the state trie.

[0025] Figure 3 This diagram illustrates the structure of any two nodes (e.g., node n1 as the master / second node and node n2 as the slave / first node) in a blockchain system exemplarily provided in the embodiments of this specification. Both node n1 and node n2 can run multiple processes to provide various services, for example, refer to... Figure 3As shown, both node n1 and node n2 can each run an access process for providing access services, a caching process for providing caching services, a pre-execution process for providing pre-execution services, a network process for providing network services, a consensus process for providing consensus services, a control process (or block management process) for providing block management services, and a storage process for providing storage services. Furthermore, node n2, as a slave node, can also run multiple computing processes for providing computing services. A process refers to a program with a certain independent function running on a data set; that is, a process in a computer is a procedure performed by the CPU sequentially executing instructions in an application, and each process is allocated its own memory address space upon creation. The multiple processes in node n1 can be multiple processes in multiple computing devices or virtual computing nodes, and the multiple processes in node n2 can also be multiple processes in multiple computing devices or virtual computing nodes. It should also be noted that the solutions provided in the embodiments of this specification are not limited to master-slave blockchain systems.

[0026] The access process can be used to receive transactions from user devices, and then the access process can call the caching process to add the received transactions to the pending transaction queue for caching.

[0027] The pre-execution process of node n2 can call the caching process to sequentially read and verify the cached transactions from the pending transaction queue, such as verifying the user equipment's signature on the transaction, and then return the verified transaction to the caching process. Furthermore, node n2 can broadcast verified transactions stored in its caching process to the network processes of other nodes via its network process; consequently, transactions received by node n1 from node n2 through its network process can be cached by its caching process and added to the pending transaction queue. Thus, the pending transaction queue cached in memory by node n1's caching process includes not only transactions received through its access process but also transactions from other nodes received through its network process.

[0028] The pre-execution process of node n1 can also call the caching process to read its cached transactions sequentially from the pending transaction queue, and at least verify transactions from user devices connected to node n1. Furthermore, the pre-execution process of node n2 can pre-execute the transactions it receives sequentially from the caching process to obtain pre-execution information for each transaction. This pre-execution information includes, for example, the pre-execution read set, the pre-execution write set, and the amount of digital / computing resources consumed to execute the transaction (i.e., resource consumption information). Moreover, after completing the pre-execution of each batch of transactions, the pre-execution process of node n1 can return the pre-execution information of that batch of transactions to the caching process for caching in the pending consensus transaction queue. It is important to note that the caching process of node n1 can also cache some state data in its memory. For any transaction pre-executed by the pre-execution process of node n1, during the pre-execution process, the pre-execution process can first call the caching process to query whether its cached state data includes the state value of any variable to be read. If so, it obtains the state value of that variable returned by the caching process; otherwise, the pre-execution process can call the storage process to query the state value of that variable from the state data already submitted to the state database. Furthermore, since the pre-execution process of node n1 returns the pre-execution information of its pre-executed transactions to the caching process, the caching process can also update its cached state data based on the received pre-execution read / write set. Additionally, since the pre-execution process can sequentially read transactions from the pending transaction queue cached by the caching process and pre-execute them, the caching process can also cache the pre-execution order of multiple transactions pre-executed by the pre-execution process in its memory based on its cached pending transaction queue.

[0029] The pre-execution read set contains several unique keys, as well as key-value pairs read from the committed world state corresponding to each of the aforementioned keys. The pre-execution write set also contains several unique keys, as well as key-value pairs expected to be committed corresponding to each of the aforementioned keys; furthermore, if a transaction deletes a key from the world state, the pre-execution write set will record a corresponding marker for the deleted key. It is important to note that if the pre-executed transaction is a contract call transaction used to invoke a smart contract, its pre-execution read / write set may contain not only state parameters related to external accounts but also several contract parameters related to the smart contract's contract state.

[0030] The following exemplifies the process by which node n1 pre-executes transactions Tx1 through Tx5 sequentially. It is assumed that transactions Tx1 and Tx2 are contract call transactions initiated by external accounts A1 and A2 respectively to invoke smart contract C1, and that smart contract C1 corresponds to contract account B1. Furthermore, it is assumed that transaction Tx3 is a transfer transaction initiated by external account A1 to external account A3, transaction Tx4 is a transfer transaction initiated by external account A4 to external account A5, and transaction Tx5 is a transfer transaction initiated by external account A6 to external account A7. Node n1, through its pre-execution process, pre-executes transactions Tx1 through Tx5, and may obtain the pre-execution information for each of transactions Tx1 through Tx5 as exemplified in Table 1 below.

[0031] trade Pre-execution read set Pre-execution write set Trading Tx1 k1 = v11, k2 = v21 k1 = v12, k2 = v22 Trading Tx2 k3 = v31, k4 = v41 k3 = v32, k4 = v42 Trading Tx3 k1 = v12, k5 = v51 k1 = v13, k5 = v52 Trading Tx4 k6 = v61, k7 = v71 k6 = v62, k7 = v72 Trading Tx5 k8 = v81, k9 = v91 k8 = v82, k9 = v92

[0032] Table 1

[0033] For the parameters provided in Table 1 above, for example, k1 represents the key of the balance of external account A1, k2 represents the key of a certain status parameter under contract account B1, k3 represents the key of the balance of external account A2, k4 represents the key of a certain status parameter under contract account B1, and k5 to k9 represent the keys of the balance under external accounts A3 to A7 respectively. v11, v12, v13, and v21 to v92 represent the values ​​of their respective keys. It should be noted that since transaction Tx3 is executed after transaction Tx1, the value of k1 in the pre-execution read set of transaction Tx3 is the value of k1 in the pre-execution write set of transaction Tx1.

[0034] The consensus process of node n1 can invoke its cache process to sequentially read multiple transactions and their related data from the queue of transactions awaiting consensus to generate a consensus proposal. This consensus proposal may include, for example, pre-execution information corresponding to each of the multiple transactions, the consensus order of the multiple transactions (the consensus order is the same as the pre-execution order of the multiple transactions), and indication information for each of the multiple transactions (e.g., the digest value of each of the multiple transactions). It should be noted that the conditions for node n1's consensus process to invoke its cache process may include, but are not limited to, invoking the cache process at fixed time steps, invoking the cache process when the amount of transaction data cached by the cache process reaches a predetermined size, or invoking the cache process when the number of pre-executed transactions cached by the cache process reaches a predetermined number, etc. Furthermore, node n1's consensus process can also send the consensus proposal to the respective network processes of other nodes (e.g., node n2) participating in the consensus process through its network process, so that its consensus process can reach a consensus with the respective consensus processes of the other nodes on the generated consensus proposal. Furthermore, it should be noted that node n1 can also calculate the grouping information corresponding to the multiple transactions indicated by the consensus proposal based on their respective pre-execution information, and carry the grouping information in the consensus proposal so that other nodes participating in the consensus proposal can group the aforementioned multiple transactions based on the grouping information.

[0035] After consensus is reached on the consensus proposal, since the transactions received by nodes n1 and n2 from the user equipment they are connected to are added to the transaction queue to be processed by the caching process of node n1 in the order of receipt, and the pre-execution process of node n1 pre-executes each transaction in the transaction queue to be processed in the order, the consensus process of node n1 can send the pre-execution information of the aforementioned multiple transactions to its control process according to the pre-execution order / consensus order of the aforementioned multiple transactions. The control process then submits part or all of the pre-execution information of the aforementioned multiple transactions as the state data of the corresponding block to the storage service, thereby obtaining the state root for generating the corresponding block and generating a block containing the state root and the aforementioned multiple transactions.

[0036] For example, during the consensus process of the consensus proposal generated by node n1, or after reaching a consensus on the consensus proposal generated by node n1, node n2 can, through its consensus process and / or control process, read the pre-execution information of each of the aforementioned transactions from the consensus proposal, and then group the multiple transactions based on the pre-execution information to obtain M transaction groups (M greater than 1); or it can read the grouping information of the aforementioned multiple transactions from the consensus proposal and group the aforementioned multiple transactions based on the grouping information to obtain M transaction groups. More specifically, for example, the consensus process of node n2 can calculate the grouping information based on the pre-execution information of each of the aforementioned multiple transactions, and send the grouping information, the aforementioned multiple transactions, and their respective corresponding pre-execution read / write sets to the control process of node n2; then the control process of node n2 can divide the aforementioned multiple transactions into M transaction groups based on the grouping information, and the control process of node n2 can schedule tasks for the N computing processes in node n2.

[0037] In obtaining the aforementioned M transaction groups, it is necessary to ensure that any two transactions within any two transaction groups do not conflict with each other. Specifically, "any two transactions do not conflict" means that no two transactions fall into one of the following categories: either the pre-execution read set of one transaction contains the same key as the pre-execution write set of another transaction, or the pre-execution write set of one transaction contains the same key as the pre-execution write set of another transaction. For any two transactions that do conflict, they must be assigned to the same transaction group. In other words, if the pre-execution write sets of any two transactions contain the same key, it is considered that the two conflicting transactions accessed the same parameter and therefore conflict, and these two transactions must be assigned to the same transaction group; if the pre-execution read set of one of the two transactions contains the same key as the pre-execution write set of the other transaction, it is considered that the two transactions accessed the same parameter and therefore conflict, and these two transactions must be assigned to the same transaction group. In another possible implementation, to efficiently determine the grouping information of the aforementioned multiple transactions, or to efficiently divide the aforementioned multiple transactions into M transaction groups, the aforementioned multiple transactions can typically be grouped according to the requirement that any two transactions located in any two different transaction groups do not access the same parameters (i.e., do not contain the same key). Thus, for transactions Tx1 to Tx5 in the aforementioned example, the grouping situation may include, for example, transactions Tx1 and Tx3 being assigned to transaction group 1, transaction Tx2 being assigned to transaction group 2, and transactions Tx4 and Tx5 being assigned to transaction groups 3 and 4, respectively.

[0038] Node n2 can be divided into M transaction groups, and multiple transactions within these M groups can be executed in parallel by its N running computing processes. However, transaction execution consumes the node's computing resources. Especially for contract call transactions that request smart contracts, the node may need to execute a large number of instructions during the transaction's execution. Therefore, it is usually necessary to calculate the transaction's resource consumption information based on the instructions consumed or the transaction's data volume during execution, and then complete the transaction based on this information. For example, modifying the balance field of the external account initiating the transaction can change the amount of digital resources it holds. Calculating the transaction's resource consumption information during execution undoubtedly increases the transaction's execution time, preventing the computing processes from completing the transaction quickly.

[0039] Figure 4 This is a flowchart illustrating a transaction execution method in a blockchain system provided in the embodiments of this specification. Specifically, this method involves any first node (e.g., node n1 as the master node) and second node (e.g., node n2 as the slave node) in the blockchain system. Both the first and second nodes can be implemented as any device, platform, equipment, or cluster of devices with computing / processing capabilities. The following description will primarily focus on the example of node n1 and node n2 collaborating to complete transaction execution, detailing the transaction execution process in the blockchain system. Figure 4 As shown, the method may include, but is not limited to, the following steps 41 to 49.

[0040] Step 41: Node n1 pre-executes the first transaction in its TEE to obtain resource consumption information and a pre-execution read / write set generated based on the resource consumption information.

[0041] The aforementioned first transaction is, for example, any transaction received by node n1 through its access process or network process. The resource consumption information of the first transaction is calculated by node n1 based on the data volume of the first transaction during the pre-execution process of the first transaction, or calculated by node n1 based on the instructions consumed by the first transaction during the pre-execution process of the first transaction.

[0042] Please continue reading Figure 3The pre-execution process of node n1 can run within its TEE (Transaction Execution Environment), while its access process, network process, and other processes can run outside its TEE. The pre-execution process running within the TEE can call a cache process outside the TEE to sequentially read cached transactions from the pending transaction queue and pre-execute these transactions to obtain the amount of digital resources consumed by the transaction (i.e., resource consumption information) and a pre-execution read / write set generated based on this resource consumption information. The pre-execution write set of the pre-execution read / write set typically includes the state value of a state parameter calculated based on the resource consumption, such as the balance of the external account initiating the transaction.

[0043] For a contract call transaction initiated by an external account to invoke a smart contract, such as the aforementioned transaction Tx1 initiated by external account A1 to invoke smart contract C1, its pre-execution read set includes the state value v11 of external account A1's balance, and also the state value v21 of a certain contract parameter in smart contract C1. During the pre-execution process of transaction Tx1 in the TEE located at node n1, for example, during the execution of smart contract C1 by the virtual machine, the pre-execution process will obtain the state value v22 of the contract parameter represented by k2 to be written; in addition, the virtual machine will also calculate the amount of digital resources required for each instruction consumed in executing the aforementioned smart contract C1, and then obtain the amount of digital resources consumed in executing smart contract C1 after completing the execution of smart contract C1, that is, obtain the resource consumption information gas1 of transaction Tx1. Finally, the pre-execution process located in the TTE can also calculate the state value v12 of k1 expected to be written in the pre-execution write set based on gas1 and the state value v11 of k1 in the pre-execution read set, that is, calculate the balance state value v12 of external account A1.

[0044] For transactions not used to invoke smart contracts, such as the aforementioned transaction Tx3 initiated by external account A1 and directed to external account A3 for the purpose of implementing a transfer function, during the pre-execution process of transaction Tx3, the resource consumption information gas2 of transaction Tx3 can be calculated based on the data volume of transaction Tx3. Furthermore, the pre-execution process located in the TEE can calculate the balance status value v13 of external account A1 based on gas2 and the amount of digital resources actually transferred by Tx3. Specifically, for example, after reading the current value v12 of the balance field of external account A1, gas2 and the amount of digital resources actually transferred by external account A1 to external account A2 through transaction Tx3 are subtracted from v12 to obtain the balance status value v13 of external account A1.

[0045] Step 43: Node n1 generates trusted data based on resource consumption information in its TEE. Trusted data is ciphertext obtained by encrypting the resource consumption information, or trusted data includes resource consumption information and a signature of the resource consumption information.

[0046] After completing the pre-execution of the first transaction and generating trusted data for it, the pre-execution process located in the TEE can return the first transaction, its pre-execution read / write set, and the trusted data to the caching process for caching in the transaction queue awaiting consensus. The pre-execution process in the TEE can sequentially read transactions from the pending transaction queue cached by the caching process and pre-execute them. Therefore, as mentioned earlier, the caching process can also cache the pre-execution order of multiple transactions pre-executed by the pre-execution process in the TEE based on its cached pending transaction queue.

[0047] Step 45: Node n1 sends trusted data and a pre-execution read / write set to node n2.

[0048] Node n1 can send trusted data and a pre-execution read / write set of the first transaction to node n2 during the consensus process with node n2 on a consensus proposal generated by node n1 and sent to node n2. For example, the consensus process of node n1 can generate a consensus proposal for multiple transactions cached in a queue of transactions awaiting consensus. This consensus proposal can include trusted data for each of the multiple transactions, the pre-execution read / write set for each of the multiple transactions, and the pre-execution order / consensus order of the multiple transactions. In addition, the consensus proposal can also include the multiple transactions or their respective indication information (e.g., the hash values ​​of the multiple transactions). As mentioned above, the aforementioned first transaction can specifically be any of the multiple transactions included or indicated in the aforementioned consensus proposal. Therefore, node n2 can obtain the trusted data and its pre-execution read / write set of the aforementioned first transaction from the consensus proposal from node n1.

[0049] When the trusted data is ciphertext obtained by encrypting resource consumption information, node n2 can decrypt the trusted data to obtain the resource consumption information of the first transaction, and then execute the subsequent step 47 based on this resource consumption information. When the trusted data includes resource consumption information and node n1's signature of the resource consumption information in its TEE, node n2 can also verify the signature in the trusted data, and only continue to execute the subsequent step 47 if the signature verification is successful. In addition, it should be noted that node n2 can also have a TEE, and correspondingly, node n2 can process trusted data in its TEE, such as decrypting trusted data or verifying signatures in trusted data in the TEE.

[0050] Step 47: Node n2 executes the first transaction based on resource consumption information and obtains the execution read / write set.

[0051] For a consensus proposal sent from node n1 to node n2 containing multiple transactions, node n2 can, for example, divide these transactions into M transaction groups based on their respective pre-execution read / write sets through its control process. Here, M is not less than the number of computation processes N running on node n2, and the pre-execution read / write sets of some of these transactions may also involve several contract parameters related to one or more smart contracts. Correspondingly, node n2 can determine the computation process corresponding to each of the M transaction groups, and then, for example, distribute the M transaction groups to its N running computation processes through its control process. For any two transaction groups, if any two transactions in these groups involve the same smart contract (e.g., any two transactions in these groups request to invoke the same smart contract), then these two transaction groups need to be sent to the same computation process by the control process. This allows node n2's N computation processes to submit their respective state data obtained after completing the execution of the transactions in their received transaction groups in parallel, thereby accelerating the generation of a block containing these multiple transactions. For example, please refer to the grouping of transactions Tx1 to Tx5 in the previous example. Since transactions Tx1 and Tx2 in transaction group 1 and transaction group 2 involve different contract parameters in smart contract C1 (the contract parameters represented by k2 and k4 respectively), the control process of node n2 can send two transaction groups, such as transaction group 1 and transaction group 2, to the computing process 1 of node n2, send transaction group 3 to the computing process 2, and send transaction group 4 to the computing process 3. This allows computing processes 1 to 3 to execute the transactions in their respective received transaction groups in parallel and submit their respective state data after completing the execution of the transactions in their respective received transaction groups in parallel.

[0052] The computation process can execute transactions in its received transaction groups sequentially. For example, computation process 1 can execute transactions Tx1, Tx2, and Tx3 in transaction groups 1 and 2 sequentially using a single worker thread. Alternatively, the computation process can execute transactions in its received transaction groups concurrently using multiple threads for faster execution. For example, computation process 1 can run worker threads 1 and 2 concurrently. Worker thread 1 can execute transactions Tx1 and Tx2 in transaction group 1 sequentially, and worker thread 2 can execute transaction Tx3 in transaction group 2. It is important to note that the computation process can use the same storage object to collect the state data obtained from executing transactions in its received transaction groups. For example, computation process 1 can use the same storage object to collect the execution read / write sets obtained from executing transactions Tx1 to Tx3. The execution write sets of transactions Tx1 to Tx3 may be used as the state data obtained by computation process 1 from executing transactions Tx1 to Tx3.

[0053] During the execution of any transaction (i.e. the first transaction) in the transaction packets received by any computing process of node n2, there is no need to recalculate the resource consumption information of the transaction. Instead, it can directly use the resource consumption information of the transaction from node n1 to execute the transaction and obtain the execution read-write set of the transaction. More specifically, during the execution of the transaction, the execution write set of the transaction is generated using the resource consumption information of the transaction from node n1.

[0054] For contract call transactions that request to invoke smart contracts, such as transaction Tx1 in the aforementioned example, when the computation process 1 of node n2 executes the smart contract C1 requested by transaction Tx1 through its virtual machine, it only needs to read the state value v21 of k2 and obtain the corresponding state value v22 of k2. It does not need to calculate the amount of digital resources consumed by each instruction consumed in executing smart contract C1, that is, it does not need to calculate the resource consumption information gas1 of transaction Tx1 based on the instructions consumed in executing smart contract C1. The computation process 1 can directly use the resource consumption information gas1 from node n1 and the state value v11 of k1 it reads to calculate the state value v12 of k1 that is expected to be written in the execution write set of transaction Tx1, that is, calculate the balance state value v12 of external account A1, and then generate an execution write set containing key-value pairs k1-v12 and key-value pairs k2-v22. The key-value pair k2-v22 in the write set may be used as the contract state data of smart contract C1 / contract account B1 obtained by computation process 1 executing transaction Tx1, while the key-value pair k1-v12 may be used as the world state data obtained by computation process 1 executing transaction Tx1. It should be noted that the state data of transaction Tx1 may be used by other transactions executed later in computation process 1. For example, the state value of k1 read by the later executed transaction Tx3 should be v12, not v11.

[0055] For any of the multiple computing processes, the virtual machine used to execute the smart contract within that process can have the function of choosing whether to enable or disable the information consumption of computing resources according to the user's needs. If this function is enabled, the virtual machine can calculate the resource consumption information of a specific transaction based on the instructions consumed in executing that transaction. Since node n2 obtains the resource consumption information of the first transaction based on trusted data from node n1, the computing process used to execute the first transaction can choose to disable this function in order to complete the execution of the first transaction more quickly.

[0056] For transactions that do not request the invocation of smart contracts, such as the aforementioned transaction Tx3 initiated by external account A1 and directed to external account A3 to realize the transfer, the computation process 1 of node n2 does not need to calculate the resource consumption information gas2 of transaction Tx3 based on the data volume of transaction Tx3. The computation process 1 can calculate the balance status value v13 of external account A1 based on the read state value v12 of k1, the resource consumption information gas2 of transaction Tx3 from node n1, and the amount of digital resources actually transferred by Tx3. Specifically, after reading the state value v12 of the balance field of external account A1, gas2 and the amount of digital resources actually transferred by external account A1 to external account A2 through transaction Tx3 are subtracted from the state value v12 to obtain the balance status value v13 of external account A1, that is, to obtain the execution write set containing key-value pairs k1-v13, and the execution write set containing key-value pairs k1-v13 may be used as the state data of transaction Tx3.

[0057] Step 49: Node n2 verifies whether node n1 committed malicious acts during the pre-execution of the first transaction based on the executed read-write set and the pre-execution read-write set. If not, the executed write set of the executed read-write set is used as the state data of the first transaction.

[0058] After completing the execution of any transaction (i.e., the first transaction) in the various transaction groups it receives, node n2's computation process can obtain the execution read-write set of that first transaction. It can then determine whether this execution read-write set matches the pre-execution read-write set of the first transaction. If the execution read-write set matches the pre-execution read-write set, the computation process can use the execution write set of the first transaction as the state data of that first transaction, so that it can subsequently commit this state data to complete the execution of the first transaction. It is particularly important to note that if the execution read-write set of the first transaction does not match its pre-execution read-write set, it indicates that node n1 may have acted maliciously during the execution of the first transaction, for example, by providing incorrect state data to its TEE during the pre-execution of the first transaction. In this case, a corresponding mechanism can be used to trigger a change of the blockchain system's master node, and then, through a similar process, the execution of the aforementioned multiple transactions containing the first transaction can be re-initiated.

[0059] Furthermore, since transactions involving the same smart contract are executed by the same computation process, the state data obtained by each of the N computation processes will not involve the contract state data of the same smart contract / contract account. Therefore, the N computation processes of node n2 can submit their respective state data in parallel without affecting each other. More specifically, if the state data obtained by a computation process only includes world state data related to the state tree, it can directly submit its obtained world state data; if the state data obtained by a computation process includes both world state data and contract state data involving at least one smart contract, then the computation process needs to first submit the contract state data of at least one smart contract it obtained, for example, by sending the obtained contract state data to the storage process, which then updates the contract state tree (i.e., the aforementioned storage tree) of the at least one smart contract accordingly, obtaining the storage root of each of the at least one smart contract; then, it merges and submits the storage root of each of the at least one smart contract and the world state data obtained by the computation process to the storage process, so that the storage process updates the state parameters in the state tree accordingly.

[0060] After all N computing processes of node n2 have completed submitting their respective state data to the storage process, the control process can call the storage process to submit its updated state tree and each storage tree to obtain the state root used to generate the corresponding block. Then, the control process generates the corresponding block based on the state root and the aforementioned multiple transactions.

[0061] In the aforementioned method embodiments, during the execution of a transaction, node n2 does not need to recalculate the resource consumption information of the transaction. Instead, it uses the resource consumption information of the transaction from node n1 to execute the transaction, that is, it uses the resource consumption information of the transaction from node n1 to generate the execution write set of the transaction. When node n2 determines that the execution read-write set and the pre-execution read-write set of the transaction indicate that node n1 has not acted maliciously during the execution of the transaction, it can use the execution write set of the transaction as the state data of the transaction to complete the execution of the transaction. In this way, node n2 can complete the execution of the transaction more quickly because it does not need to recalculate the resource consumption information of the transaction.

[0062] Based on the same concept as the aforementioned method embodiments, this specification also provides a first node in a blockchain system, which further includes a second node. For example... Figure 5 As shown, the first node includes: a pre-execution process 52, deployed in the TEE of the first node, configured to pre-execute the first transaction, obtain resource consumption information and a pre-execution read-write set generated based on the resource consumption information; and configured to generate trusted data in the TEE based on the resource consumption information; and a network process 54, configured to send the trusted data and the pre-execution read-write set to the second node.

[0063] Based on the same concept as the foregoing method embodiments, this specification also provides a second node in a blockchain system, which further includes a first node. For example... Figure 6 As shown, the second node includes: a network process 62 configured to receive trusted data and a pre-execution read / write set of a first transaction from the first node, wherein the trusted data is generated by the first node in its TEE based on the resource consumption information of the first transaction, and the resource consumption information and the pre-execution read / write set are obtained by the first node pre-executing the first transaction in its TEE; a computing process 64 configured to execute the first transaction based on the resource consumption information to obtain an execution read / write set of the first transaction; and configured to determine whether the first node has acted maliciously during the pre-execution of the first transaction based on the execution read / write set and the pre-execution read / write set, and if not, to use the execution write set of the execution read / write set as the status data of the first transaction.

[0064] Based on the same concept as the aforementioned method embodiments, this specification also provides a blockchain system, which includes a first node and a second node, wherein the first node and the second node are any two blockchain nodes in the blockchain system. Specifically: the first node is used to pre-execute a first transaction in a Trusted Execution Environment (TEE), obtaining resource consumption information and a pre-execution read / write set generated based on the resource consumption information; generating trusted data in the TEE based on the resource consumption information; and sending the trusted data and the pre-execution read / write set to the second node; the second node is used to execute the first transaction based on the resource consumption information, obtaining an execution read / write set for the first transaction; and determining whether the first node acted maliciously during the pre-execution of the first transaction based on the execution read / write set and the pre-execution read / write set; if not, using the execution write set of the execution read / write set as the state data of the first transaction.

[0065] In one possible implementation, the first transaction is used to invoke a smart contract; the first node is used to execute the smart contract in the TEE based on the first transaction to obtain the resource consumption information.

[0066] In one possible implementation, the resource consumption information is calculated based on the data volume of the first transaction.

[0067] In one possible implementation, the trusted data is obtained by encrypting the resource consumption information; the second node is further configured to decrypt the trusted data to obtain the resource consumption information.

[0068] In one possible implementation, the trusted data includes the resource consumption information and a signature corresponding to the resource consumption information; the second node is further configured to verify the signature.

[0069] In one possible implementation, the first transaction is any one of a plurality of transactions included or indicated in a consensus proposal sent from the first node to the second node; the second node is further configured to divide the plurality of transactions into M transaction groups based on their respective pre-execution read-write sets, and determine the computation process corresponding to each of the M transaction groups. Specifically, the second node is configured to execute each transaction in its respective transaction group based on the resource consumption information of each transaction in its respective transaction group through the computation process, thereby obtaining the execution read-write set of each transaction in its respective transaction group.

[0070] In one possible implementation, the trusted data and the pre-executed read-write set are located in a consensus proposal sent by the first node to the second node, and the consensus proposal also includes the first transaction or indication information for indicating the first transaction.

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

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

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

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

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

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

[0077] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic 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.

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

[0079] 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 a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

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

[0081] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification 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 node and a second node, the method being executed by the first node, the method comprising: In a Trusted Execution Environment (TEE), a first transaction is pre-executed to obtain resource consumption information and a pre-execution read / write set generated based on the resource consumption information. The resource consumption information is the amount of digital or computing resources consumed to execute the first transaction. Trusted data is generated in the TEE based on the resource consumption information; The trusted data and the pre-execution read-write set are sent to the second node, so that the second node executes the first transaction based on the resource consumption information to obtain the execution read-write set. If it is determined from the execution read-write set and the pre-execution read-write set that the first node has not committed any malicious acts during the pre-execution of the first transaction, the execution write set of the read-write set is used as the status data of the first transaction.

2. The method according to claim 1, wherein the first transaction is used to invoke a smart contract; the pre-execution of the first transaction in a Trusted Execution Environment (TEE) includes: The smart contract is executed in the TEE based on the first transaction to obtain the resource consumption information.

3. The method according to claim 1, wherein the resource consumption information is calculated based on the data volume of the first transaction.

4. The method according to claim 1, wherein the trusted data is obtained by encrypting the resource consumption information.

5. The method according to claim 1, wherein the trusted data includes the resource consumption information and a signature corresponding to the resource consumption information.

6. The method according to any one of claims 1-5, wherein the trusted data and the pre-execution read-write set are located in a consensus proposal sent by the first node to the second node, and the consensus proposal further includes the first transaction or indication information for indicating the first transaction.

7. A transaction execution method in a blockchain system, the blockchain system comprising a first node and a second node, the method being executed by the second node, the method comprising: The trusted data and the pre-execution read / write set of the first transaction are received from the first node. The trusted data is generated by the first node in its TEE based on the resource consumption information of the first transaction. The resource consumption information and the pre-execution read / write set are obtained by the first node in its TEE by pre-executing the first transaction. The resource consumption information is the amount of digital resources or computing resources required to execute the first transaction. Execute the first transaction based on the resource consumption information to obtain the execution read / write set of the first transaction; Based on the executed read-write set and the pre-executed read-write set, determine whether the first node has acted maliciously during the pre-execution of the first transaction; otherwise, use the executed write set of the executed read-write set as the status data of the first transaction.

8. The method according to claim 7, wherein the resource consumption information is calculated based on the data volume of the first transaction.

9. The method according to claim 7, wherein the trusted data is obtained by encrypting the resource consumption information; the method further comprises: The trusted data is decrypted to obtain the resource consumption information.

10. The method according to claim 7, wherein the trusted data includes the resource consumption information and a signature corresponding to the resource consumption information; the method further includes: The signature is verified.

11. The method according to any one of claims 7-10, wherein the first transaction is any one of a plurality of transactions included or indicated by the consensus proposal from the first node; the method further comprises: The multiple transactions are divided into M transaction groups based on their respective pre-execution read / write sets, and the computation process corresponding to each of the M transaction groups is determined. The step of executing the first transaction based on the resource consumption information to obtain the execution read-write set of the first transaction specifically includes: executing each transaction in its corresponding transaction group based on the resource consumption information of each transaction in its corresponding transaction group through the computing process, and obtaining the execution read-write set of each transaction in its corresponding transaction group.

12. The method according to any one of claims 7-10, wherein the trusted data and the pre-execution read-write set are located in a consensus proposal sent by the first node to the second node, and the consensus proposal further includes the first transaction or indication information for indicating the first transaction.

13. A first node device in a blockchain system, the blockchain system further comprising a second node device, the first node device comprising: The pre-execution process is deployed in the TEE of the first node device and configured to pre-execute the first transaction. It obtains resource consumption information and a pre-execution read / write set generated based on the resource consumption information. The resource consumption information is the amount of digital resources or computing resources required to execute the first transaction. And configured to generate trusted data in the TEE based on the resource consumption information; The network process is configured to send the trusted data and the pre-execution read / write set to the second node device, so that the second node device executes the first transaction based on the resource consumption information to obtain the execution read / write set of the first transaction, and if it is determined from the execution read / write set and the pre-execution read / write set that the first node device has not committed any malicious acts during the pre-execution of the first transaction, the execution write set of the read / write set is used as the status data of the first transaction.

14. A second node device in a blockchain system, the blockchain system further comprising a first node device, the second node device comprising: A network process is configured to receive trusted data and a pre-execution read / write set of a first transaction from the first node device. The trusted data is generated by the first node device in its TEE based on the resource consumption information of the first transaction. The resource consumption information and the pre-execution read / write set are obtained by the first node device in its TEE by pre-executing the first transaction. The resource consumption information is the amount of digital resources or computing resources required to execute the first transaction. The computation process is configured to execute the first transaction based on the resource consumption information to obtain the execution read-write set of the first transaction; and configured to determine whether the first node device has committed malicious acts during the pre-execution of the first transaction based on the execution read-write set and the pre-execution read-write set, and if not, to use the execution write set of the execution read-write set as the status data of the first transaction.

15. A blockchain system comprising a first node and a second node, wherein: The first node is used to pre-execute a first transaction in a Trusted Execution Environment (TEE), obtain resource consumption information and a pre-execution read / write set generated based on the resource consumption information, wherein the resource consumption information is the quantity of digital or computing resources consumed to execute the first transaction; generate trusted data in the TEE based on the resource consumption information; and send the trusted data and the pre-execution read / write set to the second node. The second node is used to execute the first transaction based on the resource consumption information and obtain the execution read-write set of the first transaction; it determines whether the first node has acted maliciously during the pre-execution of the first transaction based on the execution read-write set and the pre-execution read-write set, and if not, uses the execution write set of the execution read-write set as the status data of the first transaction.

16. The blockchain system according to claim 15, wherein the first transaction is used to invoke a smart contract; the first node is used to execute the smart contract in the TEE based on the first transaction to obtain the resource consumption information.

17. The blockchain system according to claim 15, wherein the resource consumption information is calculated based on the data volume of the first transaction.

18. The blockchain system according to claim 15, wherein the trusted data is obtained by encrypting the resource consumption information; the second node is further configured to decrypt the trusted data to obtain the resource consumption information.

19. The blockchain system according to claim 15, wherein the trusted data includes the resource consumption information and a signature corresponding to the resource consumption information; the second node is further configured to verify the signature.

20. The blockchain system according to any one of claims 15-19, wherein the first transaction is any one of a plurality of transactions included or indicated by a consensus proposal sent by the first node to the second node; the second node is further configured to divide the plurality of transactions into M transaction groups according to their respective pre-execution read-write sets, and determine the computation process corresponding to each of the M transaction groups; The second node is specifically used to execute each transaction in its corresponding transaction group based on the resource consumption information of each transaction in its corresponding transaction group through the computing process, and to obtain the execution read and write set of each transaction in its corresponding transaction group.

21. The blockchain system according to any one of claims 15-19, wherein the trusted data and the pre-execution read-write set are located in a consensus proposal sent by the first node to the second node, and the consensus proposal further includes the first transaction or indication information for indicating the first transaction.

Images