A fine-grained scheduling-based smart contract concurrent execution method

Abstract

This invention discloses a method for concurrent execution of smart contracts based on fine-grained scheduling, comprising: receiving blocks and parsing the sequentially arranged transactions within them, extracting the contract call information and state access set of the transactions; constructing a multi-layered state structure for each transaction, including a local state layer, a pre-commit state layer, and a global state layer, and initializing a dependency graph; during concurrent execution, using instructions as the smallest scheduling unit, dynamically detecting conflicts, maintaining dependencies, and managing execution states, recording the write results in the pre-commit state layer; after a transaction is completed, executing verification and committing the state; updating the dependency graph after committing, and waking up related transactions to continue scheduling and execution. This invention achieves a finer-grained concurrent scheduling mechanism while ensuring the correctness of block order and smart contract semantics, improving node execution efficiency and transaction throughput, and is suitable for high-performance blockchain systems.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and smart contracts, and particularly to a method for concurrent execution of smart contracts based on fine-grained scheduling. Background Technology

[0002] Blockchain is a distributed ledger system maintained by multiple network nodes. It features tamper-proof, trustless, and traceable characteristics and is widely used in decentralized finance, supply chain management, and other fields. A blockchain ledger consists of several blocks, all of which are linked together in the order of their generation via cryptographic hash pointers to form a chain structure called a "blockchain".

[0003] Each block contains a set of transactions arranged sequentially. Each transaction is initiated by a user to request on-chain state changes, including asset transfers, smart contract calls, and new contract deployments. The order of transactions within a block is determined by the block generator and is deterministic across the network. Smart contracts are executable code deployed on the blockchain that runs automatically when specific conditions are met. User-initiated contract call transactions include the target contract's address, input parameters, and the caller's signature. When processing such transactions, blockchain nodes load and execute the bytecode logic within the smart contract, reading and modifying the on-chain state. The execution of smart contracts is handled by a blockchain virtual machine, such as the Ethereum Virtual Machine (EVM) used by the Ethereum platform. The EVM is a stack-based execution engine that interprets and executes the bytecode instructions of the smart contract line by line. During execution, nodes read, calculate, and update contract state data based on the transaction content and write the execution results to a global state database.

[0004] To ensure that all nodes in a blockchain network have a consistent ledger state at the same block height, transactions within a block must be executed strictly in sequence, and this execution order cannot be changed. However, with the continuous growth of on-chain transaction volume, this sequential execution model has gradually exposed computational bottlenecks. Although consensus protocols have achieved performance optimizations in recent years, the execution layer still adopts a serial processing mode, severely limiting system throughput and becoming a key constraint on blockchain scalability. To address this, existing research has introduced concurrent execution mechanisms, using optimistic concurrency control, pessimistic concurrency control, and transaction dependency analysis to improve transaction throughput. However, most existing concurrent execution solutions suffer from the following problems:

[0005] 1. Coarse scheduling granularity: Existing methods usually use transactions as the basic scheduling unit, and only perform dependency determination and conflict detection between transactions. They fail to go deep into the instruction level for dynamic scheduling, which leads to the neglect of a large number of potential parallel opportunities within a transaction, thus limiting the improvement of system concurrency.

[0006] 2. Simple state management: Most methods lack a layered design in state management, usually only maintaining a global state or a single isolated state, and cannot flexibly distinguish data at different access levels; this not only incurs a large overhead in conflict isolation, but also causes dependency resolution delays and slows down the progress of the critical path.

[0007] 3. High dependency detection overhead: Some solutions maintain the dependencies between transactions through global scanning or static analysis, resulting in high runtime overhead. Especially in scenarios with high transaction density and high data conflict, the efficiency of conflict detection and dependency determination is insufficient, and the efficiency of concurrent execution is severely reduced.

[0008] 4. Difficulty in guaranteeing the orderly submission of execution results: Some technologies cannot ensure that transactions are submitted in sequence; during reordering or concurrency, the original submission order of transactions may be disrupted, resulting in inconsistent execution results and making it difficult to be compatible with existing blockchain architectures.

