Method for executing transaction in block chain and block chain node

Abstract

A method for executing a transaction in a block chain and a block chain node, the method is executed by a first node in the block chain, and the method comprises the steps of creating a first state set and a second state set corresponding to the transaction when the transaction is executed; before a first variable is written according to the transaction, a first state of the first variable is read, the first state is the current state of the first variable, and the first state of the first variable is stored in the first state set; storing a second state of the first variable in the second state set, wherein the second state is the state of the first variable written according to the transaction; and when it is determined that the write operation of the transaction on the first variable needs rollback, generating a write set of the transaction at least according to the first state set.

Description

[0001] This application is filed on May 30, 2022, with application number 202210602794.3, and the invention title is "In Block". This is a divisional application of the invention patent application for "Methods for Executing Transactions in a Blockchain and Blockchain Nodes". Technical Field

[0002] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for executing transactions in a blockchain and a blockchain node. Background Technology

[0003] 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

[0004] The purpose of this invention is to provide a method for executing transactions in a blockchain, so as to effectively change the read-write set of a transaction when the execution of the transaction is rolled back.

[0005] This specification provides, in a first aspect, a method for executing transactions in a blockchain, the method being executed by a first node in the blockchain, the method comprising:

[0006] When executing a transaction, a first state set and a second state set corresponding to the transaction are created;

[0007] Before writing to the first variable according to the transaction pair, read the first state of the first variable, the first state being the current state of the first variable, and store the first state of the first variable in the first state set;

[0008] The second state of the first variable is stored in the second state set, and the second state is the state of the first variable written according to the transaction;

[0009] When it is determined that the write operation of the transaction to the first variable needs to be rolled back, at least the write set of the transaction is generated based on the first state set.

[0010] A second aspect of this specification provides a method for executing transactions in a blockchain, the blockchain including a first node and a second node, the first node running a pre-execution process, a caching process, and a first consensus process, the method being executed by the first node, the method comprising:

[0011] The caching process sends the received transactions to the pre-execution process;

[0012] When pre-executing the transaction, the pre-execution process generates a pre-execution read set for the transaction, creates a first state set and a second state set corresponding to the transaction in the memory of the pre-execution process; before writing to a first variable according to the transaction, it reads the first state of the first variable, which is the current state of the first variable, and stores the first state of the first variable in the first state set; it stores the second state of the first variable in the second state set, which is the state of the first variable written according to the transaction; when it is determined that the write operation of the transaction to the first variable needs to be rolled back, at least a pre-execution write set for the transaction is generated based on the first state set.

[0013] After pre-executing multiple transactions, the pre-execution process sends the pre-execution read set, pre-execution write set, and pre-execution order of the multiple transactions to the caching process.

[0014] The consensus process receives the pre-execution read set, pre-execution write set, and pre-execution order of the multiple transactions from the caching process, generates a consensus proposal, which includes the pre-execution read set, pre-execution write set, and pre-execution order of the multiple transactions, and sends the consensus proposal to the second node.

[0015] A third aspect of this specification provides a method for executing transactions in a blockchain, the blockchain including a first node and a second node, wherein the second node runs a second consensus process, a block management process, and N computation processes, the method comprising:

[0016] The second consensus process receives a consensus proposal from the first node, the consensus proposal including a pre-execution read-write set and a pre-execution order of multiple transactions, and sends the pre-execution read-write set and pre-execution order of the multiple transactions to the block management process;

[0017] The block management process groups the multiple transactions according to the pre-execution read / write set and the pre-execution order to obtain multiple transaction groups, and distributes the information of the multiple transaction groups to the N computing processes;

[0018] When the N computing processes execute the transactions of the multiple transaction groups in parallel, for each transaction in the transaction group, an execution read set for the transaction is generated, and a third state set and a fourth state set corresponding to the transaction are created; before writing to the first variable according to the transaction, the third state of the first variable is read, the third state being the current state of the first variable, and the third state of the first variable is stored in the third state set; the fourth state of the first variable is stored in the fourth state set, the fourth state being the state of the first variable written according to the transaction; when it is determined that the write operation of the transaction to the first variable needs to be rolled back, at least the execution write set of the transaction is generated according to the third state set; the execution read-write sets of the multiple transactions are compared with the pre-execution read-write sets of the multiple transactions to see if they are consistent, and if they are consistent, the execution read-write set is confirmed to be correct, the execution read-write set including the execution read set and the execution write set.

[0019] The fourth aspect of this specification provides a first node in a blockchain, comprising:

[0020] A creation unit is used to create a first state set and a second state set corresponding to the transaction when executing the transaction;

[0021] The first storage unit is used to read the first state of the first variable before writing to the first variable according to the transaction pair. The first state is the current state of the first variable, and the first state of the first variable is stored in the first state set.

[0022] The second storage unit is used to store the second state of the first variable in the second state set, wherein the second state is the state of the first variable written according to the transaction;

[0023] The generation unit is configured to generate a write set of the transaction based at least on the first state set when it is determined that the write operation of the transaction to the first variable needs to be rolled back.

[0024] The fifth aspect of this specification provides a second node in a blockchain, comprising:

[0025] A receiving unit is configured to receive a pre-execution read / write set and a pre-execution order of multiple transactions from the first node in the blockchain.

[0026] A grouping unit is used to group the multiple transactions according to the pre-execution read / write set and the pre-execution order to obtain multiple transaction groups;

[0027] The first generation unit is used to generate an execution read set for each transaction in the transaction group and create a third state set and a fourth state set corresponding to the transaction when executing the transactions of the multiple transaction groups in parallel.

[0028] A first storage unit is configured to read a third state of the first variable before writing to the first variable according to the transaction pair, the third state being the current state of the first variable, and to store the third state of the first variable in the third state set.

[0029] The second storage unit is used to store the fourth state of the first variable in the fourth state set, wherein the fourth state is the state of the first variable written according to the transaction.

[0030] The second generation unit is used to generate the execution write set of the transaction at least according to the third state set when it is determined that the write operation of the transaction to the first variable needs to be rolled back.

[0031] The comparison unit is used to compare whether the execution read-write set of the plurality of transactions is consistent with the pre-execution read-write set of the plurality of transactions, so as to determine whether the execution read-write set of the plurality of transactions is correct, wherein the execution read-write set includes the execution read set and the execution write set.

[0032] A sixth 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 methods described in the first to third aspects.

[0033] A seventh aspect of this specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the methods described in the first to third aspects. Attached Figure Description

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

[0035] Figure 1 A diagram illustrating the blockchain architecture used in the embodiments described in this specification is shown.

[0036] Figure 2 This is an architecture diagram of the blockchain node in the embodiments of this specification;

[0037] Figure 3 This is a flowchart illustrating the method for executing transactions in a blockchain as described in the embodiments of this specification.

[0038] Figure 4 This is a schematic diagram of the structure of the main node in one embodiment of this specification;

[0039] Figure 5 This is a schematic diagram of the structure of the main node in another embodiment of this specification;

