Methods and blockchain nodes for executing transactions

Abstract

A method for executing transactions in a blockchain and a blockchain node, the method being executed by the first node, comprising: a cache process sending a plurality of received transactions to a first pre-execution process; the first pre-execution process pre-executes the plurality of transactions, obtains pre-execution read-write sets of the plurality of transactions and a pre-execution order of the plurality of transactions, and sends the pre-execution read-write sets and the pre-execution order of the plurality of transactions to the cache process; the cache process sends the pre-execution read-write sets of the plurality of transactions and the pre-execution order of the plurality of transactions to the first consensus process, and updates the world state data currently stored in the memory of the cache process based on the pre-execution read-write sets of the plurality of transactions; the first consensus process generates a consensus proposal, and sends the consensus proposal to a second node.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly to a method for executing transactions in a blockchain and a blockchain node. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time sequence, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. Summary of the invention

[0003] The purpose of the present invention is to provide a method for executing transactions in a blockchain, which speeds up the execution of transactions and improves the system efficiency of the blockchain by using multiple processes to provide various services in the blockchain respectively.

[0004] In a first aspect, the present specification provides a method for executing a transaction in a blockchain, wherein the blockchain includes a first node and a second node, wherein a first pre-execution process, a cache process, and a first consensus process are running in the first node, and the method is executed by the first node, including:

[0005] The cache process sends the received multiple transactions to the first pre-execution process, and the memory of the cache process stores the latest world state of at least part of the variables in the blockchain;

[0006] The first pre-execution process pre-executes the multiple transactions, obtains pre-execution read-write sets of the multiple transactions and pre-execution orders of the multiple transactions, and sends the pre-execution read-write sets and pre-execution orders of the multiple transactions to the cache process, wherein the first pre-execution process receives the state of the variable requested to be read in the first transaction from the cache process when pre-executing the first transaction among the multiple transactions;

[0007] The cache process sends the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions to the first consensus process, and updates the world state data currently stored in the memory of the cache process based on the pre-execution read-write sets of the multiple transactions;

[0008] The first consensus process generates a consensus proposal and sends the consensus proposal to a second node in the blockchain, wherein the consensus proposal includes pre-execution read-write sets of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order.

[0009] A second aspect of the present specification provides a method for executing a transaction in a blockchain, wherein the blockchain includes a first node and a second node, wherein a second consensus process, a second block management process, and N computing processes are running in the second node, and the method is executed by the second node, including:

[0010] The second consensus process receives a consensus proposal from the first node, and sends the consensus proposal to the second block management process, wherein the consensus proposal includes pre-execution read-write sets of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to a pre-execution order of the multiple transactions;

[0011] The second block management process divides the multiple transactions into multiple transaction groups according to the pre-execution read-write set, allocates the multiple transaction groups to the N computing processes, and sends the arrangement order of the multiple transactions to the N computing processes;

[0012] The N computing processes respectively execute the transactions in the transaction groups assigned to them according to the arrangement order.

[0013] A third aspect of the present specification provides a first node in a blockchain, wherein a first pre-execution process, a cache process, and a first consensus process are run in the first node.

[0014] The cache process is used to send the received multiple transactions to the first pre-execution process, and the latest world state of at least part of the variables in the blockchain is stored in the memory of the cache process;

[0015] The first pre-execution process is used to pre-execute the multiple transactions, obtain pre-execution read-write sets of the multiple transactions and pre-execution orders of the multiple transactions, and send the pre-execution read-write sets and pre-execution orders of the multiple transactions to the cache process, wherein the first pre-execution process is further used to receive the state of the variable requested to be read in the first transaction from the cache process when pre-executing the first transaction among the multiple transactions;

[0016] The cache process is used to send the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions to the first consensus process, and update the world state data currently stored in the memory of the cache process based on the pre-execution read-write sets of the multiple transactions;

[0017] The first consensus process is used to generate a consensus proposal and send the consensus proposal to a second node in the blockchain, wherein the consensus proposal includes a pre-execution read-write set of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order.

[0018] A fourth aspect of the present specification provides a second node in a blockchain, wherein a second consensus process, a second block management process, and N computing processes are running in the second node.

[0019] The second consensus process is used to receive a consensus proposal from the first node and send the consensus proposal to the second block management process, wherein the consensus proposal includes the pre-execution read-write sets of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order of the multiple transactions;

[0020] The second block management process is used to divide the multiple transactions into multiple transaction groups according to the pre-execution read-write set, assign the multiple transaction groups to the N computing processes, and send the arrangement order of the multiple transactions to the N computing processes;

[0021] The N computing processes are used to respectively execute the transactions in the transaction groups assigned to them according to the arrangement order.