[0009] Therefore, how to achieve efficient scheduling of transactions at a fine-grained level in concurrent execution while ensuring the correctness of the chain structure, transaction order, and smart contract semantics, thereby improving the efficiency of concurrent execution and system throughput, is a major technical challenge facing the current blockchain execution architecture. Summary of the Invention

[0010] To address the performance bottlenecks in existing sequential execution or coarse-grained scheduling modes, this invention proposes a smart contract concurrent execution method based on fine-grained scheduling, which improves the concurrency efficiency and overall throughput of blockchain transaction execution.

[0011] This invention discloses a method for concurrent execution of smart contracts based on fine-grained scheduling, comprising the following steps:

[0012] S1. Block and Transaction Resolution: Receive blocks and resolve the transactions in the blocks to obtain the resolution results; a block consists of several transactions arranged in order; the resolution results include transaction context and state access set, the state access set includes information about the state that a transaction will read or write;

[0013] S2. Initialize the multi-level state model: Initialize the multi-level state model based on the analysis results in S1;

[0014] S3. Initialize the transaction dependency structure: Initialize the transaction dependency structure based on the resolution results in S1;

[0015] S4. Concurrent Transaction Execution: Executes transactions concurrently; utilizes instruction-level conflict detection and scheduling algorithms to determine the order of transaction execution; uses a multi-level state model to store intermediate states during execution; uses a transaction dependency structure to maintain transaction dependencies during execution; stores the execution results in the multi-level state model after transaction execution; outputs the execution results.

[0016] S5. Result Verification and Submission: Verify whether the transaction was executed correctly by checking the execution result. If yes, submit the execution result and proceed to S6; otherwise, roll back the execution result and re-enter S2.

[0017] S6, Dependency Tracking and Scheduled Update: Inspect the transaction dependency structure and wake up all other transactions that depend on this transaction.

[0018] As a further improvement, in S2 of this invention, a multi-level state model is constructed, consisting of a local state layer, a pre-commit state layer, and a global state layer. Different levels of state provide access isolation with different granularities. Each transaction has a local state layer and a pre-commit state layer. The local state layer is only accessible to its own transaction. The data in the pre-commit state layer is only readable by subsequent transactions of its own transaction. All transactions share a global state layer, which is accessible to all transactions.

[0019] As a further improvement, in S3 of the present invention, the transaction dependency structure is represented by a graph data structure to represent the dependency relationship between transactions, where a vertex represents a transaction and an edge represents a dependency relationship between transactions, that is, a subsequent transaction is waiting for the execution result of the preceding transaction.

[0020] As a further improvement, in S4 of this invention, the order of transaction execution is determined by using an instruction-level conflict detection and scheduling algorithm as follows: the execution of a transaction consists of the execution of several instructions; before each instruction is executed, it is checked whether there is a conflict, that is, whether the instruction depends on the preceding transaction; if so, the transaction becomes a waiting state, the execution of the transaction is suspended, and other ready transactions are switched to execute; if not, or after the above dependency is resolved and the transaction is reawakened, the current instruction is executed immediately; after each instruction is executed, it is checked whether the dependency of the subsequent waiting transactions is resolved; if so, the subsequent transactions are awakened.

[0021] As a further improvement, in S4 of the present invention, the intermediate states during the execution process are stored using a multi-level state model as follows: the states read and written during instruction execution are stored in the local state layer of the current transaction; after instruction execution, the state written by the instruction is determined according to the state access set to determine whether it can be pre-committed; if so, it is written into the pre-committed state layer of the current transaction, providing dependent data that can be read in advance for subsequent transactions in the waiting state, so that the dependencies of subsequent transactions in the waiting state can be resolved in advance, and the transaction becomes ready.

[0022] As a further improvement, in S4 of the present invention, the use of the transaction dependency structure to maintain the transaction dependency relationship during the execution process specifically means: when a conflict is detected, the transaction is added to the transaction dependency structure; after the state is submitted to the pre-submission state layer, the transaction dependency structure is used to query subsequent transactions that are in the waiting state.

