Method and apparatus for executing transactions in a blockchain

Abstract

This specification provides a method and apparatus for executing transactions in a blockchain, which are applied to a blockchain node. According to this method, a plurality of first transactions belonging to a first block are received, and the plurality of first transactions are pre-executed to obtain pre-execution read-write sets of the plurality of first transactions; the pre-execution read-write sets are used to group the plurality of first transactions; during the pre-execution of the plurality of first transactions, consensus is performed on a second block in parallel; the second block is a block before the first block.

Description

[0001] This application is a divisional application of the invention patent application with the application number 2021112968579 and the title "Method and Device for Executing Transactions in a Blockchain", which was filed on November 4, 2021. Technical Field

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

[0003] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chain-like data structure in a sequential connection manner according to the time sequence, and the data blocks are guaranteed to be tamper-proof and non-forgeable in a cryptographic manner. When blockchain nodes execute multiple transactions in a block, the transaction execution speed can be accelerated by executing the transactions in parallel. However, since the variables accessed by a transaction that invokes a smart contract cannot be predicted before execution, they usually cannot be executed in parallel. Summary of the Invention

[0004] One or more embodiments of this specification provide a method and device for executing transactions in a blockchain.

[0005] According to a first aspect, there is provided a method for executing transactions in a blockchain, which is applied to a blockchain node and includes:

[0006] Receiving a plurality of first transactions belonging to a first block, pre-executing the plurality of first transactions to obtain pre-execution read-write sets of the plurality of first transactions; the pre-execution read-write sets are used to group the plurality of first transactions;

[0007] During the pre-execution of the plurality of first transactions, consensus is performed on a second block in parallel; the second block is a block before the first block.

[0008] According to a second aspect, there is provided a device for executing transactions in a blockchain, which is deployed on a blockchain node and includes:

[0009] A pre-execution module, configured to receive a plurality of first transactions belonging to a first block, pre-execute the plurality of first transactions to obtain pre-execution read-write sets of the plurality of first transactions; the pre-execution read-write sets are used to group the plurality of first transactions;

[0010] A consensus module, configured to perform consensus on a second block in parallel during the pre-execution of the plurality of first transactions; the second block is a block before the first block.

[0011] According to a third aspect, a computer-readable storage medium is provided, where the storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of the above first aspects is implemented.

[0012] According to a fourth aspect, a computing device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the method described in any one of the above first aspects is implemented.

[0013] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0014] The method and device for executing transactions in the blockchain provided in the embodiments of this specification divide the transaction execution process of a block into at least a pre-execution pipeline and a consensus pipeline, and complete the transaction execution process through the pre-execution pipeline and the consensus pipeline in parallel, thereby shortening the block generation time corresponding to the block, improving the execution efficiency of transactions, and also improving the utilization rate of computing resources and the performance of the blockchain system. In addition, by comparing the execution read set and the pre-execution read set (or the execution read-write set and the pre-execution read-write set) of a transaction, transactions with inconsistent variable states during execution and pre-execution are determined, the execution of the transaction is rolled back, and the transaction is re-executed after all transactions are processed, ensuring the state consistency of each node after executing multiple transactions. Through this solution, in the case where the probability of different transactions accessing the same variable is small, the number of rolled-back transactions is small, thereby improving the transaction execution speed.

[0015] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0017] Figure 1 is a schematic diagram of a process for executing transactions in a blockchain provided by the related art;

[0018] Figure 2A is a blockchain architecture diagram shown according to an exemplary embodiment of this specification;

[0019] Figure 2B is a schematic diagram of a process for executing transactions in a blockchain shown according to an exemplary embodiment of this specification;

[0020] Figure 3A It is a structural diagram of a node of the blockchain provided by an embodiment of this specification;

[0021] Figure 3B It is another structural diagram of a node of the blockchain provided by an embodiment of this specification;

[0022] Figure 4 It is a flowchart of a method for executing transactions in a blockchain shown according to an exemplary embodiment of this specification;

[0023] Figure 5 A block diagram of a device for executing transactions in a blockchain shown according to an exemplary embodiment of this specification. Detailed implementation manners

[0024] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification with reference to the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0025] Figure 1 It is a schematic diagram of the process of executing transactions in a blockchain provided by the related art.

[0026] As Figure 1 shown, generally speaking, in the related art, when executing transactions in a blockchain, it is completed block by block. For example, first complete the transaction execution process of block N, and then complete the transaction execution process of block N+1, etc. The transaction execution process of any block can at least include a consensus stage, an execution stage, and a block writing stage. That is, for any block, first obtain the transactions belonging to the block, then perform a consensus operation on the block. After the consensus is successful, execute the block. Finally, perform a persistence operation to write the execution result of executing the block into the state database, thereby completing the block writing of the block. Since this process completes each execution stage of the execution process block by block, the block generation time is the sum of the time consumed by each execution stage. For example, Figure 1 the block generation time of block N shown is t1. Therefore, the transaction per second (TPS) index in the blockchain is low, the utilization rate of computing resources is low, and it is difficult to improve the performance of the blockchain system.

