Methods of executing transactions in blockchain, master nodes and slave nodes of blockchain

Abstract

This specification provides a method for executing transactions in a blockchain, a master node and a slave node of the blockchain, the blockchain including the master node and the slave node, the master node including a pre-execution process and a first consensus process, the method being executed by the master node, the method including: the pre-execution process pre-executing multiple first transactions of a first block to obtain a pre-execution read-write set of each first transaction; the first consensus process generating a first consensus proposal for the first block and broadcasting the first consensus proposal to the slave node; the first consensus proposal including the pre-execution read-write set of each first transaction; in the process of the first consensus process generating the first consensus proposal, the pre-execution process pre-executing multiple second transactions of a second block; the first block is before the second block.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and more particularly, to a method for executing transactions in a blockchain, a master node, and a slave node of the blockchain. Background Art

[0002] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain, data blocks are linked sequentially in chronological order to form a chain-like data structure, and cryptography is used to ensure that these blocks cannot be tampered with or forged. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

[0003] At present, it is difficult to improve the efficiency of transaction execution, and a solution for efficient transaction execution is needed. Summary of the Invention

[0004] One or more embodiments of this specification provide a method for executing transactions in a blockchain, a master node, and a slave node of the blockchain.

[0005] According to a first aspect, a method for executing a transaction in a blockchain is provided, wherein the blockchain includes a master node and a slave node, the master node includes a pre-execution process and a first consensus process, the method being executed by the master node, the method comprising:

[0006] The pre-execution process pre-executes a plurality of first transactions of the first block to obtain a pre-execution read-write set of each first transaction;

[0007] The first consensus process generates a first consensus proposal for the first block and broadcasts the first consensus proposal to the slave node; the first consensus proposal includes a pre-execution read-write set of each of the first transactions;

[0008] During the process of the first consensus process generating the first consensus proposal, the pre-execution process pre-executes multiple second transactions of a second block; the first block is before the second block.

[0009] According to a second aspect, a method for executing a transaction in a blockchain is provided, wherein the blockchain includes a master node and a slave node, the slave node includes a second consensus process, a second management process, and a computing process, the method being executed by the slave node, the method comprising:

[0010] The slave node receives the first consensus proposal broadcast by the master node through the second consensus process; the first consensus proposal includes a pre-execution read-write set of each first transaction obtained by the master node pre-executing multiple first transactions of the first block;

[0011] The second management process obtains the pre-execution read-write set of each first transaction from the second consensus process, and the second consensus process and the slave node reach a consensus on the first block;

[0012] During consensus on the first block, the second management process groups the multiple first transactions in parallel to obtain multiple transaction groups, and sends the multiple transaction groups to the computing process;

[0013] The computing process executes the plurality of transaction groups in parallel.

[0014] According to a third aspect, a master node in a blockchain is provided, wherein the blockchain further includes a slave node, and the master node includes:

[0015] A pre-execution process, configured to pre-execute multiple first transactions of the first block to obtain a pre-execution read-write set for each first transaction;

[0016] a consensus process, configured to generate a first consensus proposal for the first block and broadcast the first consensus proposal to the slave nodes; the first consensus proposal including pre-execution read-write sets for each of the first transactions;

[0017] In the process of the consensus process generating the first consensus proposal, the pre-execution process pre-executes multiple second transactions of the second block; the first block is before the second block.

[0018] According to a fourth aspect, a slave node in a blockchain is provided, wherein the blockchain further includes a master node, and the slave node includes:

[0019] A consensus process is configured to receive a first consensus proposal broadcast by the master node; the first consensus proposal includes pre-executed read-write sets of each first transaction obtained by the master node pre-executing multiple first transactions of the first block; obtain the pre-executed read-write sets of each first transaction, and reach consensus on the first block with the master node;

[0020] a management process configured to group the plurality of first transactions in parallel to obtain a plurality of transaction groups during a consensus process on the first block;

[0021] A computing process is used to execute the multiple transaction groups in parallel.

[0022] According to a fifth aspect, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of the first aspect or the second aspect is implemented.

[0023] According to the sixth aspect, a computing device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method described in any one of the first and second aspects is implemented.

[0024] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

[0025] The embodiments of this specification provide a method for executing transactions in a blockchain, as well as master and slave nodes for the blockchain. The master node is configured with a pre-execution process and a consensus process. The pre-execution process pre-executes the current block, and the consensus process then reaches consensus on the current block. While consensus is being reached on the current block, the pre-execution process also pre-executes the next block after the current one. This effectively increases the speed of transaction execution in the blockchain and improves the performance of the blockchain system. Furthermore, slave nodes can group and execute blocks in parallel without waiting for consensus on the block, further increasing the speed of transaction execution in the blockchain.

