CN113744062B

CN113744062B - Method for performing transactions in a blockchain, blockchain node and blockchain

Info

Publication number: CN113744062B
Application number: CN202111296856.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-09-02
Anticipated expiration: 2041-11-04
Also published as: CN113744062A

Abstract

The present specification provides a method of performing transactions in a blockchain, blockchain nodes and blockchains. The block chain comprises a first node and a second node, wherein the first node and the second node are any two nodes in the block chain respectively, and the method comprises the following steps: the first node pre-executes the received multiple first transactions to obtain a pre-executed read-write set of each first transaction, and sends the multiple first transactions and the pre-executed read-write sets thereof to the second node; and the second node groups the first transactions based on the pre-execution read-write sets of the first transactions, and executes the first transactions in parallel according to the grouping result.

Description

Method for performing transactions in a blockchain, blockchain node and blockchain

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method for performing transactions in a blockchain, a blockchain node, and 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 specification provide a method of performing transactions in a blockchain, a blockchain node, and a blockchain.

According to a first aspect, there is provided a method of performing a transaction in a blockchain, the blockchain including a first node and a second node, the first node and the second node being any two nodes in the blockchain, respectively, the method including:

the first node pre-executes the received multiple first transactions to obtain a pre-executed read-write set of each first transaction, and sends the multiple first transactions and the pre-executed read-write sets thereof to the second node;

the second node groups the first transactions based on the pre-execution read-write sets of the first transactions, and executes the first transactions in parallel according to the grouping result.

According to a second aspect, there is provided a method of performing a transaction in a blockchain, the blockchain including a first node and a second node, the first node and the second node being any two nodes in the blockchain, respectively, the method being applied to the second node; the method comprises the following steps:

receiving a plurality of first transactions sent by the first node and a pre-execution read-write set of the first transactions; wherein the pre-executed read-write set of the first transactions is obtained by the first node pre-executing the received first transactions;

grouping the first transactions based on the pre-execution read-write sets of the first transactions, and executing the first transactions in parallel according to the grouping result.

According to a third aspect, there is provided a node in a blockchain, the node comprising:

a receiving unit, configured to receive a plurality of first transactions and a pre-execution read-write set of the plurality of first transactions; wherein the pre-execution read-write set of the first transactions is obtained by pre-executing the first transactions;

a grouping unit to group the plurality of first transactions based on a set of pre-executed reads and writes for the plurality of first transactions;

an execution unit to execute the plurality of first transactions in parallel according to a result of the grouping.

According to a fourth aspect, a block chain is provided, which includes a first node and a second node, where the first node and the second node are any two nodes in the block chain respectively;

the first node is used for pre-executing a plurality of received first transactions, obtaining a pre-execution read-write set of each first transaction, and sending the first transactions and the pre-execution read-write sets thereof to the second node;

the second node is used for grouping the first transactions based on the pre-execution read-write sets of the first transactions and executing the first transactions in parallel according to grouping results.

According to a fifth 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 or second aspects described above.

According to a sixth 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 one of the first or second 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 transactions in a blockchain provided by the embodiments of the present specification, each node in the blockchain groups a plurality of transactions based on the same pre-execution read-write set, executes transactions of a plurality of transaction groups in parallel based on the same world state, and processes transactions whose transaction execution results are different from the pre-execution results by using the same method, and finally, the world states obtained by each node are consistent. In the case where there are fewer conflicting transactions among the plurality of transactions and the master node is not repugnant, the execution speed of the transactions in the blockchain can be increased.

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 block chain architecture diagram applied in an embodiment of the present disclosure;

fig. 2 is a structural diagram of any two nodes of a block chain provided in an embodiment of the present specification;

FIG. 3 is a flow diagram illustrating a method of performing transactions in a blockchain according to an exemplary embodiment of the present description;

fig. 4 is an architecture diagram illustrating one block link point in accordance with an exemplary embodiment of the present description.

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 skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Fig. 1 is a block chain architecture diagram applied in the embodiment of the present disclosure.

In fig. 1, 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 is responsible for receiving different transactions from different off-link devices (e.g., clients) and initiating consensus proposals to other 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 each transaction. After the node in the blockchain agrees on the consensus proposal successfully, the nodes may perform the multiple 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. 1 is merely exemplary, and that the embodiments of the present specification are not limited to application to the blockchain shown in fig. 1, and may also be applied to a blockchain system including slices, for example.