[0022] A fifth aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in the first aspect or the second aspect.

[0023] A sixth aspect of the specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect or the second aspect is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0025] Figure 1 A diagram showing the blockchain architecture used in the embodiments of this specification;

[0026] Figure 2 This is an architectural diagram of a blockchain node in an embodiment of this specification;

[0027] Figure 3 A flow chart of a method for executing a transaction in a blockchain in an embodiment of this specification;

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

[0029] Figure 5This is a flow chart of a method for executing transactions in a blockchain in an embodiment of this specification. DETAILED DESCRIPTION

[0030] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0031] Figure 1 The following is a diagram showing the blockchain architecture used in the embodiments of this specification. Figure 1 In the example, the blockchain includes 6 nodes, namely, master node 1, slave nodes 2 to 5. The lines between the nodes schematically represent P2P (Peer to Peer) connections. All these nodes store the full amount of ledgers, that is, the status of all blocks and all accounts. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database. The difference is that the master node 1 can be responsible for receiving transactions from the client and initiating a consensus proposal to each slave node. The consensus proposal includes, for example, multiple transactions in the block to be formed (such as block B1) and the order of arrangement of the multiple transactions. After the nodes in the blockchain successfully reach a consensus on the consensus proposal, each node can execute the multiple transactions according to the order of arrangement in the consensus proposal, thereby generating block B1.

[0032] Understandably, Figure 1 The blockchain shown is only exemplary and the embodiments of this specification are not limited to application to Figure 1 The blockchain shown can also be applied to a blockchain system without a master-slave structure, for example.

[0033] in addition, Figure 1 Although it is shown that the blockchain includes 6 nodes, the embodiments of this specification are not limited to this, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirements. The Byzantine Fault Tolerance requirement can be understood as Byzantine nodes can exist inside the blockchain, but the blockchain does not reflect Byzantine behavior to the outside. In general, some Byzantine fault tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the practical Byzantine fault tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

[0034] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case where the transaction is a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case where the transaction calls a smart contract in the blockchain, the From field indicates the account address that initiates the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes the function name in the calling contract, and the incoming parameters of the function, etc., which are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

[0035] The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts 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 is to initiate a transaction pointing to the smart contract address, so that each node in the blockchain runs the smart contract code in a distributed manner. It should be noted that in addition to being able to create smart contracts by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some blockchain data structures, parameters, attributes and methods can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts). Among them, the system contract can be used to add data structures of data for different businesses in the blockchain.

[0036] In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e. deploying a contract) to Figure 1 In the blockchain shown, the data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), and the to field of the transaction is empty to indicate that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined, and each node adds a contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and saves the contract code in the state storage of the contract, so that the contract is successfully created.

[0037] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1In the blockchain shown, the from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the "0x6f8ae93..." in the to field represents the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is reached in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.

