CN114663235A

CN114663235A - Method and device for executing transaction in block chain

Info

Publication number: CN114663235A
Application number: CN202210312555.4A
Authority: CN
Inventors: 谢桂鲁; 邓福喜
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-11-04
Filing date: 2021-11-04
Publication date: 2022-06-24
Also published as: CN113744063B; CN113744063A

Abstract

The present specification provides a method and an apparatus for executing transactions in a blockchain, which are applied to a blockchain node, according to the method, receiving a plurality of first transactions belonging to a first block, and pre-executing the plurality of first transactions to obtain a pre-executed read-write set of the plurality of first transactions; the pre-execution read-write set is used for grouping the plurality of first transactions; during pre-execution of the plurality of first transactions, consensus is performed on the second blocks in parallel; the second block is a block before the first block.

Description

Method and device for executing transaction in block chain

The present application is a divisional application of the invention patent application entitled "method and apparatus for performing transactions in Block chain" with application number 2021112968579 filed on 04/11/2021.

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method and apparatus for performing transactions in a blockchain.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and the data blocks are guaranteed to be not falsified and forged in a cryptographic mode. When the block chain node executes a plurality of transactions in the block, the transaction execution speed can be increased by executing the transactions in parallel. However, transactions that invoke smart contracts are generally not able to be executed in parallel because the accessed variables cannot be predicted prior to execution.

Disclosure of Invention

One or more embodiments of the present disclosure provide a method and apparatus for performing transactions in a blockchain.

According to a first aspect, there is provided a method for performing transactions in a blockchain, applied to a blockchain node, comprising:

receiving a plurality of first transactions belonging to a first block, and performing pre-execution on the plurality of first transactions to obtain a pre-execution read-write set of the plurality of first transactions; the pre-execution read-write set is used for grouping the plurality of first transactions;

during pre-execution of the plurality of first transactions, consensus is performed on the second blocks in parallel; the second block is a block before the first block.

According to a second aspect, there is provided an apparatus for performing transactions in a blockchain, deployed at a blockchain node, comprising:

the system comprises a pre-execution module, a pre-execution module and a pre-execution module, wherein the pre-execution module is used for receiving a plurality of first transactions belonging to a first block, and pre-executing the plurality of first transactions to obtain a pre-execution read-write set of the plurality of first transactions; the pre-execution read-write set is used for grouping the plurality of first transactions;

a consensus module for performing consensus on the second blocks in parallel during the pre-execution of the plurality of first transactions; the second block is a block before the first block.

According to a third aspect, there is provided a computer readable storage medium, storing a computer program which, when executed by a processor, implements the method of any of the first aspects above.

According to a fourth aspect, there is provided a computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of any of the first aspects when executing the program.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects:

in the method and the apparatus for executing a transaction in a block chain provided in the embodiments of the present specification, a transaction execution flow of a block is divided into at least a pre-execution flow line and a consensus flow line, and the transaction execution flow is completed through the pre-execution flow line and the consensus flow line in parallel, so that a block output time corresponding to the block is shortened, a transaction execution efficiency is improved, and a utilization rate of computing resources and a performance of the block chain system are also improved. 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 transaction with inconsistent execution and pre-execution variable states is determined, the execution of the transaction is rolled back, and the transaction is re-executed after all transactions are processed, so that the state consistency of each node after a plurality of transactions are executed is ensured. By the scheme, in the condition that the probability of different transactions accessing the same variable is small, the number of the rolled back transactions is small, and therefore the transaction execution speed is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a schematic diagram illustrating a process for performing transactions in a blockchain provided in the related art;

FIG. 2A is a block chain architecture diagram illustrating an exemplary embodiment of the present description;

FIG. 2B is a diagram illustrating a process for performing transactions in a blockchain, according to an exemplary embodiment;

fig. 3A is a block diagram of a node of a block chain provided in an embodiment of the present description;

fig. 3B is another block diagram of a node of a block chain provided in an embodiment of the present specification;

FIG. 4 is a flow diagram illustrating a method for performing transactions in a blockchain in accordance with an exemplary embodiment of the present description;

