WO2023231336A1

WO2023231336A1 - Method for executing transaction and blockchain node

Info

Publication number: WO2023231336A1
Application number: PCT/CN2022/135262
Authority: WO
Inventors: 林鹏
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-05-30
Filing date: 2022-11-30
Publication date: 2023-12-07
Also published as: CN114942847A

Abstract

A method for executing a transaction in a blockchain, and a blockchain node. The method is executed by a first node, and comprises: a cache process sends a plurality of received transactions to a first pre-execution process; the first pre-execution process pre-executes the plurality of transactions to obtain a pre-execution read-write set of the plurality of transactions and a pre-execution sequence of the plurality of transactions, and sends the pre-execution read-write set and the pre-execution sequence of the plurality of transactions to the cache process; the cache process sends, to a first consensus process, the pre-execution read-write set of the plurality of transactions and the pre-execution sequence of the plurality of transactions, and updates, on the basis of the pre-execution read-write set of the plurality of transactions, the world state data currently stored in a memory of the cache process; the first consensus process generates a consensus proposal, and sends the consensus proposal to a second node.

Description

Methods and blockchain nodes for executing transactions

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on May 30, 2022, with application number 2022106027905 and the application title "Method for executing transactions and blockchain node", the entire content of which is incorporated by reference. in this application.

Technical field

The embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method and blockchain node for executing transactions in a blockchain.

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.

Contents of the invention

The purpose of the present invention is to provide a method for executing transactions in a blockchain. By using multiple processes to provide various services in the blockchain, the transaction execution speed is accelerated and the system efficiency of the blockchain is improved.

A first aspect of this specification provides a method for executing transactions in a blockchain. The blockchain includes a first node and a second node. The first node runs a first pre-execution process, a cache process and a third node. A consensus process, the method is executed by the first node, including:

The cache process sends the received multiple transactions to the first pre-execution process, and the latest world state of at least some variables in the blockchain is stored in the memory of the cache process;

The first pre-execution process pre-executes the multiple transactions, obtains the pre-execution read-write sets of the multiple transactions and the pre-execution sequences of the multiple transactions, and converts the pre-execution read-write sets of the multiple transactions and the pre-execution sequence is sent to the cache process, wherein the first pre-execution process receives the read request in the first transaction from the cache process when pre-executing the first transaction in the plurality of transactions. The state of the variable;

The cache process sends the pre-execution read-write sets of the multiple transactions and the pre-execution sequences of the multiple transactions to the first consensus process, and updates the pre-execution read-write set based on the multiple transactions. Cache the world state data currently stored in the memory of the process;

The first consensus process generates a consensus proposal and sends the consensus proposal to the second node in the blockchain. The consensus proposal includes the pre-execution read-write set of the multiple transactions and the multiple transactions. The arrangement order corresponds to the pre-execution order.

A second aspect of this specification provides a method for executing transactions in a blockchain. The blockchain includes a first node and a second node. The second node runs a second consensus process and a second block management process. process and N computing processes, the method is executed by the second node, including:

The second consensus process receives a consensus proposal from the first node and sends the consensus proposal to the second block management process. The consensus proposal includes the pre-execution read and write sets of the multiple transactions and all The arrangement order of the plurality of transactions, the arrangement order corresponding to the pre-execution order of the plurality of transactions;

The second block management process divides the multiple transactions into multiple transaction groups according to the pre-execution read and write set, allocates the multiple transaction groups to the N computing processes, and assigns the multiple transaction groups to the N computing processes. The order of transactions is sent to the N calculation processes;

The N calculation processes respectively execute transactions in the transaction groups assigned to them according to the arrangement order.

The third aspect of this specification provides a first node in a blockchain, where a first pre-execution process, a cache process and a first consensus process run,

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

The first pre-execution process is used to pre-execute the multiple transactions, obtain the pre-execution read and write sets of the multiple transactions and the pre-execution sequences of the multiple transactions, and obtain the pre-execution read and write sets of the multiple transactions. The write set and the pre-execution sequence are sent to the cache process, wherein the first pre-execution process is also used to receive the first transaction from the cache process when pre-executing the first transaction in the plurality of transactions. The status of the variable requested to be read in the transaction;

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

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

