Deterministic concurrent execution method and system for nested contract transaction

Abstract

The invention discloses a nested contract transaction-oriented deterministic concurrent execution method and system, and provides an innovative multi-stage deterministic processing flow aiming at the problems of performance bottleneck, high conflict rate and high deterministic rollback overhead when an existing block chain processes a complex nested contract. First, sub-transaction information and a dependency relationship are captured in details through pre-execution. Secondly, constructing a hyper-dependency graph and performing efficient conflict detection in combination with a state access table; thirdly, a two-stage sub-transaction level deterministic rollback algorithm is introduced, circulation is broken through a rapid simplification and minimum weight strategy, redundancy calculation is minimized, and serialization is ensured; and then, scheduling is optimized in a fine-grained re-execution stage, and the concurrency is maximized. And finally, cross-block pipeline processing is realized through multi-stage parallel. According to the system, the nested contract throughput is remarkably improved, the rollback overhead is reduced, the efficiency and expandability of processing complex interaction by the system are improved, and the certainty of cross-copy execution is ensured.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and particularly relates to the concurrent execution technology of smart contracts. More specifically, it relates to a deterministic concurrent execution method and system for improving the transaction processing efficiency of smart contracts including nested calls. Background Art

[0002] As a distributed ledger technology, blockchain greatly expands application scenarios through smart contracts, especially in fields such as consortium blockchains that require multi-party collaboration. However, to ensure data consistency, traditional blockchain systems usually adopt the method of sequentially executing transactions, which does not match the hardware capabilities of modern multi-core processors, resulting in limited system throughput and difficulty in meeting the high-performance requirements of large-scale applications. The execution of smart contracts has become a key bottleneck.

[0003] With the deepening of blockchain applications, nested contract transactions have become increasingly common, that is, one transaction triggers one or more smart contracts, and these contracts in turn call other contracts, forming a call chain. Such transactions involve state access across multiple contracts, significantly increasing the possibility of data conflicts. The deep nested call chain further exacerbates the complexity of dependency relationships during execution, making simple parallel execution strategies inefficient and prone to concurrent blocking.

[0004] Existing methods for improving blockchain execution efficiency, such as rolling back conflicting transactions after parallel execution, or adopting the execute-order-verify (EOV) model, face severe challenges when dealing with nested transactions. Rolling back the entire nested transaction as an atomic unit incurs huge overheads, especially prone to cascading rollbacks under a high conflict rate. At the same time, there is a contradiction between the deterministic execution required by the blockchain system (all replica nodes need to reach a consistent state in the consensus order) and the improvement of parallelism. The complex dependency relationships introduced by nested calls greatly reduce the available concurrent potential under a strict order. Therefore, there is an urgent need for a new concurrent execution mechanism that can effectively handle nested dependencies, reduce rollback overheads, and ensure determinism. Summary of the Invention

[0005] The purpose of the present invention is to provide a deterministic concurrent execution method and system for nested contract transactions, aiming to solve the technical problems of throughput bottlenecks, high concurrent conflict rates, and large rollback overheads under deterministic requirements faced by existing blockchain systems when dealing with nested transactions with complex call chains and cross-contract interactions.

[0006] To achieve the above object, the present invention proposes a multi-stage deterministic concurrent execution system. By decomposing nested transactions into fine-grained sub-transactions, accurately modeling the dependency relationships between sub-transactions, adopting a two-phase rollback at the sub-transaction level and a fine-grained concurrent re-execution scheduling strategy, and combining a multi-stage parallel mechanism to optimize resource utilization, the concurrent execution efficiency of nested contract transactions is significantly improved, the rollback overhead is greatly reduced, and the determinism of execution is ensured at the same time.

[0007] The specific technical solution for achieving the object of the present invention is as follows:

[0008] A deterministic concurrent execution method for nested contract transactions, comprising the following steps:

[0009] Step 1: Receive an ordered transaction block containing multiple transactions;