In addition, although fig. 1 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 the block chain, and the block chain does not show the byzantine behavior to the outside. Generally, some Byzantine Fault tolerance algorithms require the number of nodes to be greater than 3f +1, where f is the number of Byzantine nodes, such as the practical Byzantine Fault tolerance algorithm pbft (practical Byzantine Fault tolerance).

In the related art, in order to increase a per second execution Transaction (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.

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

Fig. 2 shows a structure diagram of any two nodes (e.g., node 1 and node 2) of a block chain provided in an embodiment of the present specification.

As shown in fig. 2, the node 1 includes a pre-execution module 11, a consensus module 12, and a calculation module 13, and the node 2 includes a pre-execution module 21, a consensus module 22, and a calculation module 23. Node 1 and node 2 may receive different transactions from different downlinked devices (e.g., clients, etc.), respectively, and perform pre-execution on the different transactions. The following is a detailed description taking as an example that the node 1 receives and pre-executes a plurality of transactions.

After the node 1 receives a plurality of transactions from the device under the chain, the pre-execution module 11 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 12 initiates consensus offers to the consensus modules of the other respective nodes based on the received transactions to determine the plurality of transactions included in the block to be generated, the respective pre-execution readsets of the respective transactions and the submission order of the plurality of transactions.

After the consensus is successful, the computing modules in node 1 and the other respective nodes may begin executing the plurality of transactions. The calculation module 13 of the node 1 includes a grouping submodule 131, a plurality of execution submodules (an execution submodule 132, an execution submodule 133, and an execution submodule 134 are schematically shown in the figure), and a re-execution submodule 135. The calculation module 23 of the node 2 includes a grouping submodule 231, a plurality of execution submodules (an execution submodule 232, an execution submodule 233, and an execution submodule 234 are schematically illustrated in the figure), and a re-execution submodule 235.

Specifically, in the node 1, the grouping submodule 131 first divides the plurality of transactions into a plurality of transaction groups according to the pre-execution read-write set, and there is no conflict transaction between 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. Generally, to simplify the scheme, the grouping sub-module 131 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. Each execution submodule generates an execution read-write set of the transaction in the process of executing the transaction, wherein the execution read-write set includes an execution read set and an execution write set, the execution read set may specifically be a key-value pair of a read variable generated in the process of executing the transaction, and the execution write set may specifically be a key-value pair of a written variable generated in the process of executing the transaction. If it is determined that the transaction's execution readsets are not consistent with the pre-executed readsets, then the execution of the transaction is rolled back and re-executed by the re-execution submodule 135 after the execution submodules have processed all transactions to ensure correctness of the packet.

In node 2, the grouping submodule 231 first divides the plurality of transactions into a plurality of transaction groups according to the set of pre-executed reads and writes. Thereafter, the plurality of execution sub-modules may execute the plurality of transaction groups in parallel. In the process of executing the transaction, if the execution read-write set of the transaction is determined to be inconsistent with the pre-execution read-write set, the execution of the transaction is rolled back, and the re-execution sub-module 235 re-executes the rolled-back transaction after the execution sub-modules complete all the transactions, so as to ensure the correctness of the grouping.

In some cases, node 1, after obtaining the plurality of first transactions, obtains a plurality of second transactions from other nodes (including node 2) and respective pre-executed sets of reads and writes for the respective second transactions. Wherein the plurality of first transactions and the plurality of second transactions do not include the same transaction. The first transactions and the second transactions belong to the same block. During the process that the plurality of execution sub-modules of the node 1 execute the plurality of first transactions, the grouping sub-module of the node 1 may divide the acquired plurality of second transactions into a plurality of transaction groups in parallel. After the plurality of execution sub-modules complete the execution of the plurality of first transactions, a plurality of transaction groups divided by the plurality of second transactions may be executed in parallel, thereby executing the plurality of second transactions. And in the process of executing the transaction, if the execution read-write set of the transaction is determined to be inconsistent with the pre-execution read-write set, the execution of the transaction is rolled back by each execution submodule. And in all the transactions of the block to which the first transaction and the second transaction belong, after the transactions except the rolled-back transaction are executed, re-executing the rolled-back transaction to ensure the correctness of the grouping. Similarly, the node 2 performs the similar process.

It should be noted that, after the node 2 receives a plurality of transactions from the device under the chain, the execution processes of the pre-execution module 21, the consensus module 22, and the calculation module 23 included in the node 2 are similar to the execution processes of the pre-execution module 11, the consensus module 12, and the calculation module 13 included in the node 1, and are not described herein again.

In addition, the results obtained by dividing the transaction groups by different nodes can be the same or different, but it is necessary to ensure that no conflict transaction exists between the divided transaction groups. Moreover, while each execution submodule of each node executes a plurality of transaction groups in parallel, each grouping submodule of each node may also group other transactions in parallel. For example, each execution submodule of node 1 may also group transactions 31-60 while executing transaction group 1 (e.g., comprising transactions 1-10), transaction group 2 (e.g., comprising transactions 11-20), and transaction group 3 (e.g., comprising transactions 21-30) in parallel, resulting in transaction group 4 (e.g., comprising transactions 31-40), transaction group 5 (e.g., comprising transactions 41-50), and transaction group 6 (e.g., comprising transactions 51-60).

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

As shown in fig. 3, fig. 3 is a flow chart illustrating a method of performing transactions in a blockchain that 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 above process will be described in detail below with reference to a flow chart of a method of performing a transaction as shown in fig. 3. The execution flow of only two nodes, node 1 and node 2, is shown in fig. 3, and it is understood that any two nodes in the blockchain execute the same flow as node 1 and node 2.

First, in step S301, the node 1 pre-executes a plurality of transactions, and obtains respective pre-executed read-write sets of the respective transactions.

In one embodiment, node 1 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 node 1 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 node 1 receives different transactions at different times, the latest block at the different times may be different blocks, and thus the transactions may correspond to different block world states. For example, in the case where node 1 executes a plurality of blocks in a pipeline, node 1 executes block B1 (assuming that block B1 is a block before block B2) while pre-executing a transaction belonging to block B2, so that a transaction pre-executed before block B1 is generated is pre-executed based on a world state corresponding to block B0 (assuming that block B0 is a block before block B1), and a transaction pre-executed after block B1 is generated is pre-executed based on a world state corresponding to block B1.

In another embodiment, the node 1 may perform 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, a plurality of pre-execution units may be included in the pre-execution module 11 as shown in fig. 2 to execute pre-execution of a plurality of transactions in parallel, thereby speeding up the pre-execution speed of the transactions.

After pre-executing each of the plurality of transactions, the node 1 obtains a respective set of pre-executed reads and writes for the respective transaction. 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-execution 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 by 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 in the course of executing the contract invoked by 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.

Since the world state on which the node 1 is based when the transaction is pre-executed is not necessarily the world state when the transaction is executed, the transaction pre-execution read-write set is inconsistent with the subsequent execution read-write set. In another case, it may be that node 1 intentionally acts badly to cause the transaction pre-execution read-write set to be inconsistent with the later execution read-write set.

In step S303, node 1 sends the plurality of transactions and their pre-execution read-write sets to node 2.

In one embodiment, node 1 may only send the multiple transactions and their pre-executed read-write sets to other nodes (e.g., node 2) for consensus. After consensus is complete, node 2 may group the multiple transactions based on a set of pre-executed reads and writes for the multiple transactions. In this embodiment, the node 2 cannot verify whether the node 1 performs malicious transaction, but the transaction in which the node performs malicious transaction can be sorted out by the subsequent steps.

In another embodiment, node 1 may send the block heights associated with the transactions, their pre-execution readwrite sets, and the respective pre-execution readwrite sets to other nodes for consensus. The relevant block height is the block height corresponding to the world state based on the pre-execution read-write set, and the other nodes can verify the pre-execution read-write set based on the block height related to the pre-execution read-write set by sending the block height related to each pre-execution read-write set to other nodes, so as to determine whether the nodes are bad.

In step S305, the node 1 divides the plurality of transactions into a plurality of transaction groups based on the respective pre-executed read-write sets.

The node 1 may group the plurality of transactions based on the read variable key and the write variable key included in the pre-execution read-write set of each transaction. As described above, the grouping may be such that transactions in different transaction groups do not access the same variable, including read and write operations, and in the event that the grouping condition is met, there is no conflict transaction between transaction groups, and thus, transaction groups may be executed in parallel.

In step S307, the node 1 executes transactions in the divided transaction groups in parallel, wherein a rollback is performed for transactions for which the execution read set does not coincide with the pre-execution read set.

The node 1 may execute the transactions in the divided transaction groups in parallel through a plurality of execution sub-modules. Referring to fig. 2, assuming that the grouping submodule 131 groups a plurality of transactions into 6 groups g1 to g6, the grouping submodule 131 may transmit a group g1 and a group g2 to the execution submodule 132, a group g3 and a group g4 to the execution submodule 133, and a group g5 and a group g6 to the execution submodule 134, so that the respective execution submodules may execute transactions in their grouped groups in parallel.

Taking the execution submodule 132 as an example, the execution submodule 132 may execute the group g1 and the group g2 into which it is divided in series or in parallel. Because there may be conflicts between transactions in one group, the execution submodule 132 executes transactions in a single group serially. The execution submodule 132 only needs to obtain an execution read of a transaction Tx1 after executing a transaction (e.g., transaction Tx 1) of group g 1. The execution submodule 132 may compare whether the execution read set of the transaction Tx1 is consistent with the read set in the pre-execution read-write set, and if so, since the node 1 trusts the pre-execution write set obtained by its own pre-execution transaction Tx1, the execution submodule 132 may directly use the pre-execution write set of the transaction Tx1 as the execution write set of the transaction, and update the states of the variables in the cache according to the write set, where the state maintained in the cache is the current latest world state.

If the executing read set of the transaction Tx1 is not consistent with the read set in the pre-executing read-write set, indicating that the world state of the transaction Tx1 at execution time is changed from the world state of the transaction Tx1 at pre-execution time, the pre-executing read-write set of the transaction Tx1 is an erroneous read-write set. In particular, as described above, in the case where the pre-execution read set of the transaction Tx1 is not consistent with the execution read set, the variables written by the transaction Tx1 at the pre-execution may be different variables from the variables written at the execution, so that the grouping result obtained by grouping the sub-module 131 based on the pre-execution read-write set is an erroneous grouping result. In order to make the execution submodule 132, the execution submodule 133 and the execution submodule 134 still execute each transaction group in parallel according to the existing grouping result, the execution submodule 132 rolls back the execution of the transaction Tx1, specifically, deletes the reading set obtained by executing the transaction Tx1, and moves the transaction Tx1 out of the group g1 and puts the reading set into the group g7, where the group g7 is used for collecting transactions of which the execution reading set is different from the pre-execution reading set. That is, by rolling back the execution of transaction Tx1 so that transaction Tx1 does not affect the current world state, causing the rolling back of other transactions, by moving transaction Tx1 out of group g1 so that the variables accessed by transaction Tx1 do not affect the grouping of other transactions so that the respective execution submodules can continue to execute the respective transaction groups in parallel.

Optionally, at step S309, node 1 re-executes the rolled back transaction.

After node 1 has performed all of the transactions in the plurality of transaction groups (including the transactions rolled back after execution), the transactions in group g7, i.e., the one or more transactions rolled back that were removed from the plurality of transaction groups, may be re-executed based on the variable states maintained in the cache. Wherein the variable state maintained in the cache is a variable state derived from a write set of non-rolled transactions of the plurality of transactions. The execution order in which the plurality of transactions in group g7 are re-executed may be determined according to preset rules. For example, the plurality of transactions may be performed serially according to the order of their transaction numbers in group g 7.

In another embodiment, the node 1 may return the transaction execution failure directly to the down-link device (e.g., client) after rolling back the transaction without re-executing the transaction.

In step S311, the node 1 generates a block after completing the execution of the plurality of transactions.

After the node 1 completes the execution of the plurality of transactions, or after the node 1 completes the execution of the plurality of transactions and the re-execution of the rolled-back transaction, the state database is updated according to the state data in the cache, and a block is generated. The block includes a block head and a block body. The block body includes, for example, data such as transaction bodies and receipts for the plurality of transactions. The block header may include data such as a status root, a receipt root, a transaction root, etc.

In one embodiment, the block may further include the pre-executed read-write sets of multiple transactions, and by including the pre-executed read-write sets of multiple transactions in the block, when other nodes lose data due to a failure or the like, the multiple transactions in the block may be re-executed based on the pre-executed read-write sets of the block in the node 1, so as to obtain a world state consistent with the node 1.

In step S313, the node 2 divides the plurality of transactions into a plurality of transaction groups based on the respective pre-executed read-write sets.

This step can refer to the above description of step S305, and is not described herein again.

It should be noted that the transaction groups divided by the node 1 and the node 2 for the multiple transactions may be the same or different, as long as the transactions in different transaction groups do not access the same variable. For example, the plurality of transactions includes transaction a, transaction b, transaction c, transaction d, transaction e, and transaction f, where transaction a and transaction c access the same variable, transaction e and transaction f access the same variable, and none of the other transactions access the same variable. Node 1 may divide the plurality of transactions into transaction group a and transaction group B. The transaction group A comprises a transaction a, a transaction b and a transaction c. Transaction group B includes transaction d, transaction e, and transaction f. Node 2 may divide the plurality of transactions into transaction group C and transaction group D. Wherein, the transaction group C comprises transaction a, transaction b, transaction e and transaction f. Transaction group B includes transaction d, transaction c.

In step S315, the node 2 executes the transactions in the divided transaction groups in parallel, wherein a rollback is performed for transactions in which the execution read-write set is inconsistent with the pre-execution read-write set.

Similarly to step S307, after the node 2 groups the transactions into the group d1 to the group d6, the execution submodule 232, the execution submodule 233, and the execution submodule 234 may execute the transactions in the groups d1 to d6 in parallel.

Taking the execution submodule 232 as an example, after executing a certain transaction Tx2 of the group d1, the execution submodule 232 obtains an execution read-write set of the transaction Tx 2. The execution submodule 232 may compare whether the execution read-write set of the transaction Tx2 is consistent with the pre-execution read-write set. Wherein, the case that the execution read-write set of the transaction Tx2 is inconsistent with the pre-execution read-write set includes any one of the following cases: the execution read set of transaction Tx2 is inconsistent with the pre-execution read set; the executing write set of transaction Tx2 is inconsistent with the pre-executing write set; the execute read set of transaction Tx2 is inconsistent with the pre-execute read set, and the execute write set of transaction Tx2 is inconsistent with the pre-execute write set. Here, since there may be a case where node 1 acts as a malicious node, the execution submodule 232 needs to continue to compare whether the execution write set of the transaction Tx2 is consistent with the pre-execution write set, even if it is determined that the execution read set of the transaction Tx2 is consistent with the pre-execution read set.

If the transaction Tx2 execution read-write set is consistent with the pre-execution read-write set, the execution submodule 232 may update the state of each variable in the cache according to the transaction Tx2 execution write set.

If the executing read-write set of transaction Tx2 does not coincide with the pre-executing read-write set, there may be two cases. In the first case, the world state upon which the transaction Tx2 is executed and the world state upon which it is pre-executed change, resulting in the transaction's executing read set being different from the pre-executing read set, i.e., the transaction's pre-executing read-write set is the wrong read-write set. In this first case, as described above, if the world state maintained in the cache is updated based on the write set for the transaction, it may result in incorrect grouping, thereby affecting the performance of subsequent transactions.

In the second case, node 1 may be malicious such that the pre-executed read-write set of the transaction is the wrong read-write set.

In the first case, the execution submodule 232 may rollback the execution of the transaction, specifically, delete the read-write set obtained by executing the transaction, and move the transaction out of the group d1 and place the transaction in the group d7, where the group d7 is used to collect the transactions of the execution read-write set and the pre-execution read set, thereby solving the problem caused by the first case.

It should be noted that the transactions to be rolled back obtained by the node 1 and the node 2 are the same, for example, if the transaction m is included in the group g7 corresponding to the node 1, the transaction m is also included in the group d7 corresponding to the node 2.

Optionally, at step S317, node 2 re-executes the rolled back transaction, i.e., the transaction in group d 7.

This step can refer to the above description of step S309, and is not repeated herein.

By executing the transactions as described above, each node performs rollback on the same transaction in the process of executing the transaction, and executes the rolled back transactions in the same order based on the same world state, so that each node finally obtains the same execution result on a plurality of transactions and obtains the same world state corresponding to the block including the plurality of transactions. In the case where there are fewer transaction conflicts and the master node is not malicious, the number of transactions rolled back is smaller and the individual nodes increase the transaction execution speed by executing transactions in parallel.

In step S319, node 2 generates a chunk, optionally including a set of pre-executed reads and writes for multiple transactions in the chunk.

This step may be performed as described above with reference to step S311. By including the pre-executed read-write set of multiple transactions in a block, when other nodes lose data due to a failure or the like, the multiple transactions in the block can be re-executed based on the pre-executed read-write set of the block in the node 2, thereby obtaining a world state consistent with the node 2.

By the method shown in fig. 3, each node in the block chain groups multiple transactions based on the same pre-execution read-write set, performs transactions of multiple transaction groups in parallel based on the same world state, and processes transactions with transaction execution results different from pre-execution results by the same method, and finally, the world states obtained by each node are consistent. In the case where there are fewer conflicting transactions among the plurality of transactions and the master node is not repugnant, the execution speed of the transactions in the blockchain can be increased.

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.

Embodiments of blockchain nodes are also provided herein, corresponding to the aforementioned embodiments of methods of performing transactions in blockchains.

As shown in fig. 4, fig. 4 is an architecture diagram of a blockchain link point, which may be any node in a blockchain, according to an exemplary embodiment of the present disclosure, and the node may include: a receiving unit 401, a grouping unit 402 and an executing unit 403.

The receiving unit 401 is configured to receive a plurality of first transactions and a pre-execution read-write set of the plurality of first transactions. Wherein the pre-executed read-write sets are obtained by pre-executing the first transactions.

A grouping unit 402 configured to group the plurality of first transactions based on the pre-executed read-write sets of the plurality of first transactions.

An execution unit 403, configured to execute the plurality of first transactions in parallel according to the result of the grouping. And for any first transaction, if the execution read-write set obtained by executing the first transaction is inconsistent with the pre-execution read-write set of the first transaction, rolling back the execution of the first transaction.

In some embodiments, the grouping unit 402 is further configured to obtain a plurality of second transactions and a pre-execution read-write set of the plurality of second transactions. And in the process of executing the plurality of first transactions by the execution unit 403, grouping the plurality of second transactions in parallel according to the pre-execution read-write sets of the plurality of second transactions.

In other embodiments, the node may further include: the unit is re-executed (not shown in the figure).

The re-execution unit is used for re-executing the rolled back transaction after the plurality of first transactions are executed and completed.

In other embodiments, the re-execution unit is configured to: the rolled back transaction is re-executed serially.

One or more embodiments of the present specification further provide a computer-readable storage medium storing a computer program, where the computer program can be used to execute the method for executing a transaction in a blockchain provided in any one of the embodiments of fig. 2 to 3.

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 the method for performing transactions in a blockchain as provided in any of the embodiments of fig. 2 to 3 above.

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 a 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 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 operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. 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 implemented in an actual device or end product, can be executed sequentially or in parallel according to the methods shown in the embodiments or figures (e.g., parallel processor or multi-thread processing environments, even distributed data processing environments). 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 a module implementing the same function may be implemented by a combination of multiple 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 permanent and non-permanent, removable and non-removable media, may implement the 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 so forth) 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, 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. 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. Moreover, various embodiments or examples and features of various embodiments or examples described in this specification can be combined and combined by one skilled in the art without being mutually inconsistent.

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 of performing a transaction in a blockchain, the blockchain including a first node and a second node, the first node and the second node being any two nodes in the blockchain, respectively, the method comprising:

the second node groups the first transactions based on the pre-execution read-write sets of the first transactions, and executes the first transactions in parallel according to the grouping result;

and for any first transaction, if the execution read-write set obtained by the second node executing the first transaction is inconsistent with the pre-execution read-write set of the first transaction, rolling back the execution of the first transaction.

2. The method of claim 1, wherein the method further comprises:

the first node groups the first transactions based on the pre-execution read-write sets of the first transactions, and executes the first transactions in parallel according to the grouping result; and for any first transaction, if the execution read set in the execution read-write set obtained after the first transaction is executed by the first node is inconsistent with the pre-execution read set in the pre-execution read-write set of the first transaction, rolling back the execution of the first transaction.

3. The method of claim 1, wherein the method further comprises:

the second node acquires a plurality of second transactions and a pre-execution read-write set of the second transactions;

and the second node groups the plurality of second transactions in parallel according to the pre-execution read-write sets of the plurality of second transactions in the process of executing the plurality of first transactions.

4. The method of claim 1, wherein the first node pre-executes the received plurality of first transactions, including: the first node pre-executes each first transaction based on the world state of the latest block corresponding to the first transaction.

5. The method of claim 3, wherein the second node, after performing the completing of the plurality of first transactions, further comprises: the second node re-executes the rolled back transaction.

