A pre-screening method for smart contract symbolic execution constraint solvability

Abstract

The application discloses a pre-screening method for smart contract symbolic execution constraint solvability, and belongs to the technical field of smart contract security audit. The application solves the problem of mismatching of computing resources caused by the inability to predict path constraint solving difficulty when the traditional hybrid fuzzing method in the prior art is used to process smart contracts; an isolated environment and input are configured for a fuzzing engine; ABI is parsed, and an initial test case set is randomly generated; the test case is extracted and executed, and branch distance and execution trajectory are obtained through double monitoring; local stagnation is detected according to the minimum branch distance, and the stagnation branch is converted into S5, otherwise, the seed pool is updated to return to S3; the JUMPI operand is used as a slicing criterion, a lightweight backtracking is generated to generate an instruction subset; constraint solvability is evaluated, and resources are adaptively scheduled to generate a new test case and return to S3; the cycle is repeated until the time upper limit or full branch coverage, and the high-risk area of the contract is focused. The application reduces the application of computing resources, and can be applied to hybrid fuzzing.

Description

Technical Field

[0001] This invention relates to the field of smart contract security auditing technology, specifically a pre-screening method for the solvability of symbolic execution constraints in smart contracts. Background Technology

[0002] With the rapid evolution of blockchain technology, platforms supporting smart contracts, such as Ethereum, have become core infrastructure for applications like decentralized finance (DeFi). Smart contracts, as automatically executed code running on the blockchain, directly manage vast amounts of digital assets. Because smart contracts are immutable after deployment, even the slightest logical flaw can lead to irreversible economic losses. Therefore, comprehensive automated security audits before contract deployment have become essential for ensuring the security of the blockchain ecosystem.

[0003] Currently, hybrid fuzzing is one of the mainstream technologies for smart contract vulnerability detection. It combines the high throughput mutation capability of fuzzing with the precise solution capability of symbolic execution. Ideally, when the mutation during hybrid fuzzing cannot break through complex conditional branches, the system will call the symbolic execution engine to automatically solve the path constraints and generate test cases that can trigger new paths, thereby improving code coverage.

[0004] However, existing hybrid fuzzing scheduling mechanisms for smart contracts still suffer from scheduling inefficiencies in practical applications. Traditional testing frameworks typically employ a blind invocation strategy, indiscriminately sending all path constraints to the symbolic execution engine once path exploration stalls are detected. In actual contract code, the complexity of constraints varies greatly: some constraints involve only arithmetic operations, which symbolic execution can quickly solve to generate new seeds that meet the constraints; others contain complex constraints that are difficult to solve (such as the Keccak256 hash function) and complex environmental dependencies (such as block hashes or timestamps). Because current hybrid fuzzing systems lack a pre-assessment mechanism for constraint solvability, expensive computational resources are often wasted on mathematically unsolvable or extremely expensive unsolvable paths. This not only causes severe path explosion but also leads to frequent timeouts and deadlocks in the solver, crowding out computational resources that could be used to explore other high-value solvable paths. This resource mismatch severely limits the depth and efficiency of vulnerability detection in complex smart contracts.

[0005] In summary, existing scheduling strategies typically send all stalled paths to the symbolic execution engine indiscriminately. This leads to frequent timeouts and overflows in solvers when dealing with paths containing complex nonlinear operations or environmental dependencies. This not only wastes valuable computational quotas but also blocks the exploration of other potentially solvable paths, thereby reducing the overall efficiency of vulnerability detection. Therefore, a pre-screening method for the solvability of symbolic execution constraints in smart contracts is needed. Summary of the Invention

[0006] A brief overview of the invention is given below to provide a basic understanding of certain aspects of it. It should be understood that this overview is not an exhaustive summary of the invention. It is not intended to identify key or essential parts of the invention, nor is it intended to limit the scope of the invention. Its purpose is merely to present certain concepts in a simplified form as a prelude to the more detailed description that follows.

