Transaction sequence dependency vulnerability detection system and method based on function dependency analysis

Abstract

The invention discloses a TOD (Transaction Order Dependence) vulnerability detection system and a TOD vulnerability detection method based on functional dependency analysis, which are used for systematically identifying potential transaction order dependency vulnerabilities in a smart contract by combining key links such as functional dependency analysis, transaction sequence generation, sequence rearrangement and differential analysis. According to the method, the conflict function pair is constructed, the diversified to-be-detected sequences are generated based on the conflict function pair, and then the contract execution results are subjected to differential comparison in different sequences, so that potential safety hazards caused by sequence change are captured. According to the transaction sequence dependency vulnerability detection method, static analysis, fuzzy testing and differential analysis are combined, key function dependency information extracted through static analysis is used as guidance, and a more targeted test case is generated. And through a transaction sequence variation strategy, dependence on traditional mode matching is avoided, so that the accuracy and applicability of detection are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain smart contract security, and in particular to the detection and prevention of transaction order dependency (TOD) vulnerabilities in blockchain systems. It belongs to the category of blockchain network security and software vulnerability detection technologies, and specifically relates to a transaction order dependency vulnerability detection system and method based on function dependency analysis. Background Art

[0002] With the rapid development of blockchain technology, its application fields have been increasingly broadened, covering multiple key areas such as finance, supply chain management, Internet of Things, and healthcare. As one of the core technologies in blockchain, smart contracts allow automatic execution of transactions without intermediaries. When the preset conditions are met, the contract terms will be automatically executed, which significantly improves transaction efficiency and system reliability. However, while the immutability of smart contracts enhances their security, it also brings new security challenges. Among them, TOD vulnerabilities are a common and extremely destructive type of security risk. The harm of TOD vulnerabilities may not only lead to economic losses but also affect the credibility and stability of blockchain applications. In the context of decentralized applications, especially on the Ethereum platform, validators select transactions from the memory pool and package them in order, which may lead to uncertain changes in the contract state due to competition in the transaction order, thereby triggering transaction order dependency problems. Such problems usually manifest as race conditions or forward attacks, posing serious security risks to the blockchain platform. Currently, the detection methods for TOD vulnerabilities are mainly divided into static analysis and dynamic analysis. Static analysis detects vulnerabilities by analyzing the contract code structure, which can efficiently identify potential problems but lacks the simulation of runtime behavior and is prone to false positives; dynamic analysis detects vulnerabilities by simulating the contract execution process, which can more accurately capture interactive problems, but its test cases often have incomplete coverage and low efficiency. In addition, existing methods rely too much on predefined rules and oracle judgments, resulting in false positives and false negatives in complex attack scenarios. At present, static and dynamic analysis methods have not been effectively combined, and vulnerability determination relies too much on specific rules. Therefore, there is an urgent need for a more efficient and comprehensive detection method to improve the accuracy and efficiency of TOD vulnerability detection.

[0003] The Chinese invention patent CN202411348501.9 applied for by Sichuan University discloses a method for detecting vulnerabilities in smart contracts based on feedback information fuzz testing. The method includes: First, in the static analysis stage, the system parses the smart contract code, extracts the abstract syntax tree, control flow graph, and function list information, and calculates the order priority of function calls. Subsequently, in the seed pool and test transaction construction stage, the system initializes the seed pool and mutates the transaction sequence, collects feedback information by combining EVM instrumentation, and defines the determination methods for different vulnerability types. Finally, in the dynamic testing stage, the method introduces a formula for calculating the quality score of seed test cases, and based on the feedback information during the execution process, screens and mutates the seed test cases to improve the accuracy and efficiency of vulnerability detection. This invention optimizes the fuzz testing process by combining static analysis and dynamic feedback information, improves the coverage of smart contract vulnerability detection, and reduces the false positive rate. The Chinese invention patent CN202410090931.9 applied for by Yantai University discloses a method for detecting vulnerabilities in smart contracts based on the combination of static analysis and fuzz testing. The method first statically extracts the function call sequence based on key variables to guide the generation of test cases that conform to the transaction sequence. Then, through the cross transformation of the transaction sequence, mutation processing at the function level and transaction level, high-quality test cases are constructed. Finally, based on the test oracle, the mutant test cases are used to traverse the execution paths of the smart contract to obtain the vulnerability detection results. This method improves the diversity of test cases and reduces the risks of false positives and false negatives by screening based on coverage and constructing cross test cases on the basis of the initial test case set.

