A blockchain transaction parallel execution method based on pre-execution conflict detection

Abstract

The application discloses a kind of parallel execution methods of blockchain transaction based on pre-execution conflict detection, belong to blockchain field;Specifically be: node receives transaction that user sends, and the idle time of waiting main node proposal is verified to the pre-execution operation of received transaction;Judgment elected main node packaged transaction is pre-execution transaction, if yes, according to the read-write set of each transaction, generate transaction conflict graph;And repeatedly seek independent set, main node carries out optimistic parallel execution and obtains transaction dependence graph and is packaged into proposal block;Otherwise, main node carries out optimistic parallel execution to each transaction not pre-executed, constructs directed acyclic transaction dependence graph, and is packaged to generate proposal block;Finally, each verification node executes corresponding transaction according to transaction dependence graph in sequence, and the execution result is compared and verified with the execution result of main node, when result is consistent, then the proposal block is successfully chained, and this round consensus is completed;The application improves optimistic parallel execution efficiency.

Description

Technical Field

[0001] This invention belongs to the field of blockchain, specifically a method for parallel execution of blockchain transactions based on pre-execution conflict detection. Background Technology

[0002] Cryptocurrencies were first proposed by Satoshi Nakamoto in his work in 2008. Blockchain, as the underlying technology, in its 1.0 era, employed cryptographic principles to ensure the traceability and immutability of transactions, while replacing third-party authoritative institutions with purely mathematical methods, introducing a new decentralized characteristic. In the 2.0 era, the underlying blockchain technology introduced the concept of smart contracts, at which point blockchain was applied as an independent technology in multiple fields.