[0040] Figure 6 This is a flowchart illustrating the method for executing transactions in a blockchain as described in the embodiments of this specification.

[0041] Figure 7 This is a flowchart illustrating the method for executing transactions in a blockchain as described in the embodiments of this specification.

[0042] Figure 8 This is a structural diagram of the first node in a blockchain according to one embodiment of this specification;

[0043] Figure 9 This is a structural diagram of a second node in a blockchain according to one embodiment of this specification. Detailed Implementation

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

[0045] Figure 1 This diagram illustrates the blockchain architecture used in the embodiments described in this specification. Figure 1 In this blockchain, for example, there are six nodes: master node 1 and slave nodes 2 through 5. The connections between the nodes schematically represent P2P (Peer-to-Peer) connections. Each node stores the full ledger, containing the state of all blocks and all accounts. Each node in the blockchain generates the same state by executing the same transactions, and each node stores the same state database. The difference lies in that master node 1 is responsible for receiving transactions from clients and initiating consensus proposals to the slave nodes. These proposals include information such as the multiple transactions in the block to be formed (e.g., block B1) and their order. After the nodes in the blockchain successfully reach a consensus on the proposal, each node executes the transactions according to the order specified in the proposal, thereby generating block B1.

[0046] Understandable. Figure 1 The blockchain shown is merely exemplary, and the embodiments described in this specification are not limited to applications. Figure 1The blockchain shown can also be applied to non-master-slave blockchain systems.

[0047] in addition, Figure 1 Although the example shows a blockchain with 6 nodes, this specification's embodiments are not limited to this and may include other numbers of nodes. Specifically, the nodes in the blockchain can satisfy the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as the existence of Byzantine nodes within the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require a number of nodes greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0048] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a send field (From), a receive field (To), and a data field (Data). Blockchain transactions can include platform transactions and contract transactions. Platform transactions primarily revolve around platform account operations, including account creation, fund transfers, account freezing, account unfreezing, asset issuance, and notarization. Contract transactions primarily revolve around contract execution operations, including contract deployment, contract invocation, and contract upgrades.

[0049] For example, in the case of a transfer transaction, the From field represents the account address that initiated the transaction (i.e., initiated the transfer task to another account), the To field represents the account address that received the transaction (i.e., received the transfer), and the Data field includes the transfer amount. In the case of a transaction that invokes a contract, the From field represents the account address that initiated the transaction, the To field represents the account address of the contract invoked by the transaction, and the Data field includes the function name in the invoked contract and the parameters passed to that function, etc., to be used to retrieve and execute the function's code from the blockchain during transaction execution.

[0050] Accounts in a blockchain can generally be divided into two types:

[0051] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code. It can usually only be activated by an external account.

[0052] Externally owned account: The account of a blockchain user.

[0053] In blockchain, a smart contract is a contract that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in 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. It's important to note that besides users creating smart contracts, the system can also set smart contracts in the genesis block. These contracts are generally called genesis contracts. Typically, the genesis contract can set some blockchain data structures, parameters, attributes, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0054] 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, the contract address "0x6f8ae93…" is determined. 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, and saves the contract code in the contract's state storage, thus the contract is successfully created.

[0055] 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 "0x6f8ae93…" represents 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.

[0056] In related technologies, to improve the transactions per second (TPS) metric in a blockchain, it is necessary to accelerate transaction execution. To this end, blockchain nodes can accelerate transaction execution by executing transactions in parallel. Typically, for transfer transactions, blockchain nodes first divide multiple transactions into multiple transaction groups based on the accounts accessed by the transactions. These transaction groups do not access the same accounts, thus allowing for parallel execution of each transaction group. However, when a smart contract is invoked within a transaction, the variables accessed in that transaction cannot be predicted before execution, making it impossible to effectively group multiple transactions and thus preventing parallel execution. In one implementation, the first node in the blockchain (e.g., Figure 1 The master node 1) pre-executes multiple transactions, obtaining a pre-execution read / write set for each transaction, and sends this pre-execution read / write set to other nodes in the blockchain (e.g., [node name missing]) through a consensus process with other nodes. Figure 1 (The slave nodes in the blockchain). A transaction's pre-execution read / write set includes, for example, a pre-execution read set and a pre-execution write set. The pre-execution read set includes key-value pairs of variables read during pre-execution, and the pre-execution write set includes key-value pairs of variables written during pre-execution. These variables may include, for example, external accounts in the blockchain or variables defined in a contract account. Other nodes in the blockchain can group multiple transactions based on their pre-execution read / write sets, allowing for parallel execution of these transactions based on the grouping results.

[0057] When a node in a blockchain is pre-executing a transaction, there may be situations where the transaction pre-execution fails or the contract invoked in the transaction fails to execute, requiring effective modification of the transaction's pre-execution read / write set.

[0058] Figure 2 This is an architecture diagram of the blockchain node in the embodiments of this specification. Figure 2 As shown, Figure 1 The blockchain shown includes master node 1 and various slave nodes (e.g., ...). Figure 2 Multiple processes can run in each of the slave nodes (2) shown to provide various services. Specifically, the master node 1 may include a caching process 12 for providing caching services, pre-execution processes 111 and 112 for providing pre-execution services, a consensus process 13 for providing consensus services, and a block management process 14 for providing block management services, etc. The pre-execution processes 111 and 112 are used to perform pre-execution of transactions received by the master node in parallel. It can be understood that in the embodiments of this specification, the master node 1 is not limited to including two pre-execution processes, but may include one or more pre-execution processes. In addition, the master node 1 may also include an access process for providing access services, a network process for providing network services, a storage process for providing storage services, etc. Figure 2 Not shown in the image.

[0059] Node 2 may include a caching process 21 for providing caching services, a consensus process 22 for providing consensus services, a block management process 23 for providing block management services, and computation processes 241 and 242 for providing transaction execution services. The computation processes 241 and 242 are used to execute transactions in the consensus proposal in parallel. It is understood that in this embodiment, Node 2 is not limited to including two computation processes, but may include one or more computation processes.

[0060] A process is a running activity of a program with a certain independent function within an application, concerning a set of data. In other words, a process is a procedure in a computer performed by the CPU sequentially executing instructions from an application. Each process is allocated its own memory address space upon creation, and this memory address space can only be accessed by the process itself. For example, pre-execution process 111 is allocated memory 113, pre-execution process 112 is allocated memory 114, cache process 12 is allocated memory 120, cache process 21 is allocated memory 210, computation process 241 is allocated memory 243, and computation process 242 is allocated memory 244.

[0061] In this embodiment, the multiple processes in master node 1 can be multiple processes in multiple computing devices (or virtual computing nodes) or multiple processes in a single computing device. Similarly, the multiple processes in each slave node can be multiple processes in multiple computing devices (or virtual computing nodes) or multiple processes in a single computing device. Furthermore, it should be noted that the solutions provided in the embodiments of this specification are not limited to master-slave blockchain systems.