[0027] In some related technologies, to improve the Transactions Per Second (TPS) metric in a blockchain, it is necessary to accelerate the execution speed of transactions. To this end, in a blockchain node, the execution speed of transactions can be accelerated by executing transactions in parallel. In one implementation, a blockchain node can execute transactions in parallel through multiple processes in a single machine. In another implementation, a blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers. Generally, for transfer transactions, a blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions, and different transaction groups do 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 that multiple transactions cannot be effectively grouped, and thus transactions cannot be executed in parallel.

[0028] Figure 2A The figure shows a blockchain architecture diagram to which the embodiments of the present specification are applied.

[0029] As Figure 2A shown in the figure, the blockchain includes, for example, a total of 6 nodes from node 1 to node 6. The connections between the nodes schematically represent P2P (Peer to Peer) connections. The full ledger is stored on these nodes, that is, the states of all blocks and all accounts are stored. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transactions, and each node in the blockchain stores the same state database. Each node 1 can receive transactions from the client and initiate 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 information such as the submission order of each transaction. After the nodes in the blockchain reach a successful consensus on the consensus proposal, each node can execute the multiple transactions according to the submission order in the consensus proposal, thereby generating block B1.

[0030] It can be understood that Figure 2A the blockchain shown is only exemplary, and the embodiments of the present specification are not limited to being applied to Figure 2A the blockchain shown. For example, it can also be applied to a blockchain system including sharding.

[0031] In addition, Figure 2AAlthough it is shown in the figure that the blockchain includes 6 nodes, the embodiments of this specification are not limited thereto, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the requirements of Byzantine Fault Tolerance (BFT). The so-called Byzantine Fault Tolerance requirements can be understood as that Byzantine nodes can exist inside the blockchain, but the blockchain does not exhibit Byzantine behavior externally. Generally, in some Byzantine Fault Tolerance algorithms, it is required that the number of nodes is greater than 3f + 1, where f is the number of Byzantine nodes. For example, the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0032] Embodiments of this specification provide a solution for Figure 2A executing transactions in parallel in the blockchain shown, which can effectively improve the TPS in the blockchain.

[0033] Embodiments of this specification provide a solution for executing transactions in the blockchain, which can effectively improve the TPS in the blockchain.

[0034] Figure 2B It is a schematic diagram of the process of executing transactions in a blockchain shown according to an exemplary embodiment.

[0035] As Figure 2B shown, the transaction execution process of the block can be divided into 4 pipelines: a pre-execution pipeline, a consensus pipeline, a transaction execution pipeline, and a block writing pipeline. These 4 pipelines execute in parallel. For each pipeline, the transactions of each block can be processed in sequence according to the order of the blocks. For each block, the block can be processed in the corresponding pipeline in sequence according to the order of pre-execution, consensus, execution, and block writing. Different threads or different devices can be used to complete the processes of different pipelines.

[0036] Specifically, after the nodes of the blockchain obtain multiple transactions of block N, before consensus on the multiple transactions of block N, it is necessary to first perform pre-execution on each transaction of block N on the pre-execution pipeline to obtain the pre-execution read-write sets corresponding to each transaction, and the pre-execution read-write sets can be used to group the multiple transactions of block N. After completing the pre-execution of each transaction of block N, the pre-execution of multiple transactions of block N + 1 is then performed on the pre-execution pipeline.

[0037] At the same time, during the pre-execution of each transaction of block N, on the consensus pipeline, consensus can be performed in parallel on the blocks before block N (such as block N - 1). After completing the consensus on block N - 1, consensus on block N is then performed on the consensus pipeline.

[0038] Meanwhile, during the pre-execution of each transaction in block N (i.e., during the consensus process for block N-1), on the execution pipeline, blocks before block N-1 (such as block N-2) can be executed in parallel. It should be noted that before executing block N-2, based on the pre-execution read-write sets corresponding to each transaction in block N-2, the transactions in block N-2 need to be grouped to obtain multiple transaction groups, such that transactions between groups do not access the same variables. In this way, when executing block N-2, each transaction group can be executed in parallel. After completing the execution of block N-2, on the execution pipeline, block N-1 is then executed.

[0039] Meanwhile, during the pre-execution of each transaction in block N (i.e., during the execution of block N-2), on the write block pipeline, write block operations can be performed in parallel for blocks before block N-2 (such as block N-3), that is, writing the execution results obtained from executing block N-3 into the state database. After performing the write block operation for block N-3, on the write block pipeline, the write block operation for block N-2 is then performed.