[0023] As a further improvement, S5 of the present invention specifically includes the following steps: when a transaction is completed, it enters the waiting verification stage; when all transactions before a transaction waiting for verification are submitted, the transaction enters the verification stage; the transaction verification stage checks whether the state read during the execution of the transaction is consistent with the current global state layer; if so, the execution result is submitted to the global state layer; if not, the execution result is rolled back.

[0024] The present invention has the following beneficial effects:

[0025] 1. This invention implements a method for concurrent transaction execution. This method improves the throughput of smart contract execution by simultaneously executing multiple transactions in a blockchain. This method is beneficial for blockchain environments with high transaction density.

[0026] 2. This invention implements an instruction-level conflict detection and scheduling algorithm. This algorithm detects the existence of conflicts before instruction execution and checks whether dependencies are resolved after instruction execution. This enables dynamic conflict detection, dependency maintenance, execution scheduling, and state management at the instruction level during concurrent transaction execution. This algorithm is beneficial for fully exploiting parallel opportunities within a transaction, significantly improving execution concurrency.

[0027] 3. This invention implements a multi-level state model, consisting of a local state layer, a pre-commit state layer, and a global state layer. Different levels of state provide access isolation at different granularities. Intermediate states during execution are committed to the local state layer and selectively to the pre-commit state layer, while the execution result is ultimately committed to the global state layer. This model ensures secure data access and maintenance while accelerating the resolution and resolution of dependencies between transactions. This model is beneficial for accelerating critical path progression and further improving scheduling efficiency.

[0028] 4. This invention implements a transaction dependency structure to represent the dependencies between transactions. This structure updates the dependency state between transactions in real time during transaction execution, avoiding the need for a global scan of all transaction states for conflict detection and dependency determination, thereby reducing runtime detection overhead. This structure helps reduce unnecessary blocking and further improves concurrent scheduling performance.

[0029] 5. This invention introduces a result verification and submission step, which ensures the consistency of transaction execution order and final result by sequentially verifying and submitting execution results. This step is beneficial for compatibility with existing blockchain architecture execution paradigms and has good versatility and portability.

[0030] 4. This invention implements a transaction dependency structure to represent the dependencies between transactions. This structure updates the dependency state between transactions in real time during transaction execution, avoiding the need for a global scan of all transaction states for conflict detection and dependency determination, thereby reducing runtime detection overhead. This structure helps reduce unnecessary blocking and further improves concurrent scheduling performance.

[0031] 5. This invention introduces a result verification and submission step, which ensures the consistency of transaction execution order and final result by sequentially verifying and submitting execution results. This step is beneficial for compatibility with existing blockchain architecture execution paradigms and has good versatility and portability. Attached Figure Description

[0032] Figure 1 This is a flowchart of a smart contract concurrent execution method based on fine-grained scheduling in an embodiment of the present invention;

[0033] Figure 2 This is a flowchart of conflict detection, scheduling execution, status, and dependency maintenance in this embodiment of the invention. Detailed Implementation

[0034] This invention discloses a method for concurrent execution of smart contracts based on fine-grained scheduling, comprising the following steps:

[0035] S1. Block and Transaction Resolution: Receive blocks and resolve the transactions in the blocks to obtain the resolution results; a block consists of several transactions arranged in order; the resolution results include the transaction context, the target contract being called, the input parameters, and the state access set, which includes information about the state that the transaction will read or write.

[0036] S2. Initialize the multi-level state model: Initialize the multi-level state model based on the parsing results in S1; The multi-level state model consists of a local state layer, a pre-commit state layer, and a global state layer. Different levels of state provide access isolation with different granularities. Each transaction has a local state layer and a pre-commit state layer; The local state layer is only accessible to its own transaction; The data in the pre-commit state layer is only readable by subsequent transactions of its own transaction; All transactions share a global state layer, which is accessible to all transactions.

[0037] S3. Initialize the transaction dependency structure: Initialize the transaction dependency structure based on the parsing results in S1; the transaction dependency structure is represented by a graph data structure to represent the dependencies between transactions, where a vertex represents a transaction and an edge represents a dependency between transactions, that is, a subsequent transaction is waiting for the execution result of the preceding transaction.