[0062] Figure 3 This is a flowchart illustrating a method for executing transactions in a blockchain, as described in the embodiments of this specification. This method can be... Figure 1 The master node 1 and each slave node execute, Figure 3 The example shown is from node 2.

[0063] like Figure 3 As shown, firstly, in step S301, when the master node 1 is about to execute a transaction, it generates a pre-execution read set of the transaction and creates a state set Si0 and a state set Si1 of the transaction, where i corresponds to the transaction number of the transaction. For example, transaction Tx1 corresponds to state set S10 and state set S11.

[0064] This step can be performed by Figure 2 The pre-execution process occurs within the system. In the case where master node 1 includes one pre-execution process, this process can pre-execute multiple received transactions serially. In the case where master node 1 includes multiple pre-execution processes, these multiple pre-execution processes can pre-execute multiple received transactions in parallel. The scenario of multiple pre-execution processes executing transactions in parallel will be discussed in detail below. Figure 6 Detailed description.

[0065] Specifically, master node 1 can continuously receive transactions from user devices and store the received transactions sequentially in a transaction queue. After receiving a transaction, master node 1 can broadcast it to the blockchain, allowing all slave nodes to also receive and store the transaction. Master node 1 can periodically retrieve multiple transactions from the transaction queue and pre-execute them serially. As mentioned above, the transactions can be platform transactions or contract transactions. It is understood that master node 1 can also pre-execute multiple transactions in parallel without limitation.

[0066] Figure 4 This is a schematic diagram of the structure of main node 1 in one embodiment of this specification. Figure 4 As shown, when master node 1 is about to execute any platform transaction Txi, before performing write operations on variables (i.e., external accounts), it generates state sets Si0 and Si1 to generate a pre-execution write set based on state sets Si0 and / or Si1, where i corresponds to the transaction number. Specifically, state sets Si0 and Si1 are used to store key-value pairs of external accounts involved in the write operations in transaction Txi.

[0067] In addition, when master node 1 pre-executes any platform transaction, it generates a pre-execution read set for that transaction, thereby obtaining a pre-execution read-write set for that transaction. This pre-execution read-write set includes the pre-execution read set and the pre-execution write set for the transaction.

[0068] in, Figure 3 Steps S301 to S307 shown can be derived from... Figure 2 The pre-execution process 111 is executed. For example, when pre-executing any platform transaction Txi, the pre-execution process 111 can generate state set Si0 and state set Si1, and store state set Si0 and state set Si1 in memory 113.

[0069] For example, among the multiple transactions is transaction Tx1, which is a platform transaction, for example, sent by account A to transfer 10 yuan from account A to account B. Both account A and account B are external accounts in the blockchain. When master node 1 pre-executes transaction Tx1, in order to perform the transfer from account A to account B, it first reads the current account balance of account A and the current account balance of account B. Master node 1 can determine whether the balances of account A and account B are stored in memory. If it is determined that the balances of account A and / or account B are not in memory, master node 1 can read the balances of account A and / or account B from the state database and store them in memory. If it is determined that the balances of account A and / or account B are stored in memory, the balances of account A and / or account B can be read from memory. After reading the balances of account A and / or account B, master node 1 generates a pre-execution read set for transaction Tx1, recording the key-value pairs of account A and account B in the pre-execution read set. Taking the key-value pair of account A as an example, the key is, for example, the account address of account A, and the value is the balance of account A. For example, if the balance of account A is read to be 50, then in the pre-execution read set of transaction Tx1, it is recorded as: Account A: 50.

[0070] After storing the balances of accounts A and B in memory, master node 1 updates the balances of accounts A and / or B directly in memory during the pre-execution of transactions. Furthermore, master node 1 trusts its own pre-execution results. After pre-executing multiple transactions, it updates the state database based on these results, ensuring that the states of certain variables in the state database match the states stored in memory. Therefore, the state of variables (e.g., account or contract variables) stored in memory by master node 1 during the pre-execution of multiple transactions represents the latest world state of those variables in master node 1.

[0071] During the pre-execution of transaction Tx1, before performing the first write operation, master node 1 can create state set S10 and state set S11 for transaction Tx1. State set S10 records the state of each account in transaction Tx1 whose state is to be updated (i.e., to be written) before the state update, for rollback in case of transaction Tx1 pre-execution failure. State set S11 records the latest world state of each account written during the pre-execution of transaction Tx1.

[0072] In addition, when master node 1 pre-executes any platform transaction, it generates a pre-execution read set for that transaction, thereby obtaining the pre-execution read-write set for that transaction.

[0073] Figure 5 This is a schematic diagram of the structure of main node 1 in another embodiment of this specification. For example... Figure 5As shown, when master node 1 pre-executes any contract transaction Txi, assuming that contract transaction Txi calls contract C1, and contract C1 calls contract C2, master node 1 generates a state set Si0 before performing write operations on variables (i.e., external account or contract variables). C1 Si0 C2 and state set Si1, based on state set Si0 C1 Si0 C2 And / or state set Si1 generates a pre-execution write set, where i corresponds to the transaction number. Specifically, state set Si0 C1 Si0 C2 Each of the state set Si1 can include an account state set and a contract variable state set. The account state set can be used to update the state data in the world state tree, and the contract variable state set can be used to update the state data in the contract state tree.

[0074] For example, the plurality of transactions also includes transaction Tx2, which is sent, for example, by an external account C. Transaction Tx2 calls contract C1, and contract C1 calls contract C2, for example. When master node 1 pre-executes transaction Tx2, it records the key-value pair of any variable in the pre-execution read set of transaction Tx2 when reading the state of any variable. This variable can be an external account in the blockchain or a contract variable defined in the contract. Before master node 1 first writes to the variable during the execution of contract C1, it can generate a state set S20 corresponding to contract C1. C1 and the state set S21 corresponding to transaction Tx2, where state set S20 C1 State set S21 records the state of each variable to be updated during the pre-execution process of contract C1, prior to the state update, for rollback in case of contract C1 pre-execution failure. State set S21 records the latest world state of each variable written during the pre-execution process of transaction Tx2. Before the master node first writes to variables during the execution of contract C2, it can generate state set S20 corresponding to contract C2. C2 State set S20 C2 The variables used to record the state to be updated during the pre-execution process of contract C2 are in their state before the state update, so as to be used for rollback if the pre-execution of contract C2 fails.

[0075] In step S303, before writing the transaction pair variable, master node 1 reads the world state Vi1 of the variable and stores the state Vi1 of the variable in the state set Si0. The state Vi1 is the current world state of the variable.

[0076] For the aforementioned transaction Tx1, Master Node 1 can determine that the balance of Account A after the transfer is 50-10=40 based on transaction Tx1. Therefore, Master Node 1 can perform a write operation on Account A to update the world state of Account A to 40. Before writing to Account A, Master Node 1 first reads the state V11 of Account A. Master Node 1 can first determine whether the state of Account A exists in the latest world state of variables stored in Master Node 1's memory. If it does, it can directly read the state V11 of Account A from memory, for example, V11=50. If the state of Account A is not stored in memory, Master Node 1 can read the state V11 of Account A from the state database. After reading the state V11 of Account A, Master Node 1 stores the key-value pair "Account A:V11" of Account A in the state set S10.