[0040] Since in this embodiment, the transaction execution process of a block is divided into 4 pipelines and the blocks are executed in parallel through 4 pipelines, therefore, the block production time corresponding to any block is not the sum of the time consumed in each execution stage of this block, but the duration of the stage with the longest time consumption among these 4 stages. Taking Figure 2B block N shown as an example, the block production time corresponding to block N is not the sum of t2, t3, t4, and t5, but the maximum value t4 among t2, t3, t4, and t5. Thus, the block production time corresponding to the block is greatly shortened, the execution efficiency of transactions is improved, and the utilization rate of computing resources and the performance of the blockchain system are also improved.

[0041] Figure 3A FIG. shows a structural diagram of any node of the blockchain provided by the embodiment of the present specification.

[0042] As Figure 3A shown, this node includes a pre-execution module, a consensus module, and an execution module. Among them, the execution module further includes a grouping sub-module, multiple execution sub-modules (the execution sub-module 3A1, the execution sub-module 3A2, and the execution sub-module 3A3 are schematically shown in the figure), and a re-execution sub-module, which will be specifically described below.

[0043] After receiving multiple transactions from off-chain devices or other nodes, the pre-execution module of the node pre-executes each transaction to obtain the pre-execution read-write set of each transaction. The pre-execution read-write set includes a pre-execution read set and a pre-execution write set. The pre-execution read set can be a key-value pair of a read variable generated in the process of pre-execution of the transaction, and the pre-execution write set can be a key-value pair of a written variable generated in the process of pre-execution of the transaction. The consensus module initiates a consensus proposal to the consensus modules of other nodes of the blockchain based on the received transactions to determine the multiple transactions included in the generated block, the pre-execution read set of each transaction, and the submission order of the multiple transactions.

[0044] After the consensus is successful, the execution module in the node can start to execute the multiple transactions. Specifically, in this node, the grouping submodule first divides the multiple transactions into multiple transaction groups according to the pre-execution read-write set, and there are no conflicting transactions between the transaction groups. Among them, the situation where there are conflicting transactions between two transaction groups generally includes the following situations: transaction group 1 reads variable 1, and transaction group 2 writes variable 1; transaction group 1 writes variable 1, and transaction group 2 writes variable 1; transaction group 1 reads variable 1 and writes variable 1, and transaction group 2 writes variable 1; transaction group 1 reads variable 1 and writes variable 1, and transaction group 2 reads variable 1 and writes variable 1, and so on. Among them, if two transaction groups read the same variable, it can be considered that there is no conflicting transaction. Usually, in order to simplify the solution, the grouping submodule can group multiple transactions according to the requirement that the same variables are not accessed between transaction groups.

[0045] Afterwards, multiple execution submodules can execute the multiple transaction groups in parallel. In the process of executing transactions, each execution submodule generates an execution read-write set of the transaction, wherein the execution read-write set includes an execution read set and an execution write set. The execution read set can specifically be a key-value pair of a read variable generated in the process of executing the transaction, and the execution write set can specifically be a key-value pair of a written variable generated in the process of executing the transaction. If it is determined that the execution read set of the transaction is inconsistent with the pre-execution read set, the execution of the transaction is rolled back, and the re-execution submodule re-executes the rolled-back transaction after each execution submodule completes processing all transactions to ensure the correctness of the grouping.

[0046] The node may also receive multiple transactions and pre-execution read-write sets of the multiple transactions generated by the other nodes from other nodes. Similarly, the node may group the multiple transactions according to the pre-execution read-write sets of the multiple transactions, execute the multiple transactions in parallel according to the grouping results, and if it is determined that the execution read-write set of the transaction is inconsistent with the pre-execution read-write set, the execution of the transaction is rolled back, and the re-execution submodule re-executes the rolled-back transaction after all the execution submodules have processed all the transactions.

[0047] Through the above process, each node can pre-execute multiple transactions received by itself, group the multiple transactions based on the pre-execution read-write sets obtained from the pre-execution, and thus execute the multiple transactions in parallel. Additionally, by comparing the execution read set of a transaction with the pre-execution read set (or the execution read-write set with the pre-execution read-write set), transactions with inconsistent variable states during execution and pre-execution are determined, the execution of such transactions is rolled back, and the transactions are re-executed after all transactions have been processed, ensuring the state consistency of each node after executing multiple transactions. Through this solution, in cases where the probability of different transactions accessing the same variable is low, the number of rolled-back transactions is small, thereby improving the transaction execution speed. Additionally, while each node executes multiple transaction groups in parallel, it can further group multiple other transactions in parallel, thus further improving the transaction execution speed.

[0048] Figure 3B FIG. shows another structural diagram of any node of the blockchain provided in the embodiments of the present specification.

