Method and system for parallel execution of smart contract transactions
By recording the usage of state locks in a simulated environment, smart contract transactions that can be executed in parallel are identified, and transaction execution plans are generated. This solves the problem that smart contract transactions cannot be executed in parallel and improves transaction execution efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- LINGSHU TECH CO LTD
- Filing Date
- 2022-12-29
- Publication Date
- 2026-06-12
Smart Images

Figure CN116308343B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of blockchain, and in particular to a method and system for parallel execution of smart contract transactions. Background Technology
[0002] Smart contracts are one of the most important technologies in blockchain. Blockchain transactions are essentially calls to smart contract methods. Smart contracts contain state data, which typically cannot be accessed in parallel, otherwise inconsistent results will occur.
[0003] There are two main factors affecting blockchain efficiency: consensus efficiency and transaction execution efficiency, specifically the efficiency of smart contract execution. The technical characteristics of blockchain require that smart contract transactions be executed repeatedly on different nodes, and the results must be consistent—that is, determinism. To achieve this, smart contract transactions need to be executed serially to ensure that the final result of the internal state data of the smart contract is consistent when run repeatedly on different nodes. However, this affects the efficiency of smart contract transaction execution.
[0004] There is currently no effective solution to the problem that existing technologies cannot improve the efficiency of smart contract transaction execution. Summary of the Invention
[0005] To address the aforementioned issues, this invention provides a method and system for parallel execution of smart contract transactions. By recording the usage of state locks corresponding to the state data accessed by smart contract transactions during parallel execution, the system determines smart contract transactions that can be executed in parallel. This ensures determinism while allowing for the parallel execution of smart contract transactions, thereby resolving the problem of not being able to improve the execution efficiency of smart contract transactions.
[0006] To achieve the above objectives, embodiments of the present invention provide a method for parallel execution of smart contract transactions, comprising: packaging a set of smart contract transactions into transaction blocks; in a simulated environment, completing the parallel execution process of all smart contract transactions in the set of smart contract transactions for a preset number of rounds, recording the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, and obtaining a set of state lock usage parameters corresponding to each round; selecting the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters; determining the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially according to the target set of state lock usage parameters, and obtaining a transaction execution plan; packaging the transaction blocks and the transaction execution plan for consensus; and executing all smart contract transactions in the transaction blocks according to the consensus-agreed transaction execution plan.
[0007] Further, optionally, the union of all smart contract transactions in the smart contract transaction set that has completed a preset number of rounds.
[0008] The execution process records the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, including: 5. In each round, when any state data is accessed by the current smart contract transaction, the state lock corresponding to that state data is acquired and...
[0009] Obtain the current call count corresponding to the state lock; if the current smart contract transaction is completed, release the state lock, increment the current call count, and combine the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count to form the state lock usage parameters corresponding to the state data; wherein, the current call count is initially 0.
[0010] Further optionally, the parallel execution process of all smart contract transactions in the smart contract transaction set that has completed a preset number of rounds, and the recording of the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, further includes: real-time detection of whether each state lock is in a deadlock state; when any state lock is in a deadlock state, deadlock recovery is performed on the state lock in the deadlock state.
[0011] Further optionally, the step of determining the smart contract that can be executed in parallel based on the target state lock using a parameter set...
[0012] For smart contract transactions that require sequential execution, a transaction execution plan is obtained, including: generating a partial order graph of smart contract transactions using parameter set 5 based on the target state lock; and determining smart contract transactions that can be executed in parallel based on the partial order graph.
[0013] For smart contract transactions that require sequential execution, a transaction execution plan can be obtained.
[0014] Further optionally, the step of selecting the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters includes: recording the execution time when all smart contract transactions in each round are completed;
[0015] Select the set of parameters for the state lock corresponding to the round with the shortest execution time as the set of parameters for the target state lock.
[0016] 0 On the other hand, embodiments of the present invention also provide a smart contract transaction parallel execution system, including: transaction packaging
[0017] The module is used to package a set of smart contract transactions into transaction blocks; the smart contract pre-execution module is used to complete the parallel execution process of all smart contract transactions in the set of smart contract transactions in a preset number of rounds in a simulated environment, record the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, and obtain the state lock usage parameters for each round.
[0018] The parameter set selection module is used to select the optimal state lock parameter set 5 as the target state lock parameter set from multiple state lock parameter sets; the transaction sorting module is used to determine the target state lock parameter set.
[0019] The system generates a transaction execution plan by combining smart contract transactions that can be executed in parallel and those that need to be executed sequentially; a consensus module is used to package the transaction blocks and transaction execution plans for consensus; and an execution module is used to execute all smart contract transactions in the transaction blocks according to the consensus-based transaction execution plan.
[0020] Further optionally, the smart contract pre-execution module includes: a state lock information acquisition submodule, used to acquire the state lock corresponding to any state data and the current call count corresponding to the state lock when any state data is accessed by the current smart contract transaction in each round 0; and a state lock usage parameter generation submodule, used to release the state lock if the current smart contract transaction is completed, increment the current call count by one, and combine the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count to form the state lock usage parameters corresponding to the state data; wherein, the current call count is initially 0.
[0021] Further optionally, the smart contract pre-execution module includes: a deadlock detection submodule, used to detect in real time whether each state lock is in a deadlock state; and a deadlock recovery submodule, used to perform deadlock recovery on any state lock in a deadlock state when any state lock is in a deadlock state.
[0022] Further optionally, the transaction sorting module includes: a partial order graph generation submodule, used to generate a smart contract transaction partial order graph using a parameter set based on the target state lock; and a transaction execution plan generation submodule, used to determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially based on the smart contract transaction partial order graph, and obtain a transaction execution plan.
[0023] Further optional, the selection module includes: a time recording submodule, used to record the execution time of all smart contract transactions in each round; and an optimal set selection submodule, used to select the set of state lock parameters corresponding to the round with the shortest execution time as the target set of state lock parameters.
[0024] The above technical solution has the following beneficial effects: by executing smart contract transactions in parallel in an independent environment, the usage of state locks can be determined. Based on the usage of state locks, transactions that can be executed concurrently can be determined and executed concurrently according to the transaction execution plan. After execution according to the transaction execution plan, all state data eventually become consistent, thereby improving the execution efficiency of transactions while ensuring determinism. Attached Figure Description
[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0026] Figure 1 This is a flowchart of the parallel execution method for smart contract transactions provided in an embodiment of the present invention;
[0027] Figure 2 This is a flowchart of the state lock parameter generation method provided in an embodiment of the present invention;
[0028] Figure 3 This is a flowchart of the deadlock detection method provided in the embodiments of the present invention;
[0029] Figure 4 This is a flowchart of the transaction execution plan generation method provided in an embodiment of the present invention;
[0030] Figure 5 This is a flowchart of the method for determining the target state lock using a parameter set provided in an embodiment of the present invention;
[0031] Figure 6 This is a schematic diagram of the structure of the smart contract transaction parallel execution system provided in an embodiment of the present invention;
[0032] Figure 7 This is a schematic diagram of the structure of the submodule of the smart contract pre-execution module provided in this embodiment of the invention, which is used to generate state lock usage parameters;
[0033] Figure 8 This is a schematic diagram of the structure of a sub-module of the smart contract pre-execution module for detecting deadlock provided in an embodiment of the present invention;
[0034] Figure 9 This is a schematic diagram of the transaction sorting module provided in an embodiment of the present invention;
[0035] Figure 10 This is a schematic diagram of the selection module provided in an embodiment of the present invention.
[0036] Attached diagram labels: 100 - Transaction Packaging Module; 200 - Smart Contract Pre-Execution Module; 2001 - State Lock Information Acquisition Submodule; 2002 - State Lock Usage Parameter Generation Submodule; 2003 - Deadlock Detection Submodule; 2004 - Deadlock Recovery Submodule; 300 - Selection Module; 3001 - Time Recording Submodule; 3002 - Optimal Set Selection Submodule; 400 - Transaction Sorting Module; 4001 - Partial Order Graph Generation Submodule; 4002 - Transaction Execution Plan Generation Submodule; 500 - Consensus Module; 600 - Execution Module. Detailed Implementation
[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0038] To address the problem of the inability to execute smart contract transactions in parallel in existing technologies, embodiments of the present invention provide a method for parallel execution of smart contract transactions. Figure 1 This is a flowchart of the parallel execution method for smart contract transactions provided in an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes:
[0039] S1. Package the smart contract transaction set into a transaction block;
[0040] Smart contracts typically consist of state data and methods. The state data is stored in the blockchain ledger, and calling smart contract methods will change the state data.
[0041] Blockchain nodes package smart contract transactions from the transaction pool into a transaction block B. Transaction block B is a set of smart contract transactions, represented as {t1, t2, ... t...} i}
[0042] S2. In the simulation environment, complete the parallel execution process of all smart contract transactions in the smart contract transaction set of the preset rounds, record the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, and obtain the state lock usage parameter set corresponding to each round.
[0043] Parallel execution is implemented in an isolated runtime environment where all state data is independent of the actual ledger. Modifications to the state data are only effective within this environment, and each execution process in this environment is called a pre-execution process.
[0044] Allocate a thread to each smart contract transaction in the smart contract transaction set so that all smart contract transactions can be executed in parallel.
[0045] The state data of a smart contract is protected by state locks. Each piece of state data corresponds to a state lock. Only smart contract transactions that have acquired a state lock can be executed. Smart contract transactions that have not acquired a state lock must wait until they do. When the logic in a smart contract transaction accesses state data, it first acquires the state lock, then performs the state data access operation, and finally, after the entire smart contract transaction is completed, it submits the transaction and releases the held state lock.
[0046] In this embodiment, the smart contract transactions are executed in parallel in multiple rounds according to a preset sequence. Each round consists of executing all smart contract transactions in the smart contract transaction set. Each round establishes an independent execution environment. In each round, the usage of state locks corresponding to the accessed state data during the parallel execution of smart contract transactions is recorded; that is, the state lock uses parameter 0. All state lock usage parameters in this round constitute a set of state lock usage parameters. After executing the process in multiple rounds according to the preset sequence, multiple sets of state lock usage parameters can be generated.
[0047] As an optional implementation method, the preset number of rounds is 3.
[0048] S3. Select the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters;
[0049] The optimal set of state lock parameters, denoted as L, is selected from the multiple generated sets of state lock parameters. The selection criteria can be set according to the actual situation. The selected target set of state lock parameters will participate in the formulation of subsequent transaction execution plans to improve the efficiency of smart contract transaction execution.
[0050] S4. Based on the target state lock, use the parameter set to determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially, and obtain the transaction execution plan;
[0051] Examine the usage of each state lock in the parameter set L of the target state lock. For multiple smart contract transactions using the same state lock, they must be executed in a certain order; that is, these smart contract transactions cannot be executed in parallel, but only sequentially. For multiple smart contract transactions using different state locks, there is no sequential execution requirement, so these smart contracts can be executed in parallel. Formulate a transaction execution plan P according to the above rules.
[0052] For example, transactions 1 and 2 using state lock 1 need to be executed serially, while for transaction 3 using state lock 2, transactions 1 and 2 can be executed in parallel with transaction 3.
[0053] S5. Package the transaction blocks and transaction execution plans for consensus;
[0054] The block nodes package transaction block B and its corresponding transaction execution plan P into a consensus.
[0055] S6. Execute all smart contract transactions in the transaction block according to the consensus-based transaction execution plan.
[0056] During execution, all smart contract transactions in transaction block B are scheduled and executed according to the consensus-based transaction execution plan P. Specifically, smart contract transactions that can be executed in parallel within the consensus-based transaction execution plan P are executed concurrently, while other smart contract transactions that need to be executed sequentially are executed according to their execution order. This ensures that transactions that can be executed in parallel can be executed in parallel, and that all state data eventually becomes consistent after execution according to the transaction execution plan.
[0057] As an optional implementation method, Figure 2 This is a flowchart of the state lock usage parameter generation method provided in this embodiment of the invention. It completes the parallel execution process of all smart contract transactions in a preset round of smart contract transaction set, and records the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, including:
[0058] S201. In each round, when any state data is accessed by the current smart contract transaction, obtain the state lock corresponding to the state data and obtain the current call count corresponding to the state lock.
[0059] S202. If the current smart contract transaction is completed, release the state lock, increment the current call count, and combine the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count to form the state lock usage parameters corresponding to the state data; wherein, the current call count is initially 0.
[0060] When a certain state data (using d) i (This indicates that) when the current smart transaction needs to access the state data for the first time, it needs to acquire the state lock (represented by l) corresponding to that state data. i (This is indicated by the code). After executing the entire current smart transaction, request the release of all state locks acquired during runtime. Each state lock corresponds to a monotonically increasing call count (using l). ci (This indicates the current call count). After each smart contract transaction uses the state lock once, the current call count is incremented when the state lock is released. ciAdd one, then record the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count as (t). i ,l i ,l ci ), which refers to the parameters used by the state lock.
[0061] For example, when state lock 1 is invoked for the first time, the initial number of invocations is 0, and the transaction invoking the state lock is transaction 1. At this time, the current number of invocations is incremented by 1, resulting in 1. The parameters for using the state lock are (transaction 1, state lock 1, 1). After state lock 1 is released; when state lock 1 is invoked for the second time, the transaction invoking the state lock is transaction 2. At this time, the current number of invocations is incremented by 1, resulting in 2. The parameters for using the state lock are (transaction 2, state lock 1, 2). After state lock 1 is released.
[0062] All state locks use parameters to form the target state lock parameter set L = {(t i ,l i ,l ci )}.
[0063] As an optional implementation method, Figure 3 This is a flowchart of the deadlock detection method provided in an embodiment of the present invention, as follows: Figure 3 As shown, the parallel execution process of all smart contract transactions in the smart contract transaction set for a preset number of rounds is completed. The state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round are recorded, and the process also includes:
[0064] S203. Real-time detection of whether each state lock is in a deadlock state;
[0065] S204. When any state lock is in a deadlock state, perform deadlock recovery on the state lock in the deadlock state.
[0066] To avoid deadlocks in the process, it is necessary to monitor the status of each state lock in real time, and to perform deadlock recovery as soon as a state lock deadlocks.
[0067] Specifically, deadlock recovery methods include: resource preemption, process termination (reversal), and process rollback.
[0068] As an optional implementation method, Figure 4 This is a flowchart of the transaction execution plan generation method provided in an embodiment of the present invention, such as... Figure 4 As shown, based on the target state lock and the parameter set, the smart contract transactions that can be executed in parallel and those that need to be executed serially are determined, resulting in a transaction execution plan, including:
[0069] S401. Generate a partial order graph of smart contract transactions based on the parameter set of the target state lock;
[0070] S402. Based on the partial order graph of smart contract transactions, determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed sequentially, and obtain the transaction execution plan.
[0071] Loop through each state lock and find all the usage records of the accessed state locks. For example, the usage of a certain state lock 1 by three transactions is: (transaction 1, state lock 1, 1), (transaction 2, state lock 1, 2), (transaction 3, state lock 1, 3).
[0072] Based on the above usage, a partial order graph of transactions is generated, which determines the execution dependency order of transactions. In the example above, transactions 1, 2, and 3 cannot be executed in parallel; transaction 1 must be executed before transaction 2, and transaction 2 must be executed before transaction 3.
[0073] As an optional implementation method, Figure 5 This is a flowchart of the method for determining the target state lock using a parameter set provided in an embodiment of the present invention, as shown below. Figure 5 As shown, the optimal set of state lock usage parameters is selected from multiple sets of state lock usage parameters as the target set of state lock usage parameters, including:
[0074] S301, Record the execution time when all smart contract transactions in each round are completed;
[0075] S302. Select the set of state lock parameters corresponding to the round with the shortest execution time as the target set of state lock parameters.
[0076] Record the execution time of all transactions in each round, and select the state lock parameter set corresponding to the round with the shortest execution time as the target state lock parameter set to participate in the formulation of subsequent transaction execution plans. This can improve the efficiency of smart contract transaction execution.
[0077] This invention also provides a parallel execution system for smart contract transactions. Figure 6 This is a schematic diagram of the structure of the smart contract transaction parallel execution system provided in an embodiment of the present invention, as shown below. Figure 6 The system shown includes:
[0078] The transaction packaging module 100 is used to package a collection of smart contract transactions into transaction blocks.
[0079] Smart contracts typically consist of state data and methods. The state data is stored in the blockchain ledger, and calling smart contract methods will change the state data.
[0080] Blockchain nodes package smart contract transactions from the transaction pool into a transaction block B. Transaction block B is a set of smart contract transactions, represented as {t1, t2, ... t...} i}
[0081] The smart contract pre-execution module 200 is used to complete the parallel execution process of all smart contract transactions in a preset round of smart contract transaction set in a simulated environment, record the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, and obtain the state lock usage parameter set corresponding to each round.
[0082] Parallel execution is implemented in an isolated runtime environment where all state data is independent of the actual ledger. Modifications to the state data are only effective within this environment, and each execution process in this environment is called a pre-execution process.
[0083] Allocate a thread to each smart contract transaction in the smart contract transaction set so that all smart contract transactions can be executed in parallel.
[0084] The state data of a smart contract is protected by state locks. Each piece of state data corresponds to a state lock. Only smart contract transactions that have acquired a state lock can be executed. Smart contract transactions that have not acquired a state lock must wait until they do. When the logic in a smart contract transaction accesses state data, it first acquires the state lock, then performs the state data access operation, and finally, after the entire smart contract transaction is completed, it submits the transaction and releases the held state lock.
[0085] In this embodiment, the smart contract transactions are executed in parallel over multiple rounds according to a preset sequence. Each round consists of executing all smart contract transactions in the smart contract transaction set. Each round establishes an independent execution environment. Within each round, the usage of state locks corresponding to the accessed state data during the parallel execution of smart contract transactions is recorded; these are the state lock usage parameters. All state lock usage parameters from this round constitute a set of state lock usage parameters. After executing the process in multiple rounds according to the preset sequence, multiple sets of state lock usage parameters can be generated.
[0086] As an optional implementation method, the preset number of rounds is 3.
[0087] Selection module 300 is used to select the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters.
[0088] The optimal set of state lock parameters, denoted as L, is selected from the multiple generated sets of state lock parameters. The selection criteria can be set according to the actual situation. The selected target set of state lock parameters will participate in the formulation of subsequent transaction execution plans to improve the efficiency of smart contract transaction execution.
[0089] The transaction sorting module 400 is used to determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially based on the target state lock using a parameter set, and to obtain the transaction execution plan;
[0090] For multiple smart contract transactions using the same state lock, they must be executed in a certain order; that is, these smart contract transactions cannot be executed in parallel, but only sequentially. For multiple smart contract transactions using different state locks, there is no sequential execution requirement, so these smart contracts can be executed in parallel. Develop a transaction execution plan P according to the above rules.
[0091] For example, transactions 1 and 2 using state lock 1 need to be executed serially, while for transaction 3 using state lock 2, transactions 1 and 2 can be executed in parallel with transaction 3. The consensus module 500 is used to package transaction blocks and transaction execution plans for consensus.
[0092] The block nodes package transaction block B and its corresponding transaction execution plan P into a consensus.
[0093] The execution module 600 is used to execute all smart contract transactions in the transaction block according to the consensus-based transaction execution plan.
[0094] During execution, all smart contract transactions in transaction block B are scheduled and executed according to the consensus-based transaction execution plan P. Specifically, smart contract transactions that can be executed in parallel within the consensus-based transaction execution plan P are executed concurrently, while other smart contract transactions that need to be executed sequentially are executed according to their execution order. This ensures that transactions that can be executed in parallel can be executed in parallel, and that all state data eventually becomes consistent after execution according to the transaction execution plan.
[0095] As an optional implementation method, Figure 7 This is a schematic diagram of the structure of the submodule of the smart contract pre-execution module provided in this embodiment of the invention, which is used to generate state lock usage parameters. Figure 7 As shown, the smart contract pre-execution module 200 includes:
[0096] The state lock information acquisition submodule 2001 is used to acquire the state lock corresponding to any state data and the current call count corresponding to the state lock when any state data is accessed by the current smart contract transaction in each round.
[0097] The state lock parameter generation submodule 2002 is used to release the state lock if the current smart contract transaction is completed, increment the current call count by one, and form the state lock usage parameters corresponding to the state data by combining the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count; wherein, the current call count is initially 0.
[0098] When a certain state data (using d) i (This indicates that) when the current smart transaction needs to access the state data for the first time, it needs to acquire the state lock (represented by l) corresponding to that state data. i (This is indicated by the code). After executing the entire current smart transaction, request the release of all state locks acquired during runtime. Each state lock corresponds to a monotonically increasing call count (using l). ci (This indicates the current call count). After each smart contract transaction uses the state lock once, the current call count is incremented when the state lock is released. ci Add one, then record the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count as (t). i ,l i ,l ci ), which refers to the parameters used by the state lock.
[0099] For example, when state lock 1 is invoked for the first time, the initial number of invocations is 0, and the transaction invoking the state lock is transaction 1. At this time, the current number of invocations is incremented by 1, resulting in 1. The parameters for using the state lock are (transaction 1, state lock 1, 1). After state lock 1 is released; when state lock 1 is invoked for the second time, the transaction invoking the state lock is transaction 2. At this time, the current number of invocations is incremented by 1, resulting in 2. The parameters for using the state lock are (transaction 2, state lock 1, 2). After state lock 1 is released.
[0100] All state locks use parameters to form the target state lock parameter set L = {(t i ,l i ,l ci )}.
[0101] As an optional implementation method, Figure 8 This is a schematic diagram of the structure of a submodule for detecting deadlocks in the smart contract pre-execution module provided in an embodiment of the present invention, as shown below. Figure 8 As shown, the smart contract pre-execution module 200 includes:
[0102] The deadlock detection submodule 2003 is used to detect in real time whether each state lock is in a deadlock state.
[0103] The deadlock recovery submodule 2004 is used to recover deadlocks from deadlocks when any state lock is in a deadlock state.
[0104] To avoid deadlocks in the process, it is necessary to monitor the status of each state lock in real time, and to perform deadlock recovery as soon as a state lock deadlocks.
[0105] Specifically, deadlock recovery methods include: resource preemption, process termination (reversal), and process rollback.
[0106] As an optional implementation method, Figure 9 This is a schematic diagram of the transaction sorting module provided in an embodiment of the present invention, as shown below. Figure 9 As shown, the transaction sorting module 400 includes:
[0107] The partial order graph generation submodule 4001 is used to generate a smart contract transaction partial order graph based on the target state lock and the parameter set.
[0108] The transaction execution plan generation submodule 4002 is used to determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially based on the partial order graph of smart contract transactions, and to obtain the transaction execution plan.
[0109] Loop through each state lock and find all the usage records of the accessed state locks. For example, the usage of a certain state lock 1 by three transactions is: (transaction 1, state lock 1, 1), (transaction 2, state lock 1, 2), (transaction 3, state lock 1, 3).
[0110] Based on the above usage, a partial order graph of transactions is generated, which determines the execution dependency order of transactions. In the example above, transactions 1, 2, and 3 cannot be executed in parallel; transaction 1 must be executed before transaction 2, and transaction 2 must be executed before transaction 3.
[0111] As an optional implementation method, Figure 10 This is a structural schematic diagram of the selection module provided in an embodiment of the present invention, as shown below. Figure 10 As shown, the selection module 300 includes:
[0112] The time recording submodule 3001 is used to record the execution time when all smart contract transactions in each round are completed.
[0113] The optimal set selection submodule 3002 is used to select the state lock parameter set corresponding to the round with the shortest execution time as the target state lock parameter set.
[0114] Record the execution time of all transactions in each round, and select the state lock parameter set corresponding to the round with the shortest execution time as the target state lock parameter set to participate in the formulation of subsequent transaction execution plans. This can improve the efficiency of smart contract transaction execution.
[0115] The above technical solution has the following beneficial effects: by executing smart contract transactions in parallel in an independent environment, the usage of state locks can be determined. Based on the usage of state locks, transactions that can be executed concurrently can be determined and executed concurrently according to the transaction execution plan. After execution according to the transaction execution plan, all state data eventually become consistent, thereby improving the execution efficiency of transactions while ensuring determinism.
[0116] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.
Claims
1. A method for parallel execution of smart contract transactions, characterized in that, include: Package a collection of smart contract transactions into a transaction block; In a simulated environment, the parallel execution process of all smart contract transactions in the smart contract transaction set for a preset number of rounds is completed. The state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round are recorded to obtain the state lock usage parameter set for each round. The state lock usage parameters include: the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count. Select the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters; Based on the target state lock, the set of parameters is used to determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially, thus obtaining the transaction execution plan; The step of determining the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially based on the parameter set of the target state lock, and obtaining the transaction execution plan, includes: generating a partial order graph of smart contract transactions based on the parameter set of the target state lock; determining the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially based on the partial order graph of smart contract transactions, and obtaining the transaction execution plan; The transaction blocks and transaction execution plans are packaged together for consensus. All smart contract transactions in the transaction block are executed according to the consensus-based transaction execution plan.
2. The method for parallel execution of smart contract transactions according to claim 1, characterized in that, The parallel execution process of all smart contract transactions in the smart contract transaction set that has completed a preset round records the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, including: In each round, when any state data is accessed by the current smart contract transaction, the state lock corresponding to the state data is obtained and the current call count corresponding to the state lock is obtained; If the current smart contract transaction is completed, the state lock is released, the current call count is incremented by one, and the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count are combined to form the state lock usage parameters corresponding to the state data; wherein, the current call count is initially 0.
3. The method for parallel execution of smart contract transactions according to claim 2, characterized in that, The parallel execution process of all smart contract transactions in the smart contract transaction set that has completed a preset number of rounds, recording the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, also includes: Real-time detection of whether each state lock is in a deadlock state; When any state lock is in a deadlock state, deadlock recovery is performed on the state lock in the deadlock state.
4. The method for parallel execution of smart contract transactions according to claim 1, characterized in that, The step of selecting the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters includes: Record the execution time when all smart contract transactions in each round are completed; Select the set of parameters for the state lock corresponding to the round with the shortest execution time as the set of parameters for the target state lock.
5. A parallel execution system for smart contract transactions, characterized in that, include: The transaction packaging module is used to package a collection of smart contract transactions into transaction blocks; The smart contract pre-execution module is used to complete the parallel execution process of all smart contract transactions in the smart contract transaction set for a preset number of rounds in a simulated environment, and record the state lock usage parameters corresponding to the state data accessed by all smart contract transactions in each round, so as to obtain the state lock usage parameter set for each round; wherein, the state lock usage parameters include: the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count; The selection module is used to select the optimal set of state lock usage parameters from multiple sets of state lock usage parameters as the target set of state lock usage parameters. The transaction sorting module is used to determine, based on the target state lock and a set of parameters, the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially, and to obtain a transaction execution plan. The transaction sorting module includes: a partial order graph generation submodule, used to generate a smart contract transaction partial order graph based on a parameter set using a target state lock; and a transaction execution plan generation submodule, used to determine the smart contract transactions that can be executed in parallel and the smart contract transactions that need to be executed serially based on the smart contract transaction partial order graph, and to obtain a transaction execution plan. The consensus module is used to package the transaction blocks and transaction execution plans into a consensus. The execution module is used to execute all smart contract transactions in the transaction block according to the consensus-based transaction execution plan.
6. The smart contract transaction parallel execution system according to claim 5, characterized in that, The smart contract pre-execution module includes: The state lock information acquisition submodule is used in each round to acquire the state lock corresponding to any state data when it is accessed by the current smart contract transaction and to acquire the current call count corresponding to the state lock. The state lock parameter generation submodule is used to release the state lock if the current smart contract transaction is completed, increment the current call count by one, and combine the identifier of the current smart contract transaction, the identifier of the state lock, and the current call count to form the state lock usage parameters corresponding to the state data; wherein, the current call count is initially 0.
7. The smart contract transaction parallel execution system according to claim 6, characterized in that, The smart contract pre-execution module includes: The deadlock detection submodule is used to detect in real time whether each state lock is in a deadlock state; The deadlock recovery submodule is used to recover deadlocks from any deadlock when any state lock is in a deadlock state.
8. The smart contract transaction parallel execution system according to claim 5, characterized in that, The selection module includes: The time recording submodule is used to record the execution time when all smart contract transactions in each round are completed. The optimal set selection submodule is used to select the set of state lock parameters corresponding to the round with the shortest execution time as the target set of state lock parameters.