[0004] In the methods of the above disclosed patents, the former relies on feedback information to optimize the fuzz testing process to improve the efficiency and accuracy of vulnerability detection, but does not fully combine the in-depth understanding of function call relationships through static analysis; the latter extracts the critical path through static analysis and combines fuzz testing to generate high-quality test cases, but has weak adaptability to transaction mutation strategies and overly relies on the rule definition of the test oracle. Summary of the Invention

[0005] The object of the present invention is to address the problems existing in the prior art and provide a system and method for detecting transaction order dependency vulnerabilities based on function dependency analysis, to overcome the limitations of the prior art methods for detecting transaction order dependency vulnerabilities in smart contracts. By constructing the dependency relationship between contract functions and storage variables, identifying conflicting function pairs that may lead to transaction order dependency, and generating transaction call sequences based on these conflicting function pairs, and performing execution comparison under different transaction orders to detect possible transaction order dependency vulnerabilities.

[0006] To achieve the above object, the technical solution adopted by the present invention is: A transaction order dependency vulnerability detection system based on function dependency analysis, including a function dependency analysis module, which is used to parse the source code of the smart contract, automatically identify all public and external functions, and construct the access relationships of these functions to global state variables to identify potential conflicting function pairs; A transaction sequence generation module, which dynamically constructs transaction sequences based on the conflicting function pairs, and adopts a variety of mutation strategies to generate diverse sequences to be tested; A sequence rearrangement and difference analysis module, which verifies the consistency of the contract state by adjusting the transaction call order. If it is found that the global state is inconsistent due to the change in the call order, it is marked as a potential transaction order dependency vulnerability.

[0007] Furthermore, the function dependency analysis module parses the source code of the smart contract based on a preprocessing tool to generate an intermediate representation and a control flow model for identifying the conflicting function pairs involving the same state variable.

[0008] Furthermore, the mutation strategies at least include a parameter mutation strategy and a function call sequence mutation strategy. In the transaction sequence generation module, the initial test sequence adopts a high-risk path priority coverage strategy.

[0009] Furthermore, the sequence rearrangement and difference analysis module executes the sequence to be tested and the rearranged sequence under the same initial blockchain state, and records the changes in the global state. If there are differences in the final states of the two sequences, it is determined that there is a transaction order dependency vulnerability, and the detection result is output to a log file.

[0010] A transaction order dependency vulnerability detection method based on function dependency analysis, the detection method includes the following steps: Conduct function dependency analysis on the smart contract, extract the public functions and external functions in the smart contract, identify their read and write access relationships to global state variables, and extract all possible conflicting function pairs with write-write conflicts and read-write conflicts; Generate an initial transaction sequence around the conflicting function pairs obtained from the function dependency analysis and perform diverse mutations on the initial transaction sequence to construct rich transaction call scenarios to obtain the sequence to be tested; Rearrange the generated transaction sequence, focusing on the call methods of the conflicting function pairs in different orders to obtain a rearranged sequence. By executing the sequence to be tested and the rearranged sequence respectively under the same initial blockchain state, compare whether there are differences in the final contract state; If there are differences in the execution results of the transaction sequence, it is determined that the smart contract has potential vulnerabilities related to transaction order dependencies. The suspicious conflict function pairs, relevant state variables, and inconsistent transaction call scenarios are recorded in a log or report to assist developers in locating and fixing the issues.

[0011] Further, the method for function dependency analysis includes the following steps: Parse the source code of the smart contract and construct an intermediate representation; preprocess the smart contract based on a preprocessing tool to extract the contract structure, function list, and access patterns to global state variables, generating an intermediate representation and a control flow model; Based on the interprocedural control flow graph, trace cross-function calls, traverse each function call relationship, capture the read and write operation paths of storage variables inside common functions and external functions. During this process, if there is a function call chain, sequentially collect the access information to state variables along the function call chain and uniformly map it to a global dependency graph; Identify global state variable nodes and function operation nodes in the dependency graph; abstract each global state variable into a "storage variable node", and all functions that perform write or read operations on this storage variable node are regarded as "function nodes". Establish associations between the function nodes and the storage variable nodes through "write edges" and "data dependency edges" to show the read and write access relationships of functions to variables; Based on the dependency graph, extract conflict function pairs; if two functions operate on the same storage variable and at least one of them contains a write operation, it is recorded as a conflict function pair.