fig. 5 is a block diagram of an apparatus for performing transactions in a blockchain, according to an example embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without making any creative effort shall fall within the protection scope of the present specification.

Fig. 1 is a schematic diagram illustrating a process for performing transactions in a blockchain according to the related art.

As shown in fig. 1, in the related art, generally, transactions in a block chain are performed on a block-by-block basis. For example, the transaction execution process of block N is completed first, and the transaction execution process of block N +1 is completed. The transaction execution flow of any one block may include at least a consensus phase, an execution phase, and a block write phase. That is, for any block, the transaction belonging to the block is obtained first, then the consensus operation is performed for the block, and after the consensus is successful, the block is executed. And finally, performing persistence operation to write the execution result of the block into the state database, thereby completing the block writing of the block. Since this process completes each execution stage of the execution flow block by block, the block-out time is the sum of the time consumed by each execution stage, for example, the block-out time of block N shown in fig. 1 is t 1. Therefore, the per-second Transaction (TPS) index in the blockchain is low, the utilization rate of computing resources is low, and the performance of the blockchain system is difficult to improve.

In other related art, in order to increase a per second transaction execution (TPS) index in a blockchain, it is necessary to increase the execution speed of a transaction. For this reason, the execution speed of the transaction can be increased by executing the transaction in parallel in the blockchain node. In one embodiment, the blockchain nodes may execute transactions in parallel by multiple processes in a single machine, and in another embodiment, the blockchain nodes may be deployed in a server cluster and execute transactions in parallel by multiple servers. Generally, for transfer transactions, the block link points first divide the transactions into transaction groups according to the account accessed by the transaction, and the same account is not accessed between each transaction group, so that each transaction group can be executed in parallel. However, when a smart contract is invoked in a transaction, the variables accessed in the transaction cannot be predicted prior to execution of the transaction, and thus multiple transactions cannot be efficiently grouped, i.e., transactions cannot be executed in parallel.

Fig. 2A shows a block chain architecture diagram applied in the embodiment of the present specification.

As shown in fig. 2A, the block chain includes, for example, 6 nodes from node 1 to node 6. The lines between the nodes schematically represent P2P (Peer-to-Peer) connections. All the nodes store the full-amount accounts, namely the states of all the blocks and all the accounts. Wherein each node in the blockchain generates the same state in the blockchain by performing the same transaction, each node in the blockchain storing the same state database. Each node 1 may receive transactions from clients and initiate consensus proposals to the respective slave nodes, including information such as the number of transactions in the tile to be blocked (e.g., tile B1) and the order of submission of the respective transactions. After the node in the blockchain successfully agrees on the consensus proposal, the nodes may perform the transactions according to the order of submission in the consensus proposal, thereby generating block B1.

It is to be appreciated that the blockchain shown in fig. 2A is merely exemplary, and that the embodiments of the present specification are not limited to application to the blockchain shown in fig. 2A, and may also be applied to a blockchain system including slices, for example.

In addition, although fig. 2A shows that the blockchain includes 6 nodes, the embodiments of the present specification are not limited thereto, and may include other numbers of nodes. Specifically, the nodes included in the block chain can meet the Byzantine Fault Tolerance (BFT) requirement. The byzantine fault tolerance requirement can be understood as that byzantine nodes can exist in a block chain, and the block chain does not show the byzantine behavior to the outside. Generally, some Byzantine Fault-tolerant algorithms require the number of nodes to be greater than 3f +1, where f is the number of Byzantine nodes, such as the practical Byzantine Fault-tolerant algorithm pbft (practical Byzantine Fault tolerance).

The embodiment of the specification provides a scheme for executing transactions in parallel in the blockchain shown in fig. 2A, which can effectively improve TPS in the blockchain.

The embodiment of the specification provides a scheme for executing transactions in a blockchain, which can effectively improve TPS in the blockchain.

Fig. 2B is a diagram illustrating a process for performing transactions in a blockchain, according to an example embodiment.

As shown in FIG. 2B, the transactional execution flow of the block may be divided into 4 pipelines, a pre-execution pipeline, a consensus pipeline, a transactional execution pipeline, and a write block pipeline, the 4 pipelines executing in parallel. For each pipeline, the respective transactions of the blocks may be processed in sequence in the order of the blocks. For each block, the block may be processed in the corresponding pipeline in sequence, in the order of pre-execution, consensus, execution, and writing the block. The process of different pipelines can be completed through different threads, and the process of different pipelines can also be completed through different devices.