[0026] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. 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 any creative labor.

[0028] Figure 1 This is a diagram of the blockchain architecture used in the embodiments of this specification;

[0029] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm according to an exemplary embodiment of this specification;

[0030] Figure 3 This is a schematic diagram of a process for executing a transaction in a blockchain according to an exemplary embodiment of the present specification;

[0031] Figure 4 This is a structural diagram of a master node and a slave node of a blockchain according to an exemplary embodiment of this specification;

[0032] Figure 5 This is a flow chart of a method for executing transactions in a blockchain according to an exemplary embodiment of this specification;

[0033] Figure 6This is a block diagram of a master node in a blockchain according to an exemplary embodiment of the present specification;

[0034] Figure 7 This is a block diagram of a slave node in a blockchain according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0035] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0036] Blockchains are generally categorized into three types: public, private, and consortium. Furthermore, various combinations exist, such as private + consortium, or consortium + public. Public blockchains offer the highest degree of decentralization. Participants in a public blockchain can access data records, participate in transactions, and compete through consensus for the right to record new blocks. In a private blockchain, write access to the network is controlled by a specific organization or institution, while data read access is regulated by that organization. Consortium blockchains, situated between public and private blockchains, offer partial decentralization. Each node in a consortium chain typically has a corresponding entity or organization. Participants are authorized to join the network and form a stakeholder alliance to jointly maintain the blockchain's operations.

[0037] like Figure 1 , which is a diagram of the blockchain architecture used in the embodiments of this specification.

[0038] exist Figure 1In the blockchain architecture diagram shown, the blockchain includes, for example, six nodes: master node 1 and slave nodes 2 through 6. The lines connecting the nodes schematically represent P2P (peer-to-peer) connections. These nodes can store the full ledger, that is, the state of all blocks and all accounts. Each node in the blockchain can generate the same state by executing the same transactions, and each node in the blockchain can store the same state database. The difference is that master node 1 is responsible for pre-executing received transactions and initiating a consensus proposal to each slave node. This consensus proposal includes, for example, multiple transactions in the block to be formed (e.g., block B1), as well as information such as the pre-execution read / write sets and pre-execution order of each transaction. After each node in the blockchain successfully reaches consensus on the consensus proposal, each slave node executes the multiple transactions according to the pre-execution order specified in the consensus proposal, thereby generating block B1.

[0039] I understand. Figure 1 Although the blockchain is shown as including six nodes, the embodiments of this specification are not limited thereto and may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. The Byzantine Fault Tolerance requirement can be understood as allowing Byzantine nodes to exist within the blockchain without the blockchain displaying Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes (i.e., malicious nodes), such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0040] A transaction in the blockchain field can refer to a task unit executed and recorded in the blockchain. A transaction typically includes a send field (From), a receive field (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field indicates the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address initiating the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes data such as the function name in the called contract and the parameters passed to the function, which are used to retrieve the function code from the blockchain and execute the function code when the transaction is executed.

[0041] Blockchains offer smart contract functionality. Smart contracts on blockchains are contracts that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in code. Calling a smart contract on a blockchain involves initiating a transaction to the smart contract address, enabling each node in the blockchain to execute the smart contract code in a distributed manner. It should be noted that in addition to user-created smart contracts, smart contracts can also be set up by the system in the genesis block. This type of contract is generally referred to as a genesis contract. Generally, a genesis contract can set certain blockchain data structures, parameters, properties, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0042] In the scenario of deploying a contract, for example, Bob sends a transaction containing the information of creating a smart contract (ie deploying the contract) to Figure 1 In the blockchain shown, the transaction's data field contains the code (such as bytecode or machine code) for the contract to be created. The transaction's to field is empty, indicating that the transaction is for deploying the contract. After the nodes reach consensus through the consensus mechanism, they determine the contract address "0x6f8ae93..." Each node adds a contract account corresponding to the smart contract's contract address to the state database, allocates state storage corresponding to the contract account, and saves the contract code in the contract's state storage, successfully creating the contract.

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

[0044] One of the decentralized features that distinguishes blockchain technology from traditional technologies is that it maintains ledgers on individual nodes, or distributed ledgers, rather than traditional centralized ledgers. For a blockchain system to be a decentralized, trustworthy, and impenetrable system with public, tamper-proof data records, it must ensure that distributed data records are secure, unambiguous, and irreversible in the shortest possible time. In various blockchain networks, consensus algorithms—the aforementioned consensus mechanisms—are often used to ensure ledger consistency across all nodes.

[0045] For example, blockchain nodes can implement a block-level consensus mechanism. For example, after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, the other nodes will record the same block. Another example is a transaction-level consensus mechanism. For example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, each node that recognized the blockchain transaction can add the blockchain transaction to the latest block it maintains, ultimately ensuring that each node generates the same latest block. The consensus mechanism is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), which can ensure that the latest block is accurately added to the blockchain.