[0012] Further, a method for generating the transaction sequence is as follows: Generate an initial transaction sequence; based on the conflict function pairs, preferentially combine high-risk functions into a sequence to be tested. For other non-conflict functions, select them using a random index method and then fuse them with the high-risk functions to form a function call sequence; Parameter filling and mutation; for each function call in the transaction sequence, determine the parameter types and quantities according to the function signature, and adopt different filling and mutation strategies for different parameter types; Mutate the function call sequence; in addition to mutating the input parameters, also mutate the entire function call sequence itself, including at least replacing function calls, adding function calls, deleting function calls, and data splicing: Perform multiple rounds of iteration and coverage evaluation. Evaluate the currently generated transaction sequence based on coverage metrics. If it is found that the coverage is insufficient, continue to iteratively perform parameter filling and mutation, and mutate the function call sequence until the expected coverage level is reached or the test resources are exhausted.

[0013] Further, the method for transaction sequence rearrangement and differential analysis is as follows: Extract the original transaction sequence to be tested and identify the conflicting function pairs therein. Mark the call positions where the conflicting function pairs are located and record the corresponding initial order. Generate a rearranged sequence; for the conflicting function pairs, the system attempts to swap the order of the conflicting function pairs in the transaction sequence or adjust their execution order with adjacent function calls. Differential execution and result comparison: Create independent virtual execution environments for the original transaction sequence and the rearranged sequence respectively, and execute these two sequences under the same initial blockchain state. After execution, compare the final global state variable values of the smart contract. If there are differences, it indicates that the final state of the smart contract depends on the transaction order, and there may be potential transaction order dependency vulnerabilities. Record suspicious scenarios and vulnerability information: If inconsistent states are detected, output the rearranged sequence, the information of the suspicious conflicting function pairs, and the final state comparison result to the analysis report or log.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. Through the settings of the function dependency analysis module, the transaction sequence generation module, and the sequence rearrangement and differential analysis module, the transaction order dependency vulnerability detection system of the present invention can identify the conflicting function pairs that may cause transaction order dependency and detect potential transaction order dependency vulnerabilities. It can systematically and efficiently detect transaction order dependency vulnerabilities in smart contracts, improve the security of smart contracts, and reduce the risk of economic losses caused by the uncertainty of transaction order. 2. This method combines the function dependency analysis of static analysis and the transaction order comparison analysis of dynamic testing, and has a significant improvement in detection accuracy compared with the prior art. It can accurately locate high-risk function pairs based on static analysis and effectively discover transaction order dependency vulnerabilities through dynamic execution analysis, thereby improving the security of smart contracts. 3. The transaction order dependency vulnerability detection method of the present invention constructs conflicting function pairs and generates diverse sequences to be tested based on this, and then performs differential comparison on the contract execution results in different orders, so as to capture security risks caused by order changes. 4. This method avoids the dependence on traditional pattern matching through the transaction sequence mutation strategy, thereby improving the detection accuracy and applicability, increasing the detection coverage rate, and showing a lower false positive rate and a higher accuracy rate in practical applications. Brief Description of the Drawings

[0015] Figure 1 It is a schematic architecture diagram of the transaction order dependency vulnerability detection method based on function dependency analysis of the present invention; Figure 2 It is a schematic flow diagram of the function dependency analysis method designed by the present invention; Figure 3 It is a schematic flow diagram of the transaction sequence generation method designed by the present invention; Figure 4 This is a schematic flowchart of the transaction order rearrangement and differential analysis method proposed by the present invention. Specific embodiments

[0016] Next, the technical solutions of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention. Embodiment 1

[0017] A transaction order dependency vulnerability detection system based on function dependency analysis, comprising: A function dependency analysis module, which is used to parse the source code of the smart contract, automatically identify all public and external functions, build the access relationships of these functions to global state variables, and identify potential conflicting function pairs; A transaction sequence generation module, which dynamically constructs a transaction sequence based on the conflicting function pairs and adopts a variety of mutation strategies to generate diverse sequences to be tested; A sequence rearrangement and differential analysis module, which verifies the consistency of the contract state by adjusting the transaction call order. If it is found that the global state is inconsistent due to the change in the call order, it is marked as a potential transaction order dependency vulnerability.

