Smart contract fuzzing method and system based on branch priority and dynamic-static branch distance driving

Abstract

This invention discloses a fuzz testing method and system for smart contracts driven by branch priority and dynamic / static branch distance. The method is as follows: S1. Compile and parse the contract to generate an intermediate representation; extract the data dependencies of state variables in the contract; generate a control flow graph; S2. Based on the control flow graph, extract the judgment conditions and dependent variables of each branch, evaluate each transaction branch, and mark high-priority branch areas; S3. Allocate initial test energy to test seeds according to the branch priority results; S4. Track the dependencies between transaction calls and generate an initial transaction sequence; use the state and branch structure information before the comparison instruction to identify key state variables affecting the target branch conditions and construct semantically related test seeds; comprehensively evaluate the proximity of test cases to the target branch; prioritize high-priority branch areas and adjust branch priorities; detect vulnerabilities based on test oracle execution tracking.

Description

Technical Field

[0001] This invention belongs to the field of blockchain security technology, specifically relating to a method and system for fuzzing smart contracts based on branch priority and dynamic-static branch distance (DPFuzz). Background Technology

[0002] As a distributed, shared database, blockchain profoundly impacts multiple sectors and is considered to have the potential to reshape the global business landscape. Ethereum smart contracts (automatically executed computer protocols) are the core of the cryptocurrency ecosystem, experiencing explosive growth in recent years, with over 60 million instances created on Ethereum and over one million transactions daily. However, smart contract vulnerabilities pose significant risks; for example, the DAO incident resulted in a $150 million loss due to a reentrancy vulnerability, and the FoMo3D incident resulted in losses exceeding $1 billion. Because blockchain is immutable, updating smart contracts is difficult; therefore, comprehensive security testing is necessary before deployment to eliminate vulnerability risks and avoid wasting computational resources on updates.

[0003] To address the aforementioned technical challenges, researchers in this field have developed various smart contract vulnerability detection tools, which are currently mainly divided into two categories: static analysis tools and dynamic analysis tools. The former identifies contract vulnerabilities through pattern matching and symbolic execution. However, pattern matching is prone to information loss when the contract is converted into an intermediate representation, leading to overestimation of its capabilities and a higher false positive rate. Symbolic execution, due to its precise enumeration of contract symbol traces, faces the path explosion problem and struggles to handle contracts with multiple execution paths. The latter primarily relies on fuzzing to discover errors in the contract. While the latter has made satisfactory progress in vulnerability detection, its low code coverage makes it difficult to discover vulnerabilities in uncovered program areas, resulting in a high false negative rate.

[0004] More specifically, the following challenges may be encountered when fuzzing smart contracts: (1) Existing fuzzing tools are unreasonable in uniformly allocating fuzzing resources to each branch. Since each transaction branch has equal priority, the fuzzer may waste a lot of resources to fuzz meaningless branches, while providing insufficient energy for complex and important branches. (2) When fuzzing turns to seed input generation, the space for seed input generation is too large, resulting in the generation of too many invalid seeds and low seed utilization. Although some current fuzzing tools have begun to select higher quality seed inputs, the problem of indirect input generation still exists. (3) Current fuzzing tools have bottlenecks in identifying transaction sequences that can trigger changes in the persistent state of the contract. Although existing research has attempted to determine transaction sequences through data dependency analysis, it still has limitations when facing scenarios that rely on previous transaction states or complex logical judgments. As a result, only a limited number of states can be triggered within a specific time, making it difficult to delve into complex branches to explore deeper states, thus making it difficult to uncover vulnerabilities hidden deep within complex branches. Summary of the Invention

[0005] To address the technical problems of insufficient exploration of complex state spaces and low vulnerability detection efficiency in existing smart contract fuzzing technologies, this invention provides a smart contract fuzzing method and system (DPFuzz) driven by branch priority and dynamic / static branch distance. This invention improves the accuracy and effectiveness of smart contract vulnerability detection by proposing branch priority, dynamic / static branch distance metrics, and data flow awareness strategies to guide the adaptive allocation of test resources and generate high-quality test inputs.

[0006] The technical solution adopted by this invention to solve its technical problem is as follows:

[0007] A fuzz testing method for smart contracts based on branch priority and dynamic / static branch distance is proposed, with the following specific steps:

[0008] S1. System Initialization Phase: The target smart contract is compiled and parsed to generate an intermediate representation (IR), including the Application Binary Interface (ABI), bytecode, and abstract syntax tree (AST); at the same time, the data dependencies of the state variables in the contract are extracted and analyzed; and based on the parsing results of the target smart contract bytecode from the AST, a control flow graph is generated.

[0009] S2, Code Analysis Phase: Based on the control flow graph, extract the judgment conditions and dependent variables of each branch; dependent variables include storage variables, memory variables and operand stack elements, and record their state before the comparison instruction; evaluate each transaction branch based on the control flow graph, determine the nesting level of the conditions of the branch node, the length of the branch path, and the number of state variables involved in the branch, and mark the high-priority branch area;

[0010] S3, Energy Allocation Phase: Based on the branch priority results, initial test energy is allocated to the test seeds, and in subsequent steps, high-priority seeds are prioritized to enter the fuzzy testing loop;

[0011] S4, the fuzzing loop phase, includes:

[0012] Transaction sequence generation: Based on the state variable data dependencies extracted in step S1 and the control flow graph constructed in step S1, combined with the branch conditions and their dependent variable information extracted in step S2, the dependencies between transaction sequences are tracked to generate an initial transaction sequence; at the same time, using the state before the comparison instruction recorded in step S2 and the branch structure information such as the number of nested levels of branch conditions, the length of branch paths, and the number of state variables obtained in step S2, key state variables affecting the target branch conditions are identified, and test seeds with semantic relevance are constructed to improve the reachability of deep states;

[0013] Seed mutation and optimization: During the fuzzing test loop, a dynamic and static branch distance metric feedback engine is introduced; the structural distance of the target branch is obtained through static analysis, and combined with the dynamic difference of the runtime branch conditions, the proximity of the test case to the target branch is comprehensively evaluated; based on the evaluation results, the test seeds are dynamically scheduled and energy is allocated, high-priority branch regions are given priority, and the branch priority is adaptively adjusted.

[0014] Seed scheduling and vulnerability report generation: Selecting, crossovering, and mutating seed populations, dynamically adjusting branch priorities, and using the Ethereum Virtual Machine to perform tracing based on test oracles to detect vulnerabilities.

[0015] Preferably, step S1 is as follows:

[0016] S11. Input and Parsing of the Target Contract: First, the source code of the input contract is compiled into three intermediate representations: bytecode, ABI, and AST. The bytecode is parsed into EVM (Ethereum Virtual Machine) instructions to support fuzz testing. Simultaneously, the data dependencies of the contract's state variables are extracted and analyzed.

[0017] S12. Control Flow Graph Construction: Based on the parsing results of the target smart contract bytecode by AST, generate its control flow graph, where nodes represent basic blocks and edges represent the control flow jump relationship between basic blocks.

[0018] In this invention, branch priority evaluation is calculated based on the number of variables involved in the branch, the type of variables, and the complexity of their data dependencies, in order to characterize the potential testing value of different branch regions.

[0019] Preferably, step S2 is as follows:

[0020] S21. Branch Condition Extraction: Analyze the conditional jump instructions in the control flow graph and extract the decision conditions and dependent variables for each branch. Dependent variables include stored variables, memory variables, and operand stack elements, recording their state before the comparison instruction, used for dynamic and static branch distance calculation and test target localization.

[0021] S22. Branch Evaluation: Each transaction branch is evaluated based on the control flow graph. The number of nested conditions, branch path length, and number of state variables involved in each branch are determined according to the number and type of variables and data dependency complexity. This provides a basis for subsequent score calculation and priority ranking. The number of nested conditions in a branch node is determined by traversing the control flow path and counting the condition depth from the root node to the branch node. The structural complexity of the branch path is measured by counting the path length from the branch node to the next control transfer or function exit. The number of state variables is determined by recording all state operations related to storage word loading and storage word storage using the Ethereum Virtual Machine and counting the number of unique state variables involved.

[0022] S23. Nesting Score: The nesting score is determined by the number of nested conditions of branch nodes in the CFG (Control Flow Graph). The nesting score is calculated by traversing the control flow path to determine the condition depth from the root node to the branch node.

[0023]

[0024] Among them, Depth(B i ) represents branch B i The depth of condition nesting in the control flow. The deeper the nesting level, the more complex the logical structure of the branch.

[0025] Length score calculation: The length score measures the structural complexity of a branch within the control flow path. It measures the scale of the path involved by calculating the path length from the branch node to the next control transfer or function exit. Let branch B... i The path length is L(B) i If the length score is:

[0026]

[0027] The longer the path length, the stronger the branch's extensibility in the control flow, the more complex its logical structure, and the more significant its impact on the program's execution state.

[0028] State score (i.e., number of state variables) calculation: The state score measures the degree to which a branch depends on persistent state variables. During execution, the Ethereum Virtual Machine (EVM) records all state operations related to word loading and word storage, and counts the number of unique state variables involved. The specific calculation is as follows:

[0029]

[0030] Among them, StateVar(B i ) represents branch B i The number of persistent state variables accessed. The more state variables, the stronger the branch's modification of or dependence on the contract state.

[0031] S24. Marking high-priority areas: Based on the aforementioned branch priority score calculation results, a dynamic marking mechanism for high-priority areas is further constructed: based on the nesting score, length score, and status score of each transaction branch, all transaction branches are sorted by comprehensive priority, and the transaction branches with the highest comprehensive score are marked as high-priority areas.

[0032] Preferably, step S3 is as follows:

[0033] S31. Before the fuzzing loop begins, execute the test input (i.e., the transaction and associated parameter values ​​generated by the fuzzing to drive the execution of the smart contract) on the Ethereum Virtual Machine and collect the corresponding execution paths. ;

[0034] S32. Based on the execution path, identify the split points in the transaction execution process and extract the corresponding transaction branch B;

[0035] S33, Nested score S for each transaction branch B nested Length score S length and state score S state The complexity score S of each transaction branch is calculated comprehensively. complexity ;

[0036]

[0037] S34. Detect whether there are transaction branches involving sensitive instructions (such as block.timestamp and msg.sender), and mark the transaction branches that contain sensitive instructions and are reachable;

[0038] S35. Assign an initial priority weight W to each transaction branch based on its complexity score, and give priority bonuses to transaction branches containing sensitive instructions.

[0039] S36. In subsequent fuzzing cycles, the fuzzing resources are dynamically adjusted according to the priority weight of each transaction branch, so that high-priority transaction branches can obtain more fuzzing resources.

[0040] S37. Dynamically and adaptively adjust the priority of transaction branches based on their coverage, and gradually reduce the priority of frequently covered transaction branches to avoid over-allocation of test resources.

[0041] Preferably, in the transaction sequence generation process of step S4, based on the state variable data dependency relationship extracted in step S11 and the control flow graph constructed in step S12, combined with the branch conditions and their dependency variable information extracted in step S21, the dependency relationship between transaction sequences is tracked to generate an initial transaction sequence; at the same time, using the operand stack state recorded in step S21 and the branch structure information obtained in step S22, the key state variables affecting the target branch conditions are identified, and a test seed with semantic relevance is constructed to improve the reachability of deep states.

[0042] In this invention, a data flow awareness strategy is used to identify key state variables that affect the target branch conditions, and to construct a transaction sequence with semantic relevance accordingly, so as to improve the accessibility of deep states.

[0043] Preferably, in step S4, the specific steps of the transaction sequence generation process are as follows:

[0044] S41.1 Based on the state variable data dependency relationship extracted in step S11 and the branch condition dependency variable information obtained in step S2, identify the key state variables that affect the target branch condition and their definition and usage relationship.

[0045] S41.2. Based on the dependencies of the key state variables, perform constraint analysis on the contract function calls to determine the set of candidate transactions that can modify the state variables;

[0046] S41.3. Based on the dependency order of the key state variables, sort and combine the candidate transactions to construct a transaction sequence that satisfies the data dependency relationship of the state variables, and generate a test seed with semantic relevance accordingly.

[0047] S41.4 Execute the generated transaction sequence as test input on the Ethereum Virtual Machine to drive the evolution of the contract state;

[0048] During the execution of steps S41.1 to S41.4, branch coverage information, state change information, and runtime feedback are collected for subsequent branch distance calculation and test input guidance.

[0049] In this invention, the dynamic and static branch distance metric obtains the structural distance of the target branch through static analysis and combines it with the dynamic difference of the branch conditions during runtime to comprehensively evaluate the proximity between the current test input and the target branch.

[0050] Preferably, in step S4, the specific steps of the seed mutation and optimization process are as follows:

[0051] S42.1 Calculation of Dynamic Distance: In fuzz testing, the generation of path conditions depends on the stack state and comparison operations before the critical jump instruction. Define S = {s0, s1, s2, ..., s...} i} represents the operand stack of the Ethereum Virtual Machine, where s i This represents the i-th element from the top of the stack. Typically, before the JUMPI instruction is executed, the Ethereum Virtual Machine executes a comparison instruction (such as GT, SGT, LT, SLT, EQ, or ISZERO) to determine if the branch condition is true. Except for ISZERO, the other instructions compare the top two elements s0 and s1 of the stack. Their core operation can be represented as:

[0052]

[0053] To characterize the directional features and boundary sensitivity of the comparison operation, a constant offset is introduced to obtain the adjusted dynamic gradient:

[0054]

[0055] Further assuming that transaction branch B is the target coverage branch of test case T, a function `distance(T,B)` is defined to measure the proximity between test case T and the target branch. To more accurately reflect the coverage difficulty, this invention uses absolute distance as the metric, combined with the operation type of the current instruction for calculation. Considering that in actual fuzzing, a single test case usually corresponds to multiple target branches, its dynamic distance is defined as the average distance between the test case T and n target branches B. The function `distance(T,B)` and the dynamic distance D... dyn The specific definition of (T) is as follows:

[0056]

[0057]

[0058] S42.2 Calculation of Static Distance: In fuzz testing, the exploration of test paths depends not only on runtime information such as operand stack states and comparison results, but also on the structural relationships between basic blocks in the control flow graph. To characterize the proximity of test cases to the target path, static distance is used to measure the control flow graph distance between the basic blocks already visited in the current execution path and the basic block containing the target branch.