[0049] As Figure 3B shown, the node includes a pre-execution module, a consensus module, and an execution module. Among them, the consensus module further includes a grouping sub-module. The execution module further includes a verification sub-module, multiple execution sub-modules (execution sub-module 3B1, execution sub-module 3B2, and execution sub-module 3B3 are schematically shown in the figure), and a re-execution sub-module, which will be specifically described below.

[0050] After the node receives multiple transactions from off-chain devices or other nodes, the pre-execution module pre-executes each transaction to obtain the pre-execution read-write sets of each transaction. The grouping sub-module included in the consensus module can divide the multiple transactions into multiple transaction groups according to the pre-execution read-write sets of each transaction, and there are no conflicting transactions between the transaction groups.

[0051] The consensus module can also initiate a consensus proposal to the consensus modules of other nodes according to the received transactions, so as to determine the multiple transactions included in the generated block, the submission order of the multiple transactions, and the transaction group information of the multiple transaction groups obtained by dividing the multiple transactions.

[0052] After successful consensus, the execution modules in this node and other nodes can start to execute the multiple transactions. Specifically, in this node, multiple execution sub-modules can execute the multiple transaction groups in parallel. During the execution of a transaction by each execution sub-module, an execution read-write set of the transaction is generated. If it is determined that the execution read set of the transaction is inconsistent with the pre-execution read set, the execution of the transaction is rolled back, and the re-execution sub-module re-executes the rolled-back transaction after all transactions have been processed by each execution sub-module to ensure the correctness of grouping.

[0053] The node can also receive multiple transactions from other nodes, the pre-execution read-write sets of the multiple transactions generated by other nodes, and grouping information obtained by other nodes grouping the multiple transactions according to the pre-execution read-write sets of the multiple transactions. Similarly, the node can execute multiple transactions in parallel according to the grouping result. If it is determined that the execution read-write set of the transaction is inconsistent with the pre-execution read-write set, the execution of the transaction is rolled back, and the re-execution sub-module re-executes the rolled-back transaction after all the execution sub-modules have processed all the transactions. It should be noted that in this case, the verification sub-module of the node can verify the grouping information while the execution sub-modules execute the transactions, so as to verify the grouping correctness of other nodes, that is, to verify whether other nodes provide incorrect grouping information. If it is verified that other nodes provide incorrect grouping information, the execution of the block can be stopped. If the grouping is verified to be correct, the re-execution sub-module re-executes the rolled-back transaction after all the execution sub-modules have processed all the multiple transactions to ensure the correctness of the grouping.

[0054] Through the above process, each node can pre-execute multiple transactions received by itself, group the multiple transactions based on the pre-execution read-write sets obtained from the pre-execution, and send the multiple transactions and the transaction group information for grouping the multiple transactions to other nodes, so that each of the other nodes can immediately start executing the transactions in the multiple transaction groups in parallel and verify the transaction group information while executing the transactions. In addition, by comparing the execution read set and the pre-execution read set (or the execution read-write set and the pre-execution read-write set) of the transaction, the transactions with inconsistent variable states during execution and pre-execution are determined, the execution of the transaction is rolled back, and the transaction is re-executed after all the transactions have been processed, ensuring the state consistency of each node after executing multiple transactions. Through this solution, in the case where the probability of different transactions accessing the same variable is small, the number of rolled-back transactions is small, thereby improving the transaction execution speed.

[0055] As Figure 4 shown, Figure 4 FIG. is a flowchart of a method for executing transactions in a blockchain according to an exemplary embodiment. The method can be applied to a blockchain node. The blockchain node can be implemented as any device, platform, server, or device cluster with computing and processing capabilities. The method includes the following steps:

[0056] In step 401, receive multiple first transactions belonging to a first block, and pre-execute the multiple first transactions to obtain pre-execution read-write sets of the multiple first transactions.

[0057] In this embodiment, after the blockchain node receives multiple first transactions belonging to the first block, it can first determine whether the pre-execution of the previous block of the first block has been completed. If it has been completed, it can directly perform pre-execution on the multiple first transactions belonging to the first block. If it has not been completed, it can wait for the pre-execution of the previous block of the first block to be completed and then perform pre-execution on the multiple first transactions belonging to the first block.