[0038] S4. Concurrent Transaction Execution: Transactions are executed concurrently. During concurrent execution, an instruction-level conflict detection and scheduling algorithm is introduced to determine the order of transaction execution. A multi-level state model is used to store intermediate states during execution. A transaction dependency structure is used to maintain transaction dependencies during execution. After a transaction is completed, the execution result is stored in the multi-level state model. The execution result is output, and the process proceeds to S5. Specifically, the instruction-level conflict detection and scheduling algorithm for determining the order of transaction execution is as follows: Each transaction is executed in an independent thread, and the execution of a transaction consists of the execution of several instructions. Before each instruction is executed, a conflict is checked, i.e., whether the state read by the instruction depends on the previous transaction. If so, the transaction becomes a waiting state and is paused. Execute the instruction and switch to other ready transactions for execution. If not, or if the aforementioned dependency conflict is resolved and the transaction is reawakened, immediately execute the current instruction. After each instruction is executed, check whether the dependencies of subsequent waiting transactions are resolved. If so, awaken the aforementioned subsequent transactions. A multi-level state model is used to store intermediate states during execution: the states read and written during instruction execution are stored in the local state layer of the current transaction. After instruction execution, the state written by the instruction is determined based on the state access set to determine if it can be pre-committed. If so, it is written to the pre-committed state layer of the current transaction, providing pre-read dependency data for subsequent waiting transactions, thus resolving the dependencies of these waiting transactions in advance, and the resolved transactions become ready. A transaction dependency structure is used to maintain transaction dependencies during execution: when a conflict is detected, the transaction is added to the transaction dependency structure; after the state is committed to the pre-committed state layer, the transaction dependency structure is used to query subsequent waiting transactions to awaken transactions with resolved dependencies.

[0039] S5. Result Verification and Submission: After a transaction is completed and all its preceding transactions have been submitted, the verification step begins. This step verifies whether the transaction was executed correctly based on the execution result. If yes, the execution result is submitted, and the process proceeds to S6; otherwise, the execution result is rolled back, and the process re-enters S2. S6. After a transaction is completed, it enters the waiting-for-verification phase. When all transactions preceding a transaction in the waiting-for-verification phase have been submitted, the transaction enters the verification phase. The transaction verification phase checks whether the state read during the transaction execution process is consistent with the current global state layer. If yes, the execution result of the transaction is submitted to the global state layer; otherwise, the execution result of the transaction is rolled back.

[0040] S6. Dependency Tracking and Scheduled Update: After the execution result of a transaction passes result verification and is submitted, check the transaction dependency structure and wake up all other transactions that depend on this transaction.

[0041] This invention also discloses a smart contract concurrent execution device for implementing a smart contract concurrent execution method based on fine-grained scheduling, comprising:

[0042] Parsing Module: Used for block and transaction parsing: Receives blocks, parses the transactions in the blocks to obtain the parsing results; a block consists of several transactions arranged in order; the parsing results include the transaction context, the target contract being invoked, input parameters, and a state access set, which includes information about the state that the transaction will read or write.

[0043] First initialization module: Used to initialize the multi-level state model: Initializes the multi-level state model based on the parsing results in the parsing module;

[0044] The second initialization module is used to initialize the transaction dependency structure based on the parsing results from the parsing module.

[0045] Execution and Scheduling Module: Used for concurrent transaction execution: Executes transactions concurrently; During concurrent transaction execution, an instruction-level conflict detection and scheduling algorithm is introduced to determine the order of transaction execution; A multi-level state model is used to store intermediate states during the execution process; A transaction dependency structure is used to maintain transaction dependencies during the execution process; After the transaction is completed, the execution result is stored in the multi-level state model; The execution result is output and enters the verification and submission module.

[0046] Verification and Submission Module: Used for result verification and submission. When a transaction is completed and all its preceding transactions have been submitted, the verification step is entered. This step verifies whether the transaction was executed correctly through the execution result. If it was, the execution result is submitted, and then the tracking and update module is entered. If not, the execution result is rolled back, and the first initialization module is re-entered.