[0059] Suppose the control flow graph of the contract is a directed graph, where nodes represent basic blocks and edges represent control flow transitions between basic blocks. If the execution path of test case T passes through the set of basic blocks BB={bb1,bb2,bb3,…,bb…} i Let TB be the base block containing the target transaction branch. Then, the static distance of test case T is defined as the average of the shortest path lengths between each base block on that path and the target block TB, i.e.:

[0060]

[0061] Wherein d(bb) i ,TB) indicates that in the control flow graph, from basic block bb i The shortest path length to TB is calculated here using Dijkstra's shortest path algorithm to calculate the distance between two basic blocks on the control flow graph.

[0062] S42.3, Dynamic and Static Joint Distance Function: To more comprehensively characterize the proximity between test cases and target transaction branches, a dynamic and static distance function is proposed, jointly considering both static and dynamic distance information. This balances the runtime conditional jump trend characteristics with the path proximity at the program structure level. Dynamic distance characterizes the proximity of branch boundaries reflected by operand differences in comparison instructions, while static distance provides global guidance for test path scheduling through shortest path analysis on the control flow graph. The two are complementary in fuzzy testing. Define the dynamic and static distance function D. dua (T) is as follows:

[0063]

[0064]

[0065]

[0066] in, The weighting coefficients are used to adjust the weights of dynamic and static information in the dynamic-static distance evaluation. Norm() is a normalization function that eliminates the difference in magnitude between dynamic and static distances. This distance function design not only maintains the sensitivity to critical jump points in the comparison operation, but also incorporates macroscopic proximity at the path level, which helps improve the coverage efficiency and mutation strategy selection capability of the fuzz tester in the target-oriented path guidance process.

[0067] Preferably, in step S4, the seed scheduling and vulnerability report generation process involves: using a genetic algorithm to select, crossover, and mutate the seed population, dynamically adjusting branch priorities, running test cases using the Ethereum Virtual Machine, and detecting vulnerabilities based on test oracle execution tracing. Coverage information and execution status are collected, and test results are analyzed through a feedback evaluation module to guide the optimization and generation of subsequent test seeds, forming a closed-loop testing process.

[0068] Preferably, in step S4, the specific steps of the seed scheduling and vulnerability report generation process are as follows:

[0069] S43.1 Test Seed Initialization: Construct initial test seeds. Each seed consists of a function selector, call data, and transaction-attached Ether. Fixed-type parameters are randomly generated within their valid range; for non-fixed-type parameters, the length is determined first, then the content is generated. Payment functions can be attached with a reasonable amount; otherwise, it is zero. Each function initializes at least two test seeds.

[0070] S43.2, Fitness-Based Seed Selection: The selection phase is the process of choosing parents and mothers for generating new individuals. The two most crucial aspects in this process are fitness evaluation and the design of the selection algorithm. Therefore, a fitness index integrating branch distance and branch coverage ability is designed to evaluate seed quality. The fitness function of individual X is defined as follows:

[0071]

[0072]

[0073] in, It is a constant less than 1, used to balance the weights between the branch distance feedback strategy and the traditional branch coverage strategy. Assuming the number of target trading branches for the current individual X is n, dis(X) represents the distance of individual X to all target trading branch conditions, and cov(X) represents the number of covered trading branch edges. Seeds with higher fitness have a higher probability of being selected in crossover and mutation operations. Let P(X) represent the probability of individual X being selected, and define X... G ={X1,X2,X3,…,X i Let} be the set of all candidate individuals in population G, and its calculation formula is as follows:

[0074]

[0075] S43.3 Seed Crossover and Mutation: The initial test seed consists of a single transaction. New transaction sequences are generated through crossover and mutation operations. Mutation randomly modifies the transaction parameter data, primarily focusing on the impact of assignments on function behavior. Mutation values ​​are selected from a dynamically updated mutation pool, which consists of specific values ​​from previous transactions and is continuously expanded during testing to control the mutation range and improve the exploration effect in terms of input sensitivity.

[0076] S43.4, EVM Execution Tracking: The test seed optimized by mutation in step S43.3 is submitted to the Ethereum Virtual Machine for execution as the transaction input. The contract execution process is dynamically tracked by instrumentation in the EVM interpreter. The changes in the program counter, opcode execution order, operand stack, and stored variables are recorded in real time. The execution results of comparison instructions and conditional jump instructions are monitored. The operand values ​​and branch jump information involved in the branch conditions are obtained. At the same time, the branch edges and state changes covered by the transaction execution path are statistically analyzed. The recorded program counter, opcode execution order, operand stack, and stored variable change information are used to form the transaction execution trajectory. Combined with the branch coverage information, it is used for subsequent fitness calculation and test oracle judgment.

[0077] S43.5 Test Oracles and Vulnerability Triggering: Execute test seeds in an independent Ethereum Virtual Machine instance and record the complete execution trajectory. Based on the execution results and predefined test oracles, identify vulnerabilities, including: Block Dependency (BD), Reentrancy (RE), Integer Overflow (IO), Dangerous Delegation Call (DD), Strict Ether Equality (SE), Unhandled Exception (UE), Self-Destruction (US), and Transaction Source Abuse (TO).

[0078] This invention also discloses a smart contract fuzz testing system driven by branch priority and dynamic / static branch distance, used to execute the above method, which includes the following modules:

[0079] Initialization module: Used to compile and parse the target smart contract, generate intermediate representation (IR), including application binary interface (ABI), bytecode, and abstract syntax tree (AST); extract and analyze the data dependencies of state variables in the contract; and generate a control flow graph based on the parsing results of the target smart contract bytecode from the AST.

[0080] Code analysis module: Based on the control flow graph, extract the judgment conditions and dependent variables of each branch; dependent variables include storage variables, memory variables and operand stack elements, recording their state before the comparison instruction; evaluate each transaction branch based on the control flow graph, determine the nesting level of the conditions of the branch node, the length of the branch path, and the number of state variables involved in the branch, and mark the high-priority branch area;

[0081] Energy allocation module: Allocates initial test energy to test seeds based on branch priority results;

[0082] Transaction sequence generation module: Based on the extracted state variable data dependencies and the constructed control flow graph, combined with the extracted branch judgment conditions and their dependent variable information, the module tracks the dependencies between transaction calls to generate an initial transaction sequence; at the same time, it uses the recorded state before the comparison instruction and the branch structure information such as the number of nested branch conditions, the length of the branch path, and the number of state variables to identify key state variables that affect the target branch conditions and construct test seeds with semantic relevance.

[0083] Seed mutation and optimization module: During the fuzzing loop, a dynamic and static branch distance measurement feedback engine is introduced; the structural distance of the target branch is obtained through static analysis, and combined with the dynamic difference of the runtime branch conditions, the proximity of the test case to the target branch is comprehensively evaluated; based on the evaluation results, the test seeds are dynamically scheduled and energy is allocated, high-priority branch regions are given priority, and the branch priority is adaptively adjusted.

[0084] Seed scheduling and vulnerability report generation module: Selects, crosses, and mutates seed populations, dynamically adjusts branch priorities, and uses the Ethereum Virtual Machine to perform tracing based on test oracles to detect vulnerabilities.