Specifically, after the node of the blockchain acquires the multiple transactions of the block N, before the multiple transactions of the block N are identified in common, the transactions of the block N need to be pre-executed on a pre-execution pipeline, so as to obtain pre-execution read-write sets corresponding to the transactions, where the pre-execution read-write sets may be used to group the multiple transactions of the block N. After completing the pre-execution of the individual transactions for block N, the plurality of transactions for block N +1 are then pre-executed on the pre-execution pipeline.

Meanwhile, during the pre-execution of each transaction of the block N, on the consensus pipeline, the blocks (e.g., the block N-1) before the block N may be consensus-made in parallel. After the consensus for block N-1 is completed, block N is then consensus-performed on the consensus pipeline.

Meanwhile, blocks preceding block N-1 (e.g., block N-2) may be executed in parallel on the execution pipeline during pre-execution of transactions for block N (i.e., during consensus for block N-1). Before block N-2 is executed, transactions of block N-2 need to be grouped based on pre-executed read-write sets corresponding to the transactions of block N-2, so as to obtain multiple transaction groups, and inter-group transactions do not access the same variables. Thus, in executing block N-2, the various transaction groups may be executed in parallel. After block N-2 is completed, block N-1 is then executed on the execution pipeline.

Meanwhile, during the pre-execution of each transaction of block N (i.e. during the execution of block N-2), a block write operation may be performed on a block (e.g. block N-3) preceding block N-2 in parallel on the block write pipeline, i.e. the execution result obtained by executing block N-3 is written into the status database. After a write block operation is performed for block N-3, a write block operation is then performed for block N-2 on the write block pipeline.

Since the block transaction execution flow is divided into 4 pipelines and the blocks are executed through the 4 pipelines in parallel, the block output time corresponding to any one block is not the sum of the time consumed by each execution stage of the block, but the time consumed by the longest stage of the 4 stages. Taking the block N shown in fig. 2B as an example, the block N corresponds to the out-blocking time which is not the sum of t2, t3, t4 and t5, but is the maximum value t4 among t2, t3, t4 and t 5. Therefore, the block output time corresponding to the block is greatly shortened, the execution efficiency of the transaction is improved, and the utilization rate of computing resources and the performance of a block chain system are also improved.

Fig. 3A shows a structure diagram of any one node of a block chain provided in an embodiment of the present specification.

As shown in fig. 3A, the node includes a pre-execution module, a consensus module, and an execution module. The execution module further includes a grouping submodule, a plurality of execution submodules (schematically illustrated in the figure, execution submodule 3a1, execution submodule 3a2, and execution submodule 3A3), and a re-execution submodule, which is described in detail below.

After the node receives a plurality of transactions from the devices under the chain or other nodes, the pre-execution module pre-executes each transaction to obtain a 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, where the pre-execution read set may specifically be a key-value pair of a read variable generated in the process of pre-execution transaction, and the pre-execution write set may specifically be a key-value pair of a write variable generated in the process of pre-execution transaction. The consensus module initiates a consensus proposal to the consensus modules of other nodes of the blockchain according to the received transaction to determine a plurality of transactions to be included in the generated block, respective pre-execution readsets of the transactions and a submission sequence of the transactions.

After the consensus is successful, an execution module in the node may begin executing the plurality of transactions. Specifically, in the node, the grouping submodule firstly divides a plurality of transactions into a plurality of transaction groups according to the pre-execution read-write set, and conflict transactions do not exist among the transaction groups. The situation that there is a conflict transaction between two transaction groups generally includes the following situations: the transaction group 1 reads the variable 1, and the transaction group 2 writes the variable 1; the variable 1 is written into the transaction group 1, and the variable 1 is written into the transaction group 2; transaction group 1 reads variable 1 and writes variable 1, and transaction group 2 writes variable 1; transaction set 1 reads variable 1 and writes variable 1, transaction set 2 reads variable 1 and writes variable 1, and so on. Wherein if two transaction groups read the same variable it can be considered that no conflicting transactions exist. Typically, to simplify the scheme, the grouping sub-module may group multiple transactions as required by not having access to the same variables between the various transaction groups.