[0047] Tracking and updating module: Used for dependency tracking and scheduling updates: When the execution result of a transaction passes result verification and is submitted, it checks the transaction dependency structure and wakes up all other transactions that depend on that transaction.

[0048] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] In the following description, reference is made to "one specific embodiment," which describes a subset of all possible embodiments; however, it is understood that "one specific embodiment" describes the same or different subsets of all possible embodiments and may be combined with each other without conflict.

[0050] Unless otherwise defined, all techniques used herein have the same scientific or technical meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to limit the invention.

[0051] Before providing a further detailed description of the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention will be explained, and the nouns and terms involved in the embodiments of the present invention shall be subject to the following interpretations.

[0052] 1) Block: refers to the basic unit used to record transaction data in a blockchain system. It usually includes a block header and several transactions arranged in sequence.

[0053] 2) Transaction: refers to a state change request initiated by a user in the blockchain system, which usually includes operations such as asset transfer and smart contract call, and is the basic building block of a block.

[0054] 3) Smart Contract: Program code deployed on the blockchain that executes automatically when specific conditions are met, used to control the reading, modification, and transfer of on-chain state.

[0055] 4) Instruction: Usually represented in bytecode form. Each instruction performs a specific function, such as reading from or writing to memory, performing arithmetic operations, conditional jumps, or external calls. It is the smallest unit of execution that constitutes the logic of a smart contract.

[0056] 5) Program Counter (PC): This is the location used to store the address of the memory location of the next instruction.

[0057] 6) Virtual Machine: The runtime environment used to interpret and execute the bytecode of smart contracts, such as the Ethereum Virtual Machine (EVM), which uses instructions as the smallest unit of execution.

[0058] 7) State: refers to the stored data of smart contracts in a blockchain system. It usually exists in the form of key-value pairs and is used to record account balances, contract storage variables, etc.

[0059] 8) Access Set: This refers to the set of states accessed during the execution of a transaction, typically including a Read Set and a Write Set.

[0060] 9) Concurrent Execution: This refers to the execution method of simultaneously scheduling and executing multiple transactions or instructions within transactions in a multi-threaded or multi-core environment. Unlike the strict sequential execution model used in traditional blockchains, concurrent execution allows multiple transactions or instructions to run simultaneously without violating data dependencies, thereby improving system resource utilization and overall processing throughput.

[0061] 10) Thread: The basic unit of task scheduling and execution that the operating system can perform. A thread refers to a single sequential flow of control in a program. Multiple threads can run concurrently in a program, each executing different tasks in parallel.

[0062] like Figure 1 As shown, a method for accelerating the execution of smart contracts based on just-in-time compilation includes the following steps:

[0063] S1. Block and Transaction Parsing: The system first receives blocks, usually provided by external nodes. The transactions within the block are parsed to obtain the parsing results. A block consists of several transactions arranged in sequence. The parsing results include the transaction context, the target contract being invoked, input parameters, and a state access set. The state access set includes information about the states that the transaction reads or writes. The parsing module is responsible for extracting these parsing results to prepare for subsequent processing.

[0064] S2. Initialize the multi-level state model

[0065] The first initialization module initializes a multi-level state model for transactions, which has a three-layer structure. Different levels of state provide access isolation at different granularities:

[0066] Local state layer: Each transaction has a private, accessible local state layer used to record the intermediate states during the execution of the current transaction. This state data is not visible to other transactions.

[0067] Pre-commit state layer: Each transaction has a semi-private pre-commit state layer, which is accessible to the transaction it belongs to, but only readable by subsequent transactions. This layer stores the pre-committable portion of the execution results of the transaction, supporting the early reading of partial states and the early resolution of dependencies.

[0068] Global State Layer: All transactions share a single global state layer, which is accessible to all transactions. This layer records all verified and committed execution results and represents the system's current publicly visible state.

[0069] After the multi-level state model is initialized, the local state layer and the pre-commit state layer are empty, while the global state layer stores the state before the transaction is executed.

[0070] S3. Initialize the transaction dependency structure