[0010] Step 2: Concurrent pre-execution step: Based on the first state snapshot, concurrently execute all transactions in the block, decompose each transaction into one or more sub-transactions, and record the execution information of each sub-transaction;

[0011] Step 3: Deterministic rollback step: Based on the execution information, construct a hyper-dependency graph representing the dependency relationships between the sub-transactions, apply a rollback algorithm to analyze the hyper-dependency graph, identify the sub-transactions that need to be rolled back, and determine an execution order that meets the serializability criterion;

[0012] Step 4: Fine-grained concurrent re-execution step: Based on the execution order and the dependency relationships in the hyper-dependency graph, schedule and execute the sub-transactions that have not been rolled back and the sub-transactions to be re-executed;

[0013] Step 5: Cross-block multi-stage parallel processing step: When processing the current block, start the concurrent pre-execution step described in Step 2 or the deterministic rollback step described in Step 3 using the temporary state snapshot generated after the rollback and partial submission of the previous block; after the previous block is fully committed and the final state snapshot is generated, complete the fine-grained concurrent re-execution step described in Step 4 of the current block based on this final state snapshot.

[0014] Further, the execution information described in Step 2 includes the read set, write set, contract call relationship of the transaction, and the nested structure between the sub-transactions.

[0015] Further, for the hyper-dependency graph described in Step 3, its dependency relationships include the internal dependency relationships between sub-transactions and the read-write dependency relationships between sub-transactions of different transactions; among them, the read-write dependency relationships are detected through a state access table, and the state access table maps the state to the sub-transaction read set and write set that access the state.

[0016] Further, the internal dependencies described in step 3 are divided into strong dependencies and weak dependencies. The strong dependency means that the successful completion of a subtransaction is a necessary condition for the successful completion of its parent transaction, and the weak dependency allows the subtransaction to be independently aborted.

[0017] Further, the rollback algorithm described in step 3 is a two-phase deterministic rollback algorithm. The first phase: fast rollback, identifying and processing the subgraph structure formed by direct read-write conflicts in the hyper-dependency graph, retaining the subtransactions selected by a predetermined rule, and rolling back the remaining conflicting subtransactions. The second phase: minimum-weight rollback, converting the hyper-dependency graph processed in the first phase into a global weight graph, identifying the strongly connected components in the global weight graph, and iteratively selecting and removing the dependencies required to break the cycle based on the weights or serialization costs defined for the subtransactions or their corresponding graph nodes to determine the final rollback transactions and execution order.

[0018] Further, in the second phase, the defined weight is calculated based on the execution time of the subtransaction itself and its dependent subtree as well as the cascading rollback impact factor; the serialization cost is calculated based on the aggregated weights of its in-degree and out-degree edges in the strongly connected component.

[0019] Further, step 4 specifically includes:

[0020] Step 4-1: Generating an initial scheduling plan according to the execution order and the hyper-dependency graph dependencies.

[0021] Step 4-2: Applying a fine-grained rescheduling algorithm to optimize the initial scheduling plan. The rescheduling algorithm attempts to move the subtransactions to be scheduled to earlier available time slots in the plan while satisfying the execution order, strong dependency relationships, and the constraint of no execution time overlap with the already scheduled subtransactions.

[0022] Step 4-3: Executing the subtransactions according to the optimized scheduling plan.

[0023] A deterministic concurrent execution system for nested contract transactions based on the above method. The system includes a sorting service module that executes step 1 of the method to receive an ordered transaction block containing multiple transactions; a transaction processing module that executes steps 2, 3, 4, and 5 of the method, and the specific execution manner conforms to the method; and a state storage module that stores the blockchain state and state snapshots.

[0024] Further, the transaction processing module specifically includes: a concurrent pre-execution sub-module for executing the concurrent pre-execution steps; a deterministic rollback sub-module for constructing the hyper-dependency graph and executing the rollback algorithm; a fine-grained concurrent re-execution sub-module for scheduling and executing the re-execution steps; and a multi-phase parallel processing sub-module for coordinating the cross-block multi-phase parallel processing steps.