[0046] Current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. Among these various consensus algorithms, consensus on a consensus proposal is typically determined to be successful only after a predetermined number of nodes reach agreement on the consensus data (i.e., the consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated. In other words, consensus is considered successful when 2f + 1 of the N consensus nodes reach agreement.

[0047] Figure 2 Schematic diagram of the consensus process in the PBFT consensus algorithm.

[0048] like Figure 2 As shown in Figure 1, according to the PBFT consensus algorithm, the complete consensus process can be divided into four phases: Request, Pre-Prepare, Prepare, and Commit. Assume that a blockchain includes four consensus nodes, n1 through n4, where n1 is the master node and n2 through n4 are slave nodes. According to the PBFT algorithm, n1 through n4 can tolerate f = 1 malicious node.

[0049] Specifically, during the request phase, a blockchain user can send a request to node n1 via their user device, for example, in the form of a blockchain transaction. Node n1 can receive multiple transactions from one or more user devices and store the received transactions in a transaction queue. During the preparatory phase, node n1 can retrieve multiple transactions belonging to a block from the transaction queue and generate a consensus proposal for these multiple transactions. This consensus proposal and node n1's signature on the consensus proposal are broadcast to other consensus nodes (i.e., nodes n2-n4) so that the consensus nodes can continue to reach consensus on the block. The consensus proposal may, for example, include information such as the transaction bodies of the multiple transactions and the execution order of the multiple transactions.

[0050] In the preparation phase, each slave node can sign the consensus proposal and send it to other nodes. Assuming that node n4 is a malicious node, after nodes n1, n2, and n3 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 2 As shown in , after receiving the signatures of nodes n2 and n3, node n1 verifies that the signatures of nodes n2 and n3 are correct signatures of the consensus proposal, and then determines that the preparation phase is completed. After node n2 receives the signature of node n3 and the signature of node n1 in the preparation phase and verifies them, it determines that the preparation phase is completed.

[0051] During the submission phase, each consensus node signs the consensus proposal and sends it to the other consensus nodes. After receiving the submission phase signatures of 2f = 2 other consensus nodes, each consensus node can determine that the submission phase is complete and consensus is successful. For example, after node n1 receives and verifies the submission phase signatures of nodes n2 and n3, it determines that the submission phase is complete. As a result, node n1 can update the world state based on the execution results obtained from executing the multiple transactions, generate and store the blocks including the multiple transactions (such as block B1), and return the execution results of the multiple transactions to the user device. Similarly, after determining that the submission phase is complete, nodes n2 and n3 execute the multiple transactions, generate and store block B1, and update the world state based on the execution results of the multiple transactions.

[0052] Through the above process, the storage consistency of nodes n1, n2, and n3 is achieved. In other words, even if there is a malicious node, nodes n1-n4 can still successfully reach consensus on the consensus proposal and complete the execution of the block.

[0053] In the related art, when executing transactions in the blockchain, they are usually completed block by block, which makes it difficult to improve the efficiency of transaction execution. Figure 1The solution for executing transactions in the blockchain shown can effectively increase the speed of executing transactions in the blockchain.

[0054] Figure 3 The present invention is a schematic diagram of a process of executing a transaction in a blockchain according to an exemplary embodiment.

[0055] like Figure 3 As shown, the block execution process can be divided into five stages: pre-execution, consensus, transaction execution, status update, and block writing. For each stage, transactions in each block can be processed sequentially according to the order of the blocks. Alternatively, different stages can be completed through different processes.

[0056] Specifically, after the blockchain's master node obtains multiple transactions for block N, it first pre-executes each transaction in block N, thereby obtaining the corresponding pre-execution read-write set for each transaction. This pre-execution read-write set can be used to group the multiple transactions in block N. After completing the pre-execution of each transaction in block N, the master node can, on the one hand, conduct the preliminary consensus phase (hereinafter referred to as the PP phase) for block N, namely, generate a consensus proposal for block N and broadcast this consensus proposal to each slave node. This consensus proposal may include, for example, the hash value of each transaction in block N, the pre-execution read-write set of each transaction, and the pre-execution order of each transaction in block N. On the other hand, the master node can also continue to obtain multiple transactions for block N+1 in parallel, pre-execute multiple transactions for block N+1, and conduct the PP phase of consensus on block N+1.

[0057] After receiving the consensus proposal, each slave node and the master node will enter the preparation phase (hereinafter referred to as the P phase) and the submission phase (hereinafter referred to as the C phase) of consensus on block N (for details, please refer to Figure 2 During the P and C phases of consensus on block N, the master node can concurrently update the world state in the state database based on the pre-executed write sets of each transaction in block N and write block N in parallel.

[0058] It should be noted that after the master node completes the pre-execution of block N+1, it needs to wait for the master node to complete the write of block N before it can continue to update the world state in the state database based on the pre-execution write set of each transaction in block N+1.

[0059] After receiving the consensus proposal from the master, each slave node can, during the consensus process for block N, concurrently group transactions for block N based on the pre-execution read-write set and pre-execution order sent by the master, and concurrently execute each transaction in block N according to the grouping. Optionally, each slave node can also concurrently update the state database based on the execution write set while executing transactions. For example, after each slave node completes executing a set of transactions for block N, it can concurrently update the state database based on the execution write set of the completed set of transactions while executing the next set of transactions. While updating the state database based on the execution write set of each transaction in block N, each slave node can concurrently write to block N.

[0060] It should be noted that the slave node needs to wait until the write of block N is completed before it can continue to update the state database based on the execution write set of each transaction in block N+1.

[0061] In this embodiment, after the master node completes pre-execution on the current block, it can proceed to the pre-execution and consensus phases for the next block during the PP phase of consensus on the current block. Furthermore, slave nodes can group and execute blocks in parallel without waiting for consensus on the block. This effectively increases the speed of transaction execution within the blockchain and improves the performance of the blockchain system.

[0062] Figure 4 A structural diagram of the master node and slave nodes of the blockchain provided in the embodiments of this specification is shown.

[0063] like Figure 4 As shown, the master node may include an access process 11, a pre-execution process 12, a cache process 13, a consensus process 14, a storage process 15, a management process 16 and a communication process 17, and the slave node may include an access process 21, a pre-execution process 22, a cache process 23, a consensus process 24, a storage process 25, a management process 26, a communication process 27 and a computing process 28.

[0064] The master node can interact with the client, for example, through access process 11. Access process 11 receives multiple transactions from the client and transmits them to cache process 13, which then places the received transactions into a transaction queue. In addition, cache process 13 stores the latest blockchain world state data. Pre-execution process 12 retrieves a batch of transactions from cache process 13's transaction queue at predetermined intervals and pre-executes these transactions to obtain pre-execution read-write sets for each transaction. The pre-execution read-write set for any transaction can include a pre-execution read set and a pre-execution write set. The pre-execution read set can specifically be key-value pairs of read variables generated during the pre-execution of the transaction, while the pre-execution write set can specifically be key-value pairs of write variables generated during the pre-execution of the transaction. During the pre-execution of a transaction, the state values of each variable in the transaction's read set can be retrieved from the latest state data stored by cache process 13. After each pre-execution of a transaction, the pre-execution read-write set for that transaction can be submitted to cache process 13 for storage, and the state data stored in cache process 13 can be updated using the state values of each variable in the write set obtained during the pre-execution of the transaction.

[0065] It should be noted that the master node can have multiple pre-execution processes, and these multiple pre-execution processes can pre-execute transactions in parallel. If multiple pre-execution processes pre-execute transactions in parallel, then after each transaction is executed, the read set of the pre-executed transaction must be verified before the status data stored in cache process 13 is updated. For example, after pre-execution of transaction Tx1, it is possible to verify whether the status values of the various variables in the read set of transaction Tx1 stored in cache process 13 have changed compared to the status values before pre-execution. If no changes have occurred, the status data stored in cache process 13 can be directly updated using the status values of the various variables in the write set obtained from pre-execution of the transaction. If changes have occurred, transaction Tx1 must be re-pre-executed using the new status values of the various variables in the read set of transaction Tx1 in cache process 13.

[0066] Cache process 13 stores not only individual transactions but also the pre-execution read / write sets obtained by pre-executing each transaction, as well as the pre-execution order of each transaction. At regular intervals, consensus process 14 retrieves the consensus data corresponding to a block from cache process 13. This data may include the hash value / transaction identifier / transaction body of each transaction in the block, the pre-execution read / write set of each transaction, and the pre-execution order of each transaction. Consensus process 14 generates a consensus proposal containing the consensus data and broadcasts it to other slave nodes in the blockchain via communication process 17. As other slave nodes reach consensus on the block, they return consensus information to consensus process 14 via communication process 17. Furthermore, consensus process 14 may send the transaction bodies, pre-execution read / write sets, and pre-execution order of multiple transactions in the block to management process 16. After reaching consensus, consensus process 14 may also send the consensus result to management process 16.

[0067] In one implementation, management process 16 can group transactions based on the pre-execution read / write sets of multiple transactions in the block to obtain grouping information. In another implementation, management process 16 can also obtain transaction grouping information from other slave nodes. It should be understood that this embodiment does not limit the specific method by which the management process obtains grouping information. Finally, management process 16 can use the state values of each variable in the write set obtained by pre-execution of the block to update the state database in storage process 15. Based on the transaction bodies of multiple transactions in the block, the pre-execution read / write sets, and the grouping information, management process 16 generates block data for the block and stores this block data in the block database in storage process 15.

[0068] For example, a slave node can interact with a client through access process 21. Access process 21 receives multiple transactions from the client and transmits them to cache process 23, which places the received transactions into a transaction queue. Pre-execution process 22 retrieves a batch of transactions from cache process 23's transaction queue at predetermined intervals, verifies the retrieved transactions, and returns verified transactions to cache process 23. Cache process 23 can broadcast verified transactions to the master node and other slave nodes through communication process 27. Caching process 23 can also receive transactions from other nodes through communication process 27.

[0069] On the one hand, consensus process 24 can receive consensus proposals initiated by the master node through communication process 27 and reach consensus on blocks based on the consensus proposals. At the same time, consensus process 24 can send information such as the pre-execution read / write sets and pre-execution order of the multiple transactions in the block included in the consensus proposal to management process 26. During the consensus process, consensus process 24 can return consensus messages to the master node through communication process 27 and receive consensus results from the master node through communication process 27. After consensus is successful, consensus process 24 can send the consensus results to management process 26.

[0070] On the other hand, management process 26 can concurrently group multiple transactions in a block based on their respective pre-execution read-write sets and pre-execution order, resulting in multiple transaction groups. These transaction groups are then assigned to computation processes 28, which can be multiple and can execute the transaction groups in parallel. When executing transactions, computation processes 28 can retrieve the state values of each variable in the transaction's read set from storage process 25. After each transaction group is executed, computation process 28 verifies the pre-execution write set based on the transaction group's execution results. If the verification passes, the blockchain status database in storage process 25 is updated based on the transaction group's execution results. If the verification fails, indicating malicious behavior by the master node, computation process 28 can notify management process 26, which then initiates a master change request to other slave nodes through consensus process 24 to replace the master node.

[0071] Finally, the management process 26 generates the block data of the block based on the transaction bodies of multiple transactions of the block, pre-execution read-write sets, execution read-write sets, grouping information and other information, and stores the block data in the block database in the storage process 25.

[0072] The following will refer to Figure 5 The flowchart of the method for executing a transaction shown in the figure describes the above process in detail. Figure 5 The figure shows the process of executing a block by a master node and any slave node. The master node includes at least a pre-execution process e11, a cache process e12, a consensus process e13, a management process e14, and a storage process e15. The slave node includes at least a consensus process e21, a management process e22, a computation process e23, and a storage process e24.

[0073] like Figure 5As shown, first, in step 501, pre-execution process e11 pre-executes multiple transactions belonging to block N, such as transactions Tx1-Tx6, to obtain pre-execution read-write sets corresponding to transactions Tx1-Tx6. In one embodiment, the pre-execution read-write set of a transaction includes a read set and a write set, wherein the read set includes key-value pairs of variables read when pre-executing the transaction, and the write set includes key-value pairs of variables written when pre-executing the transaction. In another embodiment, the read set of the pre-execution read-write set may include version numbers of variables read when pre-executing the transaction, and the write set may include version numbers of variables written. The state data of the blockchain's world state, for example, stores each written value of a variable and the version number corresponding to each written value. Therefore, by including the variable version number in the read-write set, the values read and written by the transaction can be determined.

[0074] If a single pre-execution process e11 pre-executes transactions Tx1-Tx6 serially, then after each pre-execution, it can directly transfer the pre-execution read-write set of each transaction to cache process e12, which then uses the pre-execution write set to update its stored world state. If multiple pre-execution processes e11 pre-execute transactions Tx1-Tx6 in parallel, then after each pre-execution, it is necessary to verify whether the read set of that transaction conflicts with other concurrently pre-executed transactions. For example, the pre-execution read set of transaction Tx2 includes variable A, and the pre-execution write set includes variable B. When pre-executing transaction Tx2, the value of variable A read is Va, and transaction Tx2 is pre-executed based on Va. After pre-executing transaction Tx2, the value of variable A in cache process e12 is verified. If the value of variable A is still Va, the pre-execution read-write set of transaction Tx2 can be stored in cache process e12, and the state value of variable B can be used to update the world state stored in cache process e12. If the value of variable A is no longer Va but becomes Vb, transaction Tx2 can be re-pre-executed based on Vb. It should be noted that in addition to verifying read-write conflicts by variable values, read-write conflicts can also be verified by variable version numbers.

[0075] Next, in step 503, consensus process e13 obtains the pre-execution read / write sets corresponding to transactions Tx1-Tx6 from cache process e12, generates a consensus proposal for block N, and broadcasts this consensus proposal to the slave nodes. This consensus proposal includes the pre-execution read / write sets corresponding to transactions Tx1-Tx6. Optionally, this consensus proposal may also include information such as the order in which transactions Tx1-Tx6 were pre-executed by pre-execution process e11 and the hash values of transactions Tx1-Tx6. After receiving this consensus proposal, the slave nodes work with the master node to reach consensus on block N. Specifically, the slave nodes can return a consensus message to the master node and receive the consensus result sent by the master node. (After consensus is successful, the slave node's consensus process e21 can send the consensus result to the management process e22.)

[0076] Then, in step 505, management process e14 obtains the pre-execution write set from the pre-execution read-write set obtained by pre-execution transactions Tx1-Tx6 from consensus process e13. While reaching consensus on block N, management process e14 concurrently updates the state database stored in storage process e15 based on the pre-execution write set. Specifically, management process e14 updates the state database using the latest state values of the variables in the pre-execution write sets of transactions Tx1-Tx6. For example, the pre-execution write set of transaction Tx1 includes variable C, while the pre-execution write sets of transactions Tx2-Tx6 do not involve variable C. Therefore, the state database can be directly updated using the state value of variable C in the pre-execution write set of transaction Tx1. For another example, the pre-execution write sets of transactions Tx3 and Tx5 both include variable D, and the pre-execution order of transaction Tx3 is after transaction Tx5. Therefore, the state value of variable D in the pre-execution write set of transaction Tx3 is the latest state value of variable D. The state database can be updated using the state value of variable D in the pre-execution write set of transaction Tx3.

[0077] In step 507, after completing the update to the state database in storage process e15, management process e14 performs a write operation on block N. Specifically, management process e14 generates a block header and block body for block N and stores them in the block database in storage process e15. The block body, for example, includes the transaction body and receipt data for transactions Tx1 through Tx6. The block header may include data such as the state root, receipt root, and transaction root.

[0078] In step 509, the slave node's consensus process e21 can send the received consensus proposal, including information such as the pre-execution read / write sets and pre-execution order of transactions Tx1 through Tx6, to the management process e22. During the consensus process, the management process e22 concurrently groups transactions Tx1 through Tx6 in the block based on the pre-execution read / write sets and pre-execution order, resulting in multiple transaction groups. This ensures that transactions in different transaction groups do not have conflicting variables, and that the transaction order within the same transaction group is consistent with the pre-execution order. Each transaction group is then executed in parallel. For example, transactions Tx1, Tx2, and Tx4 are group a, while transactions Tx3, Tx5, and Tx6 are group b.

[0079] Then, the management process e22 can assign multiple transaction groups, such as transaction group a and transaction group b, to multiple computing processes e23, and the multiple computing processes e23 can execute transaction group a and transaction group b in parallel at the same time, execute the transactions in transaction group a serially in the pre-execution order, and execute the transactions in transaction group b serially in the pre-execution order.

[0080] In step 511, after computing process e23 completes each transaction group, it uses the transaction group's write set to update the state database stored in storage process e24 and sends the transaction group's execution results to management process e22. For example, after transaction group a completes, computing process e23 can obtain the latest state values of all variables involved in the execution write sets of transactions Tx1, Tx2, and Tx4 and use these latest state values to update the state database. Finally, in step 513, after computing process e23 on the slave node completes the update of the state database in storage process e24, management process e22 performs a write operation on block N. The specific process of the write operation is similar to that of the master node and will not be further described here.

[0081] It should be noted that although the operations of the methods of the embodiments of this specification are described in a specific order in the above embodiments, this does not require or imply that the operations must be performed in this specific order, or that all of the operations shown must be performed to achieve the desired results. On the contrary, the steps depicted in the flowcharts can be performed in a different order. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step, and / or a step can be broken down into multiple steps.

[0082] Corresponding to the aforementioned method embodiment for executing transactions in a blockchain, this specification also provides an embodiment of an apparatus for executing transactions in a blockchain.

[0083] like Figure 6 As shown, Figure 66 is a block diagram of a master node in a blockchain according to an exemplary embodiment of the present specification. The blockchain also includes slave nodes. The master node may include: a pre-execution process 601 and a consensus process 602.

[0084] The pre-execution process 601 is used to pre-execute multiple first transactions of the first block to obtain a pre-execution read-write set of each first transaction.

[0085] The consensus process 602 is configured to generate a first consensus proposal for the first block and broadcast the first consensus proposal to the slave nodes, where the first consensus proposal includes a pre-execution read-write set of each first transaction.

[0086] In the process of consensus process 602 generating a first consensus proposal, pre-execution process 601 pre-executes multiple second transactions of a second block, where the first block precedes the second block.

[0087] In some embodiments, the first consensus proposal further includes a pre-execution process 601 pre-executing a pre-execution order of the plurality of first transactions.

[0088] In some other embodiments, the first consensus proposal further includes identifiers of multiple first transactions.

[0089] like Figure 7 As shown, Figure 7 This is a block diagram of a slave node in a blockchain according to an exemplary embodiment of the present specification. The blockchain also includes a master node. The slave node may include: a consensus process 701, a management process 702, and a computing process 703.

[0090] Among them, the consensus process 701 is used to receive the first consensus proposal broadcast by the master node, which includes the pre-execution read-write sets of each first transaction obtained by the master node pre-executing multiple first transactions of the first block, obtain the pre-execution read-write sets of each first transaction, and reach consensus on the first block with the master node.

[0091] The management process 702 is used to group multiple first transactions in parallel to obtain multiple transaction groups during the consensus process on the first block.

[0092] The computing process 703 is used to execute multiple transaction groups in parallel.

[0093] In other implementations, the slave node further includes: a storage process (not shown in the figure).

[0094] Among them, the storage process is used to store the status database of the blockchain.

[0095] In the process of executing multiple transaction groups, the computing process 703 updates the state database stored in the storage process in parallel based on the execution write sets of the completed transaction groups.

[0096] In other embodiments, the computation process updates the state database stored by the storage process by obtaining the pre-execution writeset corresponding to any transaction group after executing the group. Verification is then performed on the pre-execution writeset obtained after executing the group. If verification succeeds, the blockchain state database is updated based on the execution writeset of the transaction group.

[0097] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of one or more embodiments of this specification. A person of ordinary skill in the art can understand and implement them without paying any creative work.

[0098] One or more embodiments of this specification also provide a computer-readable storage medium, which stores a computer program that can be used to execute the above Figures 2 to 5 Any embodiment provides a method for executing transactions in a blockchain.

[0099] One or more embodiments of this specification further provide a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the above-mentioned Figures 2 to 5 Any embodiment provides a method for executing transactions in a blockchain.

[0100] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but 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. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0101] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered 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 devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0102] 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 exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle 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.

[0103] 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-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 "comprise", "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 clearly listed, or also includes elements inherent to such 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 particular order.

[0104] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as 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 an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0105] 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 flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce 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 flowcharts and / or block diagrams. 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.