Thereafter, the plurality of execution sub-modules may execute the plurality of transaction groups in parallel. In the process of executing the transaction, each executing submodule generates an executing read-write set of the transaction, where the executing read-write set includes an executing read set and an executing write set, the executing read set may specifically be a key-value pair of a read variable generated in the process of executing the transaction, and the executing write set may specifically be a key-value pair of a written variable generated in the process of executing the transaction. And if the execution read set of the transaction is determined to be inconsistent with the pre-execution read set, rolling back the execution of the transaction, and re-executing the rolled-back transaction by the re-execution sub-modules after all transactions are processed and completed by each execution sub-module so as to ensure the correctness of the grouping.

The node may also receive a plurality of transactions from other nodes and a set of pre-executed reads and writes for the plurality of transactions generated by the other nodes. Similarly, the node may group the multiple transactions according to a pre-execution read-write set of the multiple transactions, execute the multiple transactions in parallel according to a grouping result, rollback the execution of the transaction if it is determined that the execution read-write set of the transaction is not consistent with the pre-execution read-write set, and re-execute the rolled-back transaction after the re-execution sub-modules complete all transactions after the processing of each execution sub-module.

Through the above process, each node may perform pre-execution on a plurality of transactions received by each node, and group the plurality of transactions based on a pre-execution read-write set obtained by the pre-execution, so as to execute the plurality of transactions in parallel. 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 transaction with inconsistent execution and pre-execution variable states is determined, the execution of the transaction is rolled back, and the transaction is re-executed after all transactions are processed, so that the state consistency of each node after a plurality of transactions are executed is ensured. By the scheme, in the condition that the probability of different transactions accessing the same variable is small, the number of the rolled back transactions is small, and therefore the transaction execution speed is improved. In addition, each node can execute a plurality of transaction groups in parallel and can further group other transactions in parallel, thereby further improving the transaction execution speed.

Fig. 3B shows another structure diagram of any one node of the block chain provided in the embodiment of the present specification.

As shown in fig. 3B, the node includes a pre-execution module, a consensus module, and an execution module. Wherein the consensus module further comprises a grouping submodule. The execution module further includes a validation submodule, a plurality of execution submodules (schematically illustrated as execution submodule 3B1, execution submodule 3B2, and execution submodule 3B3), and a re-execution submodule, which is described in detail below.

After the node receives a plurality of transactions from the devices under the chain or other nodes, the pre-execution module pre-executes each transaction to obtain a pre-execution read-write set of each transaction. The grouping submodule included in the consensus module may divide the plurality of transactions into a plurality of transaction groups according to the pre-execution read-write set of each transaction, and there is no conflict transaction between each transaction group.

The consensus module can also initiate consensus offers to the consensus modules of other nodes according to the received transactions so as to determine a plurality of transactions included in the block to be generated, a submission sequence of the transactions and transaction group information of a plurality of transaction groups obtained by dividing the transactions.

After the consensus is successful, execution modules in the node and the other respective nodes may begin executing the plurality of transactions. Specifically, in the node, the plurality of execution sub-modules may execute the plurality of transaction groups in parallel. And each execution submodule generates an execution read-write set of the transaction in the process of executing the transaction. And if the execution read set of the transaction is determined to be inconsistent with the pre-execution read set, rolling back the execution of the transaction, and re-executing the rolled-back transaction by the re-execution sub-modules after all transactions are processed and completed by each execution sub-module so as to ensure the correctness of the grouping.