[0058] In one implementation, the blockchain node can perform pre-execution on each transaction after receiving it, obtaining the respective pre-execution read-write sets of each transaction. After completing the pre-execution of multiple received transactions, consensus is performed on the multiple transactions and the respective pre-execution read-write sets of each transaction to determine that the block to be generated includes the multiple transactions, determine the submission order of the multiple transactions, and determine the consistency of the respective pre-execution read-write sets of each transaction at each node. In this case, the blockchain node can perform pre-execution on each transaction based on the world state of the latest block corresponding to each transaction. The pre-executed read-write set is not visible to other transactions, and the pre-executed read-write set does not change the world state. Since the blockchain node receives different transactions at different times, the latest blocks at these different times may be different blocks, so the multiple transactions may correspond to the world states of different blocks. For example, in the case where the blockchain node executes multiple blocks in a pipeline, while the blockchain node is pre-executing the transactions belonging to block B2, it also executes block B1 (assuming block B1 is the block before block B2). Thus, the transactions pre-executed before generating block B1 are pre-executed based on the world state corresponding to block B0 (assuming block B0 is the block before block B1), and the transactions pre-executed after generating block B1 are pre-executed based on the world state corresponding to block B1.

[0059] In another implementation, the blockchain node can perform pre-execution on each of the multiple transactions after receiving the multiple transactions, based on the world state corresponding to the same current latest block. In this case, the multiple transactions are pre-executed based on the same world state.

[0060] Since the world state is not changed when pre-executing each transaction, that is, there will be no transaction conflicts in the pre-execution of each transaction. Therefore, the pre-execution of multiple transactions can be performed in parallel, thereby accelerating the speed of transaction pre-execution.

[0061] After a blockchain node pre-executes each of multiple transactions, it obtains the pre-execution read-write sets of the respective transactions. In one implementation, the pre-execution read-write set of any transaction includes a read set and a write set. The read set includes key-value pairs of variables read during the pre-execution of the transaction, and the write set includes key-value pairs of variables written during the pre-execution of the transaction. In another implementation, the read set of the pre-execution read-write set may include the version numbers of the variables read during the pre-execution of the transaction, and the write set may include the version numbers of the variables written. Wherein, in the state database, for example, each written value of the variable and the version number corresponding to each written value are stored. Thus, by including the version number of the variable in the read-write set, the values read and written by the transaction can be determined.

[0062] In the case of calling a contract in a transaction, during the process of the blockchain node executing the contract called by the transaction, it may write different variables according to the values of the variables read. For example, when the value of the variable read is 1, write 10 to variable a, when the value of the variable read is 2, write 20 to variable b, and so on. Therefore, for a transaction that calls a contract, the blockchain node must execute the transaction to determine the variables read and written by the transaction, so as to obtain the read-write set of the transaction. For this purpose, Node 1 pre-executes each of multiple transactions to obtain the pre-execution read-write set of each transaction. The process of this pre-execution is basically the same as the process of executing a transaction. The difference is that the world state based on during the pre-execution of the transaction is determined according to the preset rules as described above, and it is not necessarily the world state at the time of executing the transaction. After pre-executing the transaction, the world state is not updated according to the result of the pre-execution transaction.

[0063] In step 403, during the pre-execution of the first transaction, consensus is performed on the second block in parallel.

[0064] In this embodiment, during the pre-execution of multiple first transactions of the first block, consensus can be performed on the second block in parallel. Wherein, the second block can be any block before the first block. For example, if the first block is block N, the second block can be block N - 1, or any block before block N - 1.

[0065] In this embodiment, after consensus is performed on the previous block of the first block, consensus can be performed on the first block. Optionally, after obtaining the pre-execution read-write sets of multiple first transactions, before, during, or after performing consensus on the multiple first transactions, the multiple first transactions can be grouped based on the pre-execution read-write sets of the multiple first transactions to obtain multiple transaction groups, so that transactions in different transaction groups do not access the same variables.

[0066] For the second block, specifically, the second block includes multiple second transactions. Similarly to the first block, in one implementation, the node has pre-executed the multiple second transactions belonging to the second block in advance. Thus, the node can send the multiple second transactions, the pre-execution read-write sets of each second transaction, and the submission order of the multiple second transactions to other nodes for consensus.

[0067] In another implementation, the node can also group the multiple second transactions according to the pre-execution read-write sets of the multiple second transactions generated previously to obtain a grouping result, and send the multiple second transactions, the pre-execution read-write sets of the multiple second transactions, the grouping result of the multiple second transactions, and the submission order of the multiple second transactions to other nodes of the blockchain for consensus.

[0068] The following examples list the situations where two transaction groups access the same variable: Transaction group 1 reads variable 1, and transaction group 2 writes variable 1; or, transaction group 1 reads and writes variable 1, and transaction group 2 writes variable 1; or, transaction group 1 reads and writes variable 1, and transaction group 2 reads and writes variable 1; or, transaction group 1 reads variable 1, and transaction group 2 reads variable 1; or, transaction group 1 writes variable 1, and transaction group 2 writes variable 1. It can be understood that the above situations are only partial situations where two transaction groups access the same variable, not all situations.

[0069] In this embodiment, after executing the transactions of the previous block of the first block, the first block can be executed by executing multiple transaction groups in parallel. Further optionally, the multiple transaction groups corresponding to the first block can be executed in parallel by multiple threads, or the multiple transaction groups corresponding to the first block can be distributed to multiple computing devices to enable the multiple computing devices to execute the multiple transaction groups in parallel, thereby improving the efficiency of transaction execution.

