A shortest instruction distance scheduling method and system for a smart contract virtual machine

Abstract

The application discloses a shortest instruction distance scheduling method and system of a smart contract virtual machine. The method comprises: static analysis and preprocessing, constructing an instruction dependency graph and calculating comprehensive weights of dependency edges; runtime dynamic scheduling, scheduling and synchronizing instructions according to dynamic priorities through a lock-free ready queue, a resource bitmap and a ring bus; multi-thread cooperation and load balancing, performing instruction-level work stealing among processor cores based on dynamic thresholds. The calculation of comprehensive weights and dynamic priorities takes minimizing global distance cost as an optimization target, and is used for improving cache locality and instruction-level parallelism of instruction execution. The system comprises a static analysis module, a runtime scheduling engine and a load balancer module. The application takes minimizing the execution distance of dependent instructions as a core optimization target, effectively improves instruction-level parallelism and cache locality, and thus significantly improves the execution performance and resource utilization of the smart contract virtual machine in a high-concurrency scenario.

Description

Technical Field

[0001] This invention relates to virtual machine technology and processor instruction scheduling technology, and particularly to instruction scheduling technology for smart contract virtual machines. Technical Background

[0002] With the widespread deployment of blockchain technology in digital currencies, the Internet of Things (IoT), and distributed applications, smart contracts have become a core component for executing trusted business logic and automating interactions. However, current mainstream smart contract virtual machines (such as the Ethereum Virtual Machine, EVM) still generally adopt the traditional sequential execution model, which cannot effectively utilize the parallel computing capabilities of modern multi-core processors and heterogeneous hardware, resulting in bottlenecks such as low throughput and high latency in high-concurrency scenarios.

[0003] 1. Performance bottlenecks of existing virtual machines

[0004] Taking the EVM as an example, its stack-based bytecode design and the mechanism of gas billing and status checks for each instruction lead to frequent blocking during execution. Even in solutions that support transaction-level parallelism (such as Block-STM and PaVM), instructions within the contract must still be executed serially, failing to unlock the potential of instruction-level parallelism (ILP). While WebAssembly (WASM), as a next-generation smart contract platform, possesses near-native performance potential, the instruction-level instrumentation strategy commonly adopted to maintain billing security introduces significant host environment call overhead, thus offsetting its efficiency advantages. Furthermore, existing WASM runtimes (such as Wasmtime and Wasmer) primarily focus on improving the execution efficiency of a single instance and do not provide a fine-grained instruction-level scheduling mechanism across multiple contract instances.

[0005] 2. Hardware efficiency challenges in high-concurrency scenarios

[0006] In large-scale concurrent scenarios such as batch authentication of IoT devices and batch processing of financial transactions, virtual machines need to handle a large number of independent or weakly related contract calls simultaneously. Traditional serial execution models cannot distinguish the dependencies between these calls, leading to prolonged resource idleness and waiting. More seriously, the alternating execution of instruction streams from different contracts on the CPU can cause significant cache jitter and branch prediction confusion.

[0007] Cache misses: Instructions and data are frequently swapped in and out of the L1 / L2 cache, resulting in a significant increase in cache miss rates.

[0008] Branch prediction failure: The accuracy of the branch predictor decreases due to frequent jumps in the execution flow between control paths of different contracts.

[0009] These problems caused by the inefficiency of the microarchitecture have become the fundamental constraint on improving the overall throughput of the system.

[0010] 3. Limitations Analysis of Existing Technical Solutions

[0011] Currently, academia and industry primarily alleviate blockchain performance bottlenecks by improving transaction-level parallelism, such as by employing optimistic concurrency control (OCC) or software transactional memory (STM). However, these solutions only address concurrency issues between transactions or contract calls and do not delve into the instruction execution layer of individual contracts. Therefore, smart contract virtual machines still suffer from the following core deficiencies at the instruction-level execution level:

[0012] Lack of fine-grained parallel scheduling: The runtime cannot automatically identify instruction-level concurrency opportunities, and the instruction dependencies between different contracts and within contracts are not explicitly modeled and utilized, causing multiple threads to block each other when sharing CPU resources.

[0013] Caching and jump overhead are huge: The memory layout of the code does not take into account "hot paths" and data reuse characteristics, resulting in poor spatiotemporal locality of instruction cache and data cache, frequent branch prediction errors, and further wasting processor cycles.

[0014] Billing and security instrumentation adds an extra burden: inserting security measures such as billing checks before each instruction not only disrupts code continuity and locality but also increases frequent interactions with the host environment, introducing additional performance overhead.

[0015] Improper scheduling of heavy instructions: For computationally intensive instructions such as cryptographic operations and large integer modulo exponentiation, improper scheduling will occupy critical execution units for a long time, blocking other lightweight instructions and causing unbalanced utilization of system resources. Summary of the Invention

[0016] The technical problem to be solved by this invention is to overcome the overall execution performance bottleneck of existing smart contract virtual machines (especially WebAssembly-based virtual machines) in high-concurrency, multi-tasking scenarios due to low instruction-level parallelism, poor caching efficiency, and unbalanced resource scheduling. This invention proposes a shortest instruction distance scheduling model, which formalizes the instruction scheduling problem into a weighted path optimization problem on a dependency graph, and designs corresponding static analysis and dynamic scheduling, thereby forming an instruction scheduling scheme that significantly optimizes the performance of smart contract virtual machines in high-concurrency, multi-tasking scenarios.

[0017] The technical solution adopted by this invention to solve the above-mentioned technical problems is a shortest instruction distance scheduling method for smart contract virtual machines, comprising the following steps:

[0018] Static analysis and preprocessing: The WebAssembly bytecode of the smart contract is parsed, and an instruction dependency graph G=(V,E) is constructed. In this graph, each node in the node set V represents an instruction in the WebAssembly bytecode of the smart contract. Each instruction can only belong to one basic block. Each edge in the edge set E represents an execution order constraint that must be satisfied. This constraint is derived from the dependency relationship between instructions. An edge (u,v) indicates that instruction v can only be executed after instruction u is completed. A comprehensive weight w(u,v) is calculated for each edge (u,v) in the graph. The comprehensive weight integrates the data reuse degree, which represents the locality of data, the hot spot weight, which represents the execution frequency, and the control distance, which represents the control flow jump distance.

