Block chain transaction parallel execution method based on pre-execution conflict detection

Abstract

The invention discloses a block chain transaction parallel execution method based on pre-execution conflict detection, and belongs to the field of block chains. The method specifically comprises the steps that a node receives a transaction sent by a user, and a verification node carries out pre-execution operation on the received transaction in idle time waiting for proposal of a main node; judging whether the transaction packaged by the elected main node is a pre-execution transaction, and if so, generating a transaction conflict graph according to the read-write set of each transaction; an independent set is solved repeatedly, and the main node performs optimistic parallel execution to obtain a transaction dependency graph and packages the transaction dependency graph into a proposal block; otherwise, the main node performs optimistic parallel execution on the transactions which are not pre-executed, constructs a directed acyclic transaction dependency graph, and packages the directed acyclic transaction dependency graph to generate proposal blocks; and finally, each verification node sequentially executes corresponding transactions according to the transaction dependency graph and performs comparison verification on an execution result and an execution result of the main node, and when the results are consistent, the proposal block is successfully linked, and the consensus of the round is completed. The optimistic parallel execution efficiency is improved.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain, and specifically is a blockchain transaction parallel execution method based on pre-execution conflict detection. Background Art

[0002] Cryptocurrency was first proposed by Satoshi Nakamoto in his related work in 2008. As the underlying technology, blockchain was used in the blockchain 1.0 era to ensure the traceability and immutability of related transactions in the blockchain. At the same time, pure mathematical methods were used to replace third-party authoritative institutions, proposing a new decentralized feature. In the blockchain 2.0 era, the concept of smart contracts was introduced into the underlying blockchain technology. At this time, blockchain was applied to multiple fields as an independent technology.

[0003] Blockchain is a decentralized distributed database ledger technology. With its characteristics of traceability, immutability, decentralization, trustlessness and anonymity, it is no longer limited to the field of traditional encrypted digital currency. It provides new solutions to evidence storage, trust and data governance issues in economic development, and has broad application prospects in finance, education, medical care, agriculture, supply chain and other fields.

[0004] In blockchain technology, the addition of smart contracts gives blockchain programmability. However, in order to ensure the consistency of the final transaction execution results, most blockchains, such as Ethereum, use serial execution of transactions to prevent inconsistent execution results between nodes. In order to make full use of node computing resources, it is necessary to consider using parallel methods to optimize smart contract execution. However, in the currently widely used transaction parallel scheme, if different transactions read and write data under the same address during the parallel execution of transactions, the execution results of some transactions will be invalid and the transactions need to be rolled back. If the number of transaction rollbacks is too many, additional overhead will be generated and even security issues will occur. Summary of the invention

[0005] Aiming at the problems of low efficiency of serial scheduling mechanism and additional overhead caused by transaction rollback in parallel scheduling mechanism under existing blockchain, the present invention proposes a blockchain transaction parallel execution method based on pre-execution conflict detection. For blockchain adopting TBFT consensus mechanism, transactions are executed in parallel as fully as possible while reducing transaction conflict rollback.

[0006] The method for parallel execution of blockchain transactions with pre-execution conflict detection comprises the following steps:

[0007] Step 1: For a blockchain network with several nodes, the user continuously sends N transactions. Each node receives each transaction and saves it in its own transaction pool, and performs pre-execution operations.

[0008] There is a master node in the blockchain network, and the rest of the nodes are verification nodes. The master node is responsible for packaging transactions to generate proposal blocks, and the verification nodes are responsible for verifying the proposal blocks generated by the master node;

[0009] Pre-execution operation means: the node executes the current transaction in the current environment and saves the transaction read-write set;

[0010] Each verification node pre-executes the transactions received in succession during the idle time waiting for the master node's proposal and saves them in the cache area; that is, each node's transaction pool contains both pre-executed transactions and non-pre-executed transactions.

[0011] Step 2: For the current round of consensus, elect a master node in the blockchain network. The master node selects the transactions with the earliest sending time from its own transaction pool in order to package them;