The node may also receive a plurality of transactions and a set of pre-executed reads and writes for the plurality of transactions generated by other nodes from other nodes, and grouping information obtained by grouping the plurality of transactions by other nodes according to the set of pre-executed reads and writes for the plurality of transactions. Similarly, the node may execute a plurality of transactions in parallel according to the grouping result, and if it is determined that the execution read-write set of the transaction is inconsistent with the pre-execution read-write set, rollback is performed on the execution of the transaction, and the re-execution sub-modules re-execute the rolled-back transaction after all transactions are processed and completed by each execution sub-module. It should be noted that, in this case, the verification sub-module of the node may perform verification on the packet information while the respective execution sub-modules perform transactions, so as to verify the packet correctness of other nodes, that is, to verify whether the other nodes provide wrong packet information. Execution of the block may be stopped if it is verified that other nodes provide erroneous grouping information. If the grouping is verified to be correct, the re-execution sub-modules re-execute the rolled-back transaction after all the multiple transactions are processed and completed by each execution sub-module so as to ensure the correctness of the grouping.

Through the process, each node can perform pre-execution on a plurality of transactions received by each node, group the transactions based on the pre-execution read-write set obtained by the pre-execution, and send the transactions and the transaction group information for grouping the transactions to other nodes, so that other nodes can immediately start to perform the transactions in a plurality of transaction groups in parallel based on the transaction group information, and perform verification on the transaction group information while performing 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 transaction with inconsistent execution and pre-execution variable states is determined, the execution of the transaction is rolled back, and the transaction is re-executed after all transactions are processed, so that the state consistency of each node after a plurality of transactions are executed is ensured. By the scheme, in the condition that the probability of different transactions accessing the same variable is small, the number of the rolled back transactions is small, and therefore the transaction execution speed is improved.

As shown in fig. 4, fig. 4 is a flow chart illustrating a method of performing transactions in a blockchain, which may be applied in a blockchain node, according to an example embodiment. The block link point may be implemented as any computing, processing capable device, platform, server, or cluster of devices. The method comprises the following steps:

in step 401, a plurality of first transactions belonging to the first block are received and pre-executed to obtain a pre-executed read-write set of the plurality of first transactions.

In this embodiment, after receiving the first transactions belonging to the first block, the block node may first determine whether the pre-execution of the previous block of the first block has been completed, and if so, may directly pre-execute the first transactions belonging to the first block. If not, the pre-execution of the first transactions belonging to the first block may be performed after the pre-execution of the previous block of the first block is completed.

In one embodiment, the block link point may perform pre-execution on each transaction after receiving the transaction, resulting in a respective pre-executed read-write set for each transaction. After pre-execution of a plurality of received transactions is completed, the transactions and respective pre-execution read-write sets of the transactions are identified together to determine that a block to be generated comprises the transactions, a submission order of the transactions is determined, and consistency of the respective pre-execution read-write sets of the transactions at respective nodes is determined. In this case, the blockchain node may pre-execute each transaction based on the world state of the latest block to which each transaction corresponds. The set of pre-executed reads and writes is invisible to other transactions and does not change the world state. Since the blockchain node receives different transactions at different times, the latest block at the different times may be different blocks, and thus the transactions may correspond to the world states of the different blocks. For example, in the case of block chain nodes performing multiple blocks in a pipeline, the block chain node performs block B1 (assuming block B1 is the block before block B2) while performing transactions belonging to block B2 in advance, so that transactions performed in advance before block B1 is generated are performed in advance based on the world state corresponding to block B0 (assuming block B0 is the block before block B1), and transactions performed in advance after block B1 is generated are performed in advance based on the world state corresponding to block B1.

In another embodiment, the block link point may pre-execute each transaction of the plurality of transactions based on the world state corresponding to the same current latest block after receiving the plurality of transactions. In this case, the plurality of transactions are pre-executed based on the same world state, respectively.

Since the world state is not changed when each transaction is pre-executed, that is, there is no transaction conflict in the pre-execution of each transaction, the pre-execution of a plurality of transactions can be performed in parallel, thereby speeding up the pre-execution speed of the transaction.

The blockchain node obtains a respective pre-executed read-write set for each transaction after pre-executing each transaction of the plurality of transactions. In one embodiment, the pre-execution read-write set of any transaction includes a read set and a write set, wherein the read set includes key-value pairs (key-values) of variables read when the transaction is pre-executed and the write set includes key-value pairs of variables written when the transaction is pre-executed. In another embodiment, the read set of the pre-executed read/write set may include version numbers of variables read when the transaction is pre-executed, and the write set may include version numbers of variables written therein, where, for example, each written value of a variable and a version number corresponding to each written value are stored in the state database, so that the values read and written in the transaction may be determined by including the version numbers of the variables in the read/write set.