[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 traditional field of encrypted digital currencies. It provides new solutions to problems such as evidence preservation, trust, and data governance in economic development and has broad application prospects in many fields such as finance, education, healthcare, agriculture, and supply chain.

[0004] In blockchain technology, the addition of smart contracts endows the blockchain with programmability. However, to ensure the consistency of the final transaction execution results, most blockchains, such as Ethereum, adopt a serial transaction execution method to prevent inconsistencies between nodes. To fully utilize node computing resources, it is necessary to consider using parallel methods to optimize smart contract execution. However, in the process of parallel transaction execution, if different transactions read and write data to the same address, the execution results of some transactions will become invalid and need to be rolled back. If too many transaction rollbacks occur, it will generate additional overhead and may even lead to security issues. Summary of the Invention

[0005] This invention addresses the issues of low efficiency in serial scheduling mechanisms and additional overhead caused by transaction rollbacks in existing blockchain transactions. It proposes a parallel execution method for blockchain transactions based on pre-execution conflict detection, which maximizes the parallel execution of transactions while minimizing transaction rollbacks in blockchains using the TBFT consensus mechanism.

[0006] The method for parallel execution of blockchain transactions with pre-execution conflict detection includes 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 to its own transaction pool, and performs pre-execution operations.

[0008] In a blockchain network, there is one master node 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 refers to: the node executing the current transaction in the current environment and saving the transaction read / write set;

[0010] During the idle time while waiting for the master node's proposal, each validator node performs pre-execution operations on the transactions it receives successively and saves them to the cache area; that is, each node's transaction pool contains both pre-executed transactions and transactions that have not been pre-executed.

[0011] Step 2: For the current round of consensus, elect a master node in the blockchain network. The master node selects the transaction with the earliest sending time from its own transaction pool and packages it accordingly.

[0012] The master node is held by each node in the chain in turn;

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

[0014] Step 4: The master node first selects pre-executed transactions from the transaction pool and packages them. Based on the read and write sets of each transaction, each transaction is regarded as a node in the graph. 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 write to read is constructed between the transactions to generate the corresponding transaction conflict graph.

[0015] Step 5: Repeatedly obtain independent sets from the transaction conflict graph, perform optimistic parallel execution, and the resulting transaction order is the transaction dependency graph. Package it to generate a proposal block and proceed to Step 8.

[0016] The proposal block contains: the transactions packaged in the block (including contract name, function name, input parameters, execution result, and read / write set) and a transaction dependency graph (transaction execution order).

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

[0018] Step 7: After all packaged transactions have been executed, construct a directed acyclic transaction dependency graph by analyzing the read and write sets of all transactions, package it to generate a proposal block, and proceed to Step 8.

[0019] If there are conflicts between transactions, the edges in the transaction dependency graph are constructed according to the order in which they are executed.

[0020] A conflict occurs when at least two transactions simultaneously read from or write to a variable at the same address.

[0021] Step 8: After receiving the proposal sent by the master node, each verification node executes the corresponding transaction according to the transaction dependency graph and compares 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, the nodes in the blockchain are divided into 3f+1 nodes. When at least 2f+1 verification nodes reach a consensus with the result of the proposal block, the proposal block is successfully uploaded to the chain, and this round of consensus is completed.

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

[0023] The advantages of this invention are:

[0024] 1. A blockchain transaction parallel execution method based on pre-execution conflict detection. For each node under the TBFT consensus protocol, by fully utilizing the idle resources of the validator nodes while waiting for the master node to generate a proposal, a preliminary read-write set is obtained through transaction pre-execution operations. When a node becomes the master node and generates a proposal, it can use the preliminary read-write set obtained through pre-execution to perform optimistic parallel execution of potentially conflicting transactions in batches, 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 directed graph of transaction conflicts using the initial read / write set obtained from pre-execution, the transactions under the directed graph are divided into multiple independent sets by repeatedly obtaining independent sets from the directed graph. By executing transactions in batches under different independent sets in parallel, parallel execution is fully realized while reducing conflicts, thereby maximizing transaction execution efficiency. Attached Figure Description

[0026] Figure 1 This is a flowchart of a blockchain transaction parallel execution method based on pre-execution conflict detection according to the present invention;

[0027] Figure 2 This is a flowchart illustrating the specific implementation of a blockchain transaction parallel execution method based on pre-execution conflict detection according to the present invention.

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

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

[0030] Figure 5 In this embodiment of the invention, a corresponding transaction conflict graph is generated based on the transaction read / write set;

[0031] Figure 6 This embodiment of the invention involves repeatedly obtaining independent sets of transaction batching graphs from the transaction conflict graph;

[0032] Figure 7 This is the transaction dependency graph obtained after executing transactions in parallel in this embodiment of the invention. Detailed Implementation

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

[0034] This invention discloses a method for parallel execution of blockchain transactions based on pre-execution conflict detection, such as... Figure 1 As shown, it includes the following steps:

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

[0036] The system receives smart contract function call requests (i.e., transactions) sent by users through the client. These transactions are then sent to various nodes for storage and await further processing. There are several methods for storing transactions on nodes; the module that temporarily stores unexecuted transactions on each node will be referred to as a transaction pool.

[0037] For most blockchain systems using the TBFT consensus mechanism, nodes are primarily categorized into two types during the consensus process: master nodes and validator nodes. To ensure that the final state of each node in the blockchain remains consistent, each node needs to ensure that the transactions it executes are from the same batch and that the execution order of the transactions is consistent. To meet these requirements, in each round of consensus, a node is elected as the master node to generate proposals, and the remaining nodes act as validator nodes to verify the proposals generated by the master node.

[0038] First, the master node selects a batch of unexecuted transactions to be executed in parallel, and generates a directed acyclic graph between the transactions to determine the order in which the verification nodes execute the transactions. After the master node generates the proposal, it sends it to the verification nodes. The verification nodes will execute the transactions 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, while validator nodes are waiting for the master node to generate a proposal, only the master node is currently executing transactions on the blockchain. Other validator nodes and their respective machines are in a resource-idle state. At this time, validator nodes can select unexecuted transactions from the transaction pool for parallel pre-execution. Through pre-execution, they obtain the addresses that may be subject to read / write operations during the transaction's execution, generate a preliminary read / write set for storage, and mark the corresponding transactions as completed pre-execution transactions, waiting for the node to become a master node later. Once a validator node receives a proposal from the master node, it stops pre-execution and enters the subsequent consensus process.

[0040] For blockchain systems that use a key-value model for storage, the read / write set of a transaction in the blockchain refers to the set of keys corresponding to the addresses where the data for the read and write operations of that transaction are located.

[0041] Pre-execution operation refers to: the node executing the current transaction in the current environment and saving the transaction read / write set;

[0042] During the idle time while waiting for the master node's proposal, each validator node performs pre-execution operations on the transactions it receives successively and saves them to the cache area; that is, each node's transaction pool contains both pre-executed transactions and transactions that have not been pre-executed.

[0043] Before a validator receives a proposal from the master node and enters the subsequent verification phase, it can continuously pre-execute unexecuted transactions to obtain a preliminary read / write set of the corresponding transactions. This set is used to schedule transactions in batches when the validator becomes the master node and generates a proposal.

[0044] like Figure 2 As shown, the transaction pool is primarily used as a cache area to store unexecuted transactions in the blockchain system. All transactions sent by clients are first added to the transaction pool. Specifically, the queue area within the transaction pool stores transactions that have not yet been processed, while the pending queue area stores transactions selected by the master node that are currently being packaged to generate proposals or have completed pre-execution. Furthermore, a cache for pre-executed transactions is allocated for each node to additionally store copies of pre-executed transactions and the corresponding preliminary read / write sets obtained from pre-execution.

[0045] While the validator node waits for the master node to send a proposal, it continuously selects transactions in batches from its local transaction pool queue for pre-execution, and simultaneously transfers the selected transactions from the queue to the pending queue. For each batch of selected transactions, since the execution results obtained through pre-execution are not directly used, but rather the transaction read / write set obtained through pre-execution is used to guide the batch-by-batch parallel execution of transactions in the subsequent proposal generation process, all retrieved transactions can be executed simultaneously during the pre-execution phase. For transactions that have completed pre-execution, the transaction and its corresponding preliminary pre-execution read / write set are added to the cache of completed pre-execution transactions. After receiving the proposal from the master node, the validator node stops the pre-execution operation and enters the subsequent consensus process.

[0046] During this process, the transactions that have completed pre-execution only obtain an incomplete and inaccurate set of transaction reads and writes, and do not obtain directly usable transaction execution results. At this point, these transactions are essentially still unexecuted transactions.

[0047] Step 2: For the current round of consensus, elect a master node in the blockchain network. The master node selects the transaction with the earliest sending time from its own transaction pool and packages it accordingly.

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

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

[0050] Once a node is elected as the master node, it can prioritize selecting pre-executed transactions for proposal generation. If the number of pre-executed transactions in the cache does not reach the upper limit required for proposal generation, it can continue to select unexecuted transactions that have not undergone any processing from the transaction pool queue and package them with pre-executed transactions to generate proposals. For the selected pre-executed transactions, the subsequent steps of conflict-directed graph construction will be performed.

[0051] Specifically, unexecuted transactions selected from the transaction pool queue for packaging into proposals will be transferred to the transaction pool pending queue, such as... Figure 2 As shown.

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

[0053] Step 4: The master node first selects pre-executed transactions from the transaction pool and packages them. Based on the read and write sets of each transaction, each transaction is regarded as a node in the graph. 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 write to read is constructed between the transactions to generate the corresponding transaction conflict graph.

[0054] When generating a proposal, the masternode can select a batch of transactions to package into a block. During the proposal generation process, transactions that have already been pre-executed are selected for packaging first. If the number of pre-executed transactions has not reached the block transaction limit, unexecuted transactions can be selected from the transaction pool for packaging.

[0055] A conflicting transaction is one in which the read set of a transaction contains a duplicate address key in the write set of another transaction.

[0056] For the pre-executed transactions with preliminary read / write sets selected by the master node, a conflict-directed graph is constructed based on the preliminary read / write sets. Transactions are treated as nodes in the conflict-directed graph. For transaction A, which performs a write operation on data at the same address, and transaction B, which performs a read operation, a directed edge is constructed from write to read (i.e., from transaction A to transaction B).

[0057] Step 5: Repeatedly obtain independent sets from the transaction conflict graph, perform optimistic parallel execution, and the resulting transaction order is the transaction dependency graph. Package it 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 result, and read / write set) and the transaction dependency graph (transaction execution order).