[0019] Runtime dynamic scheduling: Maintain a ready priority queue ReadyQ to store all instructions with a dependency count of zero; calculate a dynamic priority P(v) for each ready instruction, which inherits the weight of its predecessor dependency edge and deducts the dynamic switching cost and runtime performance penalty; retrieve the highest priority instruction from ReadyQ, and after checking through the resource bitmap ResTable and occupying the resources of the execution unit it needs, launch and execute it; after the instruction completes, broadcast a completion event through the circular buffer TokenBus to atomically update the dependency count of its successor instructions;

[0020] Multi-threaded collaboration and load balancing: Monitor the load of each processor core, dynamically adjust high and low load thresholds, and perform instruction-level task stealing among processor cores according to the dual threshold rule: When the load of a processor core exceeds the high threshold, other processor cores are allowed to steal tasks from its task queue; when the load of a processor core is below the low threshold, that processor core actively steals tasks from other processor cores.

[0021] The calculation of the combined weight w(u,v) and dynamic priority P(v) aims to minimize the global distance cost function. The optimization aims to improve cache locality and instruction-level parallelism in instruction execution.

[0022] ;

[0023] For the instruction dependency graph G, the linear extension is the execution sequence that satisfies all dependency constraints; The instruction distance from instruction u to instruction v. , Indication of instructions Position index in π.

[0024] Meanwhile, a system for implementing the above method is provided, including:

[0025] The static analysis module is used to perform the static analysis and preprocessing operations described in claim 1, and output the instruction dependency graph and weight table;

[0026] A runtime scheduling engine is used to load the instruction dependency graph and weight table, and execute the runtime dynamic scheduling operation as described in claim 1.

[0027] A load balancer module is used to perform the multi-threaded collaboration and load balancing operation described in claim 1.

[0028] Specifically, the runtime scheduling engine includes: a lock-free ready priority queue (ReadyQ) implemented using a lock-free skip list, a resource bitmap (ResTable) implemented using an atomic integer bitmap, and a synchronous communication bus (TokenBus) implemented using a circular buffer; the load balancer module integrates a proportional-integral (PI) controller for dynamically adjusting the dual thresholds for job theft.

[0029] This invention enables multiple independent tasks to perform instruction-level parallelism simultaneously on one or more cores through global analysis and fine-grained scheduling of contract instructions. This reduces idle time and waiting, significantly improving system throughput and reducing latency. Furthermore, the use of instruction distance-based priority calculation effectively reduces long jumps across functions and instances.

[0030] The scheduling strategy of this invention is performed entirely within the contract instructions, without changing the order between functions or transactions. As long as the dependency graph is constructed correctly, the output can be guaranteed to be consistent with the sequential execution results.

[0031] By marking heavy instructions and prioritizing their scheduling, the system can fully utilize the CPU, multi-core, SIMD, GPU, or dedicated coprocessor, improving overall resource utilization and reducing the blocking effect of heavy computations on lightweight tasks.

[0032] This scheduling algorithm can be integrated independently as a plugin into existing WASM engines without modifying the underlying architecture. It is easy to combine with existing transaction-level parallel solutions to further improve overall performance.

[0033] This invention utilizes distance metrics to optimize instruction execution order, maximizing cache hit rate and instruction-level parallelism while ensuring correctness, fundamentally solving the performance bottleneck problem of smart contract virtual machines. The instruction scheduling method designed in this invention can analyze and coordinate globally at the instruction level, fully explore parallel potential, and reduce caching and jump costs caused by distance by optimizing instruction execution order, ultimately achieving significant optimization of throughput and latency in high-concurrency scenarios.

[0034] The beneficial effects of this invention lie in that, through global dependency analysis and fine-grained dynamic scheduling of smart contract instructions, it significantly improves the execution performance and resource efficiency of the virtual machine in high-concurrency scenarios while ensuring the semantic correctness and security of the program. Specifically, this is manifested in:

[0035] 1. Significantly improve instruction-level parallelism and system throughput: By constructing an instruction dependency graph and adopting a shortest distance scheduling strategy, this invention can identify and utilize fine-grained parallel opportunities within and across contracts, enabling multiple independent or weakly related instructions to be executed concurrently on a multi-core processor. This significantly reduces the processor's idle waiting time, resulting in a significant increase in system throughput and a marked reduction in execution latency.

[0036] 2. Effective Cache Efficiency and Branch Prediction Optimization: By employing a priority calculation model based on instruction distance as the core metric, the scheduler prioritizes the execution of instruction sequences with close data dependencies and short control flow jump distances. This strategy effectively enhances the spatiotemporal locality of code and data, reduces performance losses caused by frequent instruction and data cache invalidations and branch prediction failures, thereby improving the execution efficiency of a single core.

[0037] 3. Intelligent Resource Management and Load Balancing: The system employs a combination of static labeling and dynamic identification to perform special scheduling and resource adaptation for computationally intensive heavy instructions. It not only prioritizes CPU execution resources but also supports offloading these instructions to SIMD units, GPUs, or dedicated coprocessors for asynchronous execution. Combined with a feedback-based adaptive load balancing mechanism, this invention achieves full utilization of multi-core, heterogeneous computing resources, avoids heavy tasks blocking lightweight tasks, and improves the overall resource utilization of the system.

[0038] 4. Ensuring semantic correctness and compatibility with the existing ecosystem: The scheduling optimization of this invention is performed entirely while maintaining the original order constraints between functions and transactions. Its correctness is guaranteed by a strict instruction dependency graph, ensuring that the execution result after scheduling is completely consistent with the sequential execution, without introducing any nondeterminism. Furthermore, this solution is designed in a modular manner, allowing it to be seamlessly integrated into the existing WebAssembly virtual machine engine as an independent scheduling plugin without modifying the underlying architecture. It can also work in conjunction with higher-level optimization solutions such as transaction-level parallelism, further unlocking the system's performance potential. Attached Figure Description

[0039] Figure 1 This illustrates the overall system architecture of the present invention.

[0040] Figure 2A diagram illustrating instruction dependency and instruction distance is provided. Circular nodes represent specific instructions or basic blocks, arrows between nodes indicate data or control dependencies, and numbers labeled on the arrows represent weights w or instruction distances l.

[0041] Figure 3 A state machine diagram illustrating the scheduling process is shown.

[0042] Figure 4 This is a schematic diagram illustrating the static optimization and hotspot-focused execution strategy. Detailed Implementation