[0018] Through the settings of the function dependency analysis module, the transaction sequence generation module, and the sequence rearrangement and differential analysis module, this transaction order dependency vulnerability detection system can identify conflicting function pairs that may lead to transaction order dependencies, detect potential transaction order dependency vulnerabilities; it can systematically and efficiently detect transaction order dependency vulnerabilities in smart contracts, improve the security of smart contracts, and reduce the risk of economic losses caused by the uncertainty of transaction order.

[0019] The function dependency analysis module uses static analysis technology to parse the source code of the smart contract and identify potential conflicting function pairs. The transaction sequence generation module takes the conflicting function pairs as the core and dynamically constructs a transaction sequence covering key scenarios to generate diverse sequences to be tested; this combination of function dependency analysis with static analysis and transaction order comparison analysis with dynamic testing has a significant improvement in detection accuracy compared with the prior art; the present invention can accurately locate high-risk function pairs based on static analysis and effectively discover transaction order dependency vulnerabilities through dynamic execution analysis, thereby improving the security of smart contracts.

[0020] Further, the function dependency analysis module parses the source code of the smart contract based on a preprocessing tool (SLITHER tool) to generate an intermediate representation (IR), a control flow model, and the read-write relationships of functions and variables, etc., for identifying the conflicting function pairs involving the same state variable.

[0021] Further, the mutation strategy at least includes a parameter mutation strategy and a function call sequence mutation strategy. In the transaction sequence generation module, the initial test sequence of the system adopts a high-risk path first coverage strategy, combined with a random parameter filling method, to ensure the diversity of the test sequence. For the mutation processing of the transaction sequence, the system supports various strategies such as parameter mutation (such as bit flipping, special value replacement), function call sequence mutation (such as call order adjustment, transaction insertion and deletion), etc., to expand the coverage of transaction scenarios.

[0022] Further, in the sequence rearrangement and difference analysis module, the system executes the test sequence and the rearranged sequence under the same initial blockchain state, and records the changes in the global state. If there are differences in the final states of the two sequences, it is determined that there is a transaction order dependency vulnerability, and the detection result is output to the log file. Embodiment 2

[0023] A method for detecting transaction order dependency vulnerabilities based on function dependency analysis, as Figure 1 shown, the detection method includes the following steps.

[0024] Step 1: Perform function dependency analysis on the smart contract, extract the public functions and external functions in the smart contract, identify their read-write access relationships to the global state variables, focus on the function combinations that operate on the same global state variable and contain at least one write operation, and extract all possible conflicting function pairs with write-write conflicts and read-write conflicts; Step 2: Generate an initial transaction sequence (such as an initial seed) around the conflicting function pairs obtained from the function dependency analysis and perform diverse mutations on the initial transaction sequence to obtain diverse test sequences; specifically, it includes preferential coverage of high-risk function pairs, multi-level random filling of parameters, and various mutation operations on the function call order and structure to construct rich transaction call scenarios; Step 3: Rearrange the generated transaction sequence, focus on the call methods of the conflicting function pairs in different orders to obtain a rearranged sequence, and compare whether the final contract state changes by executing the test sequence and the rearranged sequence respectively under the same initial blockchain state; If there are differences in the execution results of the transaction sequences, it is determined that the smart contract has potential transaction order dependency vulnerabilities, and the system records the suspicious conflicting function pairs, related state variables, and inconsistent transaction call scenarios in the log or report to assist developers in further positioning and fixing.

[0025] This method for detecting transaction order - dependent vulnerabilities systematically identifies potential transaction order - dependent vulnerabilities in smart contracts by combining key steps such as function - dependency analysis, transaction - sequence generation, and sequence rearrangement and differential analysis. Transaction order - dependent vulnerabilities usually stem from the writing or reading - writing conflicts of multiple functions to the same state variable. When the call order of external transactions changes, it may lead to inconsistent contract states. This invention generates diverse sequences to be tested by constructing conflict function pairs, and then conducts differential comparison of the contract execution results under different orders to capture security hazards caused by order changes.