[0085] In summary, this invention provides a smart contract fuzzing method and system (DPFuzz) driven by branch priority and dynamic / static branch distance. By proposing branch priority, dynamic / static branch distance metrics, and data flow awareness strategies, this invention guides the adaptive allocation of test resources and generates high-quality test input, thereby improving the accuracy and effectiveness of smart contract vulnerability detection. Attached Figure Description

[0086] Figure 1 This is a framework diagram of a smart contract fuzzy testing system preferred by the present invention, driven by branch priority and dynamic / static branch distance.

[0087] Figure 2 This is a flowchart of the preferred smart contract fuzzy testing method based on branch priority and dynamic / static branch distance of the present invention.

[0088] Figure 3 This is a performance comparison chart of the branch coverage rate over time between the tool of the preferred embodiment of the present invention and other fuzzy tools during the testing process.

[0089] Figure 4 This is a comparison chart of the average branch coverage performance of the tool in the preferred embodiment of the present invention with other fuzzy tools.

[0090] Figure 5This is a comparison chart of the ablation performance of various components of the tool in a preferred embodiment of the present invention. Detailed Implementation

[0091] To provide a more detailed description of the present invention and to facilitate understanding by those skilled in the art, the present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0092] like Figure 2 As shown in the figure, this embodiment discloses a smart contract fuzz testing method driven by branch priority and dynamic / static branch distance. The specific process is as follows:

[0093] Step S1, System Initialization Phase: The target smart contract is compiled and parsed to generate an intermediate representation (IR), including the application binary interface (ABI), bytecode, and abstract syntax tree (AST). Simultaneously, the data dependencies of the state variables in the contract are extracted and analyzed. Then, a control flow graph is constructed based on the parsing results of the target smart contract bytecode using the AST. The specific steps are as follows:

[0094] S11. Input and Parsing of the Target Contract: First, the target contract is input, and the contract source code is compiled into three intermediate representations: bytecode, ABI, and AST. The bytecode is parsed into EVM instructions to support fuzz testing. Simultaneously, the data dependencies of the contract's state variables are extracted and analyzed.

[0095] S12. Control Flow Graph Construction: Based on the parsing results of the target smart contract bytecode by AST, generate its control flow graph, where nodes represent basic blocks and edges represent the control flow jump relationship between basic blocks.

[0096] Step S2, Code Analysis Phase: Based on the control flow graph, extract the judgment conditions and dependent variables of each branch; dependent variables include storage variables, memory variables and operand stack elements, and record their state before the comparison instruction; evaluate each transaction branch based on the control flow graph, calculate nesting, length and state score according to the number and type of variables and data dependency complexity of the branch, and mark high-value branch areas.

[0097] In this step, nesting, length, and state scores are calculated for each transaction branch. Priority is then determined based on these scores. The nesting score reflects the nesting level of the conditional statements within the branch; deeper nesting indicates higher logical complexity. The length score is calculated based on the number of instructions or opcodes in the branch, representing the complexity of the execution path. The state score is determined by the number of state variables involved in the branch, used to assess the branch's dependence on persistent state. This makes the fuzzy resource allocation for each transaction branch more reasonable, ultimately achieving efficient coverage.

[0098] Specifically as follows:

[0099] S21. Branch Condition Extraction: Analyze the conditional jump instructions in the control flow graph and extract the decision conditions and dependent variables for each branch. Dependent variables include stored variables, memory variables, and operand stack elements, recording their state before the comparison instruction, used for dynamic and static branch distance calculation and test target localization.

[0100] S22. Branch Evaluation: Each transaction branch is evaluated based on the control flow graph. The nesting level of conditions at each branch node, the branch path length, and the number of state variables involved in the branch are determined to provide a basis for subsequent score calculation and priority ranking. The nesting level of conditions at each branch node is determined by traversing the control flow path and counting the condition depth from the root node to the branch node. The structural complexity of the branch path is determined by counting the path length from the branch node to the next control transfer or function exit. The number of state variables is determined by recording all state operations related to storage word loading and storage word storage using the Ethereum Virtual Machine and counting the number of unique state variables involved.

[0101] S23. Nested Score Calculation: Specifically, the nested score is determined by the number of nested conditions in the branch nodes of the control flow graph. By traversing the control flow path and calculating the condition depth from the root node to the branch node, the nested score can be expressed as:

[0102]

[0103] Among them, Depth(B i ) represents branch B i The depth of condition nesting in the control flow. The deeper the nesting level, the more complex the logical structure of the branch.

[0104] Length score calculation: The length score measures the structural complexity of a branch within the control flow path. It measures the scale of the path involved by calculating the path length from the branch node to the next control transfer or function exit. Let branch B... i The path length is L(B) i If the length score is:

[0105]

[0106] The longer the path length, the stronger the branch's extensibility in the control flow, the more complex its logical structure, and the more significant its impact on the program's execution state.

[0107] State Score Calculation: The state score measures the degree to which a branch depends on persistent state variables. During execution, the Ethereum Virtual Machine records all state operations such as SLOAD (storage word loading) and SSTORE (storage word storage), and counts the number of unique state variables involved. The specific calculation is as follows:

[0108]

[0109] Where StateVar(B i ) represents branch B i The number of persistent state variables accessed. The more state variables, the stronger the branch's modification of or dependence on the contract state.

[0110] S24. Marking high-priority areas: Based on the aforementioned branch priority score calculation results, a dynamic marking mechanism for high-priority areas is further constructed: based on the nesting score, length score, and status score of each transaction branch, all transaction branches are sorted by comprehensive priority, and the transaction branches with the highest comprehensive score are marked as high-priority areas.

[0111] Step S3, Energy Allocation Phase: Based on the branch priority results, initial test energy is allocated to the test seeds. In subsequent steps, high-priority seeds are selected to enter the fuzz test execution phase. The specific steps are as follows:

[0112] S31. Before the fuzzing loop begins, execute the test input (i.e., the transaction and associated parameter values ​​generated by the fuzzing to drive the execution of the smart contract) on the Ethereum Virtual Machine and collect the corresponding execution paths. ;

[0113] S32. Based on the execution path, identify the split points in the transaction execution process and extract the corresponding transaction branch B;

[0114] S33, Nested score S for each transaction branch B nested Length score S length and state score S state The complexity score S of each transaction branch is calculated comprehensively. complexity ;

[0115]

[0116] S34. Detect whether there are transaction branches involving sensitive instructions (such as block.timestamp and msg.sender), and mark the transaction branches that contain sensitive instructions and are reachable;

[0117] S35. Assign an initial priority weight W to each transaction branch based on its complexity score, and give priority bonuses to transaction branches containing sensitive instructions.

[0118] S36. In subsequent fuzzing cycles, the fuzzing resources are dynamically adjusted according to the priority weight of each transaction branch, so that high-priority transaction branches can obtain more fuzzing resources.

[0119] S37. Dynamically and adaptively adjust the priority of transaction branches based on their coverage, and gradually reduce the priority of frequently covered transaction branches to avoid over-allocation of test resources.

[0120] Step S4, the fuzzing loop phase, includes:

[0121] Transaction sequence generation process: Based on the state variable data dependencies extracted in step S11 and the control flow graph constructed in step S12, combined with the branch conditions and their dependent variable information extracted in step S21, the dependencies between transaction sequences are tracked to generate an initial transaction sequence. Simultaneously, using the operand stack state recorded in step S21 and the branch structure information obtained in step S22, key state variables affecting the target branch conditions are identified, and semantically related test seeds are constructed to improve the reachability of deep states. Specifically, as follows:

[0122] S41.1 Based on the state variable data dependency relationship extracted in step S11 and the branch condition dependency variable information obtained in step S2, identify the key state variables that affect the target branch condition and their definition and usage relationship.

[0123] S41.2. Based on the dependencies of the key state variables, perform constraint analysis on the contract function calls to determine the set of candidate transactions that can modify the state variables;

[0124] S41.3. Based on the dependency order of the key state variables, sort and combine the candidate transactions to construct a transaction sequence that satisfies the data dependency relationship of the state variables, and generate a test seed with semantic relevance accordingly.

[0125] S41.4 Execute the generated transaction sequence as test input on the Ethereum Virtual Machine to drive the evolution of the contract state.

[0126] During execution, branch coverage information, state change information, and runtime feedback are collected for subsequent branch distance calculation and test input guidance.

[0127] Seed mutation and optimization process: During the fuzzing loop, a dynamic and static branch distance metric feedback engine is introduced: The structural distance to the target branch is obtained through static analysis, and combined with the dynamic difference of runtime branch conditions, the proximity between the test case and the target branch is comprehensively evaluated. Based on the evaluation results, test seeds are dynamically scheduled and energy allocated, prioritizing high-priority branch regions and adaptively adjusting branch priorities. The specific steps are as follows:

[0128] S42.1 Calculation of Dynamic Distance: In fuzzing, the generation of path conditions depends on the stack state and comparison operations before the critical jump instruction. We define S = {s0, s1, s2, ..., s...}i} represents the operand stack of the Ethereum Virtual Machine, where s i This represents the i-th element from the top of the stack. Typically, before the JUMPI instruction is executed, the Ethereum Virtual Machine executes a comparison instruction (such as GT, SGT, LT, SLT, EQ, or ISZERO) to determine if the branch condition is true. Except for ISZERO, the other instructions compare the top two elements s0 and s1 of the stack. Their core operation can be represented as:

[0129]

[0130] To characterize the directional features and boundary sensitivity of the comparison operation, a constant offset is introduced to obtain the adjusted dynamic gradient:

[0131]

[0132] Further assuming that transaction branch B is the target coverage branch of test case T, a function `distance(T,B)` is defined to measure the proximity between test case T and the target branch. To more accurately reflect the coverage difficulty, this embodiment uses absolute distance as the metric, combined with the operation type of the current instruction for calculation. Considering that in actual fuzzing, a single test case usually corresponds to multiple target branches, its dynamic distance is defined as the average distance between the test case T and n target branches B. The function `distance(T,B)` and the dynamic distance D... dyn The specific definition of (T) is as follows:

[0133]

[0134]

[0135] S42.2 Calculation of Static Distance: In fuzz testing, the exploration of test paths depends not only on runtime information such as operand stack state and comparison results, but also on the structural relationships between basic blocks in the control flow graph. To characterize the proximity of test cases to the target path, this embodiment uses static distance to measure the control flow graph distance between the basic blocks already visited in the current execution path and the basic block containing the target branch.

[0136] Suppose the control flow graph of the contract is a directed graph, where nodes represent basic blocks and edges represent control flow transitions between basic blocks. If the execution path of test case T passes through the set of basic blocks BB={bb1,bb2,bb3,…,bb…} i Let TB be the base block containing the target transaction branch. Then, the static distance of test case T is defined as the average of the shortest path lengths between each base block on that path and the target block TB, i.e.:

[0137]

[0138] Wherein d(bb) i ,TB) indicates that in the control flow graph, from basic block bb i The shortest path length to TB is calculated here using Dijkstra's shortest path algorithm to calculate the distance between two basic blocks on the control flow graph.

[0139] S42.3, Dynamic and Static Joint Distance Function: To more comprehensively characterize the proximity between test cases and target transaction branches, a dynamic and static distance function is proposed, jointly considering both static and dynamic distance information. This balances the runtime conditional jump trend characteristics with the path proximity at the program structure level. Dynamic distance characterizes the proximity of branch boundaries reflected by operand differences in comparison instructions, while static distance provides global guidance for test path scheduling through shortest path analysis on the control flow graph. The two are complementary in fuzzy testing. Define the dynamic and static distance function D. dua (T) is as follows:

[0140]

[0141]

[0142]

[0143] in, The weighting coefficients are used to adjust the weights of dynamic and static information in the dynamic-static distance evaluation. Norm() is a normalization function that eliminates the difference in magnitude between dynamic and static distances. This distance function design not only maintains the sensitivity to critical jump points in the comparison operation, but also incorporates macroscopic proximity at the path level, which helps improve the coverage efficiency and mutation strategy selection capability of the fuzz tester in the target-oriented path guidance process.

[0144] Seed scheduling and vulnerability report generation process: A genetic algorithm is used to select, crossover, and mutate the seed population, dynamically adjusting branch priorities. The Ethereum Virtual Machine (EVM) is used to run test cases, and vulnerability detection is based on test oracle execution tracing. Coverage information and execution status are collected, and test results are analyzed through a feedback evaluation module to guide the optimization and generation of subsequent test seeds, forming a closed-loop testing process. Specifically, it includes the following sub-steps:

[0145] S43.1 Test Seed Initialization: Construct initial test seeds. Each seed consists of a function selector, call data, and transaction-attached Ether. Fixed-type parameters are randomly generated within their valid range; for non-fixed-type parameters, the length is determined first, then the content is generated. Payment functions can be attached with a reasonable amount; otherwise, it is zero. Each function initializes at least two test seeds.

[0146] S43.2, Fitness-Based Seed Selection: The selection phase is the process of choosing parents and mothers for generating new individuals. The two most crucial aspects in this process are fitness evaluation and the design of the selection algorithm. Fitness evaluation primarily aims to find the optimal seed and allocate more fuzzy resources to it, thereby covering more transaction branches to trigger vulnerabilities. Therefore, this embodiment designs a fitness index that integrates branch distance and branch coverage capability to evaluate seed quality. The fitness function of individual X is defined as follows:

[0147]

[0148]

[0149] in, It is a constant less than 1, used to balance the weights between the branch distance feedback strategy and the traditional branch coverage strategy. Assuming the number of target transaction branches for the current individual X is n, dis(X) represents the distance of individual X from all target transaction branch conditions, and cov(X) represents the number of covered transaction branch edges. Since a larger dis(X) means a higher difficulty in covering new branches, this embodiment takes the reciprocal of the dynamic and static distances and incorporates it into the fitness function, making fitness positively correlated with distance and coverage information, thereby effectively evaluating the quality of individuals. Based on this fitness index, the value of seeds is evaluated, and high-value test cases are allocated more resources, guiding fuzzing to more effectively explore potential vulnerability paths. Specifically, seeds with high fitness have a higher probability of being selected in crossover and mutation operations. Let P(X) represent the probability of individual X being selected, and define X... G ={X1,X2,X3,…,X i Let} be the set of all candidate individuals in population G, and its calculation formula is as follows:

[0150]