[0077] For the transaction Tx2 mentioned above, assuming contract C1 includes a write operation to variable 'a', and contract C2 includes a write operation to variable 'b', when master node 1 is about to write to variable 'a' during the execution of contract C1, it reads the world state V21 of variable 'a'. a The key-value pair of variable a, "a: V21", will be used. a Stored in state set S20 C1 In the process of executing contract C2, when writing to variable b, the world state V21 of variable b is read. b The key-value pair of variable b, "b: V21", will be used. b Stored in state set S20 C2 middle.

[0078] In step S305, master node 1 stores the write state Vi2 of the variable in state set Si1.

[0079] Specifically, for the transaction Tx1 mentioned above, as described above, master node 1 determines that state 40 will be written to account A. Therefore, master node 1 stores the key-value pair "account A:40" of account A in state set S11.

[0080] For the aforementioned transaction Tx2, when master node 1 executes contract C1, it sets the key-value pair of variable a, "a: V22". a "Store it in state set S21. When executing contract C2, store the key-value pair of variable b, "b: V22". b "Store it in state set S21. Among them, V22" a For the value written to variable a when executing contract C1, V22 b This is the value written to variable b when contract C2 is executed.

[0081] In step S307, when the master node 1 rolls back the write operation, it generates a pre-execution write set of the transaction based on the state set Si0 at least.

[0082] Specifically, for transaction Tx1, assuming master node 1 determines that account B does not exist when it is about to write to account B, or determines that the balance of account B will exceed the preset balance limit after the write, in this case, master node 1 determines that transaction Tx1 has failed and needs to roll back all operations of transaction Tx1. For details, refer to... Figure 4 Master node 1 generates a pre-execution write set for transaction Tx1 based on state set S10. Since the state of account A recorded in state set S10 is consistent with the current world state of account A (i.e., the rolled-back world state), it can be concluded that the pre-execution write set for transaction Tx1 currently does not include key-value pairs of variables. In some implementations, when pre-executing transaction Tx1, since transaction Tx1 is a platform transaction, master node 1 can determine the blockchain usage fee (e.g., m yuan) for user A to use the blockchain to process transaction Tx1 based on the data volume of transaction Tx1, and record the state of account A after deducting m from the balance of account A, and the state of account D after adding m to account D, in the pre-execution write set of transaction Tx1, where account D is a system account used to collect blockchain usage fees from external accounts in the blockchain.

[0083] For transaction Tx2, assuming that master node 1 determines that contract C2 has failed during execution, it is necessary to roll back the execution of contract C2. In the actual execution of the smart contract within the transaction, any of the following situations may cause contract execution failure: insufficient gas resources (GAS) balance for transaction execution, illegal instructions in the contract, read / write failures to storage units, virtual machine stack overflow, virtual machine memory overflow, transfer failure, contract read failure, etc.

[0084] Specifically, see reference Figure 5 Master node 1, according to state set S20 C2 The pre-execution write set for transaction Tx2 is generated from state set S21, due to state set S20. C2The state of variable b recorded in the state set is consistent with the current world state of variable b (i.e., the rolled-back world state). Therefore, it can be concluded that the pre-execution write set of transaction Tx2 currently does not include the key-value pairs of variable b, but only includes the key-value pairs of variable a in state set S21 that have not been rolled back. In some implementations, when master node 1 pre-executes transaction Tx2, since transaction Tx2 is a contract transaction, master node 1 can determine the blockchain usage fee (e.g., n yuan) for the user to use the blockchain to process transaction Tx2 based on the code of the contract called by transaction Tx2, and record the state of account C after deducting n from the balance of account C, and the state of account D after adding n to account D in the pre-execution write set of transaction Tx2. Different usage fees can be set for different instructions in the contract (e.g., addition instructions, subtraction instructions, etc.) in the blockchain virtual machine, and the blockchain usage fees are accumulated during the execution of the instructions in the contract. For example, during the rollback of the execution of contract C2, the blockchain usage fees accumulated during the execution of contract C2 are not rolled back.

[0085] In another scenario, for transaction Tx2, suppose master node 1, after successfully executing contract C2, determines during the process of returning to execute contract C1 that contract C1 failed. Therefore, it is necessary to roll back the execution of both contract C1 and contract C2. Specifically, master node 1, based on state set S20... C1 and state set S20 C2 Generate the pre-execution write set for transaction Tx2, that is, master node 1 can do so based on state set S20. C1 and state set S20 C2 Determine the state set S20 C1 and state set S20 C2 The values ​​of variables a and b recorded in the database are consistent with their current world state; therefore, the key-value pairs of variables a and b do not need to be included in the pre-execution write set. Similarly, the pre-execution write set may include key-value pairs of accounts C and D, which are determined based on the blockchain usage fees accumulated by the virtual machine during the execution of contracts C1 and C2.

[0086] After completing the pre-execution of a transaction, Master Node 1 can update the world state of the variables in the pre-execution write set in memory based on the pre-execution write set of the transaction, so that subsequent transactions involving the variable can read the world state of the variable from memory during pre-execution.

[0087] In step S309, master node 1 sends the pre-execution read-write set and pre-execution order of multiple transactions to slave node 2.

[0088] After the pre-execution process in master node 1 pre-executes multiple transactions as described above and obtains the pre-execution read-write sets of each transaction, it can send the pre-execution read-write sets and pre-execution order of the multiple transactions to the caching process 12 for storage in memory 120. The consensus process 13 can then obtain the pre-execution read-write sets and pre-execution order of the multiple transactions from the caching process 12 and generate a consensus proposal to initiate consensus. This consensus proposal includes, for example, the pre-execution read-write sets of each of the multiple transactions and their pre-execution order. Each transaction in the consensus proposal is identified, for example, by its hash value. After completing the pre-execution of each transaction, master node 1 can store the transaction's identifier in the transaction queue to indicate the pre-execution order of the transaction.

[0089] After generating a consensus proposal, consensus process 13 can send the consensus proposal to block management process 14, so that block management process 14 can update the state data block based on the consensus proposal and generate a block to be stored in the block database.

[0090] After generating a consensus proposal, master node 1 sends the consensus proposal to other slave nodes so that all nodes in the blockchain can reach a consensus on the consensus proposal based on the consensus mechanism.

[0091] The consensus mechanism 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.

[0092] In one implementation, after obtaining the pre-execution read / write sets of multiple transactions, master node 1 can perform noise analysis on these sets to improve transaction execution efficiency. Specifically, for example, if master node 1 determines that the multiple transactions only include read operations on, for example, variable c, and do not include write operations on variable c, it can delete the key-value pairs of variable c from the pre-execution read sets of the multiple transactions. Since the multiple transactions do not include write operations on variable c, the world state of variable c does not change during the pre-execution of the multiple transactions. Therefore, one or more transactions that read variable c do not have access conflicts to variable c. By deleting the key-value pairs of variable c from the pre-execution read sets of the multiple transactions, it is possible to avoid grouping multiple transactions that read variable c into the same group.