[0007] In view of this, in order to solve the problem of computational resource misallocation caused by the inability to predict the difficulty of solving path constraints in traditional hybrid fuzzing testing methods when processing smart contracts, this invention provides a pre-screening method for the solvability of symbolic execution constraints of smart contracts.

[0008] The technical solution is as follows: A pre-screening method for the solvability of execution constraints of smart contract symbols, comprising the following steps:

[0009] S1. Configure an isolated environment for the fuzz testing engine, and take the binary bytecode of the smart contract under test and its corresponding binary interface ABI as its input;

[0010] S2. After configuring the environment, the fuzzy testing engine parses the ABI file in the input, identifies the callable functions and their parameter types, and uses a random generation strategy to construct the initial test case set;

[0011] S3. Extract test cases from the initial test case set using the fuzzy testing engine after configuring the environment, and drive bytecode execution in the isolated environment using a dual monitoring mechanism to determine branch distance and execution trajectory;

[0012] S4. Based on the minimum branch distance of the current branch and the judgment logic, perform accurate detection of local stagnation using the fuzzy testing engine after configuring the environment; if it is determined that the current branch has a local exploration stagnation, then execute step S5 for the determined current stagnation branch; if no local exploration stagnation has occurred and the current test case has triggered a new path, then update the test case to the seed pool and return to step S3 to continue extraction and execution.

[0013] S5. For the identified stalled branches, use the operands of the jump condition JUMPI as the slicing criterion to perform lightweight dynamic backtracking analysis in the current execution trajectory and generate instruction subsets;

[0014] S6. Traverse the instruction subset, evaluate the solvability of constraints based on the preset operator classification dictionary, and further perform adaptive resource routing scheduling to return the new test cases generated under different paths to step S3;

[0015] S7. Continuously loop through steps S3-S6, continuously updating the seed pool and optimizing resource routing and scheduling to ensure that computing resources are always concentrated in the contract area, until the test process reaches the preset global time limit or all target branches are covered and then stops.

[0016] Furthermore, in S1, when the input is high-level source code, it is automatically compiled according to its compiler version information to extract the Ethereum Virtual Machine, EVM and compatible bytecode; during the system initialization phase, the global control flow graph of the contract is scanned by static analysis to identify all jump condition JUMPI instructions; custom monitoring logic is inserted before each jump condition JUMPI instruction using an instrumentation engine to capture the operands at the top of the stack in real time during the virtual machine execution phase.

[0017] Furthermore, in step S2, by identifying all callable functions declared as public or external attributes in the ABI file of the smart contract under test and their parameter types, an initial function call sequence and parameter assignment are generated using a type-based random generation strategy for different data types such as integers, byte arrays, and addresses, thereby completing the construction of the initial test case set.

[0018] Furthermore, in S3, the execution process is as follows: On the one hand, assertion failures, overflow errors, and illegal instructions are monitored in real time through exception capture logic. The exception capture logic is implemented by deploying a state listener and an error signal interceptor in the virtual machine execution engine in the isolated environment. If the exception capture logic is triggered, the potential vulnerability is immediately reported. On the other hand, the specific execution path and branch distance D(b) of each smart contract condition branch are recorded through instrumentation probes, where b represents the specific condition jump instruction currently being monitored, i.e., the branch point. After execution, all execution trajectories are stored in the cache.

[0019] Furthermore, in S4, the fuzz testing engine treats each conditional jump branch point b in the smart contract that is triggered by the current test case and has not achieved bidirectional coverage as an active branch point and maintains a sliding window statistics table of size N to record the minimum branch distance min D(b) of the current branch in continuous mutation rounds in real time.

[0020] The judgment logic is as follows: If, after M consecutive targeted mutations, the minimum branch distance min D(b) of an active branch point b remains unchanged and the target condition direction oriented by the active branch point b is never covered, it is determined to be a local exploration stagnation. The target condition direction of the current stagnation is determined, and the fuzzy testing engine system then triggers the analysis process of step S5. If the minimum branch distance continues to shrink or a new condition direction is successfully triggered to achieve new branch coverage, the corresponding use case is stored as a high-quality seed in the seed pool, and the seed selection weight is adjusted according to the coverage growth. Then, the system returns to step S3 to continue execution.