[0012] The master node is taken turns by each node in the chain;

[0013] Step 3: Determine whether the transaction selected for packaging is a pre-execution transaction. If yes, proceed to step 4; otherwise, proceed to step 6;

[0014] Step 4: The master node preferentially selects the pre-executed transactions from the transaction pool for packaging, and treats each transaction as a node in the graph according to the read-write set of each transaction. For two transactions with the same address under the write set of one transaction and the read set of another transaction, a directed edge from the write point to the read point is constructed between the transactions to generate the corresponding transaction conflict graph;

[0015] Step 5: Repeatedly obtain independent sets for the transaction conflict graph and perform optimistic parallel execution. The resulting transaction sequence is the transaction dependency graph, which is packaged to generate a proposal block and proceed to step 8;

[0016] The proposal block contains: transactions packaged in the block (including contract name, function name, input parameters, execution results, read-write sets) and transaction dependency graph (transaction execution order)

[0017] Step 6: For each packaged transaction, the master node performs optimistic parallel execution, records the transaction write operations in the memory cache during execution, and checks after each transaction is executed whether the data in its read set has been modified by other transactions during the execution process. If so, the transaction needs to be rolled back and redone; otherwise, the transaction read-write set takes effect and the execution result is successfully obtained;

[0018] Step 7: After all packaged transactions are executed, a directed acyclic transaction dependency graph is constructed by analyzing the read-write sets of all transactions, and the proposal blocks are packaged and generated, and then proceed to step 8;

[0019] If there is a conflict between transactions, the edges in the transaction dependency graph are constructed according to the order of execution.

[0020] A conflict exists when at least two transactions read and write variables at the same address at the same time.

[0021] Step 8. After receiving the proposal sent by the master node, each verification node executes the corresponding transaction in order according to the transaction dependency graph, and compares and verifies the execution result with the execution result of the master node to determine whether the execution result is consistent. Under the Byzantine fault-tolerant consensus protocol, each node in the blockchain is divided into 3f+1 nodes. When at least 2f+1 verification nodes agree with the result of the proposal block, the proposal block is successfully on the chain, and this round of consensus is completed;

[0022] Step 9. Return to step 2, reselect the master node in the blockchain network, and execute the next round of consensus.

[0023] The advantages of the present invention are:

[0024] 1. A blockchain transaction parallel execution method based on pre-execution conflict detection. For each node under the TBFT consensus protocol, the idle resources of the verification node are fully utilized during the time when the main node generates a proposal, and the transaction pre-execution operation is performed to obtain the preliminary read-write set. When the node becomes the main node to generate a proposal, the preliminary read-write set obtained by pre-execution can be used to batch transactions that may have conflicts for optimistic parallel execution, thereby reducing transaction rollbacks caused by conflicts under optimistic parallel execution.

[0025] 2. A blockchain transaction parallel execution method based on pre-execution conflict detection, after constructing a transaction conflict directed graph using the preliminary read-write set obtained by pre-execution, the transactions under the directed graph are batched into multiple independent sets by repeatedly obtaining independent sets from the directed graph. By executing transactions under different independent sets in batches in parallel, parallel execution is fully performed while reducing conflicts, thereby improving transaction execution efficiency as much as possible. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a flow chart of a method for parallel execution of blockchain transactions based on pre-execution conflict detection of the present invention;

[0027] Figure 2 It is a specific implementation flow chart of a blockchain transaction parallel execution method based on pre-execution conflict detection of the present invention;

[0028] Figure 3 It is a schematic diagram of the independent set batching scheme of the transaction conflict directed graph of the present invention;

[0029] Figure 4 is a transaction dependency graph generated in an embodiment of the present invention;

[0030] Figure 5 In the embodiment of the present invention, a corresponding transaction conflict graph is generated according to the transaction read-write set;

[0031] Figure 6 It is a transaction batch graph for repeatedly obtaining independent sets from a transaction conflict graph in an embodiment of the present invention;