[0026] This method for detecting transaction order - dependent vulnerabilities combines static analysis, fuzzing (dynamic) testing, and differential analysis. Guided by the key function - dependency information extracted by static analysis, it generates more targeted test cases. Through the transaction - sequence mutation strategy, it avoids the dependence on traditional pattern matching, thereby improving the accuracy and applicability of detection. Experiments show that this method can accurately identify transaction order - dependent vulnerabilities, improve the detection coverage rate, and show a low false - positive rate and a high accuracy rate in practical applications.

[0027] Furthermore, as Figure 2 shown, the method of function - dependency analysis includes the following steps: Step 101: Parse the source code of the smart contract and construct an intermediate representation; in this embodiment, the smart contract is pre - processed based on a pre - processing tool to extract the contract structure, function list, and access patterns to global state variables, generating an intermediate representation and a control - flow model.

[0028] Step 102: Trace cross - function calls based on the inter - procedural control - flow graph (ICFG); traverse each function call relationship, capture the read - write operation paths of public functions and external functions to storage variables. During this process, if there is a function - call chain, collect the access information to state variables along the function - call chain in sequence and map it uniformly to the global dependency graph.

[0029] Step 103: Identify global state - variable nodes and function - operation nodes in the dependency graph; abstract each global state variable as a "storage - variable node", and all functions that perform write or read operations on this storage - variable node are regarded as "function nodes"; in the dependency graph, establish an association between the function nodes and the storage - variable nodes through "write edges" and "data - dependency edges" to clearly show the read - write access relationship of functions to variables. If a statement modifies a storage variable, add a "write edge"; if a statement depends on the value of a variable, establish a "data - dependency edge"; if there is an order - dependent relationship between statements, represent it with an "order edge".

[0030] Step 104: Based on the dependency graph, extract conflicting function pairs; if two functions operate on the same storage variable and at least one of them contains a write operation, these two functions are recorded as a conflicting function pair.

[0031] Write-write conflict means that if two functions perform write operations on the same state variable and the order between these write operations cannot be guaranteed, it may lead to inconsistent states; read-write conflict means that when a function reads the value of the same state variable before another function completes the write operation, a read-write race occurs.

[0032] Among them, write-write conflicts often result in the later write operation overwriting the result of the previous write operation, while read-write conflicts are manifested as possibly reading the old value before the write operation is completed, thus causing logical confusion or state anomalies.

[0033] The method of function dependency analysis is used to systematically parse the source code of smart contracts, automatically identify the interaction relationships between contract functions and global state variables, thereby effectively discovering function pairs with write-write conflicts or read-write conflicts, and providing accurate high-risk scenario guidance for subsequent fuzz testing and sequential difference analysis.

[0034] Further, as Figure 3 shown, a method for generating the transaction sequence is as follows: Step 201: Initial transaction sequence generation; based on the conflicting function pairs output by the function dependency analysis, first combine these conflicting function pairs (high-risk functions) into a sequence to be tested to ensure coverage of sensitive scenarios; for other non-conflicting functions, use a random indexing method to select (map each function in the contract to an index), and then fuse them with high-risk functions to form a longer and more complex call sequence; considering the diversity in the contract call environment, environmental parameters such as different block timestamps, message sender addresses, and transaction values (value) can be introduced to ensure that the initial sequence is closer to the real deployment scenario.

[0035] Step 202: Parameter filling and mutation; for each function call in the transaction sequence, determine the parameter types and quantities according to the function signature; adopt different filling and mutation strategies for different parameter types such as integers, booleans, strings, byte arrays, dynamic arrays, etc. For example, for integer parameters, random numbers or special marker values (such as 0, maximum value, minimum value, etc.) can be randomly generated; for strings or byte arrays, the methods of random length, random content, or dictionary coverage are used; this diverse parameter filling mechanism can greatly improve the coverage depth of the contract execution path.

[0036] Step 203: Function call sequence mutation; in addition to mutating the input parameters, the entire function call sequence itself is mutated to simulate a wider range of call scenarios, including but not limited to replacing function calls, adding function calls, deleting function calls, and data splicing; replacing function calls: randomly select a call position within the sequence and replace the original function with another function of the same type (similar input and output formal parameters); adding function calls: insert new function calls at any position in the sequence to test scenarios with higher complexity; deleting function calls: delete some function calls in the sequence to examine whether different contract state behaviors will occur after the absence of certain calls; data splicing: extract partial parameters or call fragments from multiple existing test cases and splice them into a new transaction sequence.