[0038] In the related art, in order to improve the transactions per second (TPS) indicator in the blockchain, it is necessary to speed up the execution of transactions. To this end, the execution speed of transactions can be accelerated by executing transactions in parallel in the blockchain node. Usually, for transfer transactions, the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions. The transaction groups do not access the same accounts, so that the transaction groups can be executed in parallel. However, when a smart contract is called in a transaction, the variables accessed in the transaction cannot be predicted before the transaction is executed, so that multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel. In one embodiment, the first node in the blockchain (for example Figure 1 The master node 1 in the blockchain pre-executes multiple transactions, obtains the pre-execution read-write set of each transaction, and sends the pre-execution read-write set to other nodes in the blockchain (such as Figure 1 Other nodes in the blockchain can group multiple transactions according to the pre-execution read-write sets of multiple transactions, so that the multiple transactions can be executed in parallel according to the grouping results.

[0039] However, in the current blockchain, the above process is usually performed in a node through a single process, including processing of client requests, consensus network communication, transaction execution, data storage, etc. With the continuous development of blockchain business, blockchain nodes running a single process are limited by physical resources, network resources and other resources, resulting in scalability, extensibility and throughput that cannot meet business needs.

[0040] The embodiments of this specification provide a solution for executing transactions in a blockchain, whereby multiple processes respectively provide pre-execution services, cache services, consensus services, block management services and other services in blockchain nodes, thereby making the blockchain nodes have high scalability and high throughput.

[0041] Figure 2 This is a diagram of the architecture of the blockchain node in the embodiment of this specification. Figure 2 As shown, Figure 1 The master node 1 and each slave node (e.g. Figure 2Multiple processes can be run in the slave node 2) shown in the figure to provide multiple services. Specifically, the master node 1 may include a cache process 12 for providing cache services, a pre-execution process 111 and a pre-execution process 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. The pre-execution process 111 and the pre-execution process 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 the present specification, the master node 1 is not limited to including two pre-execution processes, but may include one pre-execution process or more than three 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 FIG.

[0042] The slave node 2 may include a cache process 21 for providing a cache service, a consensus process 22 for providing a consensus service, a block management process 23 for providing a block management service, and a computing process 241 and a computing process 242 for providing a transaction execution service. The computing process 241 and the computing process 242 are used to execute the transactions in the consensus proposal in parallel. It can be understood that in the embodiments of this specification, the slave node 2 is not limited to including two computing processes, but may include one computing process or more than three computing processes.

[0043] A process is a running activity of a program with certain independent functions in an application on a data set, that is, a process is a process in a computer by sequentially executing instructions in an application by the CPU. Each process is allocated its own memory address space when it is created, and the 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, computing process 241 is allocated memory 243, and computing process 242 is allocated memory 244.

[0044] Among them, the multiple processes in the 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. In addition, it should be noted that the solution provided in the embodiment of this specification is not limited to the blockchain system of the master-slave architecture.

[0045] Figure 3 is a flow chart of a method for executing a transaction in a blockchain in an embodiment of this specification. The method may be Figure 2 Execute on master node 1 in .

[0046] like Figure 3 As shown, first, in step S301 , the cache process 12 in the master node 1 sends multiple transactions to the pre-execution process 111 .

[0047] As shown above, the master node 1 includes Figure 2 In addition to the various processes shown in , an access process may also be included, which may receive transactions from a user device and send the received transactions to the cache process 12, so that the cache process 12 stores the transactions received from the access process in a certain order in the memory 120 of the cache process 12. For example, the cache process 12 may store the transactions in the order in which the transactions are received, such as storing the received transactions in order in a transaction queue stored in the memory 120.

[0048] The master node 1 may also include a network process ( Figure 2 (not shown), after receiving multiple transactions, the cache process 12 may send the multiple transactions to the network process, so that the network process broadcasts the multiple transactions to other nodes in the blockchain.

[0049] At the same time, for each pre-execution process (including pre-execution process 111 and pre-execution process 112), cache process 12 can periodically send a batch of transactions of a preset number in the transaction queue to the pre-execution process, so that each pre-execution can execute the transactions in the transaction queue in parallel. Among them, cache process 12 can also send the arrangement order of the batch of transactions in the transaction queue to the pre-execution process, so that the pre-execution process can execute the batch of transactions serially according to the arrangement order in the transaction queue.

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

[0051] After receiving multiple transactions from the cache process 12, the pre-execution process 111 may first verify the signature of each transaction, and after the verification is passed, pre-execute the multiple transactions. The pre-execution process 111 executes the received multiple transactions in series, for example, the pre-execution process 111 may execute the multiple transactions in series according to the order in which the received multiple transactions are arranged.

[0052] In an embodiment of the present specification, the memory 113 may store a first state set of the first part of the variables in the blockchain, and the first part of the variables includes variables defined in the blockchain account or contract. When the pre-execution process 111 reads or writes variables during the pre-execution of the transaction, the first state set of the local cache may be updated. After pre-executing multiple transactions, the pre-execution process obtains the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions. The pre-execution read-write set of the transaction, for example, includes a pre-execution read set and a pre-execution write set, the pre-execution read set includes the key-value pairs of the variables read by the transaction in the pre-execution, and the pre-execution write set includes the key-value pairs of the variables written by the transaction in the pre-execution. The variables include, for example, external accounts in the blockchain, or variables defined in the contract account. In one embodiment, the key, value, and value version number of each variable are stored in the state database, the first state set, and the second state set. Thus, the pre-execution read set of the transaction may include the key and version number of the read variable, and the pre-execution write set of the transaction may include the key, value, and value version number of the written variable. The pre-execution process 111 increases the version number of the variable value by 1 each time the value of the variable is written.

[0053] The memory 120 of the cache process 12 stores a second state set of the second part of the variables in the blockchain. The update of the second state set can refer to Figure 3 When each pre-execution process reads a variable during the pre-execution transaction, it first determines whether the first state set includes the value of the variable. If not, it then determines whether the second state set includes the value of the variable. If not, it reads the value of the variable from the state database and stores the read value of the variable in the first state set.

[0054] Specifically, the multiple transactions include, for example, transaction Tx1. Assuming that transaction Tx1 includes a read operation on variable a and a write operation on variable b, when the pre-execution process 111 executes the read operation on variable a in transaction Tx1, it first determines whether the value of variable a is stored in the memory 113 of the pre-execution process 111. In the case where the value of variable a is stored in the memory 113, the pre-execution of transaction Tx1 can be completed based on the value of variable a, and a pre-execution read-write set of transaction Tx1 is generated. For example, the pre-execution read set of transaction Tx1 includes a key-value pair of variable a, and the pre-execution write set includes a key-value pair of variable b. In generating the pre-execution read-write set of transaction Tx1, the pre-execution process 111 updates the first state set in the memory 113 based on the write set of transaction Tx1, and stores the value of variable b written by transaction Tx1 in the pre-execution in the first state set.

[0055] In another case, when the pre-execution process 111 determines that the value of variable a is not included in the first state set in the memory 113, it may request the cache process 12 to read the value of variable a. After receiving the request, the cache process 12 determines whether the value of variable a is included in the second state set in the memory 120. If it is included, the value of variable a is sent to the pre-execution process 111. After receiving the value of variable a, the pre-execution process 111 may store the value of variable a in the first state set, so that it can be used to execute other subsequent transactions for reading variable a. If the value of variable a is not included in the second state set, the cache process 12 notifies the pre-execution process 111, and the pre-execution process 111 reads the current value of variable a from the state database, wherein the state database stores the world state corresponding to the executed block. The master node 1, for example, also includes a storage process, and the pre-execution process 11 may, for example, send a request to read variable a to the storage process. After receiving the request, the storage process reads the value of variable a in 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 in the first state set. The pre-execution process 111 stores the value of variable a read from the outside of the memory 113 in the memory 113, so that the pre-execution process 111 can directly read the value of variable a from the local memory when reading variable a in the next transaction execution, thereby improving the transaction execution speed.

[0056] After executing each transaction, the pre-execution process 111 also generates a transaction receipt for each transaction.

[0057] In step S305 , the pre-execution process 111 sends the pre-execution read-write sets and pre-execution order of the multiple transactions to the cache process 12 .

[0058] After completing the pre-execution of multiple transactions as described above, the pre-execution process 111 sends the obtained pre-execution read-write sets and pre-execution orders of the multiple transactions to the cache process 12. In addition, the pre-execution process 111 also sends the transaction receipts of each transaction to the cache process 12 for storage in the memory 120.

[0059] In step S307 , the cache process 12 updates the local state based on the pre-execution read-write sets of the multiple transactions.

[0060] After receiving the pre-execution read-write sets and pre-execution order of multiple transactions, when there is only one pre-execution process in the master node, the pre-execution process receives the variable value from the storage process to pre-execute the transaction when reading a variable for the first time, and pre-executes multiple transactions in series, and updates the first state set of the local pre-execution process with the pre-execution of each transaction, and then updates the second state set through the pre-execution read-write sets of multiple transactions. Therefore, when the transaction arrangement order of the execution phase is set to be the same as the pre-execution order, the pre-execution read-write set of each transaction will be consistent with the execution read-write set. Therefore, the first state set updated based on the pre-execution read-write set is also the latest world state in the master node 1. The cache process 12 can trust the pre-execution read-write sets of the multiple transactions, and can directly update the local second state set based on the pre-execution read-write set. After the update, the second state set also becomes the latest world state in the master node 1.

[0061] There are multiple pre-execution processes in the master node (such as Figure 2 In the case of pre-execution process 111 and pre-execution process 112 in the process of parallel pre-execution of transactions, the two pre-execution processes may read or write the same variable at the same time, which may cause the pre-execution result of one of the transactions to be not based on the current latest world state in master node 1, resulting in inconsistency between the pre-execution read-write set of the transaction and the execution read-write set of the transaction.

[0062] To this end, after receiving the pre-execution read-write sets of multiple transactions from the pre-execution process 111, the cache process 12 can sequentially detect the pre-execution read-write set of each transaction. Specifically, for example, for transaction Tx1, the cache process 12 first determines whether the second state set includes variable a in the pre-execution read set of transaction Tx1. If not, it is similarly determined whether the second state set includes other variables in the pre-execution read set of transaction Tx1. If the second state set does not include all the variables in the pre-execution read set of transaction Tx1, that is, the transaction previously submitted to the cache process 12 has not read and written the variables read by the transaction Tx1, then it can be determined that the pre-execution read set of transaction Tx1 does not conflict with the second state set.

[0063] If the cache process 12 determines that the second state set includes the value of variable a, it determines whether the value of variable a in the pre-execution read set is consistent with the value of variable a in the second state set. If they are consistent, it means that the value of variable a read by the transaction Tx1 is the latest state of variable a during the pre-execution process. After the master node 1 determines that the read value of each variable in the pre-execution read set of the transaction Tx1 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 the transaction Tx1 and the second state set. In the case where it is sequentially determined that there is no conflict between the pre-execution read sets of multiple transactions and the second state set, the second state set can be updated based on the pre-execution read-write sets of the multiple transactions.

[0064] If the cache process 12 determines that the value of variable a in the pre-execution read set of transaction Tx1 is inconsistent with the value of variable a in the second state set, it means that the value of variable a read by transaction Tx1 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 Tx1 and the second state set. In the case of determining that there is a conflict, the cache process 12 can instruct the pre-execution process 111 to re-pre-execute transaction Tx1 and other transactions pre-executed after transaction Tx1.

[0065] In addition, after receiving the pre-execution read-write sets and pre-execution order of multiple transactions, the cache process 12 can store the pre-execution read-write sets of the multiple transactions in the 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.

[0066] In step S309 , the cache process 12 sends the pre-execution read-write sets and pre-execution order of multiple transactions to the consensus process 13 .

[0067] The consensus process 13 periodically calls the interface provided by the cache process 12 to request the cache process 12 to obtain a batch of transactions to be agreed upon for consensus. In response to the request, the cache process 12 sends the pre-execution read-write sets of multiple transactions and the arrangement order of the multiple transactions to the consensus process 13, and the arrangement order is the pre-execution order of the multiple transactions. Among them, the cache process 12 can send the pre-execution read-write sets of each transaction in association with the hash value of each transaction. The cache process 12 can also send the pre-execution read-write sets of multiple transactions and their pre-execution order to the consensus process when the pre-execution read-write sets of transactions stored in the memory 120 reach a certain amount of data, or when the pre-execution read-write sets of transactions stored in the memory 120 reach a certain number.

[0068] In step S311, the consensus process 13 generates a consensus proposal and reaches consensus with other nodes.

[0069] In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, a consensus mechanism. For example, a consensus mechanism of block granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a consensus mechanism of transaction granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, each node that recognizes the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and ultimately ensure that each node generates the same latest block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the entire network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among them, in various consensus algorithms, usually after a preset number of nodes reach an agreement on the consensus data (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful. Specifically, in the PBFT algorithm, for N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f+1 nodes out of N consensus nodes reach an agreement, the consensus can be determined to be successful.

[0070] Figure 4 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 4 As shown in Figure 1, according to the PBFT consensus algorithm, the consensus process can be divided into four stages: Request, Pre-Prepare, Prepare, and Commit. Figure 1 The blockchain shown, according to the PBFT algorithm, can tolerate f = 1 malicious nodes in the master node 1, slave nodes 2-slave nodes 6, so the consensus can only be determined to be successful when 5 of the 6 nodes reach an agreement. Specifically, in the request phase, the user of the blockchain can send a transaction to the master node 1 through its user device as described above. In the preparatory phase, the master node 1 generates a consensus proposal. Specifically, in the embodiment of this specification, the consensus proposal may include information such as the pre-execution read-write sets of multiple transactions received from the cache process 12 and the pre-execution order of the multiple transactions, wherein each transaction in the consensus proposal can be identified by a transaction hash value.

[0071] The consensus process 13 can send the consensus proposal generated above and the signature of the consensus proposal by the master node 1 to other consensus nodes (i.e., slave nodes 2-6) for generating blocks. Specifically, the consensus process 13 can send the consensus proposal and signature to the network process, which is sent to other nodes. In addition, as mentioned above, the cache process 12 has broadcast each received transaction to each slave node in the form of a broadcast. In this way, the consensus proposal sent by the master node 1 to each slave node does not include the transaction body of each transaction, which reduces the amount of data in the consensus proposal, thereby reducing the amount of calculation required for each node to digitally sign the consensus node during the consensus process, and improving the consensus efficiency.

[0072] Still refer to Figure 4 In the preparation phase, each slave node can sign the consensus proposal and send it to other nodes. Assuming that slave node 6 is a malicious node, after master node 1 and slave nodes 2-5 receive signatures on the consensus proposal from 2f=2 other consensus nodes, they can determine that the preparation phase is complete and enter the submission phase. For example, Figure 4 As shown in , after receiving the signatures of slave nodes 2-5, master node 1 verifies that the signatures of slave nodes 2-5 are all correct signatures of the consensus proposal, and then determines that the preparation phase is completed. After slave node 2 receives the signatures of slave nodes 3-5 and the signature of master node 1 in the preparation phase and verifies them, it determines that the preparation phase is completed. In the submission phase, each consensus node signs the consensus proposal in the submission phase and sends it to other consensus nodes. After receiving the signatures of 2f=4 other consensus nodes in the submission phase, each consensus node can determine that the submission phase is completed and the consensus is successful. For example, after master node 1 receives and verifies the signatures of slave nodes 2-5 in the submission phase, it determines that the submission phase is completed and the consensus is successful.

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

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

[0075] In step S315 , the block management process 14 generates and submits the block.

[0076] Since the master node trusts that its pre-execution is not malicious, and the pre-execution of transactions in the master node is performed according to the correct world state, if the master node re-executes the multiple transactions based on the world state in the state database, the execution read-write sets of the multiple transactions obtained must be consistent with the pre-execution read-write sets of the multiple transactions. Therefore, the block management process 14 can directly regard the pre-execution read-write sets of the multiple transactions as the execution read-write sets to update the world state in the state database without re-executing the multiple transactions.

[0077] Thus, the block management process 14 can sequentially update the states of each account and each contract variable in the world state according to the write sets and pre-execution order of the pre-execution read-write sets of the 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 bodies and transaction receipts of each of the multiple transactions from the cache process 12, and generate the transaction roots of the transaction trees of the multiple transactions (i.e., the hash values ​​of the root nodes of the transaction trees) and the receipt roots of the receipt trees (i.e., the hash values ​​of the root nodes of the receipt trees).

[0078] Then, the block management process 14 may generate a block (e.g., block B1) including the multiple transactions. The block B1 may include a block body and a block header. The block header may include information such as a block number, a transaction root, a status root, and a receipt root. The block body may include a transaction body set and a receipt set of each transaction. After generating a block, the block management process 14 may submit the block to be stored in Figure 2 For example, the block management process 14 may send the block to the storage process so that the storage process stores the block in the block database.

[0079] Among them, since the master node trusts its own pre-execution read-write set, the block management process 14 can immediately update the world state and generate and submit the block after receiving the 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 submit the block after receiving the consensus success information from the consensus process 13.

[0080] Figure 5 is a flow chart of a method for executing a transaction in a blockchain in an embodiment of this specification. The method may be Figure 2 Execute from node 2 in.

[0081] like Figure 5 As shown, first, in step S501, the consensus process 22 in the slave node 2 reaches consensus with other nodes in the blockchain.

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

[0083] The network process in master node 1 sends the consensus proposal and the signature of master node 1 to the network processes of other nodes, so that the network process in slave node 2 can receive the consensus proposal and the signature of master node 1, and send the consensus proposal and the signature of master node 1 to consensus process 22. After receiving the consensus proposal and its signature, consensus process 22 starts the consensus process. For the specific consensus process, please refer to the reference above. Figure 4 The description will not be repeated here.

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

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

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

[0087] The block management process 23 can group the multiple transactions according to the pre-execution read-write set in the consensus proposal, so that all transactions in each two groups will not access the same variables, so that each group can be executed in parallel, and the multiple transactions in each group are arranged according to their pre-execution order. After completing the grouping, the block management process 23 can evenly distribute the multiple groups obtained by grouping to multiple computing processes. For example, in the case where only computing process 241 and computing process 242 are included in slave node 2, half of the groups in the multiple groups can be distributed to computing process 241, and the other half can be distributed to computing process 242.

[0088] It can be understood that the embodiments of this specification are not limited to the block management process 23 grouping multiple transactions. For example, the consensus process 22 can also group multiple transactions according to the pre-execution read-write sets of multiple transactions, and send the consensus proposal and the grouping result to the block management process 23.

[0089] In step S507, the block management process 23 sends the group assigned to each process and the pre-execution read-write set of each transaction in the group to each process.

[0090] In step S509, the computing process executes the transaction and updates the status database.

[0091] Taking the computing process 241 as an example, the block management process 23 may assign one or more groups to the computing process 241. In the case where the block management process 23 assigns multiple groups to the computing process 241, the computing process 241 may process multiple groups concurrently through multiple threads. At the same time, the computing process 241 serially executes multiple transactions in one group according to the pre-execution order of multiple transactions in one group.

[0092] Specifically, Figure 2 As shown, the computing process 241 includes a memory 243. Before starting to execute transactions of multiple groups, the computing process 241 can determine all variables that need to be read according to the read sets of all transactions in the multiple groups, and read all the variables in batches (for example, at one time) from the state database. After reading the states of all variables (i.e., the world state), the process 241 can store the values ​​of all the variables in the form of key-value pairs in the third state set in the memory 243. Then, the computing process 241 can execute transactions in each group based on the third state set. When the computing process 241 performs an operation of reading variables according to the transaction, the value of the variable is read from the third state set. When the computing process 241 performs an operation of writing variables according to the transaction, the value of the variable in the third state set is updated to the value written this time, and the execution read-write set of the transaction is generated 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, for example, includes the key-value pairs of the variables read during the execution of the transaction, and the execution write set, for example, includes the key-value pairs of the variables written during the execution of the transaction. By means of batch pre-reading, the computing process 241 stores the parameters that need to be read from the state database in the local memory 243 in advance, so that the computing process 241 can directly read the state from the memory during the transaction execution without having to read the state from the storage, which greatly speeds up the transaction execution speed.

[0093] Since each group does not access the same variables, that is, there are no conflicting transactions, after the computing process 241 completes the execution of all transactions in a group, it can immediately update the world state in the state database according to the execution write set of each transaction in the group without affecting the transaction execution of other groups. At the same time, the transaction execution speed is improved.

[0094] In step S511 , the block management process 23 generates and submits a block.

[0095] After determining that each computing process has completed the transaction execution and status update of the group assigned to it, the block management process 23 updates 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 23 can also obtain the transaction bodies and transaction receipts of each of the multiple transactions from the cache process 21, and generate the transaction roots of the transaction trees of the multiple transactions (i.e., the hash values ​​of the root nodes of the transaction trees) and the receipt roots of the receipt trees (i.e., the hash values ​​of the root nodes of the receipt trees).

[0096] Then, the block management process 23 may generate a block (e.g., block B1) including the multiple transactions. The block B1 may include a block body and a block header. The block header may include information such as a block number, a transaction root, a status root, and a receipt root. The block body may include a transaction body set and a receipt set of each transaction. After generating a block, the block management process 23 may submit the block to be stored in Figure 2 The block database of slave node 2.

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

[0098] The embodiment of the present specification also provides a first node in a blockchain, wherein a first pre-execution process, a cache process and a first consensus process are run in the first node for executing Figure 3 The method shown.

[0099] The cache process is used to send the received multiple transactions to the first pre-execution process, and the latest world state of at least part of the variables in the blockchain is stored in the memory of the cache process;

[0100] The first pre-execution process is used to pre-execute the multiple transactions, obtain pre-execution read-write sets of the multiple transactions and pre-execution orders of the multiple transactions, and send the pre-execution read-write sets and pre-execution orders of the multiple transactions to the cache process, wherein the first pre-execution process is further used to receive the state of the variable requested to be read in the first transaction from the cache process when pre-executing the first transaction among the multiple transactions;

[0101] The cache process is used to send the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions to the first consensus process, and update the world state data currently stored in the memory of the cache process based on the pre-execution read-write sets of the multiple transactions;

[0102] The first consensus process is used to generate a consensus proposal and send the consensus proposal to a second node in the blockchain, wherein the consensus proposal includes a pre-execution read-write set of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order.

[0103] The embodiment of this specification also provides a second node in a blockchain, in which a second consensus process, a second block management process and N computing processes are run, for executing Figure 5 The method shown.

[0104] The second consensus process is used to receive a consensus proposal from the first node and send the consensus proposal to the second block management process, wherein the consensus proposal includes the pre-execution read-write sets of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order of the multiple transactions;

[0105] The second block management process is used to divide the multiple transactions into multiple transaction groups according to the pre-execution read-write set, assign the multiple transaction groups to the N computing processes, and send the arrangement order of the multiple transactions to the N computing processes;

[0106] The N computing processes are used to respectively execute the transactions in the transaction groups assigned to them according to the arrangement order.

[0107] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0108] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

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

[0110] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0111] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0112] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0113] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0114] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0116] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0117] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0118] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present 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.

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