[0021] Furthermore, in S5, the lightweight dynamic backtracking analysis process is as follows: The fuzzy testing engine, through the taint propagation mechanism, identifies instruction sequences that have direct data or control dependencies with the jump conditions, focusing on tracing the source of the storage instruction SLOAD, the memory loading instruction MLOAD, and the environment instruction CALLDATACOPY, until it backtracks to the smart contract function input parameters. During this process, state variable modification instructions unrelated to the current branch decision are automatically eliminated, ultimately generating a highly compressed subset of instructions. .

[0022] Furthermore, in step S6, the instruction subset generated in step S5 is traversed. The constraint complexity is quantitatively evaluated based on a pre-defined operator classification dictionary, and adaptive resource routing scheduling is performed according to the evaluation results, as follows: 1) Deterministic symbolic solution path: if instruction subset If the code contains only linear operators such as addition, subtraction, and logical shift, and the slice depth is below a preset threshold T, it is marked as a regular solution point. The fuzzy testing engine calls the SMT solver to accurately solve the constraints, generates new test cases that break through the current branch, and returns them to step S3 for execution; 2) Probabilistic mutation path: If the instruction subset If hash operations, complex pre-compiled contract calls, or unmodelable environment variables are detected, they are marked as high-complexity bottlenecks. The fuzzing engine actively avoids the high-overhead symbolic execution process and maps the timeout budget originally allocated to the SMT solver to the execution frequency increment of the fuzzing engine. A high-density directed mutation scheme is launched to try to bypass mathematically unsolvable bottlenecks through random collisions. The generated test cases return to step S3 for execution.

[0023] The beneficial effects of this invention are as follows: This invention proposes a pre-screening method for the solvability of symbolic execution constraints in smart contracts. By introducing instruction-level dynamic backtracking slicing and a constraint solvability hierarchical evaluation method, it solves the problem of wasted computing resources and path explosion caused by blindly calling symbolic execution when hybrid fuzzing faces complex logic including hash functions. This invention designs an adaptive scheduling method suitable for hybrid fuzzing frameworks and, based on this constraint solvability hierarchical evaluation method, establishes an adaptive computing resource priority scheduling model. This model achieves optimal dynamic allocation of computing resources between the symbolic execution engine and the fuzzing engine by real-time diverting path constraints of different complexities. For highly solvable constraints, symbolic solution resources are precisely allocated to achieve deterministic path bursts. For constraints with low solvability or no solvability, a mutation energy redistribution mechanism is used to transform the computation time originally preset for the solver into high-frequency seed mutation power, thereby improving the overall search energy efficiency of the testing system. This invention addresses the problem that complex logical branches can easily mask security vulnerabilities in smart contracts by designing a pre-filtering and resource routing method based on the solvability of path constraints. This allows for thorough vulnerability detection and path coverage testing of smart contracts before deployment to the blockchain. By actively avoiding the ineffective use of computational resources by mathematically unsolvable paths, this invention significantly improves the detection depth and throughput performance of the testing engine when facing large-scale complex contracts. It can more efficiently capture deep logical defects, thereby reducing the risk of smart contract vulnerabilities and maintaining the security and stability of the blockchain ecosystem. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0025] Figure 1 This is a flowchart illustrating a pre-screening method for the solvability of execution constraints on smart contract symbols.

[0026] Figure 2 This is a schematic flowchart of an embodiment of a pre-screening method for the solvability of execution constraints on smart contract symbols. Detailed Implementation

[0027] To make the technical solutions and advantages of the embodiments of the present invention clearer, the exemplary embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0028] refer to Figure 1 and Figure 2 This embodiment describes a pre-screening method for the solvability of execution constraints on smart contract symbols, specifically including the following steps:

[0029] S1. Configure an isolated environment for the fuzz testing engine, and take the binary bytecode of the smart contract under test and its corresponding binary interface ABI as its input;

[0030] S2. After configuring the environment, the fuzzy testing engine parses the ABI file in the input, identifies the callable functions and their parameter types, and uses a random generation strategy to construct the initial test case set;

[0031] S3. Extract test cases from the initial test case set using the fuzzy testing engine after configuring the environment, and drive bytecode execution in the isolated environment using a dual monitoring mechanism to determine branch distance and execution trajectory;

[0032] S4. Based on the minimum branch distance of the current branch and the judgment logic, perform accurate detection of local stagnation using the fuzzy testing engine after configuring the environment; if it is determined that the current branch has a local exploration stagnation, then execute step S5 for the determined current stagnation branch; if no local exploration stagnation has occurred and the current test case has triggered a new path, then update the test case to the seed pool and return to step S3 to continue extraction and execution.

[0033] Specifically, in the "adjusting seed selection weights based on coverage growth" section, this embodiment provides a dynamic weight adjustment and probabilistic route reconstruction calculation method based on energy gain factors. This method dynamically tracks the code coverage feedback status after the execution of mutated test cases using instrumentation probes, and adaptively reconstructs the selection probability of individuals in the seed pool. The specific calculation and control process is as follows:

[0034] Step S1. Initialize seed base energy score: The system assigns a base energy score to each seed use case in the current seed pool. Assign a preset initial base weight score In this embodiment, it is preferably represented as follows:

[0035]

[0036] Step S2. Dynamically evaluate the coverage gain contribution factor: when any seed use case After mutation and returning to step S3 to drive execution in the isolated environment, the system's local stagnation detection module extracts the number of new path basic blocks triggered by this use case in real time. And based on this, calculate the current coverage growth contribution factor. :

[0037]

[0038] In the formula, This represents the total number of basic blocks in the global control flow graph of the smart contract under test.

[0039] Step S3. Dynamic selection weight update calculation: Combining the actual contribution of coverage growth in each iteration with the current branch distance state, dynamically calculate and update the selection weight of the seed according to the following energy gain formula. :

[0040]

[0041] In the formula, The preset coverage sensitivity growth coefficient is preferably 2.5 in this embodiment; This is the distance-guided adjustment constant; This is the minimum branch distance generated by the seed use case at the active branch point b. To prevent the differential adjustment constant from having a denominator of zero, it is preferred to set it as follows: .

[0042] Step S4. Normalized Selection Probability Reconstruction: To ensure that the fuzzing engine's computational resources are accurately allocated to high-quality seeds with high exploration value, the system calculates the normalized selection probability of each seed test case based on the updated selection weights. :

[0043]

[0044] In the formula, K represents the total number of active seeds in the current seed pool. When the fuzzing engine selects seeds in the next round, it will do so based on probability. A roulette wheel mechanism is used to prioritize the extraction of high-energy individuals as the basis for mutation.

[0045] S5. For the identified stalled branches, use the operands of the jump condition JUMPI as the slicing criterion to perform lightweight dynamic backtracking analysis in the current execution trajectory and generate instruction subsets;

[0046] S6. Traverse the instruction subset, evaluate the solvability of constraints based on the preset operator classification dictionary, and further perform adaptive resource routing scheduling to return the new test cases generated under different paths to step S3;

[0047] S7. Continuously loop through steps S3-S6, continuously updating the seed pool and optimizing resource routing and scheduling to ensure that computing resources are always concentrated in contract areas that are easy to break through or have high value, until the testing process reaches the preset global time limit or all target branches are covered and then stops.