[0025] Compared with the prior art, the present invention has significant beneficial effects: By means of fine-grained dependency analysis, sub-transaction-level rollback, and optimized concurrent scheduling, the system throughput for processing nested contract transactions is greatly improved; the precise rollback strategy significantly reduces unnecessary computational redundancy and rollback overhead; fine-grained concurrency and multi-stage parallelism improve the utilization rate of hardware resources; the entire process strictly follows the principle of determinism, ensuring the consistency of the system state; and it can effectively cope with the performance challenges brought by complex nested transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is the overall architecture diagram of the deterministic concurrent execution system according to Embodiment 1 of the present invention;

[0027] Figure 2 is an example diagram of the execution process of the two-phase deterministic rollback algorithm according to Embodiment 2 of the present invention;

[0028] Figure 3 is an example diagram of the fine-grained concurrent re-execution scheduling process according to Embodiment 3 of the present invention;

[0029] Figure 4 is a schematic diagram of the cross-block multi-stage parallel processing process according to Embodiment 4 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0030] Combined with the following specific embodiments and the drawings, the present invention will be further described in detail. The processes, conditions, experimental methods, etc. for implementing the present invention, except for the specifically mentioned content below, are all common knowledge and well-known common sense in the art, and the present invention has no particularly restricted content.

[0031] The present invention aims to solve the problems of high conflict rate, huge rollback overhead, and low execution parallelism caused by nested call chains and cross-contract interactions, and proposes a deterministic concurrent execution method and system for nested contract transactions. The system decomposes nested transactions into sub-transactions, precisely captures and utilizes the internal dependencies between sub-transactions and the external dependencies between transactions, realizes precise and low-overhead rollback at the sub-transaction granularity, and optimizes the parallelism of the re-execution stage through a fine-grained concurrent scheduling strategy to achieve cross-block multi-stage parallel processing, thereby significantly improving the overall performance of the system for processing nested transactions while ensuring determinism.

[0032] The specific implementation manner of the deterministic concurrent execution method and system for nested contract transactions proposed by the present invention is as follows:

[0033]

[0034]

[0035]

[0036]

[0037] It includes the following specific steps:

[0038] Step 1: Concurrent pre-execution and information recording.

[0039] Step 1-1: The system receives block B determined by the sorting service module, which contains ordered transactions. Obtain the initial consistent state snapshot for this execution 。Initialize the working thread set W for concurrent processing and related data structures.

[0040] Step 1-2: All transactions in block B are assigned to different working threads w in the working thread set W, and concurrent pre-execution is started.

[0041] Step 1-3: Each working thread w is based on the shared read-only snapshot and independently executes the transactions assigned to it 。During the execution, each nested transaction is dynamically decomposed into its constituent sub-transaction sequences, and the execution information of each sub-transaction is detailedly recorded, including but not limited to: read set (RS), write set (WS), call relationship with other contracts or sub-transactions, internal dependency type.

[0042] Step 2: Deterministic rollback and order determination

[0043] Step 2-1: Dependency graph construction: Collect the sub-transaction execution information recorded by all working threads in step one. Use the state access table to efficiently detect read-write access conflicts to the same state between different sub-transactions, and combine the internal dependency relationships between sub-transactions to construct a global super-dependency graph. The nodes of the super-dependency graph are sub-transactions, and the edges represent the internal dependencies between sub-transactions and / or external read-write dependencies caused by conflicts.

[0044] Step 2-2: Two-phase rollback algorithm:

[0045] Step 2-2a: Fast rollback (refer to Algorithm 2): Execute the fastRollback function. Traverse the state access table to identify the complete sub-graphs formed by direct read-write conflicts. For each complete sub-graph, retain one sub-transaction according to the predetermined weight policy, and add the remaining sub-transactions to the preliminary rollback list rbList.