The fourth aspect of this specification provides a second node in a blockchain, where a second consensus process, a second block management process and N calculation processes are run in the second node.

The second consensus process is configured to receive a consensus proposal from the first node and send the consensus proposal to the second block management process, where the consensus proposal includes a pre-execution read-write set of the multiple transactions. and the arrangement order of the plurality of transactions, the arrangement order corresponding to the pre-execution order of the plurality of transactions;

The second block management process is used to divide the multiple transactions into multiple transaction groups according to the pre-execution read and write set, allocate the multiple transaction groups to the N computing processes, and assign the The sequence of multiple transactions is sent to the N calculation processes;

The N calculation processes are used to execute transactions in the transaction groups assigned thereto respectively according to the arrangement sequence.

A fifth aspect of this specification provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect or the second aspect.

A sixth aspect of this specification provides a computing device, including a memory and a processor. The memory stores executable code. When the processor executes the executable code, it implements the first aspect or the second aspect. method.

Description of the drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 shows a blockchain architecture diagram applied in the embodiment of this specification;

Figure 2 is an architectural diagram of a blockchain node in the embodiment of this specification;

Figure 3 is a flow chart of a method for executing transactions in the blockchain in the embodiment of this specification;

Figure 4 is a schematic diagram of the consensus process in the PBFT consensus algorithm;

Figure 5 is a flow chart of a method for executing transactions in the blockchain in the embodiment of this specification.

Detailed ways

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 accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

Figure 1 shows a blockchain architecture diagram applied in the embodiment of this specification. As shown in Figure 1, the blockchain includes, for example, a total of 6 nodes including master node 1, slave node 2 to slave node 5. The connections between nodes schematically represent P2P (Peer to Peer, point-to-point) connections. These nodes store the entire ledger, which stores 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 Information such as the order of multiple transactions. After the nodes in the blockchain successfully reach consensus on the consensus proposal, each node can execute the multiple transactions according to the order in the consensus proposal, thereby generating block B1.

It can be understood that the blockchain shown in Figure 1 is only exemplary, and the embodiments of this specification are not limited to application to the blockchain shown in Figure 1. For example, they can also be applied to a blockchain system with a non-master-slave structure.

In addition, although FIG. 1 shows that the blockchain includes 6 nodes, the embodiments of this specification are not limited to this, and may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. The mentioned Byzantine fault tolerance requirements can be understood as meaning that Byzantine nodes can exist within the blockchain, but the blockchain does not reflect Byzantine behavior externally. Generally, some Byzantine fault-tolerant 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).

Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include sending fields (From), receiving fields (To) and data fields (Data). Among them, when the transaction is a transfer transaction, the From field represents the account address that initiated the transaction (that is, initiated a transfer task to another account), the To field represents the account address that received the transaction (that is, received the transfer), and the Data field Include transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address that initiated 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 corresponding Data such as the incoming parameters of the function are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

The functions of smart contracts can be provided in the blockchain. 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, allowing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that in addition to smart contracts that can be created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, some blockchain data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator rights 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 for different business data in the blockchain.

In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to the blockchain as shown in Figure 1. The data field of the transaction includes the code of the contract to be created ( Such as bytecode or machine code), 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. Each node adds the 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 stores The contract code is saved in the state storage of the contract, so the contract is created successfully.

In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain as shown in Figure 1. The from field of the transaction is the address of the account of the transaction initiator (Bob). "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 consensus is reached on the transaction in the blockchain, each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and update the status database based on the execution of the contract.

In related technologies, 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, transactions can be executed faster in blockchain nodes by executing them in parallel. Usually, for transfer transactions, the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions. Each transaction group does not access the same account, so that each transaction group 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 multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel. In one implementation, the first node in the blockchain (for example, master node 1 in Figure 1) can pre-execute multiple transactions, obtain the pre-execution read and write sets of each transaction, and communicate with other nodes through The pre-execution read-write set is sent to other nodes in the blockchain (such as the slave node in Figure 1) through the consensus process between nodes. Other nodes in the blockchain can group multiple transactions based on their pre-execution read and write sets, so that multiple transactions can be executed in parallel based on the grouping results.