[0048] Furthermore, in S1, when the input is high-level source code such as Solidity, it is automatically compiled according to its compiler version information to extract the Ethereum Virtual Machine, EVM, and compatible bytecode; during the system initialization phase, the global control flow graph of the contract is scanned by static analysis to identify all jump condition JUMPI instructions; custom monitoring logic is inserted before each jump condition JUMPI instruction using an instrumentation engine, and the operands at the top of the stack are captured in real time during the virtual machine execution phase to provide raw data input for subsequent calculation of the difference distance of the logic.

[0049] Furthermore, in step S2, by identifying all callable functions declared as public or external attributes in the ABI file of the smart contract under test and their parameter types, an initial function call sequence and parameter assignment are generated using a type-based random generation strategy for different data types such as integers, byte arrays, and addresses, thereby completing the construction of the initial test case set.

[0050] Specifically, if users provide historical transaction records or manually written seed test cases, the fuzzing engine will standardize the format and store them in the test case set, aiming to provide a starting search space that is closer to actual business logic.

[0051] Furthermore, in S3, the execution process is as follows: On the one hand, assertion failures, overflow errors, and illegal instructions are monitored in real time through exception capture logic. Specifically, the exception capture logic is implemented by deploying a state listener and an error signal interceptor in the virtual machine execution engine in an isolated environment. If the exception capture logic is triggered, the potential vulnerability is immediately reported. On the other hand, the specific execution path and branch distance D(b) of each smart contract condition branch are recorded through instrumentation probes, where b represents the currently monitored specific condition jump instruction, i.e., the branch point. After execution, all execution trajectories are stored in a cache for subsequent analysis.

[0052] Specifically, the branch distance D(b) is calculated based on the predicate type of the conditional judgment. For example, for the EQ instruction (equality comparison), the branch distance D(b) is defined as the absolute value of the difference between the two operands. ,in, and Let D(b) represent the original values ​​of the two operands at the top of the current execution stack that are being compared for equality; for the LT instruction (less than comparison), the branch distance D(b) is defined as... ,in, Represents the left operand. Represents the right operand, and constant is a preset micro-adjustment constant used to ensure that the distance value is always greater than zero when the logical condition is not met.

[0053] Furthermore, in S4, the fuzz test engine system maintains a sliding window statistics table of size N for each active branch in the smart contract, and records the minimum branch distance min D(b) of the current branch in continuous mutation rounds in real time;

[0054] The judgment logic is as follows: If a branch b remains unchanged in minimum branch distance min D(b) after M consecutive targeted mutations and the current branch is never covered, it is judged as a local exploration stagnation, the current stagnant branch is determined, and the fuzz test engine system then triggers the analysis process of step S5; if the branch distance continues to shrink or a new branch is covered, the corresponding test case is stored as a high-quality seed in the seed pool, and the seed selection weight is adjusted according to the coverage growth, and the process returns to step S3 to continue execution.

[0055] Furthermore, in S5, the lightweight dynamic backtracking analysis process is as follows: The fuzzy testing engine system identifies instruction sequences with direct data or control dependencies on jump conditions through a taint propagation mechanism. Specifically, it focuses on tracing the source of the storage instruction SLOAD, the memory loading instruction MLOAD, and the environment instruction CALLDATACOPY, until it traces back to the input parameters of the smart contract function. During this process, it automatically eliminates state variable modification instructions that are irrelevant to the current branch decision, ultimately generating a highly compressed subset of instructions. This significantly reduces the size of formula construction for symbolic execution.

[0056] Specifically, in step S5, "automatically removing state variable modification instructions unrelated to the current branch decision," this embodiment provides an instruction pruning and removal method based on dynamic data flow dependency topology. Taking a specific transfer control scenario in a smart contract under test as an example, the instruction removal and subset pruning process is as follows: Assume that the currently intercepted stagnant branch point b is a JUMPI conditional jump instruction used to control withdrawal permissions. The decision data that this instruction relies on at the top of the execution stack comes from a logical AND operation on the global state variable is_paused (whether the contract is paused) and the local variable user_balance (user balance). The system reverse-engineers lightweight dynamic backtracking analysis starting from this JUMPI instruction:

[0057] Taint propagation mechanism first identifies the SLOAD instruction that loads is_paused and the SLOAD instruction that loads user_balance, and then traces it further back to the CALLDATALOAD instruction that introduces external transaction data. Since these instructions and their directly related arithmetic operation instructions directly determine the jump direction of JUMPI, exhibiting a strong data dependency relationship with the jump conditions, the system retains them in full in the formula sequence to be constructed.

[0058] Irrelevant instruction removal (pruning): In the same transaction execution trajectory, if there is an SSTORE instruction (state variable modification instruction) that modifies another independent state variable total_rewards (total amount of global reward pool), or an auto-incrementing arithmetic instruction sequence that increments transfer_count (historical transfer count counter), the system will search the dependency topology graph of the current dynamic execution flow to determine that the data inflow and outflow nodes of total_rewards and transfer_count have no intersection with the taint lifecycle corresponding to the current JUMPI judgment data (i.e., there is no direct or indirect data dependency or control dependency).

[0059] At this point, before formula construction, the local stagnation detection module automatically removes and prevents the input of SSTORE status modification instructions and counter accumulation instructions that are not substantially related to the current transfer permission determination from the backtracking sequence.

[0060] Through the aforementioned automatic elimination mechanism, this embodiment highly compresses the originally lengthy dozens of state modification and context instruction slices into a simplified instruction subset containing only is_paused, user_balance, and their corresponding function input parameters. This reduces the number of terms constructed by the symbolic execution formula in the subsequent step S6 by more than 70%, fundamentally avoiding the path constraint explosion problem caused by irrelevant state variables.

[0061] Furthermore, in step S6, the instruction subset generated in step S5 is traversed. The constraint complexity is quantitatively evaluated based on a pre-defined operator classification dictionary, and adaptive resource routing scheduling is performed according to the evaluation results, as follows: 1) Deterministic symbolic solution path: if instruction subset If the code contains only linear operators such as addition, subtraction, and logical shift, and the slice depth is below a preset threshold T, it is marked as a regular solution point. The fuzzy testing engine system calls the SMT solver to accurately solve the constraints, generates new test cases that break through the current branch, and returns them to step S3 for execution; 2) Probabilistic mutation path: If the instruction subset If hash operations, complex pre-compiled contract calls, or unmodelable environment variables (such as block hashes and timestamps) are detected, they are marked as high-complexity blocking points. The fuzzing engine system actively avoids the high-overhead symbolic execution process and maps the timeout budget originally allocated to the SMT solver to the execution frequency increment of the fuzzing engine. It then initiates a high-density directed mutation scheme and attempts to bypass mathematically unsolvable bottlenecks through random collisions. The generated test cases are then returned to step S3 for execution.

[0062] Specifically, in this embodiment, adaptive resource routing scheduling, namely a weight-based quantitative evaluation and resource reallocation calculation method, is as follows:

[0063] 1) Constraint complexity score calculation: Calculate the instruction subset generated by the dynamic backtracking slice. Each instruction `inst` in the code is scanned, and the constraint complexity score is obtained by accumulating the results according to the operator dictionary. ;

[0064] Constraint complexity score Represented as:

[0065]

[0066] The preset weight dictionary is as follows: when Weight = 1, it represents a linear operator (such as ADD, SUB, AND, OR); when Weight = 5, it represents a non-linear operator (such as MUL, DIV, EXP); when Weight = 100, it represents a hash / environment operator (such as SHA3, BLOCKHASH, TIMESTAMP).

[0067] 2) Routing Decision and Resource Scheduling: The fuzzy testing engine system sets a complexity threshold T = 50, and presets a single symbolic solution timeout budget during the system initialization phase. In this embodiment The preferred time is 10 seconds; the dynamic routing and traffic splitting for use case A and use case B are as follows: (The details for use case A and use case B are as follows:)