[0046] Step 2-2b: Minimum Weight Rollback (refer to Algorithm 3): Remove the sub-transactions in rbList and their associated edges from the hyper-dependency graph to obtain the pruned hyper-dependency graph '. Input the hyper-dependency graph'into the minWeightRollback function. This function iteratively selects and marks the sub-transactions to be rolled back (updating the final rollback list rbList) by identifying strongly connected components and based on a greedy strategy (greedySelectEdges function) that minimizes the rollback cost, while determining the execution partial order pOrders that satisfies serializability.

[0047] Step 3: Fine-grained Concurrent Re-execution

[0048] Step 3-1: Scheduling Plan Generation and Optimization: Based on the final rollback list rbList and execution partial order pOrders determined in Step 2, as well as the dependency information retained in the hyper-dependency graph, generate an initial sub-transaction execution scheduling plan. Execute the finedgrainedReschedule function, apply the fine-grained rescheduling strategy, and attempt to advance the sub-transactions that satisfy dependency and resource constraints in the scheduling plan to earlier idle execution time slices to maximize parallelism, obtaining an optimized scheduling plan.

[0049] Step 3-2: Concurrent / Sequential Execution: According to the optimized scheduling plan, schedule the worker threads W in the system. For sub-transactions with no dependencies or only weak dependencies and resource availability, execute all sub-transactions not in the final rollback list rbList concurrently, or for sub-transactions with strong dependencies or resource conflicts, execute them sequentially as needed, as well as the sub-transactions in rbList that need to be re-executed.

[0050] Step 4: Cross-block Multi-stage Parallel Processing: By carefully designing and managing temporary snapshots and final snapshots, and coordinating different processing stages of different blocks on these two types of snapshots, the present invention achieves efficient cross-block multi-stage parallel processing, effectively breaking through the limitations of the traditional block serial processing mode, alleviating stage blocking, and significantly improving the overall throughput and resource utilization of the system for processing nested contract transactions.

[0051] The present invention also proposes a system for implementing the above-mentioned deterministic concurrent execution method. The system includes: an ordering service module, a transaction processing module, and a state storage module. The ordering service module is used to receive blocks containing ordered transactions from the ordering service. The state storage module is used to store the execution results. The transaction processing module is the core of the present invention and is deployed on each replica node of the blockchain network, responsible for executing the above-mentioned Steps 1 to 5.

[0052] Example 1

[0053] The following combines the attached Figure 1 to illustrate a specific embodiment of the present invention.Figure 1 Shows the overall architecture diagram of a deterministic concurrent execution system for nested contract transactions according to an embodiment of the present invention.

[0054] In this embodiment, the system includes an ordering service and multiple replica execution nodes. The ordering service is responsible for receiving transaction requests from clients and sorting and packaging these transactions into ordered transaction blocks. These ordered blocks are then distributed to all execution nodes.

[0055] After each execution node receives an ordered block, it processes it according to the three-phase deterministic concurrent execution process proposed by the present invention:

[0056] (1) Pre-execution phase: The node concurrently executes all transactions in the block based on the current consistent state snapshot. During this process, transactions are decomposed into sub-transactions, and information such as their read-write sets and call relationships is recorded. This phase uses multi-threaded parallel processing to maximize the initial execution efficiency and collect dependency information.

[0057] (2) Deterministic rollback phase: Based on the information collected in the pre-execution phase, the node constructs a hyper-dependency graph and executes a two-phase deterministic rollback algorithm. This algorithm analyzes the dependency relationships and conflicts in the hyper-dependency graph, identifies the set of sub-transactions that need to be rolled back, and determines a globally consistent execution order that meets the serializability requirement. The goal of this phase is to resolve concurrent conflicts and ensure determinism while minimizing the rollback overhead.

[0058] (3) Fine-grained concurrent re-execution phase: The node uses a fine-grained concurrent rescheduling algorithm to optimize and execute all non-rolled-back and pending re-execution sub-transactions according to the execution order determined in the rollback phase and the rolled-back sub-transactions. The goal of this phase is to utilize the parallelism at the sub-transaction level to efficiently complete the final transaction execution.

