Contract execution history-based block chain transaction parallel execution method

Abstract

The invention discloses a contract execution history-based block chain transaction parallel execution method. The method comprises the following steps of S1, performing pre-execution to obtain a transaction variable set; s2, constructing a transaction dependency graph, and performing preliminary grouping; s3, improving a firefly algorithm, and optimizing transaction grouping; s4, optimizing a scheduling scheme through a Rhododendron search algorithm; s5, performing multi-thread parallel execution according to the optimal scheduling scheme; and S6, result merging and conflict processing are executed, and a new block is generated and broadcasted. According to the invention, dual improvement of transaction execution efficiency and concurrent processing capability in the block chain system is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain transactions, and in particular, to a method for parallel execution of blockchain transactions based on contract execution history. Background Art

[0002] In a blockchain system that supports smart contracts, with the continuous expansion of the application scale and the continuous increase in the complexity of smart contracts, the transaction execution efficiency has become one of the core bottlenecks restricting the performance improvement of the blockchain system. In current mainstream blockchain platforms such as Ethereum, EOS, Fabric, etc., their transaction execution mechanisms mainly rely on serial execution, that is, transactions are strictly executed in the order of their arrangement in the block. Although the serial execution method has natural advantages in data consistency and reproducibility, it severely limits the throughput capacity and response latency of the system in high-concurrency and heavy-load transaction scenarios, and is not conducive to the wide application of blockchain in business scenarios with high-performance requirements such as financial clearing, Internet of Things traceability, and supply chain management.

[0003] To alleviate the above performance bottleneck, researchers have proposed a series of improvement methods based on transaction parallel execution, which can be mainly divided into two categories: deterministic parallel execution schemes and optimistic parallel execution schemes. The deterministic parallel scheme attempts to obtain the read-write sets of each transaction before transaction execution, and determines whether there is a dependency between transactions based on the intersection relationship between the read-write sets, so as to allocate independent transactions to different threads for parallel execution. Typical schemes include the Sealevel parallel execution model of Solana, the parallelizable object model of Sui, and the Diem modular parallel scheme proposed by Facebook (now Meta). These schemes either rely on the client to pre-define the read-write set at the transaction sending stage, or calculate the read-write set in advance through transaction pre-execution. Although such schemes can improve the parallelism to a certain extent, there are also a series of technical problems: pre-defining the read-write set by the client increases the technical burden and error risk on the user side. Especially when there are dynamic calls, callback functions or multi-layer nested logics inside the contract, it is difficult for users to accurately predict the actually accessed storage variables; while the pre-execution scheme avoids the client burden, but introduces additional computational overhead, and when the smart contract logic is complex or the call chain is long, the accuracy and performance of its pre-execution results are difficult to guarantee.

[0004] Another category is optimistic parallel execution schemes, represented by Aptos, Monad, Sei, and Hyperledger Fabric. These schemes do not rely on predefined read / write sets. Instead, they assume that transactions can be executed in parallel. They monitor variable conflicts in real time during execution and, if conflicts are detected, re-execute the relevant transactions through a transaction rollback mechanism. The advantage of optimistic parallel execution is that it avoids the upfront dependency analysis and preparatory work, theoretically improving execution throughput. However, its drawbacks are also significant. In scenarios with high transaction conflict rates, a large number of transactions will be detected as read / write conflicts during the parallel execution phase, forcing them to be rolled back and re-executed. This can lead to duplicate computation, thread idling, resource waste, and even the paradox of "execution efficiency lower than serial execution." Furthermore, frequent state rollbacks can introduce system consistency risks and data synchronization delays, further limiting the practicality of this approach.

[0005] Building on the aforementioned deterministic and optimistic parallel approaches, some research has begun to explore incorporating historical information or statistical models to predict the probability of transaction conflicts, thereby achieving more optimal scheduling strategies. However, most of these approaches still rely on static analysis of transaction logic, making it difficult to dynamically adapt to behavioral changes in actual contracts due to parameter differences or path branching. Furthermore, existing research generally lacks in-depth utilization of historical smart contract execution data, and a stable and efficient dynamic transaction dependency modeling mechanism and scheduling optimization framework have yet to be established.

[0006] In summary, existing blockchain transaction parallel execution technologies have the following major flaws: First, there is a lack of in-depth modeling of smart contract execution history and variable behavior induction, resulting in inaccurate dependency analysis and unreasonable scheduling grouping, which in turn limits the degree of parallelism; second, most transaction scheduling strategies use simple static graph partitioning or greedy grouping methods, fail to introduce optimization algorithms to dynamically seek optimality from a global perspective, and lack the ability to predict the feasibility of transaction parallelization; third, after parallel scheduling, there is a lack of a fine-grained scheduling mechanism for execution load and thread utilization, resulting in unbalanced task distribution, causing some execution units to be overloaded and some resources to be idle, making it impossible to achieve efficient thread scheduling and load-aware execution.