[0032] Figure 7 It is a corresponding transaction dependency graph obtained after executing transactions in parallel in an embodiment of the present invention. DETAILED DESCRIPTION

[0033] The present invention will be further described in detail below with reference to the accompanying drawings and implementation examples.

[0034] The present invention provides a parallel execution method of blockchain transactions based on pre-execution conflict detection, such as Figure 1 As shown, the following steps are included:

[0035] Step 1: For a blockchain network with several nodes, the user continuously sends N transactions. Each node receives each transaction and saves it in its own transaction pool, and performs pre-execution operations.

[0036] Receive smart contract function call requests sent by users through the client, i.e. transactions. Transactions will be sent to each node for storage and awaiting subsequent processing. There are multiple solutions for storing transactions in nodes. The module where each node temporarily stores unexecuted transactions is called a transaction pool.

[0037] For most blockchain systems that use the TBFT consensus mechanism, the node types in the consensus process are mainly divided into two categories: master nodes and verification nodes. In order to ensure that the final state of each node in the blockchain remains consistent, each node needs to ensure that the transactions executed are from the same batch of transactions, and the order of transaction execution must be consistent. To meet the above requirements, in each round of consensus, a node will be elected as the master node to generate proposals, and the remaining nodes will serve as verification nodes to verify the proposals generated by the master node.

[0038] First, the master node selects a batch of unexecuted transactions for parallel execution, and generates a directed acyclic graph between transactions to determine the order in which the verification node executes the transactions. When the master node proposal is generated, it is sent to the verification node. The verification node will execute the transaction according to the order in the directed acyclic graph and verify the transaction execution results of the master node.

[0039] According to the above process, when the verification node is waiting for the master node to generate a proposal, only the master node is executing transactions under the current blockchain, and other verification nodes and the machines where the nodes are located are in a state of idle resources. At this time, the verification node can select unexecuted transactions from the transaction pool for parallel pre-execution operations, obtain the addresses that may perform read and write operations during the execution of the transaction through pre-execution operations, and generate a preliminary read-write set for storage, mark the corresponding transaction as a completed pre-execution transaction, and wait for the node to become the master node later. Until the verification node receives the proposal sent by the master node, the verification node stops pre-execution and enters the subsequent consensus process.

[0040] For a blockchain system that uses a key-value model for storage, the read-write set of a transaction under the blockchain refers to the set of keys corresponding to the addresses where the data for the read and write operations of the transaction is located.

[0041] Pre-execution operation means: the node executes the current transaction in the current environment and saves the transaction read-write set;

[0042] Each verification node pre-executes the transactions received in succession during the idle time waiting for the master node's proposal and saves them in the cache area; that is, each node's transaction pool contains both pre-executed transactions and non-pre-executed transactions.

[0043] Before the verification node receives the proposal sent by the master node and enters the subsequent verification stage, the verification node can continuously pre-execute unexecuted transactions to obtain the preliminary read-write set of the corresponding transaction obtained through pre-execution, which will be used for batch scheduling of transactions when the node becomes the master node to generate proposals.

[0044] like Figure 2 As shown in the figure, the transaction pool is mainly used to store the cache area of ​​unexecuted transactions in the blockchain system. All transactions sent by the client will first be added to the transaction pool. Among them, the queue area in the transaction pool is used to store transactions that have not been processed, and the pending queue area is used to store transactions selected by the master node that are in the process of packaging and generating proposals or completed pre-execution transactions. In addition, a completed pre-execution transaction cache is opened for each node to additionally store completed pre-execution transaction copies and the preliminary read-write set corresponding to the transaction obtained by pre-execution.