[0106] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work 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 The function specified in one or more boxes.

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

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

[0109] 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. Memory is an example of a computer-readable medium.

[0110] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (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 transitory media such as modulated data signals and carrier waves.

[0111] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0112] 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, and the like 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 via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0113] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer 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 integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0114] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A method for executing a transaction in a blockchain, the blockchain comprising a master node and slave nodes, the master node comprising a pre-execution process and a first consensus process, the method being executed by the master node, the method comprising: The pre-execution process pre-executes a plurality of first transactions of the first block to obtain a pre-execution read-write set of each first transaction; The first consensus process generates a first consensus proposal for the first block, and broadcasts the first consensus proposal to the slave nodes, so that the slave nodes reach a consensus on the first block; The first consensus proposal includes a pre-executed read-write set of each of the first transactions; wherein, during the consensus process on the first block, the slave node groups the plurality of first transactions in parallel to obtain a plurality of transaction groups, and executes the plurality of transaction groups in parallel; During the process of the first consensus process generating the first consensus proposal, the pre-execution process pre-executes multiple second transactions of a second block; the first block is before the second block.

2. The method according to claim 1, wherein the first consensus proposal further comprises the pre-execution process pre-executing a pre-execution order of the plurality of first transactions.

3. The method of claim 1 , wherein the first consensus proposal further comprises identifications of the plurality of first transactions.