6. The method of claim 5, wherein the second node re-executes the rolled back transaction, comprising: the second node serially re-executes the rolled back transaction.

7. The method of claim 5, wherein the plurality of first transactions and the plurality of second transactions belong to a first block; the method further comprises the following steps:

the second node executes the plurality of second transactions in parallel according to grouping results of the plurality of second transactions after completing the execution of the plurality of first transactions; for any second transaction, if the execution read-write set obtained after the second transaction is executed by the second node is inconsistent with the pre-execution read-write set of the second transaction, rolling back the execution of the second transaction;

wherein the second node re-executing the rolled back transaction comprises re-executing the rolled back first transaction and the rolled back second transaction after executing the plurality of second transactions.

8. The method of claim 7, wherein the second node re-executes the rolled back first transaction and the rolled back second transaction, comprising: the second node re-executes the rolled back first transaction and the rolled back second transaction based on the latest world state after the execution of the plurality of second transactions is completed.

9. The method of claim 7, wherein the method further comprises:

the second node generating the first block after completing re-execution of the rolled back transaction; the first block includes pre-executed read-write sets of the plurality of first transactions and pre-executed read-write sets of the plurality of second transactions.

10. The method of claim 1, wherein the set of pre-executed reads and writes for any first transaction includes a block height at which the first transaction was pre-executed.