[0043] Figure 1 The present invention illustrates the shortest instruction distance scheduling method for smart contract virtual machines, comprising two parts:

[0044] The first half is the static analysis and preparation phase, including bytecode parsing modules, stack-to-SSA conversion modules, control flow graph and data flow graph construction modules, distance weight calculation modules, and hotspot analysis modules. These modules convert the contract source code into a formalized instruction dependency graph and generate data structures describing the weights of each dependency relationship.

[0045] The second half is the runtime scheduling phase, which includes the lock-free ready queue ReadyQ, the scheduler main loop, the execution unit resource pool, the TokenBus completion notification mechanism, and the coprocessor interface.

[0046] The static phase outputs an instruction dependency graph and weight table to the runtime phase, while the runtime phase dynamically schedules instruction execution based on the current system state.

[0047] 1. Formal Modeling and Distance Metric of Instruction Dependency Graph

[0048] The core idea of ​​this invention is to abstract the execution process of a smart contract as a path selection problem on a directed acyclic graph (DAG). Specifically, for the WebAssembly bytecode to be executed, the implicit operand passing is first explicitly transformed into variable definition-usage relationships through a stack-to-static single assignment (SSA) conversion. Based on this, an instruction dependency graph G=(V,E) is constructed, where each node in the node set V represents an instruction in the WebAssembly bytecode, and each instruction can only belong to one basic block. The edge set E represents the execution order constraints that must be satisfied, including three types of dependencies: data dependency, control dependency, and memory alias dependency.

[0049] (1) Data dependencies cover three scenarios: read-after-write (RAW), write-after-write (WAW), and write-after-read (WAR). For RAW dependencies, if instruction u defines a value for a register or memory location, and instruction v reads that value, then there exists an edge (u, v), indicating that v must be executed after u completes. For WAW and WAR dependencies, although most pseudo-dependencies are eliminated through renaming in the SSA form, these dependency edges still need to be retained for memory access and special register operations to ensure semantic correctness.

[0050] (2) Control dependencies stem from the branching structure of a program. WASM's structured control flow (blocks, loops, if statements) can be naturally mapped to basic blocks and a control flow graph (CFG). If instruction v is located within a conditional block, and its execution depends on the outcome of that condition, then a control dependency edge exists from the decision instruction to v. A conditional block is a code region controlled by conditional statements and may contain one or more basic blocks. A basic block typically consists of one or more instructions and is a logical grouping of instructions. Control dependencies ensure that the branch target is not executed before the branch condition is determined.

[0051] (3) Memory alias dependency is applied to linear memory access. WASM's memory model uses contiguous byte arrays, and different load / store instructions may access the same address. When it cannot be statically determined that addresses do not overlap, a conservative approach is taken to add dependency edges between related memory operations to avoid data races caused by out-of-order execution. That is, for non-atomic memory load and store instructions, conservative alias analysis based on memory page granularity is used to construct memory alias dependency edges to avoid potential data races. For atomic instructions (atomic.load, atomic.store, etc.), global sequential edges are inserted to maintain the sequential consistency semantics of the memory model.

[0052] Based on the dependency graph, this invention introduces the concept of instruction distance to quantify the impact of execution order on performance. For any linear extension π of the dependency graph, the linear extension is an execution sequence that satisfies all dependency constraints. The instruction distance from instruction u to v is defined. for:

[0053] ;

[0054] in Indication of instructions The position index in the execution sequence π. Intuitively, the instruction distance. This indicates how many other instructions were executed between u and v. The smaller the distance, the closer the two instructions are in time, the higher the probability that they share a cache line or register, and the lower the overhead of jumps and prefetching.

[0055] like Figure 2 As shown, the instruction dependency graph consists of nodes and weighted dependency edges. Arrows in the graph represent data or control dependencies, and the weights w(u,v) labeled on the edges combine data reusability, hotspot weights, and control distance. The scheduler's goal is to adjust the instruction order to minimize the distance between instructions on the dependency edges while satisfying dependency constraints. Minimize this, thereby improving cache locality and parallelism.

[0056] To distinguish the importance of different dependent edges, this invention defines a comprehensive weight w(u,v) for each edge (u,v), which integrates information from three dimensions:

[0057] (1) Data reuse, used to reuse the data value generated by the quantization instruction u by subsequent instructions. The frequency of consumption (use) is considered. Static analysis of the Definition-Use Chain (DU) calculates the average instruction span from the generation to the use of a data value. If a data value is frequently used and its usage points are concentrated, its reusability is high, meaning related instructions should be executed as close together as possible to improve register and cache hit rates. During static analysis, the data value generated by instruction u (corresponding to an SSA variable in SSA form) is identified through the DU chain. At runtime, this data value typically resides in a register or L1 cache. The scheduler improves resource utilization and access locality by reducing the instruction distance from u to its consumed instruction, thereby decreasing the retention time of the value in registers or caches.

[0058] In form, set instructions Defined data values ,and In instruction set It is used in the middle. It contains k instructions. It is a data value Total number of times the instruction was used .instruction For the production point, the instruction For consumption points Defined Static use of span (Span) )for The last instruction in the middle and The difference in instruction position between them. The reuse weight depends on the data value Usage density, i.e., data value Corresponding edges Data reuse :

[0059] ;