4. The method according to claim 1, wherein The master node also includes a cache process, which stores state data of the latest world state of the blockchain; After the pre-execution process pre-executes the plurality of first transactions, the process further includes: The pre-execution process submits the pre-execution read-write sets of each first transaction to the cache process; The cache process updates the state data of the stored world state according to the pre-execution write sets in the pre-execution read-write sets of the respective first transactions.

5. The method according to claim 4, wherein the pre-execution process pre-executes the plurality of second transactions of the second block, comprising: The pre-execution process reads the pre-execution read sets of the plurality of second transactions from the cache process, and pre-executes the plurality of second transactions using the read pre-execution read sets.

6. The method according to claim 4, wherein: The first consensus process generates a first consensus proposal for the first block, including: The first consensus process obtains at least the pre-execution read-write sets of the respective first transactions from the cache process, and generates the first consensus proposal based on the pre-execution read-write sets of the respective first transactions.

7. The method according to claim 6, wherein: The master node further includes a first management process and a first storage process; the first storage process stores a state database of the blockchain; and the method further includes: The master node reaches consensus on the first block with the slave node through the first consensus process; The first management process obtains, from the first consensus process, a pre-execution write set in the pre-execution read-write set of each first transaction; During consensus on the first block, the first management process updates the state database of the blockchain stored by the first storage process based on the pre-execution write set in parallel.