[0059] The optimistic parallel execution described refers to the process of assuming no conflicts among a selected batch of transactions for optimistic parallel execution. All transactions are executed directly in parallel, and only when a conflict is detected are they rolled back and redone. After optimistic parallel execution, conflicting transactions, through repeated rollbacks and redoes, will result in a serialized transaction execution sequence. This sequence can be represented by a directed acyclic graph (DAG) to show the execution dependencies between all transactions, and to verify that nodes execute conflicting transactions in a deterministic order.

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

[0061] The conflict between transactions described here refers to a situation where the address key contained in the read set of transaction A and the address key contained in the write set of transaction B share the same portion. This can be considered as transactions A and B being executed concurrently, where transaction B's write operation modifies the data read by transaction A's read operation, thus causing a parallel conflict between the two transactions. These two transactions can be treated as two nodes in a directed conflict graph, and a directed edge can be created from transaction B to transaction A, representing the conflict caused by transaction B's write operation on transaction A's read operation.

[0062] Using the above method, a conflict-directed graph is established for all retrieved pre-execution transactions. Since unexecuted transactions that have not undergone any processing do not possess any read / write set information, no operations are performed on unprocessed transactions. After the conflict-directed graph is constructed, because the actual read / write set of a transaction and its execution result are affected by the current execution environment, the read / write set obtained during transaction pre-execution may not be completely consistent with the read / write set after the actual master node packages and executes the transaction. Therefore, the read / write set obtained during pre-execution is only used to attempt to separate potentially conflicting transactions. The consistency between the actual transaction submission order and the transaction execution order among nodes is guaranteed by optimistic parallelism and the generated directed acyclic graph.