In the case of a contract invoked in a transaction, it is possible for a block link point to write a different variable depending on the value of the variable read during execution of the contract invoked for the transaction. For example, when the value of the read variable is 1, 10 is written to the variable a, when the value of the read variable is 2, 20 is written to the variable b, and so on. Thus, for a transaction that invokes a contract, the block link points must execute the transaction to determine the variables read and written for the transaction, and thus the read and write sets for the transaction. To this end, the node 1 obtains a pre-executed read-write set for each transaction by pre-executing each transaction of a plurality of transactions, the pre-executed process being substantially the same as the process of executing the transaction, except that the world state on which the transaction is based in the pre-executed transaction process is determined according to the preset rule as described above, and is not necessarily the world state at the time of executing the transaction, and the world state is not updated according to the result of the pre-executed transaction after the pre-executed transaction.

In step 403, during the pre-execution of the first transaction, the second block is identified in parallel.

In this embodiment, during the pre-execution of the plurality of first transactions of the first block, the second block may be identified in parallel. The second block may be any block before the first block, for example, if the first block is block N, the second block may be block N-1, or any block before block N-1.

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

For the second block, in particular, the second block comprises, for example, a plurality of second transactions, similar to the first block, in one implementation the node has performed in advance a pre-execution of the plurality of second transactions belonging to the second block. Therefore, the node can send the plurality of second transactions, the pre-execution read-write set of each second transaction and the submission sequence of the plurality of second transactions to other nodes for consensus.

In another implementation, the node may further group the second transactions according to a previously generated pre-execution read-write set of the second transactions to obtain a grouped result, and send the second transactions, the pre-execution read-write set of the second transactions, the grouped result of the second transactions, and a submission order of the second transactions to other nodes of the block chain for consensus.

The following example illustrates the case of accessing the same variable between two transaction groups as follows: the variable 1 is read by the transaction group 1, and the variable 1 is written into the transaction group 2; or, the transaction group 1 reads the variable 1 and writes the variable 1, and the transaction group 2 writes the variable 1; or, the transaction group 1 reads the variable 1 and writes the variable 1, and the transaction group 2 reads the variable 1 and writes the variable 1; or, the transaction group 1 reads the variable 1, and the transaction group 2 reads the variable 1; alternatively, transaction group 1 writes variable 1 and transaction group 2 writes variable 1. It will be appreciated that the above scenario is only a partial scenario, not all, of the access to the same variable between two transaction groups.

In this embodiment, after completing the transaction of the block previous to the first block, the first block may be executed by executing a plurality of transaction groups in parallel. Further optionally, the multiple transaction groups corresponding to the first block may be executed in parallel by multiple threads, or the multiple transaction groups corresponding to the first block may be distributed to multiple computing devices, so that the multiple computing devices execute the multiple transaction groups in parallel, thereby improving the efficiency of transaction execution.

Optionally, the third block may be executed in parallel in the process of consensus on the second block. The third block may be any block before the second block, for example, if the second block is block N-1, the third block may be block N-2, or any block before block N-2. In one implementation, the node has performed pre-execution on a plurality of third transactions belonging to the third block in advance, and based on a result of the pre-execution, the plurality of third transactions belonging to the third block are grouped to obtain a plurality of transaction groups corresponding to the third block, so that the plurality of transaction groups corresponding to the third block can be executed in parallel. In another implementation manner, the node may obtain a grouping result obtained by grouping a plurality of third transactions belonging to the third block, that is, a plurality of transaction groups corresponding to the third block. Wherein the grouping is based on a pre-execution read-write set of a plurality of previously generated third transactions before consensus is performed on the third block. A plurality of transaction sets corresponding to the third block may be executed in parallel. Specifically, the execution module in fig. 3A and 3B may execute the transactions in the third block as described above, and are not described herein again.

Optionally, in the process of executing the third block, the execution result corresponding to the block before the third block (which may be any one block before the third block) may also be written in the status database in parallel. For example, if the third block is block N-2, the block preceding the third block may be block N-3, or any one of the blocks preceding block N-3.