8. The method according to claim 7, wherein: The method further comprises: During consensus on the first block and after the pre-execution process completes pre-execution of the second transaction, the first consensus process concurrently generates a second consensus proposal for the second block.

9. The method according to claim 8, wherein The method further comprises: During the consensus process on the first block, and after the first consensus process broadcasts the second consensus proposal to the slave node, the master node reaches a consensus on the second block with the slave node through the first consensus process.

10. A method for executing a transaction in a blockchain, the blockchain comprising a master node and a slave node, the slave node comprising a second consensus process, a second management process, and a computation process, the method being executed by the slave node, the method comprising: The slave node receives the first consensus proposal broadcast by the master node through the second consensus process; The first consensus proposal includes a pre-execution read-write set of each first transaction obtained by the master node pre-executing multiple first transactions of the first block; The second management process obtains the pre-execution read-write set of each first transaction from the second consensus process, and the second consensus process and the slave node reach a consensus on the first block; During consensus on the first block, the second management process groups the multiple first transactions in parallel to obtain multiple transaction groups, and sends the multiple transaction groups to the computing process; The computing process executes the plurality of transaction groups in parallel.

11. The method according to claim 10, wherein: The slave node further includes a second storage process; the second storage process stores a state database of the blockchain; and the method further includes: During the execution of the multiple transaction groups, the computing process updates the state database stored in the second storage process in parallel based on the execution write sets of the completed transaction groups.