[0070] Optionally, during the process of reaching a consensus on the second block, the third block can be executed in parallel. Here, the third block can be any block before the second block. For example, if the second block is block N-1, the third block can be block N-2, or any block before block N-2. In one implementation, the node has pre-executed multiple third transactions belonging to the third block in advance, and based on the results of the pre-execution, grouped the multiple third transactions belonging to the third block to obtain multiple transaction groups corresponding to the third block. Therefore, multiple transaction groups corresponding to the third block can be executed in parallel. In another implementation, the node can obtain the grouping result of grouping multiple third transactions belonging to the third block, that is, multiple transaction groups corresponding to the third block. Here, the grouping is based on the pre-execution read-write sets of multiple third transactions generated in advance before reaching a consensus on the third block. Multiple transaction groups corresponding to the third block can be executed in parallel. Specifically, it can be achieved through Figure 3A and Figure 3B The execution module in executes multiple transactions in the third block as described above, which will not be elaborated here.

[0071] Optionally, during the process of executing the third block, the execution results corresponding to the blocks before the third block (which can be any block before the third block) can also be written into the state database in parallel. For example, if the third block is block N-2, the block before the third block can be block N-3, or any block before block N-3.

[0072] The method for executing transactions in the blockchain provided by the above embodiments of this specification divides the transaction execution process of the block into at least a pre-execution pipeline and a consensus pipeline, and completes the transaction execution process in parallel through the pre-execution pipeline and the consensus pipeline, thereby shortening the block production time corresponding to the block, improving the execution efficiency of transactions, and also improving the utilization rate of computing resources and the performance of the blockchain system.

[0073] On this basis, the inventor further found that in the transaction execution process of a block, the pre-execution process, the consensus process, the transaction execution process, and the block writing process are all likely to be the stages with the longest time consumption in this transaction execution process. Therefore, further dividing the transaction execution process of the block into at least 4 pipelines, namely a pre-execution pipeline, a consensus pipeline, a transaction execution pipeline, and a block writing pipeline, and completing the transaction execution process in parallel through the pre-execution pipeline, the consensus pipeline, the transaction execution pipeline, and the block writing pipeline can further shorten the block production time corresponding to the block, further improve the execution efficiency of transactions, and also improve the utilization rate of computing resources and the performance of the blockchain system.

[0074] It should be noted that although in the above embodiments, the operations of the method of the embodiments of this specification are described in a specific order, this does not require or imply that these operations must be performed in that specific order, or that all the shown operations must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can change the execution order. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step for execution, and / or one step can be decomposed into multiple steps for execution.

[0075] Corresponding to the foregoing method embodiments for executing transactions in a blockchain, this specification also provides embodiments of an apparatus for executing transactions in a blockchain.

[0076] As Figure 5 shown, Figure 5 FIG. is a block diagram of an apparatus for executing transactions in a blockchain shown according to an exemplary embodiment of this specification. The apparatus is deployed in a blockchain node and may include: a pre-execution module 501 and a consensus module 502.

[0077] Among them, the pre-execution module 501 is configured to receive a plurality of first transactions belonging to a first block, perform pre-execution on the plurality of first transactions, and obtain pre-execution read-write sets of the plurality of first transactions, where the pre-execution read-write sets are used to group the plurality of first transactions.

[0078] The consensus module 502 is configured to, during the process of performing pre-execution on the plurality of first transactions, perform consensus on a second block in parallel, where the second block is the block before the first block.

[0079] In some embodiments, the consensus module 502 is configured to: send a plurality of second transactions belonging to the second block, pre-execution read-write sets of each of the previously generated second transactions, and the submission order of the plurality of second transactions to other nodes of the blockchain for consensus.

[0080] In other embodiments, the consensus module 502 is configured to: group the plurality of second transactions according to the pre-execution read-write sets of the plurality of second transactions belonging to the second block generated previously to obtain a grouping result; send the plurality of second transactions, the pre-execution read-write sets of the plurality of second transactions, the grouping result, and the submission order of the plurality of second transactions to other nodes of the blockchain for consensus.

[0081] In other embodiments, the apparatus may further include: an execution module (not shown in the figure).

[0082] Among them, the execution module is configured to, during the process of performing consensus on the second block, execute a third block in parallel, where the third block is the block before the second block.

[0083] In other embodiments, the apparatus may further include: a write block module (not shown in the figure).

[0084] Among them, the write block module is used to write the execution results corresponding to the blocks before the third block into the state database in parallel during the execution of the third block.

[0085] In some other embodiments, the pre-execution module 501 is configured to: pre-execute multiple first transactions in parallel based on the world state of the latest block corresponding to each first transaction.