In the method for executing transaction in a block chain provided in the foregoing embodiment of the present specification, the transaction execution flow of the block is divided into at least the pre-execution pipeline and the consensus pipeline, and the transaction execution flow is completed through the pre-execution pipeline and the consensus pipeline in parallel, so that the block output time corresponding to the block is shortened, the transaction execution efficiency is improved, and the utilization rate of the computing resources and the performance of the block chain system are also improved.

On the basis, the inventor further finds that in the transaction execution flow of a block, the pre-execution process, the consensus process, the transaction execution process and the block writing process all have higher probability to become the stage with the longest time consumption in the transaction execution flow, so that the transaction execution flow of the block is further divided into at least 4 pipelines, namely a pre-execution pipeline, a consensus pipeline, a transaction execution pipeline and a block writing pipeline, and the transaction execution flow is completed through the pre-execution pipeline, the consensus pipeline, the transaction execution pipeline and the block writing pipeline in parallel, so that the block output time corresponding to the block can be further shortened, the transaction execution efficiency is further improved, and the utilization rate of computing resources and the performance of a block chain system are also improved.

It should be noted that although in the above embodiments, the operations of the methods of the embodiments of the present specification have been described in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

In correspondence with the aforementioned method embodiments for performing transactions in a blockchain, embodiments of an apparatus for performing transactions in a blockchain are also provided.

As shown in fig. 5, fig. 5 is a block diagram of an apparatus for performing transactions in a blockchain, the apparatus being deployed at a blockchain node, according to an exemplary embodiment of the present disclosure, and the apparatus may include: a pre-execution module 501 and a consensus module 502.

The pre-execution module 501 is configured to receive a plurality of first transactions belonging to a first block, pre-execute the plurality of first transactions to obtain a pre-execution read-write set of the plurality of first transactions, where the pre-execution read-write set is used to group the plurality of first transactions.

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

In some embodiments, the consensus module 502 is configured to: and sending the plurality of second transactions belonging to the second block, the previously generated pre-execution read-write set of each second transaction and the submission sequence of the plurality of second transactions to other nodes of the block chain for consensus.

In other embodiments, the consensus module 502 is configured to: grouping the second transactions according to a pre-execution read-write set which is generated in advance and belongs to the second block to obtain a grouping result; and sending the plurality of second transactions, the pre-execution read-write sets of the plurality of second transactions, the grouping result and the submission sequence of the plurality of second transactions to other nodes of the blockchain for consensus.

In other embodiments, the apparatus may further comprise: an execution module (not shown).

The execution module is used for executing a third block in parallel in the process of identifying the second block, wherein the third block is a block before the second block.

In other embodiments, the apparatus may further comprise: a write block module (not shown).

And the block writing module is used for writing the execution results corresponding to the blocks before the third block into the state database in parallel in the process of executing the third block.

In other embodiments, pre-execution module 501 is configured to: and pre-executing a plurality of first transactions in parallel based on the world states of the latest blocks corresponding to the first transactions respectively.

In other embodiments, the execution module is configured to: grouping the plurality of third transactions based on a pre-execution read-write set of the plurality of third transactions which are generated in advance and belong to a third block to obtain a grouping result; the plurality of third transactions are performed in parallel according to the grouping result.

In other embodiments, the execution module is configured to: obtaining a grouping result obtained by grouping a plurality of third transactions belonging to a third block; the grouping is performed based on a pre-execution read-write set of a plurality of previously generated third transactions before consensus is performed on the third block; the plurality of third transactions are performed in parallel according to the grouping result.

It should be understood that the above-mentioned device may be preset in the block chain node, and may also be loaded in the block chain node by means of downloading or the like. The corresponding modules in the above-described apparatus may cooperate with modules in the blockchain node to implement a scheme for performing transactions in the blockchain.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of one or more embodiments of the present specification. One of ordinary skill in the art can understand and implement it without inventive effort.

One or more embodiments of the present specification also provide a computer-readable storage medium storing a computer program, where the computer program is operable to execute the method for executing a transaction in a blockchain provided in any one of the embodiments of fig. 2B to 4.

One or more embodiments of the present specification also provide a computing device, including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement a method for executing a transaction in a block chain as provided in any one of fig. 2B to 4.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