[0151] S43.3 Seed Crossover and Mutation: The initial test seed consists of a single transaction, which generates a new transaction sequence through crossover and mutation operations. During crossover, if two transactions have a write-after-read dependency on the same state variable, they are combined in write-after-read order to maintain dependency semantics; if there is no significant dependency, they are combined with a certain probability to preserve diversity. Existing transaction sequences can also be further combined to construct longer and more complex sequences to enhance coverage and path diversity. Mutation involves randomly modifying transaction parameter data, primarily focusing on the impact of assignments on function behavior. Mutation values ​​are selected from a dynamically updated mutation pool, which consists of specific values ​​from previous transactions and is continuously expanded during testing to control the mutation range and improve the exploration effect in terms of input sensitivity.

[0152] S43.4, EVM Execution Tracking: The test seed optimized in step S43.3 is submitted as the transaction input to the Ethereum Virtual Machine for execution. The contract execution process is dynamically tracked by instrumentation in the EVM interpreter. The changes in the program counter, opcode execution order, operand stack, and stored variables are recorded in real time. The execution results of comparison instructions and conditional jump instructions are monitored. The operand values ​​and branch jump information involved in the branch conditions are obtained. At the same time, the branch edges and state changes covered by the transaction execution path are statistically analyzed. The recorded program counter, opcode execution order, operand stack, and stored variable change information are used to form the transaction execution trajectory. Combined with the branch coverage information, it is used for subsequent fitness calculation and test oracle judgment.

[0153] S43.5 Test Oracles and Vulnerability Triggering: Execute test seeds in an independent Ethereum Virtual Machine instance and record the complete execution trajectory. Based on the execution results and predefined test oracles, identify vulnerabilities, including: Block Dependency (BD), Reentrancy (RE), Integer Overflow (IO), Dangerous Delegation Call (DD), Strict Ether Equality (SE), Unhandled Exception (UE), Self-Destruction (US), and Transaction Source Abuse (TO). When the vulnerability triggering conditions are met, the corresponding vulnerability is determined to be valid, and the transaction sequence, execution path, and related status information that triggered the vulnerability are recorded, generating a vulnerability detection report.

[0154] The preferred embodiments of the present invention will be tested below to verify the technical advantages of the present invention.

[0155] In the experiment, for Dataset1, 10 minutes of testing time was allocated to each small contract, and 20 minutes to each large contract. For Dataset2 and Dataset3, 10 minutes and 20 minutes of testing time were set for each contract, respectively. The parameter α was set to 0.5, a value determined through experiments to effectively balance the weighting of dynamic and static distances in the seed scoring. The parameter β was also set to 0.5. This setting aims to avoid over-scoring due to excessively close distances interfering with the seed scoring mechanism, while achieving a dynamic balance between coverage and new path discovery through a targeted exploration strategy, helping to avoid local optima traps. The test environment consisted of a server with dual AMD EPYC 7763 CPUs (2.4GHz), 256GB of RAM, and an Ubuntu 20.04 LTS operating system. Solidity version solc-0.4.26 was used to compile the contracts.

[0156] like Figure 4As shown, the average branch coverage of DPFuzz, sFuzz, ConFuzzius, and IR-Fuzz on small and large smart contracts was compared and analyzed. Smartian's experimental report lacked branch coverage data and was therefore not included in the comparison. Overall, DPFuzz significantly outperformed the other three fuzzers in both small and large contracts, achieving 91.4% and 83.9% respectively. In contrast, IR-Fuzz, ConFuzzius, and sFuzz achieved coverage of 87.1%, 85.3%, and 68.3% on small contracts, respectively, while decreasing to 75.5%, 73.5%, and 59.5% on large contracts. It is foreseeable that as the contract size increases, the branch coverage of all tools decreases when handling large contracts; however, DPFuzz's performance decrease is only 7.5%, significantly lower than other fuzzers. Furthermore, in Figure 3 The text illustrates the branch coverage trends of four tools over different time periods. For small contracts, Figure 3 In the data, (a) shows that DPFuzz achieves 79% branch coverage within 10 seconds, which is approximately 24%, 11%, and 6% higher than sFuzz, ConFuzzius, and IR-Fuzz, respectively. It then stabilizes after about 60 seconds, eventually maintaining around 91.4%. For large contracts, Figure 3 In the results, (b) shows that DPFuzz achieved approximately 66% branch coverage in 10 seconds, while sFuzz, ConFuzzius, and IR-Fuzz only reached 28%, 57%, and 62%, respectively. Throughout the test, DPFuzz not only rapidly improved coverage in the early stages but also achieved a higher final stable coverage than other tools. Overall, DPFuzz outperforms existing mainstream blurrs on both small and large smart contracts, especially demonstrating higher exploration efficiency and lower performance degradation in large contract scenarios.

[0157] Table 1 is a list of datasets used in the tool experiments of the preferred embodiments of the present invention and a comparison of fuzz testing tools.

[0158] Table 1

[0159]

[0160] Table 2 is a comparison table of vulnerability detection performance between the tool of the preferred embodiment of the present invention and other fuzzing tools.

[0161] Table 2

[0162]

[0163] Table 2 shows the detection performance and operational reliability of each tool across different vulnerability categories in Dataset2. As can be seen from the table, DPFuzz demonstrates a significant advantage across all vulnerability categories. Specifically, DPFuzz detected 18 true positives in the SE category, while Slither, Mythril, and IR-Fuzz detected only 3, 1, and 12 true positives, respectively, indicating that conventional tools have significant limitations in identifying logical vulnerabilities such as strict monetary comparisons. For IO vulnerabilities, DPFuzz detected 60 true positives, 9 more than IR-Fuzz, thanks to its dynamic execution in the real Ethereum Virtual Machine environment, covering more complex execution paths. Overall, DPFuzz detected a total of 173 true positives across all vulnerability categories, approximately twice that of Mythril and 1.4 times that of IR-Fuzz, demonstrating its superior performance in multi-category vulnerability detection.

[0164] Regarding false negatives, DPFuzz produced significantly fewer false negatives than other tools in most categories. For example, in the UE category, DPFuzz produced only 4 false negatives, while Slither and Securify produced 27 and 13, respectively. This is mainly attributed to the inherent limitations of static tools in handling complex paths, their difficulty in capturing dynamically triggered vulnerabilities, and the inaccuracy of test oracles. Meanwhile, the fuzzing tools sFuzz and Smartian produced 20 and 11 false negatives in the UE category, possibly due to insufficient fuzzing capabilities for large contracts. Notably, DPFuzz did not produce any false negatives in the UD, RE, US, SE, and TO vulnerability categories, further validating its advantage in dynamic fuzzing.

[0165] Regarding false positives, DPFuzz produced almost no false positives. Its low false positive rate is attributed to its ability to accurately capture abnormal behavior during smart contract execution when running in a real Ethereum Virtual Machine environment, and to dynamically adjust the detection logic based on actual execution. A small number of potential false positives, after manual auditing, were found to mostly stem from imprecise definitions or anomaly assessments under specific boundary conditions.

[0166] In addition, Table 2 shows the timeouts and errors encountered by each tool during operation. Timeouts indicate that the analysis failed to complete within 10 minutes, while errors indicate that the tool encountered abnormalities or crashed during runtime. Mythril experienced 54 timeouts in large contracts, mainly due to inefficiency in handling complex contracts; Oyente and Securify encountered several errors due to version compatibility issues. DPFuzz, on the other hand, experienced almost no timeouts or runtime errors throughout the entire test, demonstrating its efficient and reliable analysis capabilities.