[0086] In some other embodiments, the execution module is configured to: group multiple third transactions belonging to the third block based on the pre-execution read-write sets of the multiple third transactions generated previously to obtain a grouping result; and execute the multiple third transactions in parallel according to the grouping result.

[0087] In some other embodiments, the execution module is configured to: obtain the grouping result obtained by grouping multiple third transactions belonging to the third block; the grouping is performed based on the pre-execution read-write sets of the multiple third transactions generated previously before consensus on the third block; and execute the multiple third transactions in parallel according to the grouping result.

[0088] It should be understood that the above device can be preset in the blockchain node in advance, or can be loaded into the blockchain node by means of downloading, etc. The corresponding modules in the above device can cooperate with the modules in the blockchain node to implement the solution for executing transactions in the blockchain.

[0089] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial descriptions of the method embodiments. The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solutions of one or more embodiments of this specification. Those of ordinary skill in the art can understand and implement without creative efforts.

[0090] One or more embodiments of this specification also provide a computer-readable storage medium, which stores a computer program, and the computer program can be used to execute the above Figures 2B to 4 method for executing transactions in the blockchain provided by any of the embodiments.

[0091] One or more embodiments of this specification also provide a computing device, including a memory and a processor, where the memory stores executable code, and when the processor executes the executable code, the above Figures 2B to 4A method for executing a transaction in a blockchain provided by any embodiment.

[0092] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple. For related parts, reference can be made to the partial description of the method embodiments.

[0093] The specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0094] Those of ordinary skill in the art should further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those of ordinary skill in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application. Among them, the software module can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the technical field.

[0095] The specific implementation manners described above further elaborate on the purpose, technical solution, and beneficial effects of this application. It should be understood that the above is only the specific implementation manner of this application and is not used to limit the protection scope of this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included in the protection scope of this application.

[0096] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many method flow improvements today can be regarded as direct improvements to hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented using a hardware entity module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is an integrated circuit whose logical function is determined by the user programming the device. Designers can program themselves to "integrate" a digital system onto a single PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL). There is not only one type of HDL, but many types, 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 currently are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply performing a little logical programming on the method flow using the above-mentioned several hardware description languages and programming it into the integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0097] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same functions. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0098] The systems, devices, modules, or units illustrated in the above embodiments can be specifically 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 development of future computer technologies, the computers implementing the functions of the above embodiments can be, for example, personal computers, laptop computers, in-vehicle human-machine interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0099] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, 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 among the execution orders of numerous steps and does not represent the only execution order. When the actual device or terminal product is executed, it may be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, product or device comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, it does not exclude the existence of additional identical or equivalent elements in the process, method, product or device comprising the said elements. For example, when terms such as first and second are used to denote names, they do not denote any particular order.

[0100] For the convenience of description, when describing the above device, it is divided into various modules according to functions for separate description. 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 implementing the same function can be realized 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, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings or direct couplings or communication connections shown or discussed with each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

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

[0102] These computer program instructions can 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, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions specified in one or more processes and / or blocks Figure 1 in one or more processes and / or blocks Figure 1 specified in the block or blocks.

[0103] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are performed on the computer or other programmable device to generate a computer-implemented process, thereby providing steps for implementing the functions specified in one or more processes and / or blocks Figure 1 in one or more processes and / or blocks Figure 1 specified in the block or blocks.

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

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

[0106] Computer-readable media includes both permanent and non-permanent, removable and non-removable media implemented by any method or technology for storing information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile discs (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 accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0107] Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

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

[0109] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and reference can be made to the corresponding parts of the method embodiments for related content. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

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

Claims

1. A method for executing transactions in a blockchain, applied to a blockchain node, the method comprising: Receiving a plurality of first transactions belonging to a first block, pre-executing the plurality of first transactions to obtain pre-execution read-write sets of the plurality of first transactions; The pre-execution read-write sets are used to group the plurality of first transactions, so as to execute the first transactions according to the grouping after the consensus on the first block is successful; wherein, the consensus on the first block includes the consensus on the pre-execution read-write sets; During the pre-execution of the plurality of first transactions, consensus is performed on a second block in parallel; the second block is the block before the first block.

2. The method according to claim 1, wherein Performing the consensus on the second block includes: Sending a plurality of second transactions belonging to the second block, pre-execution read-write sets of respective previously generated second transactions, and the submission order of the plurality of second transactions to other nodes of the blockchain for consensus.

3. The method according to claim 1, wherein Performing the consensus on the second block includes: Grouping the plurality of second transactions according to pre-execution read-write sets of the plurality of second transactions belonging to the second block generated previously to obtain a grouping result; Sending the plurality of second transactions, the pre-execution read-write sets of the plurality of second transactions, the grouping result, and the submission order of the plurality of second transactions to other nodes of the blockchain for consensus.