[0059] Figure 1 What is given is the processing flow inside a block. For the idle threads generated during the pre-execution and rollback processes between multiple blocks, they are allowed to read the transactions in subsequent blocks and pre-execute based on the latest persistent snapshot, implementing cross-block multi-phase parallel processing steps to increase the concurrency between blocks.

[0060] All execution nodes execute the same deterministic algorithm process to ensure that after processing the same block, the state updates finally committed to the state database are completely consistent, thus maintaining the overall consistency of the blockchain system. By decomposing the execution process into three clear phases and adopting techniques such as snapshot-based concurrency, sub-transaction-level dependency analysis and rollback, fine-grained scheduling, and cross-block multi-phase parallel processing, this system effectively improves the processing efficiency of nested contract transactions.

[0061] Embodiment 2

[0062] The following will describe a specific embodiment of the present invention in conjunction with the accompanying Figure 2 drawings. Figure 2 FIG. shows an example of the execution process of the two-phase deterministic rollback algorithm according to an embodiment of the present invention in a specific scenario.

[0063] Figure 2 (a) shows an original hyper-dependency graph, where nodes represent sub-transactions, the numbers within the nodes represent their weights, nodes of different colors belong to different original nested transactions, and the edges represent the dependency relationships between sub-transactions, including internal dependencies and external read / write dependencies.

[0064] In the fast rollback phase, as shown in Figure 2 (a), the algorithm first uses the state access table to identify the complete sub-graph formed by transactions , and . From this sub-graph, transactions and with lower weights are selected for rollback, and then these three transactions ( , , ) are removed from the hyper-dependency graph, simplifying the graph complexity. Entering the minimum-weight rollback phase, the remaining hyper-dependency graph is mapped into a global weighted graph, as shown in Figure 2 (b), and two strongly connected components are identified through the Tarjan algorithm. The first strongly connected component contains transactions , and . Among them, transaction is selected to roll back its out-edge ( → ) first due to its lowest serialization cost and transaction ID, resulting in the rollback of the sub-transaction , and the serialization order of transaction is recorded, as shown in Figure 2 (c). After completing the pruning and updating of the graph, next, continue to select the out-edge of transaction ( → ) according to the rollback strategy, roll back the sub-transactions , and , and place the serializable order of transaction before that of transaction . Finally, since only transaction remains, it is recorded at the front of the serialization order, obtaining the serialization order of this strongly connected component: { , , }, as shown in Figure 2as shown in (d). The second strongly connected component contains transactions and , and since it has the lowest serialization cost among the transactions, the out-edge of ( → ) is selected, thereby rolling back sub-transactions , and , and obtaining the serialization order: { , } as shown in Figure 2 (e).

[0065] Embodiment 3

[0066] A specific embodiment of the present invention will be described below with reference to the accompanying Figure 3 drawings. Figure 3 FIG. shows an example of the execution process of the fine-grained concurrent re-execution scheduling algorithm according to an embodiment of the present invention in a specific scenario, visualized using an execution space-time diagram.

[0067] First, based on the internal concurrency characteristics of nested contract transactions, a space-time diagram as shown in Figure 3 (a) can be obtained. Then, the first transaction in the initial sequence is taken out, and the set of non-conflicting transactions with it is obtained, that is, , , , , , . First, an attempt is made to move the entire (including , , ) forward. It is found that it can be moved forward, thereby obtaining a space-time diagram as shown in Figure 3 (b). It should be noted that if the forward movement of the entire fails, an attempt will continue to move the of a single sub-transaction forward. However, since if is moved forward, there will be a situation where some transactions of are executed before and some transactions ( ) are executed after , , violating the isolation of transactions, so the forward movement will not be allowed. Then will attempt to recursively move forward conflicting transactions , , , where cannot be scheduled due to conflicts. will first attempt to schedule it to The execution time, but since this violates the serialization order ≺ , so continue to try to move it to After successful execution completion, obtain as shown in Figure 3 (c). Then Try recursive scheduling , And all end in failure. Then Continue recursive attempts and successfully schedule To The execution time, obtain Figure 3 (d). The first round of scheduling ends. The second round of scheduling takes out Try to move forward , because , , , All moved forward successfully in previous rounds. Finally Rescheduling is successful and obtain Figure 3 (e). And further scheduling attempts for End in failure. The second round of rescheduling process ends. It can be seen from this example that only two rounds of rescheduling can obtain a more compact space-time diagram, and after the first round of scheduling ends, the execution concurrency of the rollback transaction has increased by 100%, showing the high efficiency and effectiveness of the algorithm of the present invention.