[0167] In summary, the results in Table 2 fully demonstrate that DPFuzz outperforms existing static analyzers and fuzzing tools in terms of true positive detection, false negative control, false alarm rate, and operational stability, showcasing its comprehensive advantages in smart contract vulnerability detection.

[0168] Figure 5 Figures (a) and (b) show the results of the ablation experiments, where each bar represents the percentage of achieved coverage or detected vulnerabilities compared to the results when all three components are enabled (i.e., the gray bars on the back). It is clear that the three core components have a significant impact on the overall performance of DPFuzz across contracts of different sizes. Quantitatively, without these three components, the achieved coverage decreased by 12%, 15%, and 9% for small contracts, and by 25%, 23%, and 19% for large contracts. Furthermore, it allowed DPFuzz to discover 11%, 14%, and 9% more vulnerabilities in small contracts, and 27%, 25%, and 20% more vulnerabilities in large contracts.

[0169] Reference Figure 1 A preferred embodiment of the present invention provides a smart contract fuzz testing system driven by branch priority and dynamic / static branch distance, used to execute the above method, including the following modules:

[0170] Initialization module: Used to compile and parse the target smart contract, generate intermediate representation (IR), including application binary interface (ABI), bytecode, and abstract syntax tree (AST); extract and analyze the data dependencies of state variables in the contract; and generate a control flow graph based on the parsing results of the target smart contract bytecode from the AST.

[0171] Code analysis module: Based on the control flow graph, extract the judgment conditions and dependent variables of each branch; dependent variables include storage variables, memory variables and operand stack elements, recording their state before the comparison instruction; evaluate each transaction branch based on the control flow graph, determine the nesting level of the conditions of the branch node, the length of the branch path, and the number of state variables involved in the branch, and mark the high-priority branch area;

[0172] Energy allocation module: Based on the branch priority results, it allocates initial test energy to the test seeds and prioritizes high-priority seeds to enter the fuzzy testing loop in subsequent steps;

[0173] Transaction sequence generation module: Based on the extracted state variable data dependencies and the constructed control flow graph, combined with the extracted branch judgment conditions and their dependent variable information, the module tracks the dependencies between transaction calls to generate an initial transaction sequence; at the same time, it uses the recorded state before the comparison instruction and the branch structure information such as the number of nested branch conditions, the length of the branch path, and the number of state variables to identify key state variables that affect the target branch conditions and construct test seeds with semantic relevance.

[0174] Seed mutation and optimization module: During the fuzzing loop, a dynamic and static branch distance measurement feedback engine is introduced; the structural distance of the target branch is obtained through static analysis, and combined with the dynamic difference of the runtime branch conditions, the proximity of the test case to the target branch is comprehensively evaluated; based on the evaluation results, the test seeds are dynamically scheduled and energy is allocated, high-priority branch regions are given priority, and the branch priority is adaptively adjusted.

[0175] Seed scheduling and vulnerability report generation module: It uses a genetic algorithm to select, cross over, and mutate the seed population, dynamically adjusts the branch priority, and uses the Ethereum Virtual Machine to perform tracing based on test oracles to detect vulnerabilities.

[0176] Other aspects of this embodiment can be found in the above method embodiments.

[0177] The above embodiments are used to explain the present invention and for the purpose of facilitating understanding, and are not intended to limit the present invention.

Claims

1. A smart contract fuzz testing method based on branch priority and dynamic / static branch distance, characterized by: The specific steps are as follows: S1. Initialization Phase: The target smart contract is compiled and parsed to generate an intermediate representation (IR), including the application binary interface (ABI), bytecode, and abstract syntax tree (AST); at the same time, the data dependencies of the state variables in the contract are extracted and analyzed. Then, based on the AST parsing results of the target smart contract bytecode, a control flow graph is generated; S2, Code Analysis Phase: Based on the control flow graph, extract the decision conditions and dependent variables of each branch; Dependency variables include storage variables, memory variables, and operand stack elements, recording their state before the comparison instruction; each transaction branch is evaluated based on the control flow graph, determining the nesting level of the conditions of the branch node, the length of the branch path, and the number of state variables involved in the branch, and marking high-priority branch regions; S3, Energy Allocation Phase: Based on the branch priority results, initial test energy is allocated to the test seed; S4, the fuzzing loop phase, includes: Transaction sequence generation: Based on the state variable data dependencies extracted in step S1 and the control flow graph constructed in step S1, combined with the branch judgment conditions and their dependent variable information extracted in step S2, the dependencies between transaction calls are tracked to generate an initial transaction sequence; at the same time, using the state before the comparison instruction recorded in step S2 and the branch structure information of the number of nested levels of branch conditions, the length of branch paths and the number of state variables obtained in step S2, the key state variables that affect the target branch conditions are identified, and a test seed with semantic relevance is constructed. Seed mutation and optimization: During the fuzzing test loop, a dynamic and static branch distance metric feedback engine is introduced; the structural distance of the target branch is obtained through static analysis, and combined with the dynamic difference of the runtime branch conditions, the proximity of the test case to the target branch is comprehensively evaluated; based on the evaluation results, the test seeds are dynamically scheduled and energy is allocated, high-priority branch regions are given priority, and the branch priority is adaptively adjusted. Seed scheduling and vulnerability report generation: Selecting, crossovering, and mutating seed populations, dynamically adjusting branch priorities, and using the Ethereum Virtual Machine to perform tracing based on test oracles to detect vulnerabilities.

2. The smart contract fuzz testing method based on branch priority and dynamic / static branch distance as described in claim 1, characterized in that, The specific steps of step S1 are as follows: S11. Input and parsing of the target contract: Input the target smart contract, compile the contract source code into three intermediate representations, namely bytecode, ABI and AST; extract and analyze the data dependencies of the state variables in the contract; S12. Control Flow Graph Construction: Based on the parsing results of the target smart contract bytecode by AST, generate its control flow graph, where nodes represent basic blocks and edges represent the control flow jump relationship between basic blocks.

3. The smart contract fuzz testing method based on branch priority and dynamic / static branch distance as described in claim 2, characterized in that, The specific steps of step S2 are as follows: S21. Branch Condition Extraction: Analyze the conditional jump instructions in the control flow graph and extract the judgment conditions and dependent variables of each branch; S22, Branch Evaluation: Evaluate each transaction branch based on the control flow graph, and determine the number of nested conditions of the branch node, the length of the branch path, and the number of state variables involved in the branch. S23, Branch Priority Calculation: Nested score calculation: By traversing the control flow path, the condition depth from the root node to the branch node is calculated. The nested score is represented as follows: Among them, Depth(B i ) represents branch B i The depth of condition nesting in control flow; Length score calculation: This measures the scale of the path involved in a branch by statistically analyzing the path length from the branch node to the next control transfer or function exit; let branch B... i The path length is L(B) i If the length score is: The state score calculation records all state operations related to memory word loading and memory word storage, and counts the number of unique state variables involved; the specific calculation is as follows: Among them, StateVar(B i ) represents branch B i The number of persistent state variables accessed in the data; S24. Marking high-priority areas: Based on the nesting score, length score, and status score of each transaction branch, sort all transaction branches by overall priority and mark the transaction branches with the highest overall scores as high-priority areas.