4. The method according to claim 1, wherein It further includes: During the consensus on the second block, a third block is executed in parallel; The third block is the block before the second block.

5. The method according to claim 4, wherein, It further includes: During the execution of the third block, the execution results corresponding to the blocks before the third block are written into the state database in parallel.

6. The method according to claim 1, wherein The pre-execution of the plurality of first transactions includes: pre-executing the plurality of first transactions in parallel.

7. The method according to claim 1, wherein The pre-execution of the plurality of first transactions includes: pre-executing each of the first transactions based on the world state of the latest block corresponding to each first transaction.

8. The method according to claim 1, wherein, The pre-execution of the plurality of first transactions includes: pre-executing the plurality of first transactions in parallel based on the world state of the latest block corresponding to each first transaction.

9. The method according to claim 4, wherein The execution of the third block includes: Grouping the plurality of third transactions based on pre-execution read-write sets of the plurality of third transactions belonging to the third block generated previously to obtain a grouping result; Executing the plurality of third transactions in parallel according to the grouping result.

10. The method according to claim 4, wherein, The execution of the third block includes: Obtaining a grouping result obtained by grouping a plurality of third transactions belonging to the third block; the grouping is performed based on pre-execution read-write sets of the plurality of third transactions generated previously before the consensus on the third block; Executing the plurality of third transactions in parallel according to the grouping result.

11. The method according to claim 9 or 10, wherein, For any third transaction, if the execution read-write set obtained after executing the third transaction is inconsistent with the pre-execution read-write set of the third transaction, roll back the execution of the third transaction.

12. The method according to claim 11, wherein, After the execution of the plurality of third transactions is completed, it further includes: re-executing the rolled-back third transactions.

13. The method according to claim 12, wherein, The re-execution of the rolled-back third transactions includes: re-executing the rolled-back third transactions serially.

14. The method according to claim 13, wherein, Said serially re - executing the rolled - back third transactions includes: re - executing the rolled - back third transactions based on the latest world state after the execution of the plurality of third transactions is completed.

15. The method according to claim 9 or 10, wherein, Said executing the plurality of third transactions in parallel according to the grouping result includes: Distributing the plurality of third transactions to a plurality of computing devices by groups according to the grouping result, so that the plurality of computing devices execute the plurality of third transactions in parallel by groups.

16. A device for executing transactions in a blockchain, deployed in a blockchain node, the device includes: A pre - execution module, configured to receive a plurality of first transactions belonging to a first block, perform pre - execution on the plurality of first transactions, and obtain pre - execution read - write sets of the plurality of first transactions; The pre - execution read - write sets are used to group the plurality of first transactions, so as to execute the first transactions according to the grouping after the consensus on the first block is successful; wherein, the consensus on the first block includes the consensus on the pre - execution read - write sets; A consensus module, configured to perform consensus on a second block in parallel during the pre - execution of the plurality of first transactions; the second block is the block before the first block.

17. The apparatus according to claim 16, wherein, The consensus module is configured to: Send a plurality of second transactions belonging to the second block, pre - execution read - write sets of each of the previously generated second transactions, and the submission order of the plurality of second transactions to other nodes of the blockchain for consensus.

18. The apparatus according to claim 16, wherein, The consensus module is configured to: Group the plurality of second transactions according to the pre - execution read - write sets of the plurality of second transactions belonging to the second block generated previously to obtain a grouping result; Send the plurality of second transactions, the pre - execution read - write sets of the plurality of second transactions, the grouping result, and the submission order of the plurality of second transactions to other nodes of the blockchain for consensus.

19. The apparatus according to claim 16, wherein, It further includes: An execution module, configured to execute a third block in parallel during the consensus on the second block; The third block is the block before the second block.

20. The apparatus according to claim 19, wherein, It further includes: A write - block module, configured to write the execution results corresponding to the blocks before the third block into a state database in parallel during the execution of the third block.

21. The device according to claim 16, wherein, The pre - execution module is configured to: perform pre - execution on the plurality of first transactions in parallel based on the world state of the latest block corresponding to each first transaction.

22. The apparatus according to claim 19, wherein The execution module is configured to: Group the plurality of third transactions based on the pre - execution read - write sets of the plurality of third transactions belonging to the third block generated previously to obtain a grouping result; execute the plurality of third transactions in parallel according to the grouping result.

23. The device according to claim 19, wherein, The execution module is configured to: Obtain the grouping result obtained by grouping the plurality of third transactions belonging to the third block; the grouping is performed based on the pre - execution read - write sets of the plurality of third transactions generated previously before the consensus on the third block; Execute the plurality of third transactions in parallel according to the grouping result.

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

25. 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-15 is implemented.

Images