12. The method according to claim 11, wherein The computing process updates the state database stored by the second storage process in the following manner: After executing any transaction group, the computing process obtains the pre-execution write-set corresponding to the transaction group from the second management process, and verifies the pre-execution write-set corresponding to the transaction group using the execution write-set obtained after executing the transaction group. If the verification passes, the state database of the blockchain is updated according to the execution write set of the transaction group.

13. The method according to claim 11, wherein Before the computing process executes the plurality of transaction groups, the method further includes: The calculation process determines whether the state data of the previous block of the first block has been stored; If the state data of the previous block of the first block is stored, the computing process reads the read sets of the multiple transaction groups from the state database stored by the second storage process.

14. A master node in a blockchain, the blockchain further comprising slave nodes, the master node comprising: A pre-execution process, configured to pre-execute multiple first transactions of the first block to obtain a pre-execution read-write set for each first transaction; A consensus process, configured to generate a first consensus proposal for the first block, and broadcast the first consensus proposal to the slave nodes, so that the slave nodes reach a consensus on the first block; The first consensus proposal includes a pre-executed read-write set of each of the first transactions; wherein, during the consensus process on the first block, the slave node groups the plurality of first transactions in parallel to obtain a plurality of transaction groups, and executes the plurality of transaction groups in parallel; In the process of the consensus process generating the first consensus proposal, the pre-execution process pre-executes multiple second transactions of the second block; the first block is before the second block.