[0007] Therefore, designing a parallel execution method that automatically builds transaction dependencies based on historical contract execution data and combines it with intelligent optimization algorithms to achieve high-quality grouping and scheduling has become a key issue in current blockchain system performance optimization. This method should accurately identify read-write dependencies between transactions and dynamically adjust and evolve transaction grouping schemes and thread scheduling methods by introducing global optimization mechanisms such as the firefly algorithm and the cuckoo search algorithm. This approach significantly improves execution efficiency and system throughput while ensuring transaction consistency and reproducibility, providing a practical execution optimization path for the next generation of high-performance blockchain platforms. Summary of the Invention

[0008] An object of the present invention is to propose a parallel execution method for blockchain transactions based on contract execution history. The present invention makes full use of intelligent contract historical variable behavior modeling, improved firefly algorithm and cuckoo search algorithm, and details the whole process of efficiently identifying transaction dependency relationships, optimizing transaction grouping and scheduling strategies on the premise of ensuring data consistency, and has the advantages of high parallelism, high execution efficiency, strong system throughput capacity and high resource utilization rate.

[0009] A parallel execution method for blockchain transactions based on contract execution history according to an embodiment of the present invention includes the following steps:

[0010] S1. In a blockchain node, obtain a variable set of a transaction through pre-execution;

[0011] S2. According to the variable set, construct a transaction dependency graph and perform preliminary grouping on the transaction dependency graph;

[0012] S3. Use an improved firefly algorithm to globally optimize the preliminary grouping result to obtain an optimized transaction grouping;

[0013] S4. Use a cuckoo search algorithm to perform dynamic scheduling optimization on the optimized transaction grouping to obtain an optimal parallel scheduling scheme;

[0014] S5. Use a multi-threaded or multi-core parallel execution engine to parallelly execute the transaction grouping according to the optimal parallel scheduling scheme, and use a transaction isolation and conflict rollback mechanism to maintain the consistency of transaction execution to obtain a parallel execution result;

[0015] S6. Based on the parallel execution result, perform conflict detection and state merging to generate a new block containing all execution results, and broadcast the new block to the blockchain network through a consensus mechanism.

[0016] Optionally, the S2 specifically includes:

[0017] S21. Set the affected variable set corresponding to each transaction T i as V i , where i ∈ {1, 2,..., n}, and n is the total number of transactions to be processed;

[0018] S22. For any two transactions T i and T j , i ≠ j, perform a set intersection judgment. If , then define that there is no dependency relationship between transaction T i and T j . If , then define that there is a dependency relationship between the two;

[0019] S23. Construct a transaction dependency graph G=(T, E) based on the dependencies between all trading pairs, where the vertex set T={T1, T2,..., T n} represents all transactions, and any edge e ij ∈E indicates that there is a dependency relationship between transaction T i and T j ;

[0020] S24. Perform non-overlapping grouping on the transaction dependency graph G, and use a heuristic traversal method to divide the set of non-connected transactions in any group into a preliminary grouping to obtain multiple preliminary transaction grouping sets P.

[0021] Optionally, the specific content of S3 is as follows:

[0022] S31. Map the preliminary transaction grouping set P={P1, P2,..., P k} to the initial population F={F1, F2,..., F k}, where each individual F j represents a transaction grouping scheme. For any two transactions T j , T a , T b in each individual F j If their variable sets satisfy, it is regarded as a valid grouping;

[0023] S32. Define a brightness function L j to evaluate the brightness of each individual F j . Its expression is as follows:

[0024]

[0025] Among them, indicates whether there is a variable conflict in the trading pair, σ j represents the standard deviation of the transaction grouping size, w1, w2∈[0, 1] and w1 + w2 = 1, which represent the weight coefficients of performance and balance in the brightness function;

[0026] S33. Use an improved attraction strategy with local search perturbation to update the position of the individual F j . The update expression is:

[0027]

[0028] Among them, is the jth individual in the (t + 1)th generation, is the jth individual in the tth generation, is the ith individual in the tth generation, β0 is the basic attraction intensity, γ is the light intensity attenuation factor, d ij represents Fi The trading recombination distance with F j where φ is the perturbation factor, and Rand(-1, 1) is a uniform random perturbation within the interval [-1, 1];

[0029] S34. Introduce a cross - recombination mechanism to perform a recombination operation based on the trading mapping relationship on the individuals with lower brightness in the population. The following recombination operation is adopted:

[0030]

[0031] where F * is the optimal individual in the current population, and Crossover(·) represents retaining the key grouping structure;

[0032] S35. Perform multi - generation iterative update. Let the maximum number of iterations be T max , and re - evaluate the brightness L of all individuals after each generation of iteration j , record the individual F with the maximum brightness * and its grouping structure;