[0045] While the verification node is waiting for the master node to send a proposal, the verification node continuously selects transactions in batches from the queue in the transaction pool of this node for pre-execution, and transfers the selected transactions from the queue to the pending queue. For a batch of transactions selected in batches, since the execution results obtained by pre-execution will not be used directly, only the transaction read-write sets obtained by pre-execution will be used to guide the subsequent batch parallel execution of transactions in the proposal generation process. Therefore, all the taken out transactions can be directly executed in parallel at the same time in the pre-execution stage. For transactions that have completed pre-execution, the transaction and its corresponding preliminary pre-execution read-write set are added to the completed pre-execution transaction cache. After receiving the proposal from the master node, the verification node stops the pre-execution operation and enters the subsequent consensus process.

[0046] In this process, the pre-executed transactions only obtain inaccurate transaction read-write sets, and do not obtain directly usable transaction execution results. At this time, these transactions are still unexecuted transactions in essence.

[0047] Step 2: For the current round of consensus, elect a master node in the blockchain network. The master node selects the transactions with the earliest sending time from its own transaction pool in order to package them;

[0048] The master node is taken turns by each node in the chain; when the node is judged to be the master node in this round of consensus, a batch of unexecuted transactions will be selected to try to package and generate proposals, and the transaction results and the directed acyclic graph between transactions will be obtained through optimistic parallel execution.

[0049] In other consensus processes where this node is not elected as the master node, the node participates in the consensus as a verification node and pre-executes some transactions, and adds the transactions and the corresponding pre-execution preliminary read-write sets to the completed pre-execution transaction cache.

[0050] When a node is elected as the master node, it can give priority to selecting completed pre-execution transactions for proposal generation. When the number of transactions in the completed pre-execution cache does not reach the upper limit of the number of transactions required for proposal generation, it can continue to select unprocessed unexecuted transactions and completed pre-execution transactions from the transaction pool queue to package and generate proposals. For the selected completed pre-execution transactions, the conflict directed graph of the subsequent steps will be constructed.

[0051] Among them, the unexecuted transactions selected from the transaction pool queue for packaging and generating proposals will be transferred to the transaction pool pending queue, such as Figure 2 shown.

[0052] Step 3: Determine whether the transaction selected for packaging is a pre-execution transaction. If yes, proceed to step 4; otherwise, proceed to step 6;

[0053] Step 4: The master node preferentially selects the pre-executed transactions from the transaction pool for packaging, and treats each transaction as a node in the graph according to the read-write set of each transaction. For two transactions with the same address under the write set of one transaction and the read set of another transaction, a directed edge from the write point to the read point is constructed between the transactions to generate the corresponding transaction conflict graph;

[0054] When generating proposals, the master node can select a batch of transactions to package and generate blocks. In the process of generating proposals, the pre-executed transactions are selected first for packaging. If the number of pre-executed transactions does not reach the upper limit of the block transaction number, the unexecuted transactions can continue to be selected from the transaction pool for packaging.

[0055] Conflicting transactions refer to transactions where the read set of a transaction and the write set of other transactions have duplicate address keys.

[0056] For the pre-executed transactions with preliminary read-write sets selected by the master node for packaging, a conflict directed graph is established based on the preliminary read-write set. Among them, the transaction is used as a node in the conflict directed graph. For transaction A that writes data at the same address and transaction B that reads data at the same time, a directed edge from write to read, that is, transaction A points to transaction B, will be constructed.

[0057] Step 5: Repeatedly obtain independent sets for the transaction conflict graph and perform optimistic parallel execution. The resulting transaction sequence is the transaction dependency graph, which is packaged to generate a proposal block and proceed to step 8;

[0058] The proposal block contains: the transactions packaged in the block (including contract name, function name, input parameters, execution results, read-write sets) and the transaction dependency graph (transaction execution order).

[0059] The optimistic parallel execution described means that for a batch of transactions selected for optimistic parallel execution, it is first assumed that there is no conflict between the above transactions, and all transactions are directly executed in parallel, and the transactions are rolled back and redone only when conflicts are detected. After the optimistic parallel execution of transactions, the conflicting transactions will be repeatedly rolled back and redone to obtain a serialized transaction execution sequence, which can be used to represent the execution dependency relationship between all transactions through a directed acyclic graph, and is used to verify that the node executes the conflicting transactions in a deterministic order.