[0120] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0121] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims

1. A method for executing a transaction in a blockchain, the blockchain comprising a first node and a second node, the first node running a first pre-execution process, a cache process and a first consensus process, the method being executed by the first node, comprising: The cache process sends the received multiple transactions to the first pre-execution process, and the memory of the cache process stores the current status of at least part of the variables in the blockchain; The first pre-execution process pre-executes the multiple transactions, obtains pre-execution read-write sets of the multiple transactions and pre-execution orders of the multiple transactions, and sends the pre-execution read-write sets and pre-execution orders of the multiple transactions to the cache process, wherein the first pre-execution process receives the state of the variable requested to be read in the first transaction from the cache process when pre-executing the first transaction among the multiple transactions; The cache process sends the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions to the first consensus process, and updates the state data stored in the memory of the cache process based on the pre-execution read-write sets of the multiple transactions; The first consensus process generates a consensus proposal and sends the consensus proposal to a second node in the blockchain, wherein the consensus proposal includes pre-execution read-write sets of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order.

2. The method according to claim 1, wherein the first pre-execution process pre-executes the plurality of transactions comprising: When pre-executing the first transaction, the first pre-execution process receives the status of the variable requested to be read in the first transaction from the cache process when determining that the status of the variable requested to be read by the first transaction is not stored in the memory of the first pre-execution process, and updates the status data stored in the memory of the first pre-execution process based on the pre-execution read-write set of the first transaction.