[0033] S36. When the iteration stop condition is reached, output the trading grouping scheme corresponding to the individual F with the maximum brightness value as the optimized trading grouping. *

[0034] Optionally, the S4 specifically includes:

[0035] S41. Input the optimized trading grouping into the scheduling optimization module, where each grouping contains several conflict - free transactions that can be executed in parallel;

[0036] S42. Construct a population of scheduling schemes. Each scheduling individual represents a scheme that maps trading groupings to parallel execution units. Each grouping is assigned to an execution unit to form a set of mapping relationships, and initialize the scheduling individuals as the initial population of the cuckoo search algorithm;

[0037] S43. Set the fitness function of the scheduling scheme to evaluate the performance of each scheduling individual. The fitness function comprehensively considers two factors: the maximum execution time and the imbalance of the load among execution units

[0038] S44. Use the cuckoo search algorithm to update the scheduling scheme. By introducing the Levy flight strategy, perturb the mapping relationships in the scheduling individuals to achieve a large - span search based on local search, jump out of the local optimal solution, randomly re - assign execution units to some trading groupings to form a new scheduling scheme, and evaluate the quality based on the fitness function;

[0039] ​S45. Set the replacement probability, perform a replacement operation on the individual with the lowest fitness in the population, cross - recombine its partial mapping structure with the individual with the highest current fitness, retain excellent allocation strategies and introduce new combinations to enhance population diversity;

[0040] S46. Repeatedly execute the fitness evaluation, search update, and replacement recombination steps until the preset number of iterations is reached or no fitness improvement has been achieved for several consecutive generations. Finally, output the scheduling plan with the highest fitness function value as the optimal parallel scheduling plan.

[0041] Optionally, the specific steps of S5 are as follows:

[0042] S51. Take the obtained optimal parallel scheduling plan as the execution input, dispatch each transaction group to the corresponding parallel execution unit according to this plan, and start an independent thread or process in each execution unit to load the set of transactions to be executed, and initialize the execution context environment of each transaction;

[0043] S52. In each parallel execution unit, sequentially execute the transactions assigned to it, adopt an optimistic concurrency control mechanism, record the set of read - write variables of each transaction during the execution process, and mark the execution status of each transaction as:

[0044] Successfully committed: All transactions have been executed completely without conflicts;

[0045] Rollbackable: Conflicts occurred with other parallel transactions during the execution of the transaction, and it needs to be aborted and wait for rescheduling;

[0046] Abnormally terminated: The execution failed due to reasons such as transaction code exceptions, insufficient Gas, or logical errors;

[0047] S53. During the execution process, establish a transaction execution log in real - time, including variable access records, contract call paths, status change details, and resource consumption data, and generate an intermediate state snapshot for subsequent result merging and verification;

[0048] S54. After the parallel execution is completed, uniformly collect the execution results of each execution unit and perform conflict detection. If multiple transactions have read - write conflicts on the same variable, give priority to retaining the results of the transactions with earlier execution order, mark the conflicting transactions as conflict - failed, and prepare to enter the next round of rescheduling execution process;

[0049] S55. Merge the states of the conflict - free transaction results, perform variable update operations, uniformly write them into the node state database, and at the same time record the transaction hashes, status change summaries, and contract event logs that have been successfully submitted, and generate a structured execution result data packet;

[0050] S56. If there are conflicting transactions or abnormal transactions, initiate the rollback process, clear the intermediate state changes caused by them, re-add them to the transaction pool or mark them as in an unexecutable state. After all transaction status confirmations are completed, form the final parallel execution result.

[0051] The beneficial effects of the present invention are as follows:

[0052] (1) By introducing the historical data of the execution of smart contracts local to blockchain nodes, the present invention realizes the dynamic identification of the actual impact variables of each transaction, avoids the prediction deviation problem caused by the pre-defined read-write sets of clients in traditional deterministic parallel schemes, and also avoids the additional performance overhead caused by pre-execution of transactions. The transaction dependency relationship constructed based on the real execution history is closer to the actual operating environment, effectively improving the accuracy of conflict-free judgment between transactions, thus laying an accurate foundation for subsequent grouping optimization and parallel execution, and significantly improving the overall parallel execution ability.

[0053] (2) The present invention innovatively applies the improved firefly algorithm to the transaction grouping stage to optimize the brightness, avoid conflicts and balance the structure of the preliminary grouping results from a global perspective, improving the number of parallelizable transactions in each round of grouping; in the scheduling stage, the cuckoo search algorithm is introduced to intelligently optimize the parallel scheduling scheme, combined with the fitness function of the maximum execution time and load balance, realizing the reasonable allocation of multi-thread or multi-core resources, improving the overall operation efficiency of the system, and solving the problems of uneven thread allocation and low system resource utilization existing in the existing methods.