[0068] Embodiment 4

[0069] Figure 4 Shows a schematic diagram of a cross-block multi-stage parallel processing mechanism according to an embodiment of the present invention, demonstrating the process of implementing pipeline processing using different state snapshots. Different colors in the figure represent different blocks, and each block has three stages: a pre-execution stage, a rollback stage, and a re-execution stage.

[0070] Pre-execution and rollback stages in parallel: In the traditional execution mode, all transactions of the current block Must be pre-executed completely and the rollback operation completed before entering the re-execution stage. However, through the above analysis, it is known that there is a large space for parallel optimization in this process. Therefore, in this solution, for the idle threads generated during the pre-execution and rollback of the block , they are allowed to prefetch the transactions in the block And perform pre-execution based on the persistent snapshot , as shown in Figure 4 (a). In this way, the transactions of subsequent blocks can enter the execution stage in advance without having to wait for all transactions of the current block to be executed. To ensure the correctness of the execution result, in the block During the execution of a transaction, it is necessary to check whether it is consistent with the block The transaction has cross-block read and write dependencies. → situation, in which It's a block The affairs in It's a block Transactions in the blockchain, i.e. blocks Affairs Read the block Affairs The written data, because at this time Updates to are not yet persisted, so The stale state version is read during execution, so Must be rolled back and After a successful submission, execution is attempted again to ensure the correctness of the execution result. In this way, the system can utilize computing resources during both the execution and rollback phases, improving overall throughput. This mechanism allows the pre-execution phase of subsequent blocks to proceed in parallel with the pre-execution and rollback phases of the current block, effectively reducing waiting and idle system resources and improving parallel processing capabilities.

[0071] Rollback and re-execution phases are parallel: when the block After the rollback phase is completed, the system generates a temporary snapshot , at this time the block The transaction enters the re-execution phase, and the block The transaction starts based on the snapshot Execute and rollback, so that the rollback phase and the re-execution phase can be carried out in parallel, such as Figure 4 (b) To ensure the correctness of the execution results, in this process, if the block A transaction in Depends on the block Rollback transaction ,Right now → , then the transaction The stale state is read, which will affect the correctness of the final execution result. It will be directly added to the rollback list and rescheduled and executed in the subsequent re-execution phase. Transactions will depend on the final snapshot Execute to ensure the consistency and correctness of the final execution results, such as Figure 4As shown in (c). By allowing transactions to execute on a temporary snapshot and perform a final commit after the final snapshot is generated, the limitation of serial execution within a traditional block is broken through, enabling transactions in multiple blocks to be executed efficiently and concurrently.

[0072] The protection scope of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, changes and advantages that can be conceived by those skilled in the art are included in the present invention, and the appended claims are taken as the protection scope.

Claims