[0068] Case A: Deterministic symbolic solution path (when...) If a problem is identified as a regular solution point, the system precisely allocates computing resources and directly assigns actual solution time. The SMT solver calculates the quota; if the solution is successful, it generates a deterministic test case seed that can break through the current branch.

[0069] Case B: Probabilistic mutation path ( If a high-complexity bottleneck is identified, the system actively avoids symbolic execution. At this point, the system executes a mutation energy redistribution mechanism, allocating the timeout budget originally set for the SMT solver. Completely converted into an increase in the execution frequency of the fuzz testing engine .

[0070] Execution frequency increment Represented as:

[0071]

[0072] in, The preset timeout budget for a single solution (10 seconds in this embodiment) is used. In this invention, when a high-complexity path is identified, the current time quota is redirected to the fuzz testing engine. This represents the average latency of the Ethereum Virtual Machine executing a single test case. Its value is obtained in real time through the historical execution data of the fuzzing engine system in step S3. By converting the time originally consumed in the solver deadlock into tens of thousands of targeted mutation attempts at the branch point, the mathematically unsolvable bottleneck is bypassed through probabilistic collisions.

[0073] Example of practical business effect: Suppose a contract branch contains `require(keccak256(data) == target)`, where `require` is a conditional preconditional check predicate in Solidity, `keccak256` is a built-in cryptographic hash function in Ethereum, `data` is the external input byte array for the function call, and `target` is a preset hash matching target value. Older technologies might alternately or probabilistically attempt symbol execution, causing the solver to time out and throw an error after 10 seconds of wasted time on `keccak256`. In contrast, the technology in this application pre-screens and identifies the SHA3 instruction, and scores it accordingly. =100 > T, the fuzzing engine system instantly skips symbolic execution and uses all 10 seconds to perform high-density random mutations, increasing the mutation frequency and thus greatly improving the probability of capturing deep logic vulnerabilities.

[0074] Although the invention has been described with reference to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and instructional purposes, and not for the purpose of interpreting or limiting the subject matter of the invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the invention is illustrative and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A pre-screening method for the solvability of symbolic execution constraints in smart contracts, characterized in that, Includes the following steps: S1. Configure an isolated environment for the fuzz testing engine, and take the binary bytecode of the smart contract under test and its corresponding binary interface ABI as its input; S2. After configuring the environment, the fuzzy testing engine parses the ABI file in the input, identifies the callable functions and their parameter types, and uses a random generation strategy to construct the initial test case set; S3. Extract test cases from the initial test case set using the fuzzy testing engine after configuring the environment, and drive bytecode execution in the isolated environment using a dual monitoring mechanism to determine branch distance and execution trajectory; S4. Based on the minimum branch distance of the current branch and the judgment logic, perform accurate detection of local stagnation using the fuzzy testing engine after configuring the environment; if it is determined that the current branch has a local exploration stagnation, then execute step S5 for the determined current stagnation branch; if no local exploration stagnation has occurred and the current test case has triggered a new path, then update the test case to the seed pool and return to step S3 to continue extraction and execution. S5. For the identified stalled branches, use the operands of the jump condition JUMPI as the slicing criterion to perform lightweight dynamic backtracking analysis in the current execution trajectory and generate instruction subsets; S6. Traverse the instruction subset, evaluate the solvability of constraints based on the preset operator classification dictionary, and further perform adaptive resource routing scheduling to return the new test cases generated under different paths to step S3; S7. Continuously loop through steps S3-S6, continuously updating the seed pool and optimizing resource routing and scheduling to ensure that computing resources are always concentrated in the contract area, until the test process reaches the preset global time limit or all target branches are covered and then stops.

2. The pre-screening method for the solvability of execution constraints of smart contract symbols according to claim 1, characterized in that, In S1, when the input is high-level source code, it is automatically compiled according to its compiler version information to extract the Ethereum Virtual Machine, EVM and compatible bytecode. During the system initialization phase, the global control flow graph of the contract is scanned by static analysis to identify all jump condition JUMPI instructions; custom monitoring logic is inserted before each jump condition JUMPI instruction using an instrumentation engine to capture the operands at the top of the stack in real time during the virtual machine execution phase.

3. The pre-screening method for the solvability of execution constraints of smart contract symbols according to claim 2, characterized in that, In step S2, by identifying all callable functions declared as public or external attributes in the ABI file of the smart contract under test and their parameter types, an initial function call sequence and parameter assignment are generated using a type-based random generation strategy for different data types such as integers, byte arrays, and addresses, thus completing the construction of the initial test case set.

4. The pre-screening method for the solvability of execution constraints of smart contract symbols according to claim 3, characterized in that, In S3, the execution process is as follows: On the one hand, assertion failures, overflow errors, and illegal instructions are monitored in real time through exception capture logic. The exception capture logic is implemented by deploying a state listener and an error signal interceptor in the virtual machine execution engine in the isolated environment. If the exception capture logic is triggered, the potential vulnerability is immediately reported. On the other hand, the specific execution path and branch distance D(b) of each smart contract condition branch are recorded by instrumentation probes, where b represents the specific condition jump instruction currently being monitored, i.e., the branch point. After execution, all execution trajectories are stored in the cache.

5. The pre-screening method for the solvability of execution constraints of smart contract symbols according to claim 4, characterized in that, In step S4, the fuzzing engine treats each conditional jump branch point b in the smart contract triggered by the current test case but not achieving bidirectional coverage as an active branch point and maintains a sliding window statistics table of size N. It records the minimum branch distance min D(b) of the current branch in consecutive mutation rounds in real time. The judgment logic is as follows: If the minimum branch distance min D(b) of an active branch point b remains unchanged after M consecutive targeted mutations and the target condition direction oriented by the active branch point b is never covered, it is determined to be a local exploration stagnation. The target condition direction of the current stagnation is determined, and the fuzzing engine system then triggers the analysis process in step S5. If the minimum branch distance continues to decrease or a new condition direction is successfully triggered, thus achieving new branch coverage, the corresponding test case is stored as a high-quality seed in the seed pool, and the seed selection weight is adjusted according to the coverage growth. The process then returns to step S3 to continue execution.

6. The pre-screening method for the solvability of execution constraints of smart contract symbols according to claim 5, characterized in that, In S5, the lightweight dynamic backtracking analysis process is as follows: The fuzzy testing engine uses a taint propagation mechanism to identify instruction sequences that have direct data or control dependencies with the jump conditions. Specifically, it focuses on tracing the source of the storage instruction SLOAD, the memory loading instruction MLOAD, and the environment instruction CALLDATACOPY, until it backtracks to the input parameters of the smart contract function. During this process, it automatically removes state variable modification instructions that are irrelevant to the current branch decision, ultimately generating a highly compressed subset of instructions. .

7. The pre-screening method for the solvability of execution constraints of smart contract symbols according to claim 6, characterized in that, In step S6, the instruction subset generated in step S5 is traversed. The constraint complexity is quantitatively evaluated based on a pre-defined operator classification dictionary, and adaptive resource routing scheduling is performed according to the evaluation results, as follows: 1) Deterministic symbolic solution path: if instruction subset If the slice contains only linear operators such as addition, subtraction, and logical shift, and the slice depth is lower than the preset threshold T, it is marked as a regular solution point. The fuzz test engine calls the SMT solver to accurately solve the constraints, generates new test cases that break through the current branch, and returns them to step S3 for execution. 2) Probabilistic mutation path: if instruction subset If hash operations, complex pre-compiled contract calls, or unmodelable environment variables are detected, they are marked as high-complexity bottlenecks. The fuzzing engine system actively avoids the high-overhead symbolic execution process and maps the timeout budget originally allocated to the SMT solver to the execution frequency increment of the fuzzing engine. It then initiates a high-density directed mutation scheme and attempts to bypass mathematically unsolvable bottlenecks through random collisions. The generated test cases are then returned to step S3 for execution.

Images