However, in the current blockchain, the above process is usually carried out through a single process in the node, including client request processing, consensus network communication, transaction execution, data storage, etc. With the continuous development of blockchain business, running single processes The blockchain nodes of the process are limited by physical resources, network resources and other resources, resulting in scalability, expansibility, and throughput that cannot meet business needs.

The embodiments of this specification provide a solution for executing transactions in a blockchain. Multiple processes provide services such as pre-execution services, caching services, consensus services, and block management services in blockchain nodes, thereby making the area Blockchain nodes have high scalability and high throughput.

Figure 2 is an architectural diagram of a blockchain node in the embodiment of this specification. As shown in Figure 2, multiple processes can be run in the master node 1 and each slave node (such as the slave node 2 shown in Figure 2) in the blockchain shown in Figure 1 to provide a variety of 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, The block management process 14 of the block management service, etc. The pre-execution process 111 and the pre-execution process 112 are used to pre-execute the transactions received by the master node in parallel. It can be understood that in the embodiment of this 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., which are not shown in Figure 2 .

The slave node 2 may include a cache process 21 for providing cache services, a consensus process 22 for providing consensus services, a block management process 23 for providing block management services, and a computing process 241 for providing transaction execution services. and calculation process 242, etc. The calculation process 241 and the calculation process 242 are used to execute transactions in the consensus proposal in parallel. It can be understood that in the embodiment 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.

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 that is carried out by the CPU sequentially executing instructions in the application program. Each process is assigned its own memory address space when it is created, 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, calculation process 241 is allocated memory 243, calculation Process 242 is allocated memory 244.

The multiple processes in the master node 1 may be multiple processes in multiple computing devices (or virtual computing nodes), or may be multiple processes in a single computing device. Similarly, the multiple processes in each slave node may be multiple processes in multiple computing devices (or virtual computing nodes), or may be multiple processes in a single computing device. In addition, it should be noted that the solutions provided by the embodiments of this specification are not limited to the master-slave architecture blockchain system.

Figure 3 is a flow chart of a method for executing transactions in a blockchain in an embodiment of this specification. This method can be executed by master node 1 in Figure 2.

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

As shown above, in addition to the various processes shown in Figure 2, the master node 1 may also include an access process, which can receive transactions from the user device and send the received transactions to the cache process 12. Therefore, the cache process 12 stores the transactions received from the access process into the memory 120 of the cache process 12 in a certain order. For example, the cache process 12 may store transactions in the order in which they are received, such as by storing the received transactions in order in a transaction queue stored in the memory 120 .

The master node 1 may also include a network process (not shown in Figure 2). 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.

At the same time, for each pre-execution process (including pre-execution process 111 and pre-execution process 112), the cache process 12 can regularly send a preset number of transactions in the transaction queue to the pre-execution process, so that each pre-execution process Parallel pre-execution of transactions in the transaction queue. The caching process 12 can also send the order of the batch of transactions in the transaction queue to the pre-execution process, so that the pre-execution process can serially execute the batch of transactions according to the order of the batch of transactions in the transaction queue.

In step S303, the pre-execution process 111 pre-executes multiple transactions and obtains pre-execution read and write sets for each transaction.

After receiving multiple transactions from the cache process 12, the pre-execution process 111 may first verify the signatures of each transaction, and after passing the verification, perform pre-execution of the multiple transactions. The pre-execution process 111 serially executes multiple received transactions. For example, the pre-execution process 111 may serially execute multiple transactions in the order in which the multiple received transactions are arranged.

In the embodiment of this specification, the memory 113 may store the first state set of the first part of variables in the blockchain, where the first part of variables includes variables defined in the blockchain account or contract. When the pre-execution process 111 reads or writes variables during the pre-execution transaction, it may update the locally cached first state set. After pre-executing multiple transactions, the pre-execution process obtains the respective pre-execution read and write sets of the multiple transactions and the pre-execution sequence of the multiple transactions. The pre-execution read-write set of a transaction 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 in pre-execution of the transaction. The pre-execution write set includes the transaction Key-value pairs for variables written in pre-execution. The variables include, for example, external accounts in the blockchain, or variables defined in contract accounts. In one implementation, the state database, the first state set, and the second state set store keys, values, and version numbers of the values for each variable. Thus, a transaction's pre-execution read set may include keys and version numbers of variables read, and a transaction's pre-execution write set may include keys, values, and version numbers of variables written. Each time the pre-execution process 111 writes the value of a variable, it increments the version number of the variable's value by 1.

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 may refer to the description of subsequent steps in FIG. 3 . 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 first state set. If not, it then determines whether the value of the variable is included in the second state set. If it is still not included, then The value of the variable is read from the state database, and the value of the read variable is stored in the first state set.