1. A deterministic concurrent execution method for nested contract transactions, characterized in that, It includes the following steps: Step 1: Receive an ordered transaction block containing multiple transactions; Step 2: Concurrent pre-execution step: Based on the first state snapshot, concurrently execute all transactions in the block, decompose each transaction into one or more sub-transactions, and record the execution information of each sub-transaction; Step 3: Deterministic rollback step: Based on the execution information, construct a hyper-dependency graph representing the dependency relationships between the sub-transactions, apply a rollback algorithm to analyze the hyper-dependency graph, identify the sub-transactions that need to be rolled back, and determine an execution order that meets the serializability criterion; Step 4: Fine-grained concurrent re-execution step: Based on the execution order and the dependency relationships in the hyper-dependency graph, schedule and execute the sub-transactions that have not been rolled back and the sub-transactions to be re-executed; Step 5: Cross-block multi-stage parallel processing step: When processing the current block, start the concurrent pre-execution step described in Step 2 or the deterministic rollback step described in Step 3 using the temporary state snapshot generated after the rollback and partial submission of the previous block; after the previous block is fully committed and the final state snapshot is generated, complete the fine-grained concurrent re-execution step described in Step 4 of the current block based on this final state snapshot.

2. The deterministic concurrent execution method according to claim 1, wherein The execution information described in Step 2 includes the read set, write set, contract call relationship of the transaction, and the nested structure between the sub-transactions.

3. The deterministic concurrent execution method according to claim 1, characterized in that For the hyper-dependency graph described in Step 3, its dependency relationships include internal dependency relationships between sub-transactions and read-write dependency relationships between sub-transactions of different transactions; among them, the read-write dependency relationships are detected through a state access table, and the state access table maps the state to the read set and write set of the sub-transactions that access this state.

4. The deterministic concurrent execution method according to claim 3, wherein The internal dependency relationships described in Step 3 are divided into strong dependencies and weak dependencies. The strong dependency means that the successful completion of a sub-transaction is a necessary condition for the successful completion of its parent transaction, and the weak dependency allows the sub-transaction to be independently aborted.

5. The deterministic concurrent execution method according to claim 1, wherein The rollback algorithm described in Step 3 is a two-phase deterministic rollback algorithm; the first phase: fast rollback, identify and process the sub-graph structure formed by direct read-write conflicts in the hyper-dependency graph, retain the sub-transactions selected by a predetermined rule, and roll back the remaining conflicting sub-transactions; the second phase: minimum weight rollback, convert the hyper-dependency graph processed in the first phase into a global weight graph, identify the strongly connected components in the global weight graph, and based on the weights or serialization costs defined for the sub-transactions or their corresponding graph nodes, iteratively select and remove the dependencies required to break the cycle to determine the final rollback transactions and execution order.

6. The deterministic concurrent execution method according to claim 5, wherein In the second phase, the defined weights are calculated based on the execution time of the sub-transaction itself and its dependent sub-tree and the cascading rollback impact factor; the serialization cost is calculated based on the aggregated weights of its in-degree and out-degree edges in the strongly connected component.

7. The deterministic concurrent execution method according to claim 1, wherein The specific content of Step 4 includes: Step 4-1: Generate an initial scheduling plan according to the execution order and the hyper-dependency graph dependency relationships; Step 4-2: Apply a fine-grained rescheduling algorithm to optimize the initial scheduling plan. The rescheduling algorithm attempts to move the sub-transactions to be scheduled to an earlier available time period in the plan, while meeting the constraints of the execution order, strong dependency relationships, and no execution time overlap with the already scheduled sub-transactions; Step 4-3: Execute sub-transactions according to the optimized scheduling plan.

8. A deterministic concurrent execution system for nested contract transactions based on the method described in claim 1, characterized in that, The system includes a sorting service module that executes method step 1 to receive an ordered transaction block containing multiple transactions; a transaction processing module that executes method steps 2, 3, 4, and 5, and the specific execution manner conforms to the method described in any one of claims 1 to 7; and a state storage module that stores the blockchain state and state snapshots.

9. The deterministic concurrent execution system according to claim 8, wherein The transaction processing module specifically includes: a concurrent pre-execution sub-module for executing concurrent pre-execution steps; a deterministic rollback sub-module for constructing a super-dependency graph and executing a rollback algorithm; a fine-grained concurrent re-execution sub-module for scheduling and executing re-execution steps; and a multi-phase parallel processing sub-module for coordinating cross-block multi-phase parallel processing steps.

Images