It will be further appreciated by those of ordinary skill in the art that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. Among other things, the software modules may be located in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The above-mentioned embodiments, objects, technical solutions and advantages of the present application are described in further detail, it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present application, and are not intended to limit the scope of the present application, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present application should be included in the scope of the present application.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., 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 which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, 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 a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 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 medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the system embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims

1. A method for performing transactions in a blockchain, the method being applied to a blockchain node, the method comprising:

2. The method of claim 1, wherein the consensus for the second tile comprises:

and sending the plurality of second transactions belonging to the second block, the previously generated pre-execution read-write sets of each second transaction and the submission sequence of the plurality of second transactions to other nodes of the block chain for consensus.

3. The method of claim 1, wherein the consensus for the second tile comprises:

grouping a plurality of second transactions according to a pre-execution read-write set of the plurality of second transactions which are generated in advance and belong to the second block to obtain a grouping result;

sending the plurality of second transactions, the pre-executed 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 of claim 1, further comprising:

executing a third block in parallel in the process of identifying the second block; the third block is a block before the second block.

5. The method of claim 4, further comprising:

and in the process of executing the third block, writing the execution results corresponding to the blocks before the third block into a state database in parallel.

6. The method of claim 1, wherein the pre-executing the plurality of first transactions comprises: pre-executing the plurality of first transactions in parallel.

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

8. The method of claim 1, wherein said pre-executing the plurality of first transactions comprises: and pre-executing the plurality of first transactions in parallel based on the world states of the latest blocks corresponding to the first transactions respectively.

9. The method of claim 4, wherein the executing the third block comprises:

grouping a plurality of third transactions belonging to the third block based on a pre-execution read-write set of the plurality of previously generated third transactions to obtain a grouping result;

performing the plurality of third transactions in parallel according to the grouping result.

10. The method of claim 4, wherein the executing the third block comprises:

obtaining grouping results obtained by grouping a plurality of third transactions belonging to the third block; the grouping is performed based on a pre-execution read-write set of the plurality of previously generated third transactions before the third block is identified;

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

12. The method of claim 11, wherein after performing the completing of the plurality of third transactions, further comprising: the rolled back third transaction is re-executed.

13. The method of claim 12, wherein said re-executing the rolled back third transaction comprises: the rolled back third transaction is re-executed serially.

14. The method of claim 13, wherein the serially re-executing the rolled back third transaction comprises: re-executing the rolled-back third transaction based on the latest world state after executing the plurality of third transactions.

15. The method of claim 9 or 10, wherein said performing the plurality of third transactions in parallel according to the grouped result comprises:

sending the plurality of third transactions in groups to a plurality of computing devices according to the grouping result, so that the plurality of computing devices execute the plurality of third transactions in parallel in groups.

16. An apparatus for performing transactions in a blockchain, the apparatus being deployed at a blockchain link point, the apparatus comprising:

17. The apparatus of claim 16, wherein the consensus module is configured to:

18. The apparatus of claim 16, wherein the consensus module is configured to:

19. The apparatus of claim 16, further comprising:

the execution module is used for executing a third block in parallel in the process of consensus on the second block; the third block is a block before the second block.

20. The apparatus of claim 19, further comprising:

and the block writing module is used for writing the execution result corresponding to the block before the third block into a state database in parallel in the process of executing the third block.

21. The apparatus of claim 16, wherein the pre-execution module is configured to: and pre-executing the plurality of first transactions in parallel based on the world states of the latest blocks corresponding to the first transactions respectively.

22. The apparatus of claim 19, wherein the execution module is configured to:

grouping a plurality of third transactions belonging to the third block based on a pre-execution read-write set of the plurality of previously generated third transactions to obtain a grouping result; performing the plurality of third transactions in parallel according to the grouping result.

23. The apparatus of claim 19, wherein the execution module is configured to:

obtaining grouping results obtained by grouping a plurality of third transactions belonging to the third block; the grouping is performed based on a pre-execution read-write set of the plurality of previously generated third transactions before the third block is identified; performing the plurality of third transactions in parallel according to the grouping result.

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

25. A computing device comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any of claims 1-15.