[0037] Step 204: Multiple rounds of iteration and coverage evaluation; to further improve the effectiveness of the test sequence, the currently generated transaction sequence is evaluated based on coverage metrics (branch coverage, state variable coverage). If the coverage is found to be insufficient, operations such as parameter filling and mutation, and function call sequence mutation are iteratively executed until the expected coverage level is reached or the test resources are exhausted.

[0038] This transaction sequence generation method designs an efficient and diverse sequence construction and mutation strategy for function pairs in smart contracts that may have transaction order dependence vulnerabilities, in order to cover as many potential risk scenarios as possible. Through randomization and multi-dimensional mutation, it fully simulates the complex call behaviors of multi-party transactions in a real blockchain environment, laying a comprehensive test foundation for subsequent order rearrangement and differential analysis.

[0039] Furthermore, as Figure 4 shown, the method of transaction sequence rearrangement and differential analysis is as follows: Step 301: Extract the original transaction sequence to be tested and identify the conflicting function pairs therein. To focus on the impact brought by the order change, mark the call positions where the conflicting function pairs are located and record the corresponding initial order.

[0040] Step 302: Generate a rearranged sequence; first, for the conflicting function pairs, attempt to swap the order of the conflicting function pairs in the transaction sequence; then, to ensure the semantic consistency of the sequence after the operation, the corresponding parameter information (such as the length of a dynamic array, the index of a variable-byte parameter, etc.) needs to be updated simultaneously, so as to ensure that the function parameters correspond one-to-one with the call positions. It should be noted that the generated rearranged sequence needs to remain unchanged in other aspects (such as the total number of calls, random environment parameters, etc.) compared with the original transaction sequence to be tested (such as the sequence to be tested), so as to limit the impact as much as possible to the call order.

[0041] Step 303: Differential execution and result comparison; Create independent virtual execution environments for the original transaction sequence and the rearranged sequence respectively, and execute these two sequences under the same initial blockchain state. After the execution is completed, compare the final global state variable values of the smart contract. If there are differences, it indicates that the final state of the smart contract depends on the transaction order, and there is a potential vulnerability of transaction order dependence.

[0042] Step 304: Record suspicious scenarios and vulnerability information; If inconsistent states are detected, output the rearranged sequence, the information of suspicious conflict function pairs, and the final state comparison result to the analysis report or log, so that auditors or developers can quickly locate the cause of the problem; If multiple conflict function pairs all lead to inconsistent states, the frequency of conflicts, occurrence conditions, etc. can be further counted to provide a reference basis for repair and reinforcement.

[0043] Based on the foregoing generation of transaction sequences, this transaction sequence rearrangement and differential analysis method flexibly rearranges the call order of conflict function pairs, and detects whether there is a vulnerability of transaction order dependence by recording the final state of contract execution; If there are significant differences in the global variables or key outputs of the contract after rearrangement, it indicates that the contract may have a vulnerability of transaction order dependence.

[0044] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A transaction order dependency vulnerability detection system based on function dependency analysis, characterized in that It includes a function dependency analysis module which is used to parse the source code of the smart contract, automatically identify all public and external functions, construct the access relationships of these functions to global state variables, and identify potential conflicting function pairs; A transaction sequence generation module which, based on the conflicting function pairs, dynamically constructs transaction sequences and uses multiple mutation strategies to generate diverse sequences to be tested; A sequence rearrangement and differential analysis module which verifies the consistency of the contract state by adjusting the transaction call order. If it is found that the global state is inconsistent due to the change in the call order, it is marked as a potential transaction order dependency vulnerability.

2. The transaction order dependency vulnerability detection system based on function dependency analysis according to claim 1, characterized in that The function dependency analysis module parses the source code of the smart contract based on a preprocessing tool to generate an intermediate representation and a control flow model for identifying the conflicting function pairs involving the same state variable.

3. The transaction order dependency vulnerability detection system based on functional dependency analysis according to claim 1, characterized in that, The mutation strategies at least include a parameter mutation strategy and a function call sequence mutation strategy. In the transaction sequence generation module, the initial test sequence adopts a high-risk path first coverage strategy.

4. The transaction order dependency vulnerability detection system based on functional dependency analysis according to claim 1, characterized in that The sequence rearrangement and differential analysis module executes the sequence to be tested and the rearranged sequence under the same initial blockchain state and records the changes in the global state. If there are differences in the final states of the two sequences, it is determined that there is a transaction order dependency vulnerability, and the detection result is output to a log file.