3. The method according to claim 2, wherein the first pre-execution process pre-executes the plurality of transactions comprising: When pre-executing a second transaction among the plurality of transactions, the first pre-execution process pre-executes the second transaction based on state data stored in a memory of the first pre-execution process.

4. The method according to claim 1, wherein a second pre-execution process is also running in the first node, and the method further comprises: The cache process verifies the read sets in the pre-execution read-write sets of the multiple transactions according to the status data currently stored in the memory of the cache process. When the verification passes, the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions are stored in the memory of the cache process, and the status data currently stored in the memory of the cache process is updated based on the pre-execution read-write sets of the multiple transactions.

5. The method according to claim 1, wherein the first pre-execution process pre-executes the plurality of transactions comprising: When pre-executing a third transaction among the multiple transactions, the first pre-execution process reads the status of the variable requested to be read by the third transaction from a status database upon determining that the status of the variable requested to be read by the third transaction is not stored in the memory of the first pre-execution process and the status of the variable requested to be read by the third transaction is not stored in the memory of the cache process.

6. The method according to claim 1, wherein a first block management process is also running in the first node, and the method further comprises: The first consensus process sends the consensus proposal to the first block management process, and the first block management process updates the state database according to the pre-execution read-write sets of the multiple transactions and the arrangement order of the multiple transactions, and generates and stores blocks.