11. A method of performing a transaction in a blockchain, the blockchain comprising a first node and a second node, the first node and the second node being any two nodes in the blockchain, respectively, the method being applied to the second node; the method comprises the following steps:

grouping the first transactions based on the pre-execution read-write sets of the first transactions, and executing the first transactions in parallel according to the grouping result;

and for any first transaction, if the execution read-write set obtained after the first transaction is executed is inconsistent with the pre-execution read-write set of the first transaction, rolling back the execution of the first transaction.

12. The method of claim 11, wherein the method further comprises:

obtaining a plurality of second transactions and a pre-execution read-write set of the second transactions; and grouping the plurality of second transactions according to the pre-execution read-write sets of the plurality of second transactions in parallel in the process of executing the plurality of first transactions.

13. The method of claim 12, wherein after performing the completion of the plurality of first transactions, further comprising: the rolled back transaction is re-executed.

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

15. The method of claim 13, wherein the plurality of first transactions and the plurality of second transactions belong to a first block; the method further comprises the following steps:

after completion of execution of the plurality of first transactions, executing the plurality of second transactions in parallel according to grouped results of the plurality of second transactions; for any second transaction, if the execution read-write set obtained after the second transaction is executed is inconsistent with the pre-execution read-write set of the second transaction, rolling back the execution of the second transaction;