4. The smart contract fuzz testing method based on branch priority and dynamic / static branch distance as described in claim 3, characterized in that, The specific steps of step S3 are as follows: S31. Execute the test input on the Ethereum Virtual Machine and collect the corresponding execution paths. ; S32. Based on the execution path, identify the split points in the transaction execution process and extract the corresponding transaction branch B; S33, Nested score S for each transaction branch B nested Length score S length and state score S state The complexity score S of each transaction branch is calculated comprehensively. complexity ; S34. Detect whether there are transaction branches involving sensitive instructions, and mark the transaction branches that contain sensitive instructions and are reachable; S35. Assign an initial priority weight W to each transaction branch based on its complexity score, and give priority bonuses to transaction branches containing sensitive instructions. S36. In subsequent fuzzing cycles, the fuzzing resources are dynamically adjusted according to the priority weight of each transaction branch, so that high-priority transaction branches can obtain more fuzzing resources. S37. Dynamically and adaptively adjust the priority of transaction branches based on their coverage, and gradually reduce the priority of frequently covered transaction branches.

5. The smart contract fuzz testing method based on branch priority and dynamic / static branch distance as described in claim 4, characterized in that, In step S4, the specific steps of the transaction sequence generation process are as follows: S41.1 Based on the state variable data dependency relationship extracted in step S11 and the branch condition dependency variable information extracted in step S21, identify the key state variables that affect the target branch condition and their definition and usage relationship. S41.

2. Based on the dependencies of the key state variables, perform constraint analysis on the contract function calls to determine the set of candidate transactions that can modify the state variables; S41.3 Based on the dependency order of key state variables, sort and combine candidate transactions to construct a transaction sequence that satisfies the data dependency relationship of state variables and generate test seeds with semantic relevance. S41.4 Execute the generated transaction sequence as test input on the Ethereum Virtual Machine to drive the evolution of the contract state; During the execution of steps S41.1 to S41.4, branch coverage information, state change information, and runtime feedback are collected.

6. The smart contract fuzz testing method based on branch priority and dynamic / static branch distance as described in claim 5, characterized in that, In step S4, the specific steps of the seed mutation and optimization process are as follows: S42.1 Dynamic Distance Calculation: In fuzz testing, the generation of path conditions depends on the stack state and comparison operations before the critical jump instruction. Define S = {s0, s1, s2, ..., s...} i } represents the operand stack of the Ethereum Virtual Machine, where s i This represents the i-th element from the top of the stack downwards; Let transaction branch B be the target coverage branch of test case T; define the function distance(T,B) to measure the proximity between test case T and the target branch; the dynamic distance is defined as the average distance between test case T and n target branches B; S42.2 Static distance calculation: Suppose the control flow graph of the contract is a directed graph, where nodes represent basic blocks and edges represent control flow transitions between basic blocks; if the execution path of test case T passes through the set of basic blocks BB={bb1,bb2,bb3,…,bb…} i }, and the basic block where the target transaction branch is located is denoted as TB. Then the static distance of the test case T is defined as the average of the shortest path lengths between each basic block on the path and the target block TB. S42.3 Joint Dynamic and Static Distance Function: Define a joint dynamic and static distance function that considers both static and dynamic distance information.

7. The smart contract fuzz testing method based on branch priority and dynamic / static branch distance as described in claim 6, characterized in that, In step S4, the specific steps of seed scheduling and vulnerability report generation are as follows: S43.1 Test Seed Initialization: Construct initial test seeds. Each seed consists of a function selector, call data, and transaction-attached Ether. Each function initializes at least two test seeds. S43.2, Fitness-Based Seed Selection: Design a fitness index that integrates branch distance and branch coverage ability to evaluate seed quality; the fitness function of individual X is defined as follows: in, This is used to balance the weights between the branch distance feedback strategy and the traditional branch coverage strategy; let n be the number of target trading branches for the current individual X, dis(X) represents the distance of individual X from all target trading branch conditions, and cov(X) represents the number of covered trading branch edges; seeds with higher fitness have a higher probability of being selected in crossover and mutation operations, and P(X) represents the probability of individual X being selected, defined as X G ={X1,X2,X3,…,X i Let} be the set of all candidate individuals in population G, calculated using the formula shown below: S43.3 Seed Crossover and Mutation: The initial test seed consists of a single transaction, and a new transaction sequence is generated through crossover and mutation operations; S43.4, EVM Execution Tracking: The mutated test seed from step S43.3 is submitted as the transaction input to the Ethereum Virtual Machine for execution. The contract execution process is dynamically tracked by instrumentation in the EVM interpreter. The changes in the program counter, opcode execution order, operand stack, and stored variables are recorded in real time. The execution results of comparison instructions and conditional jump instructions are monitored. The operand values ​​and branch jump information involved in the branch conditions are obtained. At the same time, the branch edges and state changes covered by the transaction execution path are statistically analyzed. The recorded program counter, opcode execution order, operand stack, and stored variable changes are used to form the transaction execution trajectory. Combined with the branch coverage information, it is used for subsequent fitness calculation and test oracle judgment. S43.5 Test Oracles and Vulnerability Triggering: Based on runtime information and branch coverage results obtained from EVM execution tracing, predefined test oracles are used to detect the execution behavior of smart contracts. When the vulnerability triggering conditions are met, the corresponding vulnerability is determined to be established, and the transaction sequence, execution path and related status information that trigger the vulnerability are recorded, generating a vulnerability detection report.

8. A smart contract fuzz testing system driven by branch priority and dynamic / static branch distance, used to execute the method as described in any one of claims 1-7, characterized in that, Includes the following modules: Initialization module: Used to compile and parse the target smart contract, generating intermediate representation (IR), including application binary interface (ABI), bytecode, and abstract syntax tree (AST); Extract and analyze the data dependencies of state variables in the contract; Then, based on the AST parsing results of the target smart contract bytecode, a control flow graph is generated; Code analysis module: Based on the control flow graph, extract the decision conditions and dependent variables of each branch; Dependency variables include storage variables, memory variables, and operand stack elements, recording their state before the comparison instruction; each transaction branch is evaluated based on the control flow graph, determining the nesting level of the conditions of the branch node, the length of the branch path, and the number of state variables involved in the branch, and marking high-priority branch regions; Energy allocation module: Allocates initial test energy to test seeds based on branch priority results; Transaction sequence generation module: Based on the extracted state variable data dependencies and the constructed control flow graph, combined with the extracted branch judgment conditions and their dependent variable information, the module tracks the dependencies between transaction calls to generate an initial transaction sequence; at the same time, it uses the recorded state before the comparison instruction and the branch structure information such as the number of nested branch conditions, the length of the branch path, and the number of state variables to identify key state variables that affect the target branch conditions and construct test seeds with semantic relevance. Seed mutation and optimization module: Introduces a dynamic and static branch distance metric feedback engine during the fuzzing loop; The structural distance to the target branch is obtained through static analysis, and combined with the dynamic difference of the runtime branch conditions, the closeness between the test cases and the target branch is comprehensively evaluated. Based on the evaluation results, test seeds are dynamically scheduled and energy is allocated, with priority given to high-priority branch regions and branch priorities adjusted adaptively. Seed scheduling and vulnerability report generation module: Selects, crosses, and mutates seed populations, dynamically adjusts branch priorities, and uses the Ethereum Virtual Machine to perform tracing based on test oracles to detect vulnerabilities.

Images