[0063] After constructing the conflict directed graph, the transactions selected by the master node are batched and executed in optimistic parallel. The conflict directed graph shows that for transactions that have completed pre-execution, there are directed edges between directly adjacent transactions in the conflict graph, indicating that two adjacent transactions are very likely to have read-write conflicts during actual execution, while non-adjacent transactions are less likely to have read-write conflicts during actual execution.

[0064] Based on this, the independent sets are repeatedly calculated for the directed graph of transaction conflicts. A batch of transactions selected by the master node are then divided into different independent sets and an unprocessed transaction set, such as... Figure 3 As shown. First, for the selected transactions that have not undergone any processing, they are directly added to the set of unprocessed transactions. For transactions in the conflicting directed graph, the independent set of the directed graph is obtained. After obtaining all non-adjacent transactions in the directed graph, the transactions and all their corresponding edges are removed from the conflicting directed graph. Then, the independent set of the obtained subgraph is obtained again. The above steps are repeated until the conflicting directed graph does not contain any transactions, thus completing the batching of transactions.

[0065] Based on the above, using the read / write set obtained during pre-execution as the criterion for judging the approximation of the actual execution result, it can be considered that the possibility of transaction conflicts among transactions under the same independent set is low, and they can be optimistically executed in parallel simultaneously; the possibility of transaction conflicts among transactions between different independent sets is high, and transaction rollback and redo will occur when optimistically executed in parallel simultaneously, so they will not be optimistically executed in parallel simultaneously; transactions under the unprocessed transaction set can be optimistically executed in parallel with any other transactions because the information is unknown.

[0066] After constructing the directed graph of transaction conflicts, independent sets are obtained from the graph. The transactions represented by nodes in these independent sets are those that do not have read / write set conflicts with each other. After removing the corresponding nodes from the conflicting directed graph, independent sets are obtained again, and this process is repeated until the conflicting directed graph contains no nodes. Multiple independent sets obtained in this way are executed in batches sequentially. Transactions within the same independent set are less likely to conflict during actual execution and can be optimistically executed in parallel. Transactions within different independent sets are more likely to conflict and need to be executed separately. For unexecuted transactions, since they do not contain the initial read / write set, optimistic parallel execution is performed directly on these unexecuted transactions individually.

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

[0068] During transaction execution, version checks are performed on the read and write sets of the transaction at that execution phase. If a transaction that performs a read operation on data at a certain address during execution is subsequently modified by a write operation of another committed transaction, the transaction will be rolled back to ensure the consistency of the transaction execution result.

[0069] Step 7: After all packaged transactions have been executed, construct a directed acyclic transaction dependency graph by analyzing the read and write sets of all transactions, package it to generate a proposal block, and proceed to Step 8.

[0070] If there are conflicts between transactions, the edges in the transaction dependency graph are constructed according to the order in which they are executed.