wherein the re-executing the rolled back transaction comprises re-executing the rolled back first transaction and the rolled back second transaction after executing the plurality of second transactions.

16. The method of claim 15, wherein said re-executing the rolled back first transaction and the rolled back second transaction comprises: re-executing the rolled back first transaction and the rolled back second transaction based on the latest world state after executing the plurality of second transactions.

17. The method of claim 15, wherein the method further comprises:

generating the first block after completing re-execution of the rolled back transaction; the first block includes pre-executed read-write sets of the first transactions and pre-executed read-write sets of the second transactions.

18. The method of claim 11, wherein the set of pre-executed reads and writes for any first transaction includes a block height at which the first transaction was pre-executed.

19. A second node in a blockchain, the second node comprising:

a receiving unit, configured to receive a plurality of first transactions and a pre-execution read-write set of the plurality of first transactions from a first node in the blockchain; wherein the pre-executed read-write set of the first transactions is derived by pre-executing the first transactions by the first node;

and the execution unit is used for executing the plurality of first transactions in parallel according to the grouping result, and for any first transaction, if the execution read-write set obtained after the first transaction is executed is not consistent with the pre-execution read-write set of the first transaction, the execution of the first transaction is rolled back.

20. A block chain comprises a first node and a second node, wherein the first node and the second node are any two nodes in the block chain respectively;

the second node is configured to group the plurality of first transactions based on the pre-execution read-write sets of the plurality of first transactions, execute the plurality of first transactions in parallel according to the grouping result, and rollback execution of any one of the first transactions if an execution read-write set obtained after execution of the first transaction is inconsistent with the pre-execution read-write set of the first transaction.

21. 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-18.

22. 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-18.