[0060] The higher the reusability, the greater the weight. For example, data values... Used multiple times (High value) and very narrow range of applications ( (Smaller values ​​indicate higher density, suggesting the data is thermal data.) Connecting production points... and consumption points Edges will receive high weights, prompting the scheduler to generate... Then quickly allocate consumption The instruction keeps the data in a register or L1 cache. Adding 1 to the denominator avoids division by zero; the higher the reusability, the greater the weight.

[0061] (2) Hotspot Weight: Utilizing Performance Profile Analysis (PGO) technology, execution frequency data is collected during contract deployment or testing. Frequently executed functions, loops, and basic blocks are assigned higher hotspot weights. Hotspot instructions should be scheduled preferentially to fully utilize the CPU's branch prediction and prefetching mechanisms. Hotspot weights can be calculated using normalized execution counts:

[0062] ;

[0063] in This is a count of the number of times instruction u is executed within the basic block. Instructions within the same basic block have the same Hot value. This represents any instruction in the node set V. The denominator is the maximum number of times all basic blocks in the instruction dependency graph G=(V,E) are executed.

[0064] (3) Control Distance (Ctrl): On the control flow graph, the shortest path length between basic blocks is calculated using Breadth-First Search (BFS) or the Floyd-Warshall shortest path algorithm, representing the minimum number of edges required to jump from one basic block containing an instruction to another. A large control distance means a large jump span, which can easily lead to instruction cache invalidation and branch predictor confusion. The larger the control distance, the lower the weight should be (as a negative contribution).

[0065] ;

[0066] in For the shortest path between basic blocks, These are the basic blocks containing instructions u and v, respectively. This is the normalization constant.

[0067] Considering the above three factors, the edge (u,v) weight for:

[0068] ;

[0069] Where α, β, and γ are adjustable coefficients corresponding to data reuse (Reuse), hotspot weight (Hot), and control distance (Ctrl), respectively. Initial values ​​can be obtained through offline training (such as particle swarm optimization) on representative workloads, and fine-tuned based on feedback during runtime. This allows for the selection of weights... Large edges are used to prioritize the scheduling of instruction pairs with high data reuse, frequent execution, and short jump distances, thereby minimizing cache mismatch and pipeline bubbles.

[0070] The optimization objective of this invention is to find a linear extension π of the instruction dependency graph G such that the global distance cost function is minimized.

[0071] ;

[0072] The global distance cost function can be solved using a greedy scheduling algorithm, which can provide an approximate solution in polynomial time and ensure that the approximation ratio does not exceed 2.

[0073] 2. Preprocessing optimization

[0074] This part is executed during contract deployment or initial loading. A series of static analysis techniques are used to preprocess and optimize the bytecode, providing support for runtime scheduling. The specific preprocessing steps are as follows:

[0075] (1) Bytecode parsing and verification: In accordance with the WebAssembly specification, the input WASM binary file is subjected to type checking, stack depth verification, and memory boundary verification. Only modules that pass the complete verification are allowed to proceed to the next processing step, ensuring security.

[0076] (2) Stack to SSA Conversion: WASM uses an implicit stack to pass operands. To facilitate dependency analysis, the system maintains a shadow stack to simulate the stack operation of each instruction, and explicitly names the popped operands as temporary variables. When encountering WASM local variable access instructions local.get / local.set, the version of the local variable is recorded; when encountering a branch merging point, the merge instruction φ function in the SSA form, used to resolve multi-path assignment conflicts, merges the variable values ​​of different paths. In the converted SSA representation, each value is assigned only once, which facilitates the construction of accurate data dependencies.

[0077] (3) Control Flow Graph Construction: Based on the structured control instructions of WASM, such as block instructions, loop instructions, if instructions, br_if conditional jump instructions, and br_table jump table instructions, the function is decomposed into a sequence of basic blocks. Each basic block has no branches and may jump only at the end. Control dependency edges between basic blocks are constructed to form a complete control flow graph (CFG). For loop structures, the loop head and back edges are identified to provide information for subsequent hotspot analysis and loop unrolling.

[0078] (4) DU chain and memory alias analysis: Traverse the SSA instruction sequence, establish a definition-using linked list for each variable, and record the definition location and all usage locations. For memory operations, a coarse-grained alias analysis based on page granularity is adopted: a 64KB page is used as the alias set, and load / store operations within the same page are conservatively considered as potential conflicts. More refined pointer analysis techniques can be introduced in future implementations.

[0079] (5) Control distance matrix calculation: Execute BFS or Floyd-Warshall algorithm on CFG to calculate the shortest path length between any two basic blocks. To avoid O(n²) space overhead, sparse storage is adopted: only the distance from hot basic blocks to other blocks is stored, and the distance between cold basic blocks is dynamically calculated or uses the default value when needed.

[0080] (6) Hotspot Identification and Labeling: Combining static heuristics (such as loop depth and function call frequency) and optional PGO data, hotspot weights are assigned to each basic block and function. If a loop is identified as a hotspot, the system can selectively unroll or vectorize it, generating a simd.hint for runtime reference. For library functions shared across contracts (such as common hash algorithms and signature verification), they are marked as global hotspots to facilitate subsequent batch processing optimization.

[0081] (7) Code layout optimization: Based on the hotspot analysis results, adjust the layout order of functions and basic blocks in memory. Arrange the basic blocks of hot paths into contiguous addresses and place cold paths at the end; for frequently called small functions, consider inlining to eliminate call overhead. These static optimizations can shorten the physical distance between instructions and, in conjunction with runtime instruction distance scheduling, synergistically improve cache efficiency.

[0082] (8) Weight Table Generation and Persistence: Based on the above analysis results, the initial weight w(u,v) is calculated for each dependency edge and serialized into a .dist file. This file contains metadata such as function ID, instruction index, reusability, hotspot weight, and control distance. The file format adopts compact binary encoding or JSON format. At runtime, the weight table is loaded into memory along with the bytecode or JIT-generated machine code for the scheduler to quickly query.

[0083] Through the above preprocessing, the system converts the original bytecode into a scheduling intermediate representation that carries dependencies, weight information, and layout optimization. The scheduling intermediate representation includes an instruction dependency graph G=(V,E), a weight table, and code layout, enabling the runtime scheduler to focus on the optimal instruction selection in a dynamic environment while satisfying dependency constraints. This maximizes instruction-level parallelism and hardware resource utilization while ensuring semantic correctness.

[0084] like Figure 4 As shown, the static phase improves spatial locality through code layout optimization (such as continuous arrangement of hot basic blocks, loop expansion, and function inlining).

[0085] 3. Runtime dynamic scheduling mechanism

[0086] The goal of runtime scheduling is to dynamically select the next instruction to execute while satisfying dependency constraints, thereby minimizing the global distance cost. The scheduling system is composed of components based on instruction readiness conditions, readiness organization, and scheduled execution.

[0087] (1) Dependency Counting and TokenBus Synchronization Mechanism: Each instruction maintains a dependency count, depCnt, initially set to its in-degree (number of predecessor instructions) in the instruction dependency graph G=(V,E), i.e., the number of all dependency edges (u,v) pointing to that node. Upon completion of a predecessor instruction, a completion event is broadcast via TokenBus. TokenBus is a circular buffer where multiple worker threads can concurrently write the completed instruction ID, while other threads poll and read it. The reading thread searches the successor node list based on the ID and performs an atomic decrement operation depCnt-- for each successor. If a node's depCnt drops to zero, it indicates that all its predecessors have completed, and the node becomes ready, its priority is calculated, and it is inserted into ReadyQ. This decoupled event notification mechanism avoids global lock contention and is suitable for multi-core environments.

[0088] Compared with traditional global locks or barrier synchronization, this mechanism achieves fine-grained instruction completion notification in high-concurrency environments through lock-free TokenBus broadcasting and atomic updates of local dependency counts, significantly reducing synchronization overhead and improving the scalability of the scheduler.

[0089] (2) Ready priority queue: ReadyQ stores all instruction nodes with a dependency count of zero. Each node contains an instruction ID, priority P, the thread identifier it belongs to, and a timestamp. The priority P is calculated as follows:

[0090] ;

[0091] in, Let v be the set of its predecessor nodes. This indicates that u is the predecessor node of v, which is the predecessor instruction. This is the weight of the dependency edge from the predecessor instruction u to the current instruction v, i.e., the weight of the predecessor dependency edge. The first term in the above formula is the static inheritance weight: candidate instruction It inherits the largest weight among its predecessor's dependent edges. This represents, from a data flow perspective, the instruction... The degree required by the currently completed instructions.

[0092] The second term in the above formula is the dynamic switching cost. This is the core scheduling constraint at runtime. Let Last be the instruction that this core has just executed, and v be the candidate instruction. This indicates the basic block containing Last. Jump to the basic block containing v The overhead is minimal if instruction v and Last are in the same basic block or adjacent blocks; however, the overhead increases significantly if v is in a distant basic block. This forces the scheduler to prioritize nodes that are sequential in execution time with the previous instruction when multiple candidate instructions with high static weights exist, thus achieving a mapping from code space proximity to execution time continuity.

[0093] The runtime performance penalty, MissPenalty, reflects whether a cache miss (including L1 / L2 cache misses and translation backstop (TLB) misses) has recently occurred. If an instruction frequently causes cache misses, the system increases its MissPenalty value, thereby reducing its scheduling order in priority calculations and avoiding a sustained negative impact on pipeline efficiency.

[0094] To support high concurrency access, ReadyQ employs a lock-free skip list, ensuring thread safety through atomic CAS (Compare-And-Swap) operations. Each node in the skip list is accompanied by a version number and an ABA count, preventing race conditions caused by concurrent modifications. Maintaining the ABA count (atomically incrementing version number) is used to detect whether a node has been modified and reused by other threads during CAS operations, preventing the ABA problem.

[0095] (3) Resource Bitmap ResTable: To coordinate the competition for hardware resources by different instructions, the system maintains a resource bitmap ResTable, where each bit corresponds to an execution unit, such as the integer arithmetic logic unit (ALU), floating-point unit (FPU), single instruction multiple data (SIMD) vector unit, memory port, coprocessor, etc. Before issuing an instruction, the scheduler attempts to occupy the corresponding bit through a 64-bit CAS operation. If the resource is idle, the occupation is successful and the instruction is executed; if the resource is busy, the instruction is re-inserted into the ReadyQ or placed in the wait queue.

[0096] Unlike existing smart contract virtual machines that generally lack instruction-level resource coordination mechanisms, this invention introduces an explicit resource management table based on bitmaps, namely the Resource Bitmap ResTable. This explicit resource management allows the scheduler to flexibly allocate resources according to instruction types, simulating the resource reservation function of the hardware scheduler at the software level, thereby avoiding functional unit conflicts in dynamic scheduling and improving the utilization efficiency of heterogeneous hardware.

[0097] (4) The workflow of the main scheduling loop is as follows:

[0098] like Figure 3 As shown, the scheduler operates in a multi-state loop, with states including: initializing ReadyQ, calculating priorities, matching execution units, executing instructions, and updating TokenBus dependencies. The specific workflow of the scheduler is as follows:

[0099] (4-1) Initialize ReadyQ: The scheduler starts in this state, scans the instruction dependency graph, and adds all instruction nodes with an in-degree of zero to the ready queue.

[0100] (4-2) Priority calculation: After entering this state, the scheduler combines the static weight table and real-time feedback information to calculate the dynamic priority for each ready instruction.

[0101] (4-3) Matching Execution Units: The scheduler pops the highest priority node u from ReadyQ, checks the type of execution unit required by instruction u, and queries the resource bitmap ResTable to determine if the resource is available. If the queue is empty, the thread briefly spins or yields the CPU; if the resource is unavailable, it decides whether to wait immediately (high priority) or re-enqueue (low priority) based on the instruction priority; if the resource is available, proceed to step (4-3).

[0102] (4-3) Instruction Execution: The scheduler occupies the corresponding bit in the resource bitmap ResTable through CAS atomic operations, marks the execution unit as busy, and dispatches instruction u to the corresponding execution unit. For scalar operations, they are executed directly on the CPU core; for vector operations, they are submitted to the SIMD unit; for computationally intensive tasks marked as coprocessor offload of GPU, they are encapsulated as work item units and submitted to the GPU queue.

[0103] (4-4) TokenBus Update Dependencies: After the instruction is executed, the resource slots are released, and a completion event is published on TokenBus. The background thread listens for the TokenBus thread read time and performs dependency updates on all successor nodes v of u.

[0104] (4-5) New Ready Instruction Processing: For a new ready node v whose dependency count reaches zero, the scheduler recalculates its priority P(v). If v is detected to have recently caused a cache miss, a MissPenalty entry is added to lower its priority; if v is located on a hot path and has been executed multiple times consecutively, its priority can be appropriately increased to maintain the data's availability in the cache. After calculation, v is inserted into ReadyQ and awaits the next round of scheduling.

[0105] The above process is repeated until all instructions have been executed. If resources are insufficient or dependencies are not met at any stage, the scheduler will re-insert the instruction into the queue or temporarily store it, and return to the priority calculation state to continue scheduling other ready instructions.

[0106] (5) Performance Counter Feedback and Adaptive Adjustment: The system integrates a lightweight performance monitoring module, which periodically (e.g., every 10ms) reads the performance event counters provided by the hardware, including the number of L1 / L2 cache misses, the number of translation back buffer (TLB) misses, and the number of branch prediction errors. Based on the performance counter data, the system adopts two types of optimization measures:

[0107] Runtime dynamic adjustment: If a certain type of instruction (such as a specific memory access pattern) is frequently detected to cause cache misses, the scheduler adds a penalty term, MissPenalty, to this type of instruction, delaying its scheduling. The coefficients α, β, and γ used in the dependency edge comprehensive weight calculation are initially obtained through offline training during the static analysis phase, but may no longer be optimal at runtime due to changes in workload characteristics or static analysis errors. Therefore, the system uses a lightweight proportional-integral-derivative PID controller or sliding window averaging to smoothly adjust the coefficients of α, β, and γ, allowing the scheduling strategy to gradually adapt to the current workload characteristics.

[0108] Static re-optimization trigger: If a branch prediction hit rate of a hot loop is found to be low, the system records the information and triggers static re-optimization when the contract is loaded again or when it is idle. The loop unrolling strategy and basic block layout order are adjusted, and scheduling metadata such as instruction dependency graph, weight table and code layout are regenerated.

[0109] (6) Hotspot Concentration Execution Strategy: When the scheduler detects that a thread or a group of instructions has entered a hotspot area (such as dense loop iterations), it adopts a continuous execution mode: temporarily raises the priority baseline of the thread, allowing it to continuously fetch multiple instructions from the ReadyQ for execution, avoiding frequent switching to other threads that could cause cache jitter. Set a continuous execution window (such as 32 instructions or 1ms time), and prioritize the selection of instructions from the same thread within the window. When the window ends or the thread leaves the hotspot area, normal scheduling resumes. For common hotspot functions that multiple threads need to call (such as SHA256 hash calculation), the scheduler can adopt a batch processing mode: collect multiple requests to be called, execute the function body sequentially, and make full use of the resident effect of the instruction cache.

[0110] like Figure 4 As shown, when the runtime scheduler detects a hotspot area, it adopts a continuous execution window and batch processing mode to centrally execute instructions of the same thread or the same hotspot function, thereby reducing cache jitter and switching overhead.

[0111] (7) Preemptive Scheduling of Heavy Instructions: For computationally intensive instructions (such as large integer exponentiation and elliptic curve dot product), the system marks them as heavy instructions during static analysis. The scheduler sets a higher base priority for heavy instructions and allocates execution resources preferentially. If a heavy instruction is detected to occupy the CPU for a long time, the scheduler can actively check if there are any idle coprocessors or GPUs and offload the task to release CPU resources. For coprocessors that support asynchronous execution, the scheduler immediately switches to other threads to continue scheduling after submitting the task. When the coprocessor completes, the result is retrieved through interrupt or polling mechanisms to achieve true parallelism.

[0112] 4. Multi-threaded collaboration and load balancing

[0113] In a multi-core, multi-instance environment, to avoid load imbalance and resource contention, this invention introduces the following mechanism:

[0114] (1) Dual-threshold load control model: The system maintains two dynamic thresholds: High and Low. High represents the threshold for excessive load on a core. When the ReadyQ length or CPU utilization of a worker thread exceeds High, other idle cores are allowed to actively steal tasks. Low represents the threshold for excessive load. When the load is below Low, the core will actively steal tasks from the global queue or other busy cores. High and Low are dynamically adjusted by the PID controller based on the global CPU utilization.

[0115]

[0116]

[0117] Where t represents the current time and t+1 represents the next time. This represents the current average CPU utilization. The target utilization rate is (e.g., 70%). For proportionality coefficients, This is the integral coefficient. This adaptive threshold avoids the inadequacy of a fixed threshold under different loads.

[0118] (2) NUMA-aware task stealing: On servers with a non-uniform memory access architecture (NUMA), memory access latency across NUMA nodes is significantly higher than local access. The stealing strategy of this invention prioritizes inter-core operations within the same NUMA node: when a core needs to steal a task, it first scans the ReadyQ of other cores within the same node; only when there are no tasks to steal on the current node does it search across nodes. Low-priority or cold path instructions are prioritized during stealing to avoid interrupting currently executing hot sequences. The stealing granularity is controlled to no more than 16 nodes at a time to prevent excessive migration from causing cache invalidation.

[0119] (3) Aging strategy and fairness guarantee: To prevent low-priority instructions from starving for a long time, nodes in ReadyQ are given a waiting timestamp. The scheduler periodically scans the queue and adds aging weight to nodes whose waiting time exceeds a threshold (e.g., 1ms), gradually increasing their priority. The aging speed is inversely proportional to the initial priority, ensuring that all ready instructions eventually have a chance to be executed.

[0120] Unlike traditional task-level load balancing, this invention introduces mechanisms such as dual-threshold load control, NUMA-aware job theft, and instruction-level aging strategies into the instruction-level scheduling environment of the smart contract virtual machine, achieving fine-grained, low-overhead, and topology-aware multi-threaded collaboration and load balancing.

[0121] 5. Safety and accuracy assurance

[0122] (1) Proof of semantic consistency: For any valid linear extension π of the instruction dependency graph, the final state of the program (register values, memory contents) is exactly the same as when executed in the original order. The proof is based on the following invariant:

[0123] Invariant I (readiness condition): For any node in ReadyQ, the dependency count of all its predecessors has been reduced to zero, that is, all predecessors have been completed.

[0124] Invariant II (Topological Order): The execution sequence π output by the scheduler satisfies that for any edge (u,v)∈E, we have That is, π is the topological order of the instruction dependency graph.

[0125] It can be proven by mathematical induction that the algorithm maintains the above invariant each time it issues a command, so the final output sequence π satisfies all dependency constraints and the program semantics remain unchanged.

[0126] (2) Atomic Instructions and Memory Model: For WASM atomic instructions (atomic.load, atomic.store, atomic.rmw, etc.), the system adds global order edges to them in the instruction dependency graph, forming a mandatory execution chain to ensure that the execution order of all atomic instructions is equivalent to a certain order consistency model. When the scheduler encounters an atomic instruction, it must wait for all preceding atomic instructions to complete, achieving a lock-like effect, but done at the software level.

[0127] (3) Exception and trap handling: For instructions that may throw exceptions (such as unreachable, throw, memory out of bounds access), the system introduces exception dependency edges in the instruction dependency graph: all subsequent instructions that may be affected by the exception depend on the exception point. Once an exception is detected, the scheduler immediately terminates the scheduling of the relevant threads, clears the unexecuted nodes in ReadyQ, and propagates the exception to the host environment to maintain consistency with the exception behavior during sequential execution.

[0128] 6. Theoretical Properties and Complexity Analysis

[0129] Theoretically, the shortest instruction distance scheduling problem belongs to the category of weighted topology sorting or weighted completion time minimization problems, similar to the classic single-machine weighted completion time problem, and is NP-hard when dependency constraints exist. However, this invention employs a strategy combining local greedy algorithms and dynamic feedback. While ensuring topology order constraints, it proves local optimality through proximity swapping, and simultaneously achieves global optimality on special DAGs with small series and parallel widths. The scheduling complexity of this algorithm is approximately O(|V|log|V|+|E|), where V and E are the number of nodes and edges in the instruction dependency graph, meeting the real-time requirements of concurrent execution.

[0130] Example

[0131] The embodiments describe how to integrate the shortest instruction distance scheduling algorithm of the present invention into the WASM engine to build a complete smart contract execution system.

[0132] Implementation of the Static Analysis Module. A new static analysis pass is added to the WASM virtual machine's module loading process. After the module passes verification, before compilation into machine code, the call stack is pushed to the SSA converter. The converter processes functions one by one: allocating an SSA context for each function and maintaining a version mapping table and shadow value stack for local variables. When encountering a local variable read instruction `local.get`, the current version of the SSA variable is looked up in the mapping table; when encountering a local variable store instruction `local.set`, a new version is generated and the mapping table is updated; when encountering an arithmetic logic instruction, the SSA value at the top of the operand stack is popped, a new SSA instruction node is generated, and the result is pushed onto the stack. For branch instructions, their control flow target is identified, and a merge function `φ` in static single assignment form is inserted for the merging point. After the conversion, each function corresponds to an intermediate code sequence represented by an SSA.

[0133] Based on SSA, construct a control flow graph and instruction dependency graph. Traverse the SSA instructions, creating a vertex object in V for each node, recording its type, opcode, and operands. Add edges in E according to data flow relationships: if instruction v uses a value defined by instruction u, add an edge (u,v) and mark it as a RAW dependency. For memory operations, a conservative strategy is adopted: if the addresses of two load / store instructions cannot be statically determined to be non-overlapping, add a memory dependency edge. For atomic instructions, maintain a global atomic instruction chain, concatenating each atomic instruction as the successor of the previous one. For control dependencies, add control edges from branch decision instructions to the basic block entries of all their controls.

[0134] Distance and Weight Calculation. Implement a breadth-first search (BFS) function to calculate the shortest path matrix between basic blocks on the control flow graph (CFG). Since the function size is typically small (smart contract functions average 50-200 instructions), directly using the Floyd-Warshall algorithm is acceptable. The calculated control distance matrix is ​​stored in a sparse format. For data reuse, traverse the DU chain and calculate the average instruction interval from definition to use of the same variable. Hotspot weights are initially based on a static heuristic: instructions within loops are weighted at 1.0, those outside loops at 0.5, and function entry and exit weights at 0.3. If performance-oriented optimization (PGO) is enabled, a lightweight counter is inserted during the first run to collect execution frequency and update the hotspot weights.

[0135] The weight calculation module calculates weights according to the formula. The algorithm iterates through each edge of the instruction dependency graph, queries the corresponding reusability, hotspot, and control distance, and calculates the overall weight. The initial values ​​of coefficients α, β, and γ are set to 1.2, 0.8, and 0.5, respectively (determined based on offline experiments). The calculation results are serialized into a .dist file in JSON format, containing the function ID, instruction list, and weight information for each edge. This file is stored along with the compiled machine code for loading at runtime.

[0136] Implementation of the runtime scheduler. A custom scheduler module, SchedulerModule, is added to the WASM execution engine. When a contract is instantiated, SchedulerModule reads the corresponding distance-weight file (.dist) and constructs an in-memory instruction dependency graph structure. A dependency count (depCnt) is assigned to each node, initially set to its in-degree; all nodes with a depCnt value of zero are added to ReadyQ. ReadyQ uses a lock-free skip list implemented in C++, with a maximum skip list level of 4. Each node stores the instruction ID, a priority float value, and a timestamp. The skip list supports concurrent insertion (push) and retrieval of the highest-priority element (pop_max) operations, ensuring linearity through CAS (Compare-and-Swap).

[0137] The scheduling main loop runs in a dedicated Worker thread. The thread continuously calls `pop_max()` from the `ReadyQ` queue to acquire the highest priority node; if the queue is empty, it calls the thread control function `std::this_thread::yield()` to yield the CPU. After acquiring a node, it queries its instruction type and attempts to acquire the resource. The resource bitmap `ResTable` uses an atomic 64-bit unsigned integer type `std::atomic`.<uint64_t> In this implementation, each bit corresponds to one execution unit. The corresponding bit is set using an atomic fetch_or operation. If the return value indicates that the bit is already occupied, the node is re-inserted into ReadyQ and processing of the next node continues. If the resource is successfully acquired, a machine code function pointer generated by the lightweight compiler backend Cranelift is invoked to execute the instruction. After the instruction execution is complete, the resource bit is cleared using an atomic fetch_and operation, and a completion event is written to TokenBus.

[0138] The TokenBus is implemented as a circular array of size 65536 (2^16), using two atomic variables, head and tail, as read and write pointers. During writing, tail is incremented using fetch_add and modulo the result, and the instruction ID is written to the array. During reading, head is checked against tail; if they are not equal, the ID at the head position is read and head is incremented. Multiple worker threads can write concurrently, while a dedicated listening thread is responsible for reading and updating the dependency count. After reading the ID from the TokenBus, the listening thread looks up the successor list of that instruction (pre-generated in the static phase), and for each successor, it calls the atomic fetch_sub(&depCnt[succ],1). If depCnt becomes zero, its priority is recalculated and inserted into ReadyQ.

[0139] Performance monitoring and adaptive adjustment. In the scheduling loop, every 10ms, the performance event monitoring system `perf_event_open` is called to read hardware performance counters, including hardware cache miss events `PERF_COUNT_HW_CACHE_MISSES` and hardware branch prediction failure events `PERF_COUNT_HW_BRANCH_MISSES`. This data is accumulated into a sliding window (100ms window size) to calculate the average miss rate. If the miss rate of a certain type of instruction exceeds a threshold (e.g., 20%), its `MissPenalty` item is increased, specifically: `MissPenalty = δ × miss_rate`, where the coefficient δ is initially 0.5. When calculating priority, `MissPenalty` is subtracted from the weight, lowering the priority of that instruction. Every second, the coefficients in the priority are adjusted based on global CPU utilization: if the utilization is lower than the target value, α in the weight `w` is increased (increasing the reuse weight); if the miss rate remains high, α is increased... (Punishment for long-distance jumps).

Claims

1. A method for scheduling smart contract virtual machines using the shortest instruction distance, characterized in that, include: Static analysis and preprocessing: The WebAssembly bytecode of the smart contract is parsed, and an instruction dependency graph G=(V,E) is constructed. In this graph, each node in the node set V represents an instruction in the WebAssembly bytecode of the smart contract. Each instruction can only belong to one basic block. Each edge in the edge set E represents an execution order constraint that must be satisfied. This constraint is derived from the dependency relationship between instructions. An edge (u,v) indicates that instruction v can only be executed after instruction u is completed. A comprehensive weight w(u,v) is calculated for each edge (u,v) in the graph. The comprehensive weight integrates the data reuse degree, which represents the locality of data, the hot spot weight, which represents the execution frequency, and the control distance, which represents the control flow jump distance. Runtime dynamic scheduling: Maintain a ready priority queue ReadyQ to store all instructions with a dependency count of zero; calculate a dynamic priority P(v) for each ready instruction, which inherits the weight of its predecessor dependency edge and deducts the dynamic switching cost and runtime performance penalty; retrieve the highest priority instruction from ReadyQ, and after checking through the resource bitmap ResTable and occupying the resources of the execution unit it needs, launch and execute it; after the instruction completes, broadcast a completion event through the circular buffer TokenBus to atomically update the dependency count of its successor instructions; Multi-threaded collaboration and load balancing: Monitor the load of each processor core, dynamically adjust high and low load thresholds, and perform instruction-level task stealing among processor cores according to the dual threshold rule: When the load of a processor core exceeds the high threshold, other processor cores are allowed to steal tasks from its task queue; when the load of a processor core is below the low threshold, that processor core actively steals tasks from other processor cores. The calculation of the combined weight w(u,v) and dynamic priority P(v) aims to minimize the global distance cost function. The optimization aims to improve cache locality and instruction-level parallelism in instruction execution. ； in, For the instruction dependency graph G, the linear extension is the execution sequence that satisfies all dependency constraints; The instruction distance from instruction u to instruction v. , Indication of instructions Position index in π.

2. The method as described in claim 1, characterized in that... The edges of the instruction dependency graph are classified according to the dependency relationships, including data dependency edges, control dependency edges, and memory alias dependency edges. For atomic instructions, global order dependency edges are added to maintain the sequential consistency of memory operations. For non-atomic memory load and store instructions, conservative alias analysis based on memory page granularity is used to construct memory alias dependency edges to avoid potential data races.

3. The method as described in claim 1, characterized in that, Calculation of the overall weight w(u,v): ； Where α, β, and γ represent the data reuse degree, respectively. Hot topic weight and control distance The adjustable coefficient.

4. The method as described in claim 3, characterized in that, The specific details of the calculation of the overall weight w(u,v) are as follows: ； in, For instructions The generated data values, and In instruction set Used in; instruction set It contains k instructions, that is It is a data value Total number of times Span is used )for The last instruction and The difference in instruction positions between them. ； in, It is the execution count of the basic block containing instruction u, and V represents the node set of the instruction dependency graph; ； in, For the shortest path between basic blocks, These are the basic blocks containing instructions u and v, respectively. This is the normalization constant.