[0093] In another example, the plurality of transactions includes multiple first transactions, each transferring a preset amount (a positive amount) to a first account in the blockchain. Therefore, the master node 1 can delete the key-value pair of the first account from the pre-execution read-write set of the plurality of first transactions. For example, each of the plurality of transactions needs to transfer funds to the aforementioned account D to pay blockchain usage fees. In this case, each transaction is associated with account D, affecting transaction grouping. Therefore, deleting the key-value pair of account D from the read-write set of the plurality of transactions helps to execute transactions more efficiently in parallel.

[0094] In step S311, after receiving the pre-execution read-write set and pre-execution order of multiple transactions, node 2 groups the multiple transactions according to the pre-execution read-write set and executes the multiple transactions in parallel according to the grouping result.

[0095] After receiving the consensus proposal, the block management process 23 in slave node 2 can group the multiple transactions according to the pre-execution read / write set in the consensus proposal. This ensures that all transactions in any two groups do not access the same variables, allowing the groups to be executed in parallel. The multiple transactions in each group are arranged according to their pre-execution order. After grouping the multiple transactions, the block management process 23 can evenly distribute the resulting transaction groups to the various computation processes in slave node 2. After the consensus process 22 in slave node 2 reaches consensus on the consensus proposal with other nodes, each computation process in slave node 2 can retrieve the multiple transactions proposed in the consensus proposal from the received transactions based on the hash values ​​of each transaction in the consensus proposal. These multiple transactions are then executed in parallel according to the grouping results, thus executing the transactions in each group in parallel.

[0096] It is understood that the embodiments in this specification are not limited to grouping multiple transactions by slave node 2. For example, master node 1 may also group multiple transactions according to the pre-execution read-write set of multiple transactions and generate a consensus proposal, which includes the pre-execution read-write set, pre-execution order and grouping result of multiple transactions.

[0097] In step S313, when executing each transaction, node 2 generates an execution read set for the transaction and creates a state set Sti0 and a state set Sti1 for the transaction, where i corresponds to the transaction number of the transaction.

[0098] Steps S313 to S321 can be performed by Figure 2 Each computation process (e.g., computation process 241 and computation process 242) in the process is executed.

[0099] Similar to pre-execution, the execution read set includes key-value pairs of variables read during the execution of the transaction, and the execution write set includes key-value pairs of variables written during the execution of the transaction. Therefore, when node 2 executes a transaction, it records the key-value pairs of the read variables in the execution read set whenever a variable read operation is performed, thereby generating the execution read set of the transaction.

[0100] Referring to the description of step S301 above, node 2 can create a state set Sti0 and a state set Sti1 for transaction Txi before the first write operation during the execution of transaction Txi. State set Sti0 records the state of each variable in transaction Txi before its update, for rollback in case of transaction Txi execution failure. State set Sti1 records the latest state of each account written during transaction Txi execution; this state is the world state, and the variables can be external accounts in the blockchain or contract variables defined in the contract.

[0101] In step S315, before writing based on the transaction pair variable, node 2 reads the world state Vi1 of the variable and stores the state Vi1 of the variable into the state set Sti0.

[0102] In step S317, the write state Vi2 of the variable stored by node 2 in the state set Sti1 is obtained.

[0103] In step S319, when node 2 rolls back a write operation, it generates an execution write set of the transaction based on at least the state set Sti0.

[0104] Steps S315 to S319 can be referred to the description of steps S303 to S307 above, and will not be repeated here.

[0105] In step S321, node 2 compares whether the pre-execution read / write set and the execution read / write set of the transaction are consistent.

[0106] After each transaction is completed, node 2 can compare the pre-execution read / write set with the execution read / write set for that transaction. If the pre-execution read / write set and the execution read / write set are found to be consistent, node 2 can update the world state of the variables in the execution write set in memory based on the execution write set of that transaction, so that subsequent transactions involving those variables can read the world state of those variables from memory during execution.

[0107] When it is determined that the pre-execution read-write sets and execution read-write sets of multiple transactions are consistent, slave node 2 can confirm that master node 1 has not acted maliciously, and the pre-execution read-write sets of multiple transactions are correct. Therefore, the grouping based on these pre-execution read-write sets is also correct. Consequently, the transaction execution results obtained by executing multiple transactions in parallel under these groups are also correct, meaning that the execution read-write sets of multiple transactions are correct. Each computing process can update the state database according to the execution write sets of each transaction it is assigned to. After each computing process completes the execution of the transactions, block management process 23 generates blocks and stores them in the block database.

[0108] When slave node 2 determines that the pre-execution read-write set and the execution read-write set of a transaction are inconsistent, it can determine that master node 1 has engaged in malicious behavior. Therefore, it can terminate the execution of multiple transactions and perform operations with other slave nodes to replace the master node.

[0109] Figure 6 This is a flowchart illustrating a method for executing transactions in a blockchain, as described in the embodiments of this specification. This method can be... Figure 2 The master node 1 in the process is executed.

[0110] like Figure 6 As shown, firstly, in step S601, the cache process 12 in the master node 1 sends multiple transactions to the pre-execution process 111.

[0111] As shown above, in addition to the main node 1, Figure 2 In addition to the processes shown, an access process may also be included, which can receive transactions from the user equipment and send the received transactions to the caching process 12, thereby storing the transactions received from the access process into the memory 120 of the caching process 12 in a certain order. For example, the caching process 12 can store transactions in the order they were received, such as storing the received transactions sequentially into a transaction queue stored in the memory 120.