[0071] The second initialization module initializes the transaction dependency structure, which is used to maintain the state access dependencies between transactions in subsequent steps. This structure is represented as a dependency graph, with transactions as nodes and dependencies represented as directed edges. The rules for constructing dependencies are as follows: If there are transactions A and B in a block, and A precedes B, and A's write set contains a certain state key X, and B's read set also contains that state key X, then a directed edge (A → B) is added to the dependency graph from transaction A to transaction B, indicating that B depends on the execution result of A. The dependencies between transactions are not constructed during initialization, but are dynamically completed during the concurrent execution of transactions (i.e., in S4).

[0072] S4. Concurrent Transaction Execution: The execution and scheduling module executes transactions concurrently. Each transaction is executed in an independent thread, with multiple threads running simultaneously to execute multiple transactions concurrently. Different threads execute different transactions using the same execution flow, supporting the concurrent execution of dozens or hundreds of transactions. The execution of a transaction consists of the execution of several instructions. During execution, instruction-level conflict detection and scheduling algorithms are introduced to determine the order of transaction execution. A multi-level state model is used to store intermediate states during execution. A transaction dependency structure is used to maintain transaction dependencies during execution. After transaction execution is complete, the execution result is stored in the multi-level state model, such as... Figure 2 As shown, the execution flow of a transaction t (or a thread) is as follows:

[0073] 1) S4.1 Read the PC of the next instruction to be executed in the current transaction t, and obtain the specific instruction in the corresponding EVM bytecode through the PC.

[0074] 2) S4.2 If the instruction accesses a state key (e.g., reads state k), then query the state access set to determine whether state k was accessed by a previous transaction t. * If the transaction is not written, then there is no conflict, proceed to S4.4; if it is, continue querying the multi-level state model to determine the preceding transaction t. * Has the execution result or pre-committed status k been submitted? If not, there is no conflict, proceed to S4.4; if yes, the status k read by the current instruction has not yet been written by the previous transaction t*, a conflict is detected, proceed to S4.3.

[0075] S4.3 If a conflict exists (i.e., the preceding transaction t on which this instruction depends) * (If the write to k is not yet complete), the transaction enters a waiting state, is added to the transaction dependency structure, and its execution is paused while switching to another ready transaction for execution. After the above dependencies (conflicts) are resolved, the transaction t is reawakened and then proceeds to S4.4.

[0076] 3) S4.4 Execute the current instruction and store the read and written states into the local state layer of the current transaction.

[0077] S4.5 After instruction execution, determine whether the state written by the instruction can be pre-committed based on the current transaction t's state access set; that is, whether the state written by the current instruction is the final state written by the current transaction. If so, write it into the current transaction's pre-committed state layer. Query subsequent transactions in a waiting state through the transaction dependency structure. Utilize the data in the pre-committed state layer to provide these subsequent transactions with pre-readable dependency data, accelerating the resolution of state dependencies and readiness determination for subsequent transactions, and waking up these subsequent transactions.

[0078] 4) S4.6 Determine if the current instruction is the last instruction of the current transaction. If yes, complete the transaction execution and proceed to S5; otherwise, update the PC and proceed to S4.1.

[0079] S5. Result Verification and Submission: When all instructions for a transaction t are executed, it enters the verification waiting phase. After all preceding transactions of t have been submitted, t can enter the verification process. The verification process determines whether the state read by all instructions during the execution of the transaction is consistent with the current global state layer. If the verification is successful, the execution result is submitted, that is, the state data in the local state layer is submitted to the global state layer, and then proceeds to S6; if the verification fails (e.g., the rollback of preceding transactions causes inconsistencies in dependent states), the execution result of the transaction is rolled back, and the process proceeds to S2 for re-execution.

[0080] S6. Dependency Tracking and Scheduled Update: After the execution result of a transaction t is verified and submitted, the dependency structure is checked to obtain all transactions that depend on transaction t and are in a waiting state. The dependencies of all such waiting transactions are resolved and they are then awakened.

[0081] The above detailed description is a specific description of feasible embodiments of the present invention. These embodiments are not intended to limit the patent scope of the present invention. All equivalent implementations or modifications that do not depart from the present invention should be included within the scope of the technical solution of the present invention.