5. The method as described in claim 1, characterized in that, The calculation of dynamic priority P(v) is as follows: ； The first term in the above formula is the static inheritance weight: instruction Inherit the maximum weight among its predecessor's dependent edges; The second item is the cost of dynamic switching. The core scheduling constraints at runtime. This indicates the basic block containing the instruction Last. Jump to the basic block containing instruction v The overhead, where Last is the instruction that the core has just executed; The third item is the runtime performance penalty item MissPenalty(v); a dynamic penalty item calculated based on the hardware cache miss rate of instruction v collected at runtime.

6. The method as described in claim 1, characterized in that, The Ready priority queue (ReadyQ) is implemented using a lock-free skip list, and concurrency safety is ensured through CAS atomic operations of comparison and swapping. The TokenBus is implemented using a circular buffer with head and tail pointers controlled by atomic variables head and tail, used for multi-threaded concurrent writing of instruction completion events. The ResTable is implemented using an atomic integer bitmap, with each bit mapping to a physical or logical execution unit, and resource bits are occupied and released through atomic fetch_or and fetch_and operations.

7. The method as described in claim 1, characterized in that, The runtime dynamic scheduling process also includes a hot spot concentration execution strategy: when the execution flow is detected to enter a hot spot area, the scheduler will prioritize issuing instructions from the same thread context continuously within a preset continuous execution window; And heavy instruction offloading strategy: For heavy instructions marked as computationally intensive, increase their scheduling priority and support asynchronous dispatch to the graphics processing unit (GPU) or coprocessor for execution.

8. The method as described in claim 1, characterized in that, During multi-threaded collaboration and load balancing, under the non-uniform memory access architecture NUMA, work stealing is prioritized among cores within the same NUMA node; it also includes an aging strategy: dynamically prioritizing instruction nodes that have been waiting for too long in ReadyQ.

9. The method as described in claim 1, characterized in that, It also includes performance feedback and adaptive adjustment steps: periodically reading hardware cache miss events from the hardware performance counters by calling the performance event monitoring system perf_event_open, obtaining the cache miss rate based on the hardware cache miss events and dynamically adjusting the runtime performance penalty term MissPenalty; and adjusting the adjustable coefficients α, β and γ in the comprehensive weight calculation using a proportional-integral-derivative PID controller or a sliding window average smoothing method based on the workload characteristics.

10. A shortest instruction distance scheduling system for a smart contract virtual machine, characterized in that, include: The static analysis module is used to perform the static analysis and preprocessing operations described in claim 1, and output the instruction dependency graph and weight table; A runtime scheduling engine is used to load the instruction dependency graph and weight table, and execute the runtime dynamic scheduling operation as described in claim 1. A load balancer module is used to perform the multi-threaded collaboration and load balancing operation described in claim 1.

Images