[0112] Master node 1 may also include network processes ( Figure 2 (Not shown in the image) After receiving multiple transactions, the caching process 12 can send the multiple transactions to the network process, which in turn broadcasts the multiple transactions to other nodes in the blockchain.

[0113] Meanwhile, for each pre-execution process (including pre-execution process 111 and pre-execution process 112), the caching process 12 can periodically send a preset number of transactions from the transaction queue to the pre-execution process, so that each pre-execution process can execute the transactions in the transaction queue in parallel. The caching process 12 can also send the order of these transactions in the transaction queue to the pre-execution process, so that the pre-execution process can execute these transactions serially according to their order in the transaction queue.

[0114] In step S603, the pre-execution process 111 pre-executes multiple transactions to obtain a pre-execution read / write set for each transaction.

[0115] After receiving multiple transactions from the caching process 12, the pre-execution process 111 can first verify the signature of each transaction. After successful verification, it can pre-execute the multiple transactions. The pre-execution process 111 executes the received multiple transactions serially. For example, the pre-execution process 111 can execute the multiple transactions serially according to the order in which they are received.

[0116] In the embodiments described in this specification, memory 113 may store a state set of some variables in the blockchain, including variables defined in blockchain accounts or contracts. When the pre-execution process 111 reads or writes variables during the pre-execution of a transaction, it can update the locally cached state set. The pre-execution process 111 can... Figure 3 The method shown yields the pre-execution write set for each transaction.

[0117] After pre-executing multiple transactions, pre-execution process 111 obtains the pre-execution read / write sets for each transaction and the pre-execution order of the transactions.

[0118] The memory 120 of cache process 12 stores a state set of some variables in the blockchain. Updates to this state set can be referenced... Figure 6 The following describes the subsequent steps. When each pre-execution process reads a variable during the pre-execution transaction, it first determines whether the value of the variable is included in the state set stored locally in the pre-execution process. If not, it then determines whether the value of the variable is included in the state set in the memory of the cache process. If it is still not included, it reads the value of the variable from the state database and stores the read value of the variable in the state set of the pre-execution process.

[0119] Specifically, these multiple transactions include, for example, transaction Tx3. Assuming transaction Tx3 includes a read operation on variable 'a' and a write operation on variable 'b', when pre-execution process 111 executes the read operation on variable 'a' in transaction Tx3, it first determines whether the value of variable 'a' is stored in its memory 113. If the value of variable 'a' is stored in memory 113, pre-execution of transaction Tx3 can be completed based on that value, generating a pre-execution read / write set for transaction Tx3. For example, the pre-execution read set of transaction Tx3 includes key-value pairs of variable 'a', and the pre-execution write set includes key-value pairs of variable 'b'. In generating the pre-execution read / write set of transaction Tx3, pre-execution process 111 updates the state set in memory 113 based on the write set of transaction Tx3, storing the value of variable 'b' written during pre-execution of transaction Tx3 in this state set.

[0120] In another scenario, if the pre-execution process 111 determines that the state set in memory 113 does not contain the value of variable 'a', it may request the cache process 12 to read the value of variable 'a'. Upon receiving this request, the cache process 12 determines whether the state set in memory 120 contains the value of variable 'a'. If it does, it sends the value of variable 'a' to the pre-execution process 111. The pre-execution process 111, upon receiving the value of variable 'a', stores the value of variable 'a' in the state set in memory 113, making it available for subsequent transactions that read variable 'a'. If the state set in memory 120 does not contain the value of variable 'a', the cache process 12 notifies the pre-execution process 111, which then reads the current value of variable 'a' from the state database, which stores the world state corresponding to completed blocks. The master node 1 may also include a storage process. The pre-execution process 11 may, for example, send a request to the storage process to read variable 'a'. Upon receiving this request, the storage process reads the value of variable 'a' from the state database and returns the value of variable 'a' to the pre-execution process 111. After receiving the value of variable a from the storage process, the pre-execution process 111 similarly stores the value of variable a into the first state set. By storing the value of variable a read from outside memory 113 into memory 113, the pre-execution process 111 can directly read the value of variable a from local memory when reading variable a in the next transaction execution, thereby improving the transaction execution speed.

[0121] After each transaction is completed, the pre-execution process 111 also generates a transaction receipt for each transaction.

[0122] In step S605, the pre-execution process 111 sends the pre-execution read-write set and pre-execution order of multiple transactions to the caching process 12.

[0123] After completing the pre-execution of multiple transactions as described above, the pre-execution process 111 sends the resulting pre-execution read / write set and pre-execution order of the multiple transactions to the caching process 12. In addition, the pre-execution process 111 also sends the transaction receipts of each transaction to the caching process 12 for storage in memory 120.

[0124] In step S607, the cache process 12 updates the local state based on the pre-execution read-write set of multiple transactions.

[0125] After receiving the pre-execution read / write sets and pre-execution order of multiple transactions, in the case of only one pre-execution process in the master node, since the pre-execution process receives the variable value from the storage process for transaction pre-execution when it first reads a variable, and pre-executes multiple transactions serially, updating the local state set of the pre-execution process as each transaction is pre-executed, and then updating the state set in memory 120 using the pre-execution read / write sets of multiple transactions, setting the transaction arrangement order in the execution phase to be the same as the pre-execution order will make the pre-execution read / write sets of each transaction consistent with the execution read / write sets. Therefore, the state set in memory 113 updated based on the pre-execution read / write sets is also the latest world state in master node 1. The cache process 12 can trust the pre-execution read / write sets of multiple transactions and can directly update the state set in memory 120 based on these pre-execution read / write sets. After the update, the state set in memory 120 also becomes the latest world state in master node 1.

[0126] There are multiple pre-execution processes in the master node (e.g.) Figure 2 In the case of pre-execution processes 111 and 112, the two pre-execution processes may simultaneously perform read or write operations on the same variable during the parallel pre-execution of transactions. This may result in the pre-execution result of one of the transactions not being based on the latest world state in master node 1, thus causing inconsistency between the pre-execution read / write set and the execution read / write set of the transaction.

[0127] Therefore, after receiving pre-execution read / write sets for multiple transactions from pre-execution process 111, caching process 12 can sequentially check the pre-execution read / write set for each transaction. Specifically, for example, for transaction Tx3, caching process 12 first determines whether the state set in memory 120 includes variable 'a' from the pre-execution read set of transaction Tx3. If not, it similarly determines whether the second state set includes other variables from the pre-execution read set of transaction Tx3. If the state set in memory 120 does not include all variables from the pre-execution read set of transaction Tx3, that is, the transaction previously submitted to caching process 12 has not yet read or written the variables read by transaction Tx3, then it can be determined that the pre-execution read set of transaction Tx3 does not conflict with the state set in memory 120.

[0128] If caching process 12 determines that the state set in memory 120 includes the value of variable 'a', it then determines whether the value of variable 'a' in the pre-execution read set is consistent with the value of variable 'a' in the state set in memory 120. If they are consistent, it means that the value of variable 'a' read by transaction Tx3 is the latest state of variable 'a' during the pre-execution process. Once caching process 12 has determined that the read value for each variable in the pre-execution read set of transaction Tx3 is the latest state during the pre-execution process, it can be determined that there is no conflict between the pre-execution read set of transaction Tx3 and the state set in memory 120. In cases where it is sequentially determined that there is no conflict between the pre-execution read sets of multiple transactions and the state sets in memory 120, the state set in memory 120 can be updated based on the pre-execution read / write sets of these multiple transactions.

[0129] If the caching process 12 determines that the value of variable 'a' in the pre-execution read set of transaction Tx3 is inconsistent with the value of variable 'a' in the state set in memory 120, it indicates that the value of variable 'a' read by transaction Tx3 is not the latest state in the pre-execution process. Therefore, it can be determined that there is a conflict between the pre-execution read set of transaction Tx3 and the second state set. In the case of a conflict, the caching process 12 can instruct the pre-execution process 111 to re-pre-execute transaction Tx3 and other transactions pre-executed after transaction Tx3.

[0130] In addition, after receiving the pre-execution read-write set and pre-execution order of multiple transactions, the caching process 12 can store the pre-execution read-write set of the multiple transactions in memory 120, and store the identifiers of the multiple transactions in the transaction queue according to the pre-execution order of the multiple transactions to indicate the pre-execution order of the multiple transactions.

[0131] In step S609, the caching process 12 sends the pre-execution read / write set and pre-execution order of multiple transactions to the consensus process 13.

[0132] Consensus process 13 periodically calls the interface provided by caching process 12 to request a batch of transactions to be agreed upon for consensus. In response to this request, caching process 12 sends a pre-execution read / write set of multiple transactions and their order to consensus process 13; this order is the pre-execution order of the transactions. Caching process 12 can send the pre-execution read / write set of each transaction in association with its hash value. Caching process 12 can also send the pre-execution read / write set of multiple transactions and their pre-execution order to consensus process 12 when the pre-execution read / write set of transactions stored in memory 120 reaches a certain data volume or a certain number of transactions stored in memory 120.

[0133] In step S611, consensus process 13 generates a consensus proposal and conducts consensus with other nodes.

[0134] In different types of blockchain networks, consensus algorithms, or consensus mechanisms, are typically used to ensure consistency of the ledger across all nodes recording it. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) obtains a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), guaranteeing 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). In most consensus algorithms, consensus is considered successful only after a predetermined number of nodes reach agreement on the data to be agreed upon (i.e., the consensus proposal). 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.