[0054] (3) Strengthen the execution control and rollback management mechanisms, improving the reliability and fault tolerance of transaction execution. During the parallel execution process, the present invention constructs an execution status tracking and conflict control mechanism based on transaction isolation, classifies and manages the transaction execution status in detail, and supports exception detection and result rollback through log records and intermediate state snapshots. At the same time, when the system discovers conflicts or exceptions, it can automatically trigger the rescheduling process, effectively ensuring the consistency of transaction data and avoiding state errors or execution failures caused by parallel conflicts. This mechanism improves the fault tolerance of the system and enhances the robustness and stability of blockchain transaction processing. Description of the Drawings

[0055] The drawings are used to provide a further understanding of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the present invention and do not constitute a limitation to the present invention. In the drawings:

[0056] Figure 1 It is the overall flowchart of a method for parallel execution of blockchain transactions based on contract execution history proposed by the present invention. Detailed Embodiments

[0057] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are all simplified schematic diagrams, only schematically showing the basic structure of the present invention, so they only show the components related to the present invention.

[0058] Reference Figure 1 , a blockchain transaction parallel execution method based on contract execution history, comprising the following steps:

[0059] S1. In a blockchain node, obtain a set of variables of a transaction through pre-execution;

[0060] S2. According to the set of variables, construct a transaction dependency graph and perform preliminary grouping on the transaction dependency graph;

[0061] S3. Use an improved firefly algorithm to globally optimize the preliminary grouping result to obtain an optimized transaction grouping;

[0062] S4. Use a cuckoo search algorithm to dynamically schedule and optimize the optimized transaction grouping to obtain an optimal parallel scheduling scheme;

[0063] S5. Use a multi-threaded or multi-core parallel execution engine to parallelly execute the transaction grouping according to the optimal parallel scheduling scheme, and use a transaction isolation and conflict rollback mechanism to maintain the consistency of transaction execution to obtain a parallel execution result;

[0064] S6. Based on the parallel execution result, perform conflict detection and state merging to generate a new block containing all execution results, and broadcast the new block to the blockchain network through a consensus mechanism.

[0065] By constructing a blockchain transaction parallel execution method based on contract execution history, the system can automatically identify the variable dependency relationships between transactions from historical data, and form a conflict-free parallel transaction set accordingly, thus avoiding errors and computational overhead caused by manual predefined or pre-execution. Further, through global optimization of grouping and scheduling by an optimization algorithm, the parallel transaction execution has higher throughput, lower latency, and better execution stability, effectively breaking through the performance bottleneck of the traditional serial execution method.

[0066] In this embodiment, the S2 specifically includes:

[0067] S21. Set the set of affected variables V corresponding to each transaction T, where i ∈ {1, 2,..., n}, and n is the total number of transactions to be processed; i The corresponding set of affected variables is V i , where i ∈ {1, 2,..., n}, and n is the total number of transactions to be processed;

[0068] S22. For any two transactions T and T, i ≠ j, perform a set intersection judgment. If i and T j , i ≠ j, perform a set intersection judgment. If then define transaction Ti has no dependency relationship with T j , if then it is defined that there is a dependency relationship between the two;

[0069] S23. Construct a transaction dependency graph G=(T, E) based on the dependency relationships between all trading pairs, where the vertex set T={T1, T2,..., T n} represents all transactions, and any edge e in the edge set E ij ∈E represents that transaction T i has a dependency relationship with T j ;

[0070] S24. Perform non-overlapping grouping on the transaction dependency graph G. Adopt a heuristic traversal method to divide the set of non-connected transactions in any group into a preliminary grouping, and obtain multiple preliminary transaction grouping sets P.

[0071] Through constructing a transaction dependency graph based on the set of transaction variables and using the conflict relationships between nodes in the graph structure for grouping, the present invention can effectively identify transaction clusters that can be executed in parallel, avoiding the problem of inaccurate prediction of contract behavior in traditional static analysis methods. At the same time, the heuristic grouping strategy improves the grouping efficiency, enabling the entire dependency recognition and grouping process to achieve efficient parallel preparation under the premise of controllable complexity, and significantly improving the parallel execution quality.

[0072] In this embodiment, the specific steps of S3 are as follows:

[0073] S31. Map the preliminary transaction grouping set P={P1, P2,..., P k} to the initial population F={F1, F2,..., F k}, where each individual F j represents a transaction grouping scheme. For any two transactions T j , T a in each individual F b , if their variable sets satisfy then it is regarded as a valid grouping;

[0074] S32. Define a brightness function L j to evaluate the brightness of each individual F j . Its expression is as follows:

[0075]

[0076] where represents whether there is a variable conflict in the trading pair, σ j represents the standard deviation of the transaction grouping size, w1, w2∈[0, 1] and w1 + w2 = 1, representing the weight coefficients of performance and balance in the brightness function;

[0077] S33. Update the position of individual F using an improved attraction strategy with local search perturbation, and the update expression is: j where:

[0078]

[0079] is the j-th individual in the (t + 1)-th generation, is the j-th individual in the t-th generation, is the i-th individual in the t-th generation, β0 is the basic attraction intensity, γ is the light intensity attenuation factor, d is the trading recombination distance between F ij and F i and F j , φ is the perturbation factor, and Rand(-1, 1) is a uniform random perturbation in the interval [-1, 1];

[0080] S34. Introduce a crossover recombination mechanism to perform a recombination operation based on the trading mapping relationship on the individuals with lower brightness in the population, and adopt the following recombination operation:

[0081]

[0082] where F * is the optimal individual in the current population, and Crossover(·) represents retaining the key grouping structure;

[0083] S35. Perform multi-generation iterative update. Let the maximum number of iterations be T max . After each generation of iteration, re-evaluate the brightness L j of all individuals, and record the individual F * with the maximum brightness and its grouping structure;

[0084] S36. When the iteration stop condition is reached, output the trading grouping scheme corresponding to the individual F * with the maximum brightness value as the optimized trading grouping.

[0085] The present invention optimizes the preliminary trading grouping by introducing an improved firefly algorithm, which can fully balance the variable conflicts between transactions and the execution load between groups, and achieve a grouping structure with high brightness, low conflict, and high balance. The algorithm uses mechanisms such as the brightness function, attraction mechanism, perturbation update, and crossover recombination to gradually improve the quality of the trading grouping in multiple rounds of iteration, optimize the parallel potential from a global perspective, and lay a stable foundation for subsequent scheduling and execution.

[0086] In this embodiment, the S4 specifically includes:

[0087] S41. Input the optimized transaction groups into the scheduling optimization module, where each group contains several conflict-free transactions that can be executed in parallel.

[0088] S42. Construct a population of scheduling plans. Each scheduling individual represents a plan for mapping the transaction groups to parallel execution units. Each group is assigned to an execution unit to form a set of mapping relationships. Initialize the scheduling individuals as the initial population of the cuckoo search algorithm.

[0089] S43. Set the fitness function of the scheduling plan to evaluate the performance of each scheduling individual. The fitness function comprehensively considers two factors: the maximum execution time and the imbalance of the load among the execution units.

[0090] S44. Use the cuckoo search algorithm to update the scheduling plan. By introducing the Levy flight strategy, perturb the mapping relationships in the scheduling individuals to achieve large-span search based on local search, jump out of the local optimal solution, randomly reassign the execution units for some transaction groups to form a new scheduling plan, and evaluate its quality based on the fitness function.

[0091] S45. Set the replacement probability and perform a replacement operation on the individual with the lowest fitness in the population. Cross-recombine part of its mapping structure with the individual with the highest current fitness, retain the excellent allocation strategy and introduce new combinations to enhance the diversity of the population.

[0092] S46. Repeat the steps of fitness evaluation, search update, and replacement recombination until the preset number of iterations is reached or there is no fitness improvement for several consecutive generations. Finally, output the scheduling plan with the highest fitness function value as the optimal parallel scheduling plan.

[0093] The present invention uses the cuckoo search algorithm to dynamically optimize the scheduling plan of transaction groups, effectively combines the two core indicators of the maximum execution time and the load balance of execution units, and avoids the problems of uneven thread utilization and unbalanced resource allocation in traditional scheduling. The introduction of the Levy flight strategy and the recombination mechanism improves the ability to explore the solution space and the ability to jump out of the local optimum, making the generated scheduling plan more globally optimal, thereby improving the parallel execution performance of the entire system.

[0094] In this embodiment, the specific steps of S5 are as follows:

[0095] S51. Take the obtained optimal parallel scheduling plan as the execution input, dispatch each transaction group to the corresponding parallel execution unit according to this plan, and start an independent thread or process in each execution unit to load the set of transactions to be executed, and initialize the execution context environment of each transaction.

[0096] S52. In each parallel execution unit, execute the transactions assigned to it in sequence. Adopt the optimistic concurrency control mechanism, record the read and write variable sets of each transaction during the execution process, and mark the execution status of each transaction as follows:

[0097] Successfully committed: All transactions have been executed completely without conflicts;

[0098] Rollbackable: Conflicts occur with other parallel transactions during the execution of the transaction, and it needs to be aborted and wait for rescheduling;

[0099] Abnormally terminated: The execution fails due to reasons such as transaction code exceptions, insufficient Gas, or logical errors;

[0100] S53. During the execution process, establish a transaction execution log in real time, including variable access records, contract call paths, status change details, and resource consumption data, and generate an intermediate state snapshot for subsequent result merging and verification;

[0101] S54. After the parallel execution is completed, uniformly collect the execution results of each execution unit and perform conflict detection. If multiple transactions have read and write conflicts on the same variable, preferentially retain the results of the transaction with a higher execution order, mark the conflicting transactions as conflict failures, and prepare to enter the next round of rescheduling execution process;