5. A method for detecting transaction order dependence vulnerabilities based on function dependence analysis, characterized in that The detection method uses the transaction order dependency vulnerability detection system based on function dependency analysis as described in any one of claims 1 to 4. The detection method includes the following steps: Perform function dependency analysis on the smart contract, extract the public functions and external functions in the smart contract, identify their read-write access relationships to global state variables, and extract all possible conflicting function pairs with write-write conflicts and read-write conflicts; Generate an initial transaction sequence around the conflicting function pairs obtained from the function dependency analysis and perform diverse mutations on the initial transaction sequence to construct rich transaction call scenarios to obtain the sequences to be tested; Rearrange the generated transaction sequences, focusing on the call methods of the conflicting function pairs in different orders to obtain rearranged sequences. By executing the sequences to be tested and the rearranged sequences respectively under the same initial blockchain state, compare whether there are differences in the final contract states; If there are differences in the execution results of the transaction sequences, it is determined that the smart contract has a potential transaction order dependency vulnerability, and the suspicious conflicting function pairs, relevant state variables, and inconsistent transaction call scenarios are recorded in the log or report to assist developers in positioning and fixing.

6. The method for detecting transaction order dependency vulnerabilities based on function dependency analysis according to claim 5, characterized in that, The method of function dependency analysis includes the following steps: Parse the source code of the smart contract and construct an intermediate representation; perform preprocessing on the smart contract based on a preprocessing tool, extract the contract structure, function list, and access patterns to global state variables, and generate an intermediate representation and a control flow model; Trace cross-function calls based on the inter-procedural control flow graph, traverse each function call relationship, capture the read and write operation paths of stored variables inside common functions and external functions. During this process, if there is a function call chain, sequentially collect the access information of state variables along the function call chain and uniformly map it to the global dependency graph; Identify global state variable nodes and function operation nodes in the said dependency graph; abstract each global state variable into a "stored variable node", and all functions that perform write or read operations on this stored variable node are regarded as "function nodes". Establish an association between the function node and the stored variable node through "write edges" and "data dependency edges" to show the read and write access relationship of functions to variables; Based on the said dependency graph, extract conflicting function pairs; if two functions perform operations on the same stored variable and at least one write is included, it is recorded as a conflicting function pair.

7. The method for detecting transaction order dependency vulnerabilities based on functional dependency analysis according to claim 5, characterized in that A method for generating the said transaction sequence is as follows: Initial transaction sequence generation; based on the said conflicting function pairs, preferentially combine high-risk functions into the sequence to be tested. For other non-conflicting functions, select them using a random index method and then fuse them with high-risk functions to form a function call sequence; Parameter filling and mutation; for each function call in the transaction sequence, determine the parameter type and quantity according to the function signature, and adopt different filling and mutation strategies for different parameter types; Function call sequence mutation; in addition to mutating the input parameters, also mutate the complete function call sequence itself, including at least replacing function calls, adding function calls, deleting function calls, and data splicing: Multiple rounds of iteration and coverage evaluation, evaluate the currently generated transaction sequence based on the coverage metric. If it is found that the coverage is insufficient, continue to iteratively perform the operations of parameter filling and mutation, and function call sequence mutation until the expected coverage level is reached or the test resources are exhausted.

8. The method for detecting transaction order dependence vulnerabilities based on function dependence analysis according to claim 5, characterized in that, The method for rearranging and differential analysis of the said transaction sequence is as follows: Extract the original transaction sequence to be tested and identify the conflicting function pairs in it, mark the call positions where the conflicting function pairs are located, and record the corresponding initial order; Generate a rearranged sequence; for the said conflicting function pairs, the system attempts to exchange the order of the conflicting function pairs in the transaction sequence or adjust their execution order with adjacent function calls; Differential execution and result comparison; create independent virtual execution environments for the original transaction sequence and the rearranged sequence respectively, and execute these two sequences under the same initial blockchain state. After execution, compare the final global state variable values of the smart contract. If there are differences, it indicates that the final state of this smart contract depends on the transaction order and there is a potential vulnerability of transaction order dependence; Record suspicious scenarios and vulnerability information; If an inconsistent state is detected, output the rearranged sequence, the information of the suspicious conflicting function pairs, and the final state comparison result to the analysis report or log.

Images