[0060] For the completed pre-execution transactions and their corresponding read-write sets selected by the master node, a conflict directed graph will be constructed for the above transactions.

[0061] The conflict between transactions described here means that when the address key contained in the read set of a transaction A and the address key contained in the write set of another transaction B have the same part, it can be considered that when transactions A and B are executed in parallel, the write operation of transaction B will modify the data read by the read operation of transaction A, and the two transactions may have a parallel conflict. The above two transactions can be regarded as two nodes in the conflict directed graph, and a directed edge pointing from transaction B to transaction A is established at the same time, indicating that the write of transaction B caused a conflict with the read of transaction A.

[0062] Through the above method, a conflict directed graph is established for all the completed pre-execution transactions that have been taken out. Since the unprocessed unexecuted transactions do not have any read-write set related information, no corresponding operations are performed on the unprocessed transactions. After the conflict directed graph is built, since the actual read-write set and execution result of the transaction are affected by the current execution environment, the read-write set obtained by the transaction pre-execution may not be completely consistent with the read-write set after the actual master node is packaged and executed. Therefore, the read-write set obtained by the pre-execution transaction is only used to try to separate transactions that may have conflicts. The actual transaction submission order and the consistency of the transaction execution order between nodes are guaranteed by optimistic parallelism and the generated directed acyclic graph.

[0063] After the conflict directed graph is constructed, the transactions selected by the master node are batched and actually executed optimistically in parallel. It can be concluded from the transaction conflict directed graph that for transactions that have completed pre-execution, there are directed edges between directly adjacent transactions in the conflict graph, indicating that the two adjacent transactions are likely to have read-write conflicts during the actual execution process, while non-adjacent transactions are less likely to have read-write conflicts during the actual execution process.

[0064] Based on this, the independent set is repeatedly obtained for the transaction conflict directed graph, and a batch of transactions selected by the master node are divided into different independent sets and unprocessed transaction sets, such as Figure 3 As shown. First, for the selected transactions that have not been processed, directly add them to the unprocessed transaction set; for the transactions in the conflicting directed graph, obtain the independent set of the directed graph, and after obtaining all non-adjacent transactions in the directed graph, remove the transactions and all corresponding edges from the conflicting directed graph, and then continue to obtain independent sets for the obtained subgraph, repeat the above steps until the conflicting directed graph does not contain any transactions, and complete the batching of transactions.

[0065] From the above, based on the read-write set obtained by pre-execution as the judgment basis that is close to the actual execution result, it can be considered that the possibility of transaction conflicts in transactions under the same independent set is low, and optimistic parallel execution can be performed at the same time; the possibility of transaction conflicts in transactions between different independent sets is high, and transaction rollback and redo will occur when optimistic parallel execution is performed at the same time, so optimistic parallel execution will not be performed at the same time; transactions under the unprocessed transaction set can be optimistically executed in parallel with any other transactions because the information is unknown.

[0066] After the transaction conflict directed graph is constructed, the independent set is obtained for the directed graph. At this time, the transactions represented by the nodes in the independent set are transactions that do not have read-write set conflicts with each other. After removing the corresponding nodes of the independent set in the conflict directed graph, continue to obtain the independent set, and repeat the above operation until the conflict directed graph does not contain any nodes. Multiple independent sets taken out in the above manner are executed in batches in a serial manner. The transactions under the same independent set are less likely to conflict during the actual execution process, and optimistic parallel execution can be attempted; transactions under different independent sets are more likely to conflict in the actual process and need to be executed separately. For unexecuted transactions, since they do not contain the preliminary read-write set, optimistic parallel execution is performed directly on the unexecuted transactions alone.

[0067] Step 6: For each packaged transaction, the master node performs optimistic parallel execution, records the transaction write operations in the memory cache during execution, and checks after each transaction is executed whether the data in its read set has been modified by other transactions during the execution process. If so, the transaction needs to be rolled back and redone; otherwise, the transaction read-write set takes effect and the execution result is successfully obtained;