15. The master node according to claim 14, wherein the first consensus proposal further comprises the pre-execution process pre-executing a pre-execution order of the plurality of first transactions.

16. The masternode according to claim 14, wherein the first consensus proposal further comprises identifications of the plurality of first transactions.

17. A slave node in a blockchain, the blockchain further comprising a master node, the slave node comprising: A consensus process, configured to receive a first consensus proposal broadcast by the master node; The first consensus proposal includes a pre-execution read-write set of each first transaction obtained by the master node pre-executing multiple first transactions of the first block; obtaining the pre-execution read-write set of each first transaction and reaching a consensus on the first block with the master node; a management process configured to group the plurality of first transactions in parallel to obtain a plurality of transaction groups during a consensus process on the first block; A computing process is used to execute the multiple transaction groups in parallel.

18. The slave node according to claim 17, wherein: The slave node also includes: A storage process for storing the state database of the blockchain; In the process of executing the multiple transaction groups, the computing process updates the state database stored by the storage process in parallel based on the execution write sets of the completed transaction groups.

19. The slave node according to claim 18, wherein: The computing process updates the state database stored by the storage process in the following manner: After executing any transaction group, obtain the pre-execution write set corresponding to the transaction group, and use the execution write set obtained after executing the transaction group to verify the pre-execution write set corresponding to the transaction group; If the verification passes, the state database of the blockchain is updated according to the execution write set of the transaction group.

20. 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 13.

21. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 13 is implemented.

Images