[0102] S55. Merge the statuses of the non-conflicting transaction results, perform variable update operations, uniformly write them into the node status database, and at the same time record the transaction hashes, status change summaries, and contract event logs of the successfully submitted transactions to generate a structured execution result data packet;

[0103] S56. If there are conflicting transactions or abnormal transactions, start the rollback process, clear the intermediate state changes caused by them, re-add them to the transaction pool or mark them as non-executable states. After all transaction status confirmations are completed, form the final parallel execution result.

[0104] Through the multi-threaded parallel execution process based on the optimal scheduling scheme, the present invention realizes the efficient execution of the conflict-free transaction set. During the execution process, the optimistic concurrency control mechanism and transaction isolation strategy are adopted to effectively ensure the consistency of transaction states. After parallel execution, conflict detection and rollback management are uniformly performed to ensure the final correctness and verifiability of blockchain data. At the same time, a complete execution log and state snapshot are constructed to improve the traceability and exception handling ability of the system and enhance the system robustness.

[0105] Example:

[0106] To verify the feasibility of the present invention in implementation, the present invention is applied to the parallel transaction execution optimization task of a certain blockchain financial trading platform. This platform is based on the Ethereum virtual machine architecture and deploys multiple complex financial smart contracts, involving high-frequency and high-concurrency transaction types such as collateralized lending and asset exchange. The daily trading volume exceeds 50,000 transactions. During peak trading hours, the system often experiences execution bottlenecks and confirmation delays, severely restricting the overall performance and user experience.

[0107] Previously, the platform adopted a traditional serial transaction execution mode. Although it performed stably in terms of data consistency and security, it had obvious bottlenecks when facing high-concurrency transactions. For example, between 18:00 and 20:00 every day is the peak user activity period. The average time from transaction submission to confirmation is 2.31 seconds, and the block throughput is maintained at 12 - 15 TPS (transactions per second), with obvious processing delays. The platform tried to introduce a traditional optimistic parallel execution framework, which had a slight improvement during low-conflict transaction periods. However, in the case of intensive contract calls and complex trading behaviors, state conflict rollbacks frequently occurred, and the transaction retry rate exceeded 26%, resulting in serious waste of system resources.

[0108] The method of the present invention is deployed in this scenario and is actually verified through the following steps. First, the platform extracts and models the contract execution data of the existing deployment, extracts the variable access trajectories of approximately 1.2 million historical transactions, and constructs a variable influence dictionary for contract methods. This historical variable set is deployed in the local cache of the node, providing a basis for the subsequent construction of the transaction dependency graph. During system operation, the node receives pending transactions from the transaction pool, and in real-time calls the dependency construction module in the present invention to determine the parallel relationship between transactions based on the variable set, construct the transaction dependency graph, and complete the preliminary grouping.

[0109] Subsequently, the transaction grouping scheme is optimized through an improved firefly algorithm. During this process, the population size is set to 30, the maximum number of iterations is 100, and the parameters of the brightness function are α = 0.7 and β = 0.3. The optimization results show that the transaction grouping conflict rate drops from the initial 8.2% to 1.6%, and the average within-group deviation value of transactions decreases by approximately 47.4%. On this basis, the cuckoo search algorithm is used to optimize the load balancing of the transaction grouping scheduling scheme. The parallel execution unit is set to 8 threads, the search period is 50 rounds, the Levy flight step size is used to simulate large-scale scheduling perturbations, and the execution allocation scheme is adjusted in real-time in combination with the fitness function. The final optimal scheduling result runs in parallel on the real deployment node, triggering and executing the transaction set.

[0110] During execution, the system uses an optimistic concurrency control mechanism, maintaining independent transaction isolation domains within each thread and recording execution logs and state change snapshots for each transaction. In a real-world test involving 1,300 transactions, total transaction processing time decreased from 156 seconds for serial execution to 46 seconds, throughput increased to 28.2 transactions per second, average transaction confirmation time decreased to 0.92 seconds, and system resource utilization increased to 83%. In high-conflict blocks, the average transaction rollback rate decreased from 26% to 5.3%, significantly improving system robustness and throughput stability.

[0111] Through comprehensive deployment and field testing, this method demonstrates that it effectively addresses the challenges of low blockchain transaction execution efficiency, high conflict rates, and uneven resource allocation in high-concurrency scenarios, achieving overall optimization of transaction scheduling and execution processes. Its strong adaptability and high execution stability make it widely applicable for blockchain system execution optimization tasks in high-load scenarios such as finance, government affairs, and logistics.

[0112] Table 1: Performance comparison of the present invention and traditional execution methods on the financial blockchain platform

[0113]

[0114] It can be clearly seen from Table 1 that the present invention has significant advantages over traditional methods in multiple key performance indicators, verifying its feasibility and efficiency in real business environments.