[0068] During the transaction execution, the read-write set of the transaction in the execution stage is checked for versions. If a transaction that performs a read operation on the data under a certain address during the execution process is modified by the write operation of other submitted transactions, the transaction will be rolled back to ensure the consistency of the transaction execution results.

[0069] Step 7: After all packaged transactions are executed, a directed acyclic transaction dependency graph is constructed by analyzing the read-write sets of all transactions, and the proposal blocks are packaged and generated, and then proceed to step 8;

[0070] If there is a conflict between transactions, the edges in the transaction dependency graph are constructed according to the order of execution.

[0071] A conflict exists when at least two transactions read and write variables at the same address at the same time.

[0072] Step 8. After receiving the proposal sent by the master node, each verification node executes the corresponding transaction in order according to the transaction dependency graph, and compares and verifies the execution result with the execution result of the master node to determine whether the execution result is consistent. Under the Byzantine fault-tolerant consensus protocol, each node in the blockchain is divided into 3f+1 nodes. When at least 2f+1 verification nodes agree with the result of the proposal block, the proposal block is successfully on the chain, and this round of consensus is completed;

[0073] Step 9. Return to step 2, reselect the master node in the blockchain network, and execute the next round of consensus.

[0074] Example:

[0075] There are four nodes in the current blockchain network, namely node 1 to node 4. Assume that seven transactions from T0 to T6 are continuously sent to the blockchain network, and all transactions will be successfully executed and uploaded to the chain in two rounds of consensus. The read-write sets actually involved in the above seven transactions are as follows, and it is assumed that the read-write sets obtained by the subsequent verification node pre-execution are consistent with the actual transaction read-write sets:

[0076] T0 (read: X, Y, write: A, E)

[0077] T1 (read: A, B, write: C, D)

[0078] T2 (read: C, E, write: F)

[0079] T3 (read: D, F, write: G, H)

[0080] T4 (read: G, I, write: J)

[0081] T5 (read: B, J, write: K)

[0082] T6 (read: H, K, write: A, E)

[0083] In the first round of consensus, assuming that the blockchain network elects node 1 as the master node, the transaction pools of all nodes and the transaction storage in the completed pre-execution cache are as follows:

[0084] Node 1 (Transaction pool: T0, T1, T2, T3, T4, T5, T6, Cache: None)

[0085] Node 2 (Transaction pool: T0, T1, T2, T3, T4, T5, T6, Cache: None)

[0086] Node 3 (Transaction pool: T0, T1, T2, T3, T4, T5, T6, Cache: None)

[0087] Node 4 (Transaction pool: T0, T1, T2, T3, T4, T5, T6, Cache: None)

[0088] At this time, node 1 serves as the master node. Since there are no completed pre-execution transactions in the cache, it selects transactions in the transaction pool and attempts to package them. Assume that in this round of consensus, node 1 selects transactions T0 and T1 for packaging.

[0089] Since the above two transactions read and write the variable with address A at the same time, during the parallel execution process of node 1, transaction T1 finds that the data it reads is modified by transaction T0 after execution. At this time, transaction T1 will be re-executed based on the modified data of transaction T0. Therefore, transaction T1 is actually executed twice in the master node packaging stage, and the result of the first execution is invalid.

[0090] The generated transaction dependency graph is as follows Figure 4 As shown, transaction T1 needs to be executed after transaction T0 is completed. After the master node completes the above process, it sends the generated proposal block to all other verification nodes.

[0091] While waiting for the master node to generate the proposal block, all remaining verification nodes (nodes 2 to 4) will perform pre-execution operations on the transactions in the transaction pool until they receive the proposal block sent by the master node. Assuming that the verification node can complete the pre-execution of all transactions in the transaction pool before receiving the proposal block sent by the master node, the transaction storage status of all node transaction pools and completed pre-execution caches is as follows:

[0092] Node 1 (Transaction pool: T0, T1, T2, T3, T4, T5, T6, Cache: None)

[0093] Node 2 (Transaction Pool: T0, T1, T2, T3, T4, T5, T6, Cache: T0, T1, T2, T3, T4, T5, T6)

[0094] Node 3 (Transaction Pool: T0, T1, T2, T3, T4, T5, T6, Cache: T0, T1, T2, T3, T4, T5, T6)

[0095] Node 4 (Transaction Pool: T0, T1, T2, T3, T4, T5, T6, Cache: T0, T1, T2, T3, T4, T5, T6)

[0096] After the verification node receives the proposal sent by the master node, it executes the corresponding transactions T0 and T1 in sequence according to the transaction dependency graph and verifies the transaction execution results. When 2f+1 nodes can agree with the result of the proposal block, the proposal block (including transactions T0 and T1) can be successfully uploaded to the chain, and this round of consensus is completed. At this time, the transaction storage status of all node transaction pools and completed pre-execution caches is as follows:

[0097] Node 1 (Transaction Pool: T2, T3, T4, T5, T6, Cache: None)

[0098] Node 2 (Transaction Pool: T2, T3, T4, T5, T6, Cache: T2, T3, T4, T5, T6)

[0099] Node 3 (Transaction Pool: T2, T3, T4, T5, T6, Cache: T2, T3, T4, T5, T6)

[0100] Node 4 (Transaction Pool: T2, T3, T4, T5, T6, Cache: T2, T3, T4, T5, T6)

[0101] In the second round of consensus, assuming that the blockchain network elects node 2 as the master node, there are completed pre-executed transactions in the cache of node 2, so the completed pre-executed transactions are preferentially selected for packaging. At this time, the corresponding transaction conflict graph is generated according to the read-write sets of each transaction, as shown in Figure 5 As shown in the figure, taking transactions T2 and T3 as examples, T2 performs a write operation on the variable under address F, and T3 performs a read operation on the variable under address F, thereby constructing a directed edge from the write transaction to the read transaction.

[0102] The above transaction conflict graph is repeatedly used to obtain independent sets, and the transactions are divided into batches as follows Figure 6 As shown in Figure 7, during the transaction execution process, the master node can execute transactions in the order of parallel execution of transactions T2 and T4, parallel execution of transactions T3 and T5, and execution of transaction T6. After the execution is completed in the above order, the actual execution order of the transactions is that transaction T3 is executed after T2 and T4, transaction T5 is executed after T4, and transaction T6 is executed after T3 and T5. The corresponding transaction dependency graph is shown in Figure 7. After completing the packaging and generating the proposal block, the verification node will execute the transactions in the order under the transaction dependency graph and verify the results.

[0103] After this round of consensus is completed, the storage of transactions in all node transaction pools and completed pre-execution caches is as follows:

[0104] Node 1 (Transaction Pool: None, Cache: None)

[0105] Node 2 (Transaction Pool: None, Cache: None)

[0106] Node 3 (Transaction Pool: None, Cache: None)

[0107] Node 4 (Transaction Pool: None, Cache: None)

[0108] It should be noted that in the actual execution process, transactions after batching may still have transaction conflicts under optimistic parallel execution. For transactions with conflicts during parallel execution, transaction rollback and redo are still adopted to ensure the consistency of transaction execution.

[0109] The contents not described in detail in the specification of the present invention belong to the prior art known to the professional and technical personnel in the field. It is pointed out here that the above description helps those skilled in the art to understand the invention, but does not limit the protection scope of the invention. Any equivalent replacement, modification and / or simplification of the above description without departing from the essence of the invention falls within the protection scope of the invention.

Claims