7. A method for executing a transaction in a blockchain, the blockchain comprising a first node and a second node, the second node running a second consensus process, a second block management process, and N computing processes, the method being executed by the second node, comprising: The second consensus process receives a consensus proposal from the first node, and sends the consensus proposal to the second block management process, wherein the consensus proposal includes a pre-execution read-write set of multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to a pre-execution order of the multiple transactions; The second block management process divides the multiple transactions into multiple transaction groups according to the pre-execution read-write set, allocates the multiple transaction groups to the N computing processes, and sends the arrangement order of the multiple transactions to the N computing processes; The N computing processes respectively execute transactions in the transaction group assigned to them according to the arrangement order, including: a first computing process among the N computing processes reads state data from a state database according to a pre-execution read set of all transactions included in the transaction group assigned to it, and stores the read state data in the memory of the first computing process.

8. The method according to claim 7, further comprising: The second block management process sends the pre-execution read-write set of the transaction allocated to each computing process to each computing process; The N computing processes respectively execute the transactions in the transaction group assigned to them according to the arrangement order, including: after the first computing process executes the first transaction in the transaction group assigned to it, obtains the execution read-write set of the first transaction, compares whether the execution read-write set of the first transaction is consistent with the pre-execution read-write set of the first transaction, and when they are consistent, updates the status data currently stored in the memory of the first computing process according to the execution read-write set of the first transaction.