Claims

1. A method for concurrent execution of smart contracts based on fine-grained scheduling, characterized in that, Includes the following steps: S1. Block and Transaction Resolution: Receive a block and resolve the transactions in the block to obtain the resolution result; the block consists of several transactions arranged in order; the resolution result includes the transaction context and the state access set, the state access set including information about the state that the transaction will read or write. S2. Initialize the multi-level state model: Initialize the multi-level state model based on the analysis results in S1; S3. Initialize the transaction dependency structure: Initialize the transaction dependency structure based on the resolution results in S1; S4. Concurrent Transaction Execution: Executes transactions concurrently; utilizes instruction-level conflict detection and scheduling algorithms to determine the order of transaction execution; The process utilizes a multi-level state model to store intermediate states during execution; a transaction dependency structure to maintain transaction dependencies during execution; and the execution result stored in the multi-level state model after a transaction is completed. The execution result is then output. Specifically, the method of using instruction-level conflict detection and scheduling algorithms to determine the order of transaction execution involves: the execution of a transaction consists of the execution of several instructions; before each instruction is executed, a conflict is checked to determine if the instruction depends on a preceding transaction; if so, the transaction enters a waiting state, its execution is paused, and other ready transactions are switched to execute; if not, or after the aforementioned dependency has been resolved and the transaction is reawakened, the current instruction is executed immediately; after each instruction is executed, it is checked whether there is a subsequent transaction in a waiting state whose dependency has been resolved; if so, the transaction is awakened. S5. Result Verification and Submission: Verify whether the transaction was executed correctly by checking the execution result. If yes, submit the execution result and proceed to S6; otherwise, roll back the execution result and re-enter S2. S6, Dependency Tracking and Scheduled Update: Inspect the transaction dependency structure and wake up all other transactions that depend on this transaction.

2. The method for concurrent execution of smart contracts based on fine-grained scheduling according to claim 1, characterized in that, In S2, the multi-level state model consists of a local state layer, a pre-commit state layer, and a global state layer. Different levels of state provide access isolation with different granularities. Each transaction has a local state layer and a pre-commit state layer. The local state layer is only accessible to its own transaction. The data in the pre-commit state layer is only readable by subsequent transactions of its own transaction. All transactions share a global state layer, which is accessible to all transactions.

3. The method for concurrent execution of smart contracts based on fine-grained scheduling according to claim 1 or 2, characterized in that, In S3, the transaction dependency structure is represented by a graph data structure to represent the dependencies between transactions, where a vertex represents a transaction and an edge represents a dependency between transactions, that is, a subsequent transaction is waiting for the execution result of the preceding transaction.

4. The method for concurrent execution of smart contracts based on fine-grained scheduling according to claim 3, characterized in that, In S4, the use of a multi-level state model to store intermediate states during execution specifically involves: storing the states read and written during instruction execution in the local state layer of the current transaction; after instruction execution, determining whether the states written by the instruction can be pre-committed based on the state access set; if so, writing them into the pre-committed state layer of the current transaction to provide pre-read dependency data for subsequent transactions in a waiting state, thus resolving the dependencies of subsequent transactions in a waiting state in advance, and the transaction becomes ready.

5. The method for concurrent execution of smart contracts based on fine-grained scheduling according to claim 1, 2, or 4, characterized in that, In S4, the specific steps of maintaining transaction dependencies during the execution process using the transaction dependency structure are as follows: when a conflict is detected, the transaction is added to the transaction dependency structure; after the state is submitted to the pre-submission state layer, the transaction dependency structure is used to query subsequent transactions that are in a waiting state.

6. The method for concurrent execution of smart contracts based on fine-grained scheduling according to claim 5, characterized in that, The S5 process specifically includes the following steps: after a transaction is completed, it enters the waiting-for-verification phase; after all transactions before a transaction waiting for verification have been submitted, the transaction enters the verification phase; the transaction verification phase checks whether the state read during the execution of the transaction is consistent with the current global state layer; if so, the execution result is submitted to the global state layer; if not, the execution result is rolled back.

Images