[0115] First, in terms of transaction processing speed, when the average number of transactions in the test block is 1,200, the traditional serial execution takes an average of 148.7 seconds per round of processing, and the TPS (transactions per second) remains at around 13.2. The maximum TPS during the peak period is only 15.1, which is close to the upper limit of the platform's processing capacity. After adopting the traditional optimistic parallel execution method, although the TPS is increased to 18.5 and the total processing time is shortened to 97.4 seconds, the transaction rollback rate reaches 26.3%, the system execution is unstable, and resources are severely reused, resulting in limited improvement in overall efficiency. In contrast, the method of the present invention further reduces the average total processing time to 43.8 seconds, increases the TPS to 29.8, and the maximum TPS reaches 34.6, which is almost 2.6 times that of the serial execution mode, greatly improving the processing throughput.

[0116] Secondly, in terms of transaction response speed and system stability, the present invention significantly reduces the transaction confirmation time from 2.31 seconds in serial execution to 0.87 seconds, making the user experience more real-time. At the same time, through accurate modeling and grouped optimization of transaction dependencies, the grouped conflict rate drops from the initial 8.2% to 1.6%, and the state rollback rate drops significantly to 5.3%, avoiding a large number of repeated execution problems caused by high conflicts in the optimistic parallel approach. Especially in high-concurrency scenarios, the number of transaction retries per round is greatly reduced from 312 times in traditional parallel execution to 61 times, and the system performance is more stable.

[0117] In addition, in terms of resource utilization, the present invention optimizes parallel scheduling through the cuckoo search algorithm, achieving more reasonable task allocation and thread scheduling, increasing the utilization rate of multi-threaded execution units from 61% in the traditional parallel method to 83%, avoiding the phenomenon of some threads being idle or overloaded, and improving the overall utilization efficiency of the platform's hardware resources. The optimized grouped structure performs excellently in grouped balance, and the standard deviation of the number of transactions within the group drops by 47.4% compared to the initial scheme, further ensuring the balance and efficiency of the parallel execution process.

[0118] In summary, the present invention not only solves the technical problems such as "low parallelism, high conflict rate, uneven scheduling, and throughput bottleneck" in traditional blockchain transaction execution, but also achieves a significant performance improvement in actual deployment, providing a stable, efficient, and implementable execution optimization solution for blockchain systems in high-frequency trading scenarios.

[0119] The above is only a preferred specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention, according to the technical solution and inventive concept of the present invention, making equivalent substitutions or changes, should be covered by the protection scope of the present invention.

Claims

1. A blockchain transaction parallel execution method based on contract execution history, characterized in that, It includes the following steps: S1. In the blockchain node, obtain the variable set of the transaction through pre-execution; S2. Based on the variable set, construct a transaction dependency graph and perform preliminary grouping on the transaction dependency graph; S3. Use an improved firefly algorithm to globally optimize the preliminary grouping result to obtain an optimized transaction grouping; S4. Use the cuckoo search algorithm to perform dynamic scheduling optimization on the optimized transaction grouping to obtain an optimal parallel scheduling scheme; S5. Use a multi-threaded or multi-core parallel execution engine to execute the transaction grouping in parallel according to the optimal parallel scheduling scheme, and use a transaction isolation and conflict rollback mechanism to maintain the consistency of transaction execution to obtain a parallel execution result; S6. Based on the parallel execution result, perform conflict detection and state merging to generate a new block containing all execution results, and broadcast the new block to the blockchain network through a consensus mechanism.

2. The blockchain transaction parallel execution method based on contract execution history according to claim 1, wherein The specific content of S2 includes: S21. Set each transaction T i The corresponding set of affected variables is V i , where i ∈ {1, 2,..., n} and n is the total number of transactions to be processed; S22. For any two transactions T i and T j , where i ≠ j, perform a set intersection judgment. If then define that transaction T i and T j have no dependency relationship. If then define that there is a dependency relationship between the two; S23. Construct a transaction dependency graph G=(T, E) based on the dependencies between all trading pairs, where the vertex set T={T1, T2,..., T n} represents all transactions, and any edge e ij ∈E indicates that there is a dependency relationship between transaction T i and T j ; S24. Perform non-overlapping grouping on the transaction dependency graph G, and use a heuristic traversal method to divide the set of non-connected transactions in any group into a preliminary grouping to obtain a plurality of preliminary transaction grouping sets P.