9. The method according to claim 8, further comprising: After the first computing process completes the execution of all the transactions assigned to it, the first computing process updates the world state in the state database according to the execution write sets of all the transactions assigned to it.

10. A first node in a blockchain, wherein a first pre-execution process, a cache process, and a first consensus process are running in the first node, The cache process is used to send the received multiple transactions to the first pre-execution process, and the memory of the cache process stores the current status of at least part of the variables in the blockchain; The first pre-execution process is used to pre-execute the multiple transactions, obtain the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions, and send the pre-execution read-write sets and the pre-execution order of the multiple transactions to the cache process, wherein: The first pre-execution process is further used to receive, from the cache process, a state of a variable requested to be read in a first transaction among the plurality of transactions when pre-executing the first transaction; The cache process is used to send the pre-execution read-write sets of the multiple transactions and the pre-execution order of the multiple transactions to the first consensus process, and update the state data stored in the memory of the cache process based on the pre-execution read-write sets of the multiple transactions; The first consensus process is used to generate a consensus proposal and send the consensus proposal to a second node in the blockchain, wherein the consensus proposal includes a pre-execution read-write set of the multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to the pre-execution order.

11. A second node in a blockchain, wherein a second consensus process, a second block management process, and N computing processes are running in the second node, The second consensus process is used to receive a consensus proposal from the first node and send the consensus proposal to the second block management process, wherein the consensus proposal includes a pre-execution read-write set of multiple transactions and an arrangement order of the multiple transactions, and the arrangement order corresponds to a pre-execution order of the multiple transactions; The second block management process is used to divide the multiple transactions into multiple transaction groups according to the pre-execution read-write set, assign the multiple transaction groups to the N computing processes, and send the arrangement order of the multiple transactions to the N computing processes; The N computing processes are used to respectively execute the transactions in the transaction groups assigned to them according to the arrangement order, including: A first computing process among the N computing processes reads state data from a state database according to pre-execution read sets of all transactions included in a transaction group assigned to it, and stores the read state data in a memory of the first computing process.

12. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 9.

Images