[0071] A conflict occurs when at least two transactions simultaneously read from or write to a variable at the same address.

[0072] Step 8: After receiving the proposal sent by the master node, each verification node executes the corresponding transaction according to the transaction dependency graph and compares 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, the nodes in the blockchain are divided into 3f+1 nodes. When at least 2f+1 verification nodes reach a consensus with the result of the proposal block, the proposal block is successfully uploaded to the chain, and this round of consensus is completed.

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

[0074] Example:

[0075] The current blockchain network has four nodes, designated Node 1 through Node 4. Assume that seven transactions (T0 through T6) are continuously sent to this blockchain network, and all transactions will be successfully executed and recorded on the chain in two rounds of consensus. The actual read / write sets involved in these seven transactions are as follows, and it is assumed that the read / write sets obtained by the subsequent verification nodes during 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] Under 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 pre-execution cache are as follows:

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

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

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

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

[0088] At this point, Node 1 acts as the master node. Since there are no completed pre-execution transactions in the cache, it selects transactions from the transaction pool to attempt to package them. Assume that in this round of consensus, Node 1 selects transactions T0 and T1 to package.

[0089] Since the two transactions above simultaneously read and write to the variable at address A, during the parallel execution process on node 1, after transaction T1 finishes execution, it discovers that the data it read has been modified by transaction T0. At this point, transaction T1 will re-execute based on the data modified by transaction T0. Therefore, transaction T1 is actually executed twice during the master node's packaging phase, 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 will send the generated proposal block to all other validator nodes.

[0091] While waiting for the master node to generate the proposal block, all remaining validator nodes (nodes 2-4) will pre-execute the transactions in the transaction pool until they receive the proposal block sent by the master node. Assuming that the validator nodes can complete the pre-execution of all transactions in the transaction pool before receiving the proposal block sent by the master node, the transaction pool and the transaction storage status of all nodes at this time are as follows:

[0092] Node 1 (Transaction pools: 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 validator node receives the proposal sent by the master node, it executes the corresponding transactions T0 and T1 sequentially according to the transaction dependency graph and verifies the transaction execution results. When 2f+1 nodes can reach a consensus with the result of the proposed block, the proposed block (including transactions T0 and T1) can be successfully added to the chain, and this round of consensus is completed. At this time, the transaction pools of all nodes and the transaction storage status in the pre-execution cache are 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 the blockchain network elects node 2 as the master node, and node 2's cache contains pre-executed transactions, these pre-executed transactions are prioritized for packaging. At this point, a corresponding transaction conflict graph is generated based on the read / write sets of each transaction, as shown below. 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, thus constructing a directed edge from the write transaction to the read transaction.

[0102] The independent sets are repeatedly obtained from the above transaction conflict graph, and the transactions are divided into batches as follows: Figure 6 As shown, during the master node's transaction execution, transactions T2 and T4 can be executed in parallel, followed by transactions T3 and T5, and then transaction T6. After execution in this order, the actual execution order of the transactions is: transaction T3 is executed after T2 and T4, transaction T5 after T4, and transaction T6 after T3 and T5, resulting in the corresponding transaction dependency graph shown in Figure 7. After the proposal block is generated, the verification nodes will execute the transactions and verify the results in the order shown in the transaction dependency graph.

[0103] After this round of consensus is completed, the transaction storage status of all nodes' transaction pools and the transactions already pre-executed in the cache 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 actual execution, transactions may still conflict even under optimistic parallel execution. For transactions that conflict during parallel execution, transaction rollback and redoing will still be implemented to ensure the consistency of transaction execution.

[0109] Contents not described in detail in this specification are prior art known to those skilled in the art. It is hereby indicated that the above description is intended to help those skilled in the art understand this invention, but does not limit the scope of protection of this invention. Any equivalent substitutions, modifications, improvements, and / or simplifications of the above descriptions that do not depart from the essential content of this invention fall within the scope of protection of this invention.

Claims

1. A method for parallel execution of blockchain transactions based on pre-execution conflict detection, characterized in that, Comprise the following steps: Step one, for the blockchain network with several nodes, the user continuously sends N transactions, each node successively receives each transaction and saves it to the respective transaction pool, and performs a pre-execution operation; Each verification node performs a pre-execution operation on the transactions received successively in the idle time waiting for the proposal of the main node, and saves them to the cache area; that is, there are pre-executed transactions and transactions that have not been pre-executed in the transaction pool of each node at the same time; Step two, for the current round of consensus, the main node in the blockchain network is elected, and the remaining nodes are verification nodes, the main node selects the transaction with the earliest sending time from its own transaction pool in order to pack; Step three, determine whether the selected transaction for packing is a pre-executed transaction, if so, go to step four; Otherwise, go to step six; Step four, the main node preferentially selects a transaction that has completed pre-execution from the transaction pool for packing, and according to the read-write set of each transaction, each transaction is regarded as a node in the graph, and a directed edge from the write to the read is constructed between two transactions with the same address in the write set of one transaction and the read set of another transaction, generating a corresponding transaction conflict graph; Step five, repeatedly find independent sets for the transaction conflict graph, perform optimistic parallel execution, and the transaction order obtained is the transaction dependency graph, and a proposal block is packed and generated, and step eight is entered; Step six, for each transaction packed, the main node performs optimistic parallel execution, and records the write operation of the transaction in the memory cache during execution, and after each transaction is executed, checks whether the data in the read set is modified by other transactions during execution, if so, the transaction needs to be rolled back and redone; otherwise, the read-write set of the transaction takes effect and successfully obtains the execution result; Step seven, after all the transactions packed are executed, a directed acyclic transaction dependency graph is constructed by analyzing the read-write sets of all transactions, and a proposal block is packed and generated, and step eight is entered; Step eight, after each verification node receives the proposal sent by the main node, it executes the corresponding transaction according to the transaction dependency graph, and compares and verifies the execution result with the execution result of the main node to determine whether the execution results are consistent, and under the Byzantine fault tolerance consensus protocol, the nodes in the blockchain are divided into 3f+1 nodes, and when at least 2f+1 verification nodes agree with the result of the proposal block, the proposal block is successfully chained, and the current round of consensus is completed; f is a natural integer; Step nine, return to step two, and select a new main node in the blockchain network to perform the next round of consensus.

2. The parallel execution of blockchain transactions based on pre-execution conflict detection method according to claim 1, wherein, In the blockchain network, the main node is responsible for packing transactions to generate a proposal block, and the verification node is responsible for verifying the proposal block generated by the main node; The pre-execution operation refers to the execution of the current transaction under the current environment, and the saving of the transaction read-write set. 3.The method of claim 1, wherein, The main node is rotated among the nodes in the chain.

4. The method of claim 1, wherein the method further comprises: The proposal block contains: the packed transactions in the block and the transaction dependency graph; the packed transactions contain the contract name, function name, input parameter, execution result and read-write set.

5. The method of claim 1, wherein, The transaction conflict refers to that at least two transactions simultaneously read and write a same address variable; if there is a conflict between the transactions, edges in a transaction dependency graph are constructed according to the execution order.

6. The method of claim 1, wherein, The proposal generation process of the main node selecting and packing transactions comprises: Preferentially selecting and packing the transactions that have completed pre-execution in the transaction pool, and when the number of the transactions that have completed pre-execution cannot reach the upper limit of the block, continuing to select and pack the transactions that have not been executed in the transaction pool.

7. The method of claim 1, wherein, The step of the main node constructing a transaction conflict graph comprises: Judging whether there is an address that is overlapped in a read set of a transaction and a write set of another transaction, if there is, considering that the write operation of the transaction causes a conflict to the read operation of the other transaction, and constructing a write-to-read directed edge between the transactions represented by the nodes in the transaction conflict graph; Performing the above edge construction operation on all the transactions that have completed pre-execution to construct a transaction conflict directed graph. 8.The method of claim 1, wherein, In the step five, repeatedly seeking independent sets of the transaction conflict directed graph until there is no node in the transaction conflict directed graph, at this time, the transactions under the same independent set are the transactions that do not exist conflicts and are tried to be executed in an optimistic parallel manner; the transactions under different independent sets are the transactions that exist conflicts and are processed in batches according to an arbitrary serial order; for the transactions that have not been processed, all the transactions are executed in an optimistic parallel manner.

Images