[0135] Specifically, consensus process 13 can generate a consensus proposal, which includes a pre-execution read-write set of multiple transactions and their pre-execution order, wherein each transaction in the consensus proposal can be identified by the hash value of the transaction.

[0136] In step S613, consensus process 13 sends the consensus proposal to block management process 14.

[0137] After generating a consensus proposal, consensus process 13 can send the consensus proposal to block management process 14.

[0138] In step S615, the block management process 14 generates and submits a block.

[0139] Since the master node trusts that its pre-execution is not malicious, and the pre-execution of transactions in the master node is based on the correct world state, if the master node re-executes the multiple transactions based on the world state in the state database, the resulting executed read-write set of the multiple transactions will necessarily be consistent with the pre-executed read-write set of the multiple transactions. Therefore, the block management process 14 can directly regard the pre-executed read-write set of the multiple transactions as the executed read-write set to update the world state in the state database, without needing to re-execute the multiple transactions.

[0140] Therefore, the block management process 14 can update the state of each account and each contract variable in the world state according to the write set and pre-execution order of the pre-execution read-write set of multiple transactions in the consensus proposal, and update the values ​​of each node in the state tree according to the updated world state, including the state root (i.e., the hash value of the root node of the state tree). The block management process 14 can also obtain the transaction body and transaction receipt of each of the multiple transactions from the caching process 13, and generate the transaction root (i.e., the hash value of the root node of the transaction tree) and the receipt root (i.e., the hash value of the root node of the receipt tree) of the transaction tree of the multiple transactions respectively.

[0141] Then, the block management process 14 can generate a block (e.g., block B1) including the multiple transactions. Block B1 may include a block body and a block header. The block header may include information such as the block number, transaction root, state root, and receipt root. The block body may include a set of transaction bodies and a set of receipts for each transaction. After generating the block, the block management process 14 can commit the block for storage. Figure 2 The block database of master node 1. For example, block management process 14 can send the block to storage process so that storage process stores the block in the block database.

[0142] Since the master node trusts its own pre-executed read / write set, the block management process 14 can immediately update the world state and generate and commit blocks after receiving a consensus proposal from the consensus process 13. It can be understood that the block management process 14 can also update the world state and generate and commit blocks after receiving a consensus success message from the consensus process 13.

[0143] Figure 7 This is a flowchart illustrating a method for executing transactions in a blockchain, as described in the embodiments of this specification. This method can be... Figure 2 Execute from node 2 in the middle.

[0144] like Figure 7 As shown, firstly, in step S701, consensus process 22 in node 2 reaches consensus with other nodes in the blockchain.

[0145] Similar to master node 1, slave node 2 can also include a receiving process and a network process. Figure 2 (Not shown in the diagram) Slave node 2 can receive transactions from user devices through the receiving process and receive transactions sent by other nodes through the network process. After receiving a transaction, the receiving process and the network process send the transaction to the caching process 21, so that the caching process 21 can store the received transactions in memory 210 in the form of a transaction queue. Similar to master node 1, the caching process 21 can also send the transactions in the transaction queue to the network process for broadcasting to other nodes in the blockchain.

[0146] The network process in master node 1 sends the consensus proposal and master node 1's signature to the network processes of other nodes. The network process in node 2 then receives the consensus proposal and master node 1's signature and sends them to consensus process 22. Upon receiving the consensus proposal and its signature, consensus process 22 begins the consensus process.

[0147] In step S703, consensus process 22 sends the consensus proposal to block management process 23.

[0148] After receiving the consensus proposal, consensus process 22 can send the consensus proposal to block management process 23 after the signature verification of the master node is passed.

[0149] In step S705, the block management process 23 groups multiple transactions according to the consensus proposal and assigns the multiple groups to multiple computing processes.

[0150] Block management process 23 can group the multiple transactions according to the pre-execution read / write set in the consensus proposal, ensuring that all transactions in any two groups do not access the same variables, thus allowing the groups to be executed in parallel. The transactions within each group are arranged according to their pre-execution order. After grouping, block management process 23 can evenly distribute the resulting groups among multiple computation processes. For example, in the case where slave node 2 only includes computation processes 241 and 242, half of the groups can be allocated to computation process 241, and the other half to computation process 242.

[0151] It is understood that the embodiments in this specification are not limited to the block management process 23 grouping multiple transactions. For example, the consensus process 22 may group multiple transactions according to the pre-execution read-write set of multiple transactions and send the consensus proposal and grouping results to the block management process 23.

[0152] In step S707, the block management process 23 sends the groups allocated to each process and the pre-execution read / write sets of each transaction within the group to each process.

[0153] In step S709, the computation process executes the transaction and updates the state database.

[0154] Taking computation process 241 as an example, block management process 23 can allocate one or more groups to computation process 241. When block management process 23 allocates multiple groups to computation process 241, computation process 241 can process multiple groups concurrently through multiple threads. Simultaneously, computation process 241 executes multiple transactions in a group sequentially according to the pre-execution order of multiple transactions in a group. When executing each transaction, computation process 241 can... Figure 3 The method shown executes each transaction, and will not be described in detail here.

[0155] In addition, such as Figure 2 As shown, computation process 241 includes memory 243. Before starting to execute transactions in multiple groups, computation process 241 can determine all variables that need to be read based on the read sets of all transactions in the multiple groups, and read all variables in batches (e.g., all at once) from the state database. After reading the state (i.e., world state) of all variables, process 241 can store the values ​​of all variables in the state set in memory 243 as key-value pairs. Then, computation process 241 can execute transactions in each group based on the state set in memory 243. When performing a read operation based on a transaction, computation process 241 reads the value of the variable from the state set in memory 243. When performing a write operation based on a transaction, it updates the value of the variable in the state set in memory 243 to the value written, and generates an execution read-write set for the transaction accordingly. Similar to the pre-execution read-write set, the execution read-write set includes an execution read set and an execution write set. The execution read set includes, for example, key-value pairs of variables read during transaction execution, and the execution write set includes, for example, key-value pairs of variables written during transaction execution. By using batch pre-reading, the computing process 241 pre-stores the parameters that need to be read from the state database into the local memory 243. As a result, the computing process 241 can directly read the state from the memory during the execution of the transaction, without having to read the state from the storage, which greatly speeds up the transaction execution.