3. A blockchain transaction parallel execution method based on contract execution history according to claim 1, characterized in that, The specific content of S3 includes: S31. Map the initial transaction grouping set \(P = \{P1, P2,..., P k \}\) to the initial population \(F = \{F1, F2,..., F k \}\), where each individual \(F j \) represents a transaction grouping scheme. For any two transactions \(T j \), \(T a \) in each individual \(F b \), if their variable sets satisfy \), they are regarded as valid groupings; S32. Define the luminance function L j For evaluating each individual F j with respect to luminance, and its expression is as follows: Among them, indicates whether there is a variable conflict in the trading pair, and σ j represents the standard deviation of the trading group size. w1, w2 ∈ [0, 1] and w1 + w2 = 1, representing the weight coefficients of performance and balance in the luminance function; S33. Use an improved attraction strategy with local search perturbation to update the position of individual F j The update expression is as follows: Among them, is the j-th individual of the (t + 1)-th generation, is the j-th individual of the t-th generation, is the i-th individual of the t-th generation, β0 is the basic attraction intensity, γ is the light intensity attenuation factor, d ij represents F i and F j the trading recombination distance between them, φ is the perturbation factor, Rand(-1, 1) is the uniform random perturbation within the [-1, 1] interval; S34. Introduce a cross-recombination mechanism to perform a recombination operation based on the transaction mapping relationship on the individuals with lower brightness in the population, and use the following recombination operation: Among which F * is the optimal individual in the current population, and Crossover(·) means to retain the key grouping structure; S35. Perform multi-generation iterative updates, and set the maximum number of iterative generations as T max , and re-evaluate the brightness L of all individuals after each generation of iteration j , record the individual F with the maximum brightness * and its grouping structure; S36. When the iteration stop condition is reached, output the individual F with the maximum brightness value * The corresponding transaction grouping scheme is used as the optimized transaction grouping 4. A blockchain transaction parallel execution method based on contract execution history according to claim 1, characterized in that, The specific content of S4 includes: S41. Input the optimized transaction grouping into the scheduling optimization module, where each grouping contains several conflict-free transactions that can be executed in parallel; S42. Construct a scheduling scheme population, where each scheduling individual represents a scheme for mapping the transaction grouping to parallel execution units. Each grouping is assigned to an execution unit to form a mapping relationship set, and initialize the scheduling individual as the initial population of the cuckoo search algorithm; S43. Set the fitness function of the scheduling scheme to evaluate the performance of each scheduling individual. The fitness function comprehensively considers two factors, the maximum execution time and the imbalance of the load between execution units S44. Use the cuckoo search algorithm to update the scheduling scheme. By introducing the Levy flight strategy, perturb the mapping relationship in the scheduling individual to achieve a large-span search based on local search, jump out of the local optimal solution, randomly reassign the execution units for some transaction groupings to form a new scheduling scheme, and evaluate the pros and cons based on the fitness function; S45. Set the replacement probability, perform a replacement operation on the individual with the lowest fitness in the population, perform cross-recombination on its partial mapping structure with the individual with the highest current fitness, retain the excellent allocation strategy and introduce new combinations to enhance the diversity of the population; S46. Repeat the steps of fitness evaluation, search update, and replacement recombination until the preset number of iterations is reached or the fitness improvement has not been achieved for several consecutive generations. Finally, output the scheduling scheme with the highest fitness function value as the optimal parallel scheduling scheme.

5. A blockchain transaction parallel execution method based on contract execution history according to claim 1, characterized in that, The specific content of S5 includes: S51. Use the obtained optimal parallel scheduling scheme as the execution input, dispatch each transaction grouping to the corresponding parallel execution unit according to this scheme, and start an independent thread or process in each execution unit to load the set of transactions to be executed, and initialize the execution context environment of each transaction; S52. In each parallel execution unit, the transactions assigned to it are executed in sequence. An optimistic concurrency control mechanism is adopted, and the read and write variable sets of each transaction are recorded during the execution process. The execution status of each transaction is marked as follows: Successfully committed: All transactions have been executed completely without conflicts. Rollbackable: Conflicts have occurred with other parallel transactions during the execution of the transaction, and it needs to be aborted and wait for rescheduling. Abnormally terminated: The execution fails due to reasons such as abnormal transaction code, insufficient Gas, or logical errors. S53. During the execution process, a transaction execution log is established in real time, including variable access records, contract call paths, status change details, and resource consumption data, and an intermediate state snapshot is generated for subsequent result merging and verification. S54. After the parallel execution is completed, the execution results of each execution unit are collected uniformly for conflict detection. If multiple transactions have read and write conflicts on the same variable, the transaction results with a higher execution order are preferentially retained, and the conflicting transactions are marked as conflict failures, preparing to enter the next round of rescheduling execution process. S55. The statuses of the non-conflicting transaction results are merged, variable update operations are executed, and they are uniformly written into the node status database. At the same time, the transaction hashes, status change summaries, and contract event logs of the successfully submitted transactions are recorded to generate a structured execution result data packet. S56. If there are conflicting transactions or abnormal transactions, a rollback process is started to clear the intermediate state changes caused by them, and they are re-added to the transaction pool or marked as non-executable. After all transaction status confirmations are completed, the final parallel execution result is formed.

Images