Specifically, the multiple transactions include, for example, transaction Tx1. Assume 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 the memory 113 of the pre-execution process 111. Whether the value of variable a is stored, 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, transaction Tx1 The pre-execution read set includes the key-value pair of variable a, and the pre-execution write set includes the key-value pair of variable b. In the pre-execution read-write set that generates the transaction Tx1, the pre-execution process 111 updates the first state set in the memory 113 based on the write set of the transaction Tx1, and stores the value of the variable b written by the transaction Tx1 in the pre-execution in the first state set. .

In another case, when the pre-execution process 111 determines that the first state set in the memory 113 does not include the value of variable a, 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 second state set in the memory 120 includes the value of variable a, and if so, sends the value of variable a to the pre-execution process 111 . After receiving the value of variable a, the pre-execution process 111 can store the value of variable a into the first state set, so that it can be used to execute other subsequent transactions that read variable a. If the second state set does not include the value of variable a, 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, where the state database stores the completed The world state corresponding to the block. For example, the master node 1 also includes a storage process. The pre-execution process 11 can, for example, send a request to read the variable a to the storage process. After receiving the request, the storage process reads the value of the variable a in the state database and saves the variable. The value of a is returned 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. The pre-execution process 111 stores the value of the variable a read from the outside of the memory 113 into the memory 113, so that when the pre-execution process 111 reads the variable a in the next execution transaction, it can directly read the variable from the local memory. The value of a, thereby increasing the speed of transaction execution.

After each transaction is executed, the pre-execution process 111 also generates a transaction receipt for each transaction.

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

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 sequences of the multiple transactions to the cache process 12 together. In addition, the pre-execution process 111 also sends the transaction receipt of each transaction to the cache process 12 for storage in the memory 120 .

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

After the cache process 12 receives the pre-execution read-write sets and pre-execution sequences of multiple transactions, in the case where there is only one pre-execution process in the master node, since the pre-execution process reads a variable for the first time from the storage process Receive variable values for pre-execution of transactions, and serially pre-execute multiple transactions, and update the local first state set of the pre-execution process with the pre-execution of each transaction, and then update it through the pre-execution read and write sets of multiple transactions. The second state set, therefore, when the transaction sequence in the execution phase is set to be the same as the pre-execution sequence, the pre-execution read and write set of each transaction will be consistent with the execution read and write set. Therefore, based on the pre-execution read and write The first state set updated by the set is also the latest world state in 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 sets. After the update, the second state set also becomes the latest world state in master node 1.

In the case where there are multiple pre-execution processes in the master node (such as the pre-execution process 111 and the pre-execution process 112 in Figure 2), the two pre-execution processes may simultaneously execute the same variable during the process of parallel pre-execution transactions. Performing a read or write operation may result in the pre-execution result of one of the transactions not being obtained 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.

To this end, after receiving the pre-execution read-write sets of multiple transactions from the pre-execution process 111, the cache process 12 may sequentially detect the pre-execution read-write sets 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 other variables in the pre-execution read set of transaction Tx1 are included in the second state set. If the second state set does not include all variables in the pre-execution read set of transaction Tx1, that is, the transaction previously submitted to the cache process 12 has not read or written the variables read by the transaction Tx1, then it can be determined that the variables of the transaction Tx1 The pre-execution read set does not conflict with the second state set.

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 indicates that the variable read by the transaction Tx1 The value of a is the latest status of variable a during pre-execution. When the master node 1 determines that the value read for each variable in the pre-execution read set of transaction Tx1 is the latest state in the pre-execution process, it can be determined that there is no conflict between the pre-execution read set of transaction Tx1 and the second state set. In the case where it is determined sequentially that there is no conflict between the pre-execution read sets of multiple transactions and the second status set, the second status set may be updated based on the pre-execution read and write sets of the multiple transactions.

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, so , it can be determined that the pre-execution read set of transaction Tx1 conflicts with the second status set. In the event that a conflict is determined to exist, the cache process 12 may instruct the pre-execution process 111 to re-pre-execute the transaction Tx1 and other transactions pre-executed after the transaction Tx1.