[0156] Since the groups do not access the same variables, i.e., there are no conflicting transactions, the computation process 241 can immediately update the world state in the state database based on the execution write set of each transaction in a group after completing the execution of all transactions in that group, without affecting the transaction execution of other groups. This also improves the transaction execution speed.

[0157] In step S711, the block management process 23 generates and submits a block.

[0158] After determining that each computation process has completed the execution of transactions and state updates for its assigned group, the block management process 23 updates the values ​​of each node in the state tree, including the state root (i.e., the hash value of the root node of the state tree), based on the updated world state. The block management process 23 can also retrieve the transaction bodies and transaction receipts of multiple transactions from the cache process 21, and generate the transaction roots (i.e., the hash values ​​of the root nodes of the transaction trees) and receipt roots (i.e., the hash values ​​of the root nodes of the receipt trees) of the transaction trees for the multiple transactions, respectively.

[0159] Then, the block management process 23 can generate a block (e.g., block B1) including the multiple transactions. Block B1 may include a block body and a block header. The block header may include information such as the block number, transaction root, state root, and receipt root. The block body may include a set of transaction bodies and a set of receipts for each transaction. After generating the block, the block management process 23 can commit the block for storage. Figure 2 The block database of node 2.

[0160] Through the above process, while achieving storage consistency among all nodes in the blockchain, the multi-process architecture of the blockchain nodes can be used to further accelerate the execution speed of transactions and improve the system efficiency of the blockchain.

[0161] Figure 8 This specification provides a structural diagram of a first node in a blockchain according to one embodiment, comprising:

[0162] The creation unit 81 is used to create a first state set and a second state set corresponding to the transaction when executing the transaction;

[0163] The first storage unit 82 is used to read the first state of the first variable before writing to the first variable according to the transaction pair. The first state is the current state of the first variable, and the first state of the first variable is stored in the first state set.

[0164] The second storage unit 83 is used to store the second state of the first variable in the second state set, wherein the second state is the state of the first variable written according to the transaction;

[0165] The generation unit 84 is configured to generate a write set of the transaction based at least on the first state set when it is determined that the write operation of the transaction to the first variable needs to be rolled back.

[0166] Figure 9 This specification provides a structural diagram of a second node in a blockchain according to one embodiment, comprising:

[0167] Receiving unit 91 is used to receive a pre-execution read / write set and a pre-execution order of multiple transactions from the first node in the blockchain;

[0168] Grouping unit 92 is used to group the multiple transactions according to the pre-execution read / write set and the pre-execution order to obtain multiple transaction groups;

[0169] The first generation unit 93 is used to generate an execution read set for each transaction in the transaction group and create a third state set and a fourth state set corresponding to the transaction when executing the transactions of the multiple transaction groups in parallel.

[0170] The first storage unit 94 is used to read the third state of the first variable before writing to the first variable according to the transaction pair, the third state being the current state of the first variable, and to store the third state of the first variable in the third state set.

[0171] The second storage unit 95 is used to store the fourth state of the first variable in the fourth state set, wherein the fourth state is the state of the first variable written according to the transaction.

[0172] The second generation unit 96 is used to generate the execution write set of the transaction at least according to the third state set when it is determined that the write operation of the transaction to the first variable needs to be rolled back.

[0173] The comparison unit 97 is used to compare whether the execution read-write set of the plurality of transactions is consistent with the pre-execution read-write set of the plurality of transactions, so as to determine whether the execution read-write set of the plurality of transactions is correct. The execution read-write set includes the execution read set and the execution write set.

[0174] 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 also 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 also 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.

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

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

[0177] 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 said 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.

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

[0179] 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 illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

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

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

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

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

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

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

[0188] 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 method for executing a transaction in a blockchain, the method being executed by a first node in the blockchain, the method comprising: When a transaction is pre-executed, a pre-execution read set for the transaction is generated, and a first state set and a second state set corresponding to the transaction are created. Before writing to the first variable according to the transaction pair, read the first state of the first variable, which is the current state of the first variable, and store the first state in the first state set; The second state of the first variable is stored in the second state set, where the second state is the state of the first variable written according to the transaction. When it is determined that the write operation of the transaction to the first variable needs to be rolled back, at least based on the first state set and the current world state, a pre-execution write set of the transaction is generated. After pre-executing multiple transactions, a consensus proposal is generated, which includes a pre-execution read set, a pre-execution write set, and a pre-execution order of the multiple transactions.

2. The method according to claim 1, wherein the blockchain further comprises a second node, and the method further comprises: The consensus proposal is sent to the second node.

3. The method according to claim 1 or 2, wherein, The first variable is a contract variable, and the first state set and the second state set are contract variable state sets.

4. The method according to claim 1 or 2, wherein, The transaction invokes a first contract, which in turn invokes a second contract. The second contract includes write operations on the first variable, and the first state set corresponds to the second contract. The step of generating a pre-execution write set for the transaction based on the first state set when it is determined that the write operation on the first variable of the transaction needs to be rolled back includes: generating a pre-execution write set for the transaction based on the first state set and the second state set when it is determined that the pre-execution of the second contract has failed and needs to be rolled back.

5. The method according to claim 2, wherein, The plurality of transactions only include read operations on the second variable and do not include write operations on the second variable. The method further includes: after pre-executing the plurality of transactions to obtain a pre-execution read-write set of the plurality of transactions, deleting the key-value pairs of the first variable in the pre-execution read set of the plurality of transactions.

6. The method according to claim 2, wherein, The plurality of transactions includes a plurality of first transactions, wherein the first transactions are used to transfer a preset amount to a first account in the blockchain, wherein the amount is a positive amount, and the method further includes deleting the key-value pairs of the first account from the pre-execution read-write set of the plurality of first transactions.

7. A first node in a blockchain, comprising: A creation unit is used to generate a pre-execution read set of the transaction and create a first state set and a second state set corresponding to the transaction when the transaction is to be executed. The first storage unit is used to read the first state of the first variable before writing to the first variable according to the transaction pair. The first state is the current state of the first variable, and the first state is stored in the first state set. The second storage unit is used to store the second state of the first variable in the second state set, wherein the second state is the state of the first variable written according to the transaction. The first generation unit is used to generate a pre-execution write set for the transaction, based at least on the first state set and the current world state, when it is determined that the write operation of the transaction to the first variable needs to be rolled back. The second generation unit is used to generate a consensus proposal after pre-executing multiple transactions. The consensus proposal includes a pre-execution read set, a pre-execution write set, and a pre-execution order of the multiple transactions.

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

Images