1. A method for parallel execution of blockchain transactions based on pre-execution conflict detection, characterized in that: The steps include: Step 1: For a blockchain network with several nodes, the user continuously sends N transactions. Each node receives each transaction and saves it in its own transaction pool, and performs pre-execution operations. Each verification node pre-executes the transactions it receives in the idle time while waiting for the master node's proposal and saves them in the cache area. That is, each node's transaction pool contains both pre-executed transactions and transactions that have not been pre-executed. Step 2: For the current round of consensus, the master node in the blockchain network is elected, and the remaining nodes are verification nodes. The master node selects the transactions with the earliest sending time from its own transaction pool in order to package them; Step 3: Determine whether the transaction selected for packaging is a pre-execution transaction. If yes, proceed to step 4; Otherwise, go to step 6; Step 4: The master node preferentially selects the pre-executed transactions from the transaction pool for packaging, and treats each transaction as a node in the graph according to the read-write set of each transaction. For two transactions with the same address under the write set of one transaction and the read set of another transaction, a directed edge from the write point to the read point is constructed between the transactions to generate the corresponding transaction conflict graph; Step 5: Repeatedly obtain independent sets for the transaction conflict graph and perform optimistic parallel execution. The resulting transaction sequence is the transaction dependency graph, which is packaged to generate a proposal block and proceed to step 8; Step 6: For each packaged transaction, the master node performs optimistic parallel execution, records the transaction write operations in the memory cache during execution, and checks after each transaction is executed whether the data in its read set has been modified by other transactions during the execution process. If so, the transaction needs to be rolled back and redone; otherwise, the transaction read-write set takes effect and the execution result is successfully obtained; Step 7: After all packaged transactions are executed, a directed acyclic transaction dependency graph is constructed by analyzing the read-write sets of all transactions, and the proposal blocks are packaged and generated, and then proceed to step 8; Step 8. After receiving the proposal sent by the master node, each verification node executes the corresponding transaction in order according to the transaction dependency graph, and compares and verifies the execution result with the execution result of the master node to determine whether the execution result is consistent. Under the Byzantine fault-tolerant consensus protocol, each node in the blockchain is divided into 3f+1 nodes. When at least 2f+1 verification nodes agree with the result of the proposal block, the proposal block is successfully on the chain, and this round of consensus is completed; f is a natural integer; Step 9. Return to step 2, reselect the master node in the blockchain network, and execute the next round of consensus.

2. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: In the blockchain network, the master node is responsible for packaging transactions to generate proposal blocks, and the verification node is responsible for verifying the proposal blocks generated by the master node; Pre-execution operation means that the node executes the current transaction in the current environment and saves the transaction read-write set.

3. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: The master node is taken turns by each node in the chain.

4. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: The proposal block includes: transactions packaged in the block and transaction dependency graph; the packaged transactions include contract name, function name, input parameters, execution results and read-write sets.

5. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: The transaction conflict refers to at least two transactions reading and writing variables at the same address at the same time; if there is a conflict between transactions, the edges in the transaction dependency graph are constructed according to the order of execution.

6. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: The process of the master node selecting transactions to package and generate proposals includes: Prioritize the selection of pre-executed transactions in the transaction pool for packaging. When the number of pre-executed transactions cannot reach the block limit, continue to select unexecuted transactions in the transaction pool for packaging.

7. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: The step of constructing a transaction conflict graph by the master node includes: Determine whether there are overlapping addresses in the read set of one transaction and the write set of another transaction. If so, it is considered that the write operation of one transaction has caused a conflict with the read operation of another transaction. In the transaction conflict graph, a directed edge from write to read is constructed between the transactions represented by the nodes; The above edge building operation is performed on all the completed pre-execution transactions taken out to construct a transaction conflict directed graph.

8. A method for parallel execution of blockchain transactions based on pre-execution conflict detection as claimed in claim 1, characterized in that: In the step 5, independent sets are repeatedly obtained for the transaction conflict directed graph until there are no nodes in the transaction conflict directed graph. At this time, transactions under the same independent set are non-conflicting transactions, and optimistic parallel execution is attempted; transactions under different independent sets are conflicting transactions, and are processed in batches according to any serial order; for transactions that have not been processed, they are executed in an optimistic parallel manner with all transactions.

Images