In addition, after receiving the pre-execution read-write sets and pre-execution sequences of multiple transactions, the cache process 12 can store the pre-execution read-write sets of the multiple transactions in the memory 120, and process the multiple transactions in the transaction queue according to the pre-execution read-write sets. The pre-execution sequence stores the identifiers of the multiple transactions to indicate the pre-execution sequence of the multiple transactions.

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

The consensus process 13 regularly 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 and write sets of multiple transactions and the arrangement order of the multiple transactions to the consensus process 13. The arrangement order is the pre-execution order of the multiple transactions. Wherein, the cache process 12 may send the pre-execution read-write set of each transaction in association with the hash value of each transaction. The cache process 12 may also send multiple transaction data to the consensus process when the pre-execution read-write set of transactions stored in the memory 120 reaches a certain amount of data, or when the pre-execution read-write set of transactions stored in the memory 120 reaches a certain amount. Pre-execution read and write sets and their pre-execution order.

In step S311, the consensus process 13 generates a consensus proposal and performs consensus with other nodes.

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, blockchain nodes can implement a block-granular consensus mechanism. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, the records of other nodes will be the same. block. For another example, a transaction-granularity consensus mechanism 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 across the entire network on block information (or block data), which can ensure that the latest blocks are 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 various consensus algorithms, the consensus success of the consensus proposal is usually determined after a preset number of nodes reach an agreement on the consensus data (ie, consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated. That is to say, when 2f + 1 nodes among the N consensus nodes reach an agreement, the consensus can be determined to be successful.

Figure 4 is a schematic diagram of the consensus process in the PBFT consensus algorithm. As shown in Figure 4, according to the PBFT consensus algorithm, the consensus process can be divided into four stages: Request, Pre-Prepare, Prepare and Commit. For the blockchain shown in Figure 1, according to the PBFT algorithm, f=1 malicious node can be tolerated among master node 1, slave node 2-slave node 6, so when 5 of the 6 nodes need to reach consensus, Only then can the consensus be confirmed to be successful. Specifically, during 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 preliminary stage, the master node 1 generates a consensus proposal. Specifically, in the embodiment of this specification, the consensus proposal may include the pre-execution read-write set of multiple transactions received from the cache process 12 and the pre-execution of the multiple transactions. Information such as order, where individual transactions in a consensus proposal can be identified by transaction hash values.

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 (ie, the slave node 2 to the slave node 6) for use in generating blocks. Specifically, the consensus process 13 can send the consensus proposal and signature to the network process, and the network process sends it 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 broadcast. In this way, the consensus proposal sent by the master node 1 to each slave node does not include the transactions of each transaction. It reduces the amount of data required for consensus proposals, thereby reducing the amount of calculation required by each node to digitally sign the consensus node during the consensus process, and improving consensus efficiency.

Still referring to Figure 4, in the preparation phase, each slave node can sign the consensus proposal and send it to each other node. Assuming that slave node 6 is a malicious node, after master node 1, slave node 2-slave node 5 respectively receive the signatures of the consensus proposal from 2f = 2 other consensus nodes, it can be determined that the preparation phase is completed and the submission phase can be entered. For example, as shown in Figure 4, after master node 1 receives the signatures of slave node 2-slave node 5, it verifies that the signatures of slave node 2-slave node 5 are correct signatures for the consensus proposal, then the preparation stage is determined. Completed, the slave node 2 determines that the preparation phase is completed after receiving the signatures of the slave nodes 3 to 5 and the signature of the master node 1 in the preliminary phase and passing the verification. In the submission phase, each consensus node signs the consensus proposal in the submission phase and sends it to each other consensus node. After receiving the signatures of 2f = 4 other consensus nodes in the submission phase, each consensus node can confirm that the submission phase is completed and the consensus success. For example, after master node 1 receives and verifies the signatures of the submission phase from slave node 2 to slave node 5, it determines that the submission phase is completed and the consensus is successful.

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

After generating the consensus proposal, the consensus process 13 may send the consensus proposal to the block management process 14.

In step S315, the block management process 14 generates and submits blocks.

Since the master node trusts its own pre-execution without doing evil, 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 obtained The execution read-write sets of the multiple transactions 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 and write sets of the multiple transactions as the execution read and write sets to update the world state in the state database without re-executing the multiple transactions.

Therefore, the block management process 14 can sequentially update the status of each account and each contract variable in the world state according to the write set and pre-execution sequence of the pre-execution read-write set of multiple transactions in the consensus proposal, and update the state tree according to the updated world state. The value of each node in , including the state root ((that is, 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 the multiple transactions from the cache process 13, and generate the transaction roots of the transaction trees of the multiple transactions (that is, the hash value of the root node of the transaction tree) and receipts respectively. The receipt root of the tree (that is, the hash value of the root node of the receipt tree).

Then, the block management process 14 may generate a block (for example, block B1) including the plurality of transactions. The block B1 may include a block body and a block header, where the block header may include a block number, transaction Root, status root, receipt root and other information, the block body can include the transaction body set and receipt set of each transaction. After generating the block, the block management process 14 can submit the block to be stored in the block database of the master node 1 in Figure 2 . For example, block management process 14 may send the block to the storage process so that the storage process stores the block in a block database.

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

Figure 5 is a flow chart of a method for executing transactions in the blockchain in the embodiment of this specification. This method can be executed by slave node 2 in Figure 2.

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

Similar to master node 1, slave node 2 can also include a receiving process and a network process (not shown in Figure 2). Slave node 2 can receive transactions from user devices through the receiving process, and can receive transactions from other nodes through the network process. Transaction sent. 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 memory 210 in the form of a transaction queue. Similar to the master node 1, the cache process 21 can also send transactions in the transaction queue to the network process to broadcast to other nodes in the blockchain.

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 transfer the consensus The proposal and the signature of master node 1 are sent to consensus process 22. After receiving the consensus proposal and its signature, the consensus process 22 starts the consensus process. For the specific consensus process, please refer to the description above with reference to Figure 4, and will not be described again here.

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

After receiving the consensus proposal and passing the signature verification of the master node, the consensus process 22 can send the consensus proposal to the block management process 23.

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

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 each Multiple transactions in a group are arranged in their pre-execution order. After completing the grouping, the block management process 23 may evenly distribute the multiple groups obtained by grouping to multiple computing processes. For example, in the case where the slave node 2 only includes the calculation process 241 and the calculation process 242, half of the number of components in the plurality of groups can be assigned to the calculation process 241, and the other half of the number of components can be assigned to the calculation process 242.

It can be understood that the embodiment of this specification is not limited to the grouping of multiple transactions by the block management process 23. For example, the consensus process 22 can also group multiple transactions according to the pre-execution read and write sets of multiple transactions. And send the consensus proposal and grouping results to the block management process 23.

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.

In step S509, the calculation process executes the transaction and updates the status database.

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

Specifically, as shown in Figure 2, the calculation process 241 includes a memory 243. Before starting to execute multiple groups of transactions, the calculation process 241 can determine all variables that need to be read based on the read sets of all transactions in the multiple groups. , and reads all variables in batches (for example, all at once) from the state database. After reading the states of all variables (ie, world state), process 241 can pair the values of all variables with key values. The form is stored in the third state set in the memory 243. The calculation process 241 may then execute transactions in each group based on the third set of states. When the calculation process 241 performs the operation of reading variables according to the transaction, it reads the value of the variable from the third state set, and when it performs the operation of writing the variable according to the transaction, it updates the value of the variable in the third state set to the value of this write. The entered value is used to generate the execution read-write set of the transaction. 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, the key-value pairs of variables read during the transaction execution process, and the execution write set includes, for example, the key-value pairs of variables written during the transaction execution process. Through batch pre-reading, the calculation process 241 stores the parameters that need to be read from the state database into the local memory 243 in advance, so that the calculation process 241 can directly read the state from the memory during the execution of the transaction without the need for Reading state from storage greatly speeds up transaction execution.

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

In step S511, the block management process 23 generates and submits blocks.

After determining that each computing process has completed transaction execution and status updates for the groups 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 root of the state tree The hash value of the node)). The block management process 23 can also obtain the transaction bodies and transaction receipts of multiple transactions from the cache process 21, and generate the transaction roots of the transaction trees of the multiple transactions (that is, the hash value of the root node of the transaction tree) and the receipt tree respectively. The receipt root (that is, the hash value of the root node of the receipt tree).

Then, the block management process 23 may generate a block (for example, block B1) including the plurality of transactions. The block B1 may include a block body and a block header, where the block header may include a block number, transaction Root, status root, receipt root and other information, the block body can include the transaction body set and receipt set of each transaction. After generating the block, the block management process 23 can submit the block to be stored in the block database of the slave node 2 in FIG. 2 .

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

Embodiments of this specification also provide a first node in the blockchain, where a first pre-execution process, a cache process and a first consensus process are run, for executing the method shown in Figure 3.

Embodiments of this specification also provide a second node in the blockchain. The second node runs a second consensus process, a second block management process and N calculation processes for executing the method shown in Figure 5. .

The N calculation processes are used to execute transactions in the transaction groups assigned thereto respectively according to the arrangement order.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. 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 of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, 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., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

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, this application does not rule out 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, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it may be executed sequentially or in parallel according to the methods shown in the embodiments or figures (for example, a parallel processor or a multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The present 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 process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

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

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape, magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

One or more embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. 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 the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A method of executing transactions in a blockchain. The blockchain includes a first node and a second node. The first node runs a first pre-execution process, a cache process and a first consensus process. The method is executed by the first node and includes:

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 some variables in the blockchain;

The first pre-execution process pre-executes the multiple transactions, obtains the pre-execution read-write sets of the multiple transactions and the pre-execution sequences of the multiple transactions, and converts the pre-execution read-write sets of the multiple transactions and the pre-execution sequence is sent to the cache process, wherein the first pre-execution process receives the read request in the first transaction from the cache process when pre-executing the first transaction in the plurality of transactions. The state of the variable;

The cache process sends the pre-execution read-write sets of the multiple transactions and the pre-execution sequences of the multiple transactions to the first consensus process, and updates the pre-execution read-write set based on the multiple transactions. Cache state data stored in the process's memory;

The first consensus process generates a consensus proposal and sends the consensus proposal to the second node in the blockchain. The consensus proposal includes the pre-execution read-write set of the multiple transactions and the multiple transactions. The arrangement order corresponds to the pre-execution order.
The method of claim 1, wherein the first pre-execution process pre-executes the plurality of transactions including: when pre-executing the first transaction, the first pre-execution process determines that the first pre-execution process When the state of the variable requested to be read in the first transaction is not stored in the memory of the process, the state of the variable requested to be read in the first transaction is received from the cache process, and the pre-execution read based on the first transaction is The write set updates the state data stored in the memory of the first pre-execution process.
The method of claim 2, wherein the first pre-execution process pre-executes the plurality of transactions including: when the first pre-execution process pre-executes a second transaction in the plurality of transactions, based on the The state data stored in the memory of the first pre-execution process pre-executes the second transaction.
The method of claim 1, wherein a second pre-execution process is also running in the first node, and the method further includes: the cache process caches the cache process based on the status data currently stored in the memory of the cache process. The read sets in the pre-execution read and write sets of multiple transactions are verified. When the verification passes, the pre-execution read and write sets of the multiple transactions and the pre-execution sequence of the multiple transactions are stored in the memory of the cache process. , updating the state data currently stored in the memory of the cache process based on the pre-execution read and write sets of the multiple transactions.
The method of claim 1, wherein the first pre-execution process pre-executes the plurality of transactions including: when the first pre-execution process pre-executes a third transaction among the plurality of transactions, the first pre-execution process determines that the When the state of the variable read by the third transaction request is not stored in the memory of the first pre-execution process, and the state of the variable read by the third transaction request is not stored in the memory of the storage process, from the state Read the status of the variable read by the third transaction request from the database.
According to the method of claim 1, a first block management process is also run in the first node, and the method further includes: the first consensus process sending the consensus proposal to the first block Management process, the first block management process updates the status database according to the pre-execution read and write sets of the multiple transactions and the arrangement order of the multiple transactions, and generates and stores blocks.
A method of executing transactions in a blockchain. The blockchain includes a first node and a second node. The second node runs a second consensus process, a second block management process and N calculation processes. , the method is executed by the second node, including:

The second consensus process receives a consensus proposal from the first node and sends the consensus proposal to the second block management process. The consensus proposal includes the pre-execution read and write sets of the multiple transactions and all The arrangement order of the plurality of transactions, the arrangement order corresponding to the pre-execution order of the plurality of transactions;

The second block management process divides the multiple transactions into multiple transaction groups according to the pre-execution read and write set, allocates the multiple transaction groups to the N computing processes, and assigns the multiple transaction groups to the N computing processes. The order of transactions is sent to the N calculation processes;

The N calculation processes respectively execute transactions in the transaction groups assigned to them according to the arrangement order.
The method according to claim 7, wherein the N computing processes respectively execute transactions in the transaction group assigned to them according to the arrangement order, including: the first computing process among the N computing processes performs transactions according to the transaction group assigned to it. The pre-execution read set of all transactions included in the transaction group reads status data from the status database, and stores the read status data into the memory of the first computing process.
The method according to claim 8, further comprising: the second block management process sending the pre-execution read and write sets of transactions assigned to each computing process to each computing process;

The N calculation processes respectively executing the transactions in the transaction group assigned to them according to the arrangement order include: the first calculation process obtains the first transaction after executing the first transaction in the transaction group assigned to it. The execution read-write set of the transaction is compared to see whether the execution read-write set of the first transaction is consistent with the pre-execution read-write set of the first transaction. If they are consistent, the execution read-write set of the first transaction is compared. Update state data currently stored in the memory of the first computing process.
The method according to claim 9, further comprising: after the first computing process completes execution of all transactions assigned to it, update the world state in the state database according to the execution write set of all transactions assigned to it.
A first node in a blockchain, where a first pre-execution process, a cache process and a first consensus process run,

The cache process is used to send multiple received transactions to the first pre-execution process, and the memory of the cache process stores the current status of at least some variables in the blockchain;

The first pre-execution process is used to pre-execute the multiple transactions, obtain the pre-execution read and write sets of the multiple transactions and the pre-execution sequences of the multiple transactions, and obtain the pre-execution read and write sets of the multiple transactions. The write set and the pre-execution sequence are sent to the cache process, wherein the first pre-execution process is also used to receive the first transaction from the cache process when pre-executing the first transaction in the plurality of transactions. The status of the variable requested to be read in the transaction;

The cache process is used to send the pre-execution read-write set of the multiple transactions and the pre-execution order of the multiple transactions to the first consensus process, and update the pre-execution read-write set based on the multiple transactions. The state data stored in the memory of the cache process;

The first consensus process is used to generate a consensus proposal and send the consensus proposal to the second node in the blockchain. The consensus proposal includes the pre-execution read-write set of the multiple transactions and the multiple transactions. The arrangement order of transactions, the arrangement order corresponds to the pre-execution order.
A second node in a blockchain, where a second consensus process, a second block management process and N calculation processes run,

The second consensus process is configured to receive a consensus proposal from the first node and send the consensus proposal to the second block management process, where the consensus proposal includes a pre-execution read-write set of the multiple transactions. and the arrangement order of the plurality of transactions, the arrangement order corresponding to the pre-execution order of the plurality of transactions;

The second block management process is used to divide the multiple transactions into multiple transaction groups according to the pre-execution read and write set, allocate the multiple transaction groups to the N computing processes, and assign the The sequence of multiple transactions is sent to the N calculation processes;

The N calculation processes are used to execute transactions in the transaction groups assigned thereto respectively according to the arrangement sequence.
A computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to perform the method described in any one of claims 1-10.