Method for evaluating authenticity of intelligent contract transaction sequence dependence vulnerability variation generation result

Abstract

The invention provides a method for evaluating the authenticity of an intelligent contract transaction sequence dependence vulnerability variation generation result. The method comprises the following steps of: firstly, finding a function containing transfer in a contract and a function which can indirectly influence the transfer amount or the transfer object of the transfer; the function where the TOD vulnerability is located is found by locally executing a transaction sequence containing the two functions. And secondly, setting a global variable as a lock, and fixing the execution sequence of tFun and cFun by using an assertion mechanism of the smart contract to achieve the effect of repairing the transaction sequence dependency vulnerability. Thirdly, the repaired vulnerabilities are handed over to a variation tool for variation, and a varied vulnerability data set is obtained; and finally, calculating a Jaccard similarity coefficient between the varied vulnerability and the vulnerability of the original contract, and obtaining the authenticity of the varied vulnerability of the variation tool.

Description

Technical Field

[0001] This invention belongs to the field of information security, focusing on the security of smart contracts, and specifically applies to the scenario of evaluating the authenticity of results generated by transaction-ordering dependency (TOD) vulnerability mutation tools. The core idea is to repair a real-world TOD vulnerability contract and then mutate it using a mutation tool. The result is then compared with the original real contract's TOD vulnerability to determine whether the generated vulnerability truly simulates a real-world TOD vulnerability. By detecting the authenticity of the vulnerabilities generated by the TOD vulnerability mutation tool, reliable data support is provided for the evaluation and optimization of TOD vulnerability mutation tools. Background Technology

[0002] Smart contracts, as a key component of decentralized applications, control a large amount of digital assets, and their security has always been a major concern. The Time-of-Demand (TOD) vulnerability is one of the most frequent vulnerabilities in smart contracts, stemming from the uncertainty of transaction packaging and execution order in a blockchain environment: the order in which transactions are initiated does not necessarily represent the order of execution; the execution order is determined by miners, thus potentially leading to discrepancies between the initiation and execution orders. A participant in a smart contract transaction could become a malicious miner, manipulating the execution order of a transaction in the transaction pool to achieve a more favorable outcome for themselves, resulting in unfair execution results.

[0003] Currently, there are various tools available for detecting TOD vulnerabilities, but evaluation and testing tools require a large number of TOD vulnerabilities. Since manually creating TOD vulnerability datasets is time-consuming and labor-intensive, some mutation tools have emerged to automatically generate TOD vulnerabilities, providing sufficient datasets for evaluation and testing tools. Mutation refers to modifying parts of the contract code to introduce vulnerabilities into a previously vulnerability-free contract, achieving the effect of injecting vulnerabilities into the contract. However, the vulnerabilities generated by mutation cannot prove whether they are sufficiently similar to real contracts, i.e., whether they can simulate the effect of real-world vulnerabilities, rather than being a toy contract artificially created out of thin air to build a vulnerability dataset. Real-world contracts are far greater than toy contracts in terms of lines of code and logical complexity, and the detection performance of testing tools on toy contracts is significantly different from their performance on real contracts. Therefore, a method is needed to evaluate the realism of vulnerability datasets generated by TOD vulnerability mutation.

[0004] To address this issue, this invention proposes a method for evaluating the authenticity of mutation-generated results for smart contract transaction order dependency vulnerabilities. The method first identifies the function containing `transfer` and functions that indirectly affect the transfer amount or transfer object within the contract. The function containing the TOD vulnerability is located by locally executing a transaction sequence containing these two functions. Secondly, a global variable is set as a lock, and the assertion mechanism of the smart contract is used to fix the execution order of `tFun` and `cFun`, thus repairing the transaction order dependency vulnerability. Thirdly, the repaired vulnerability is passed to a mutation tool for mutation, resulting in a mutated vulnerability dataset. The Jaccard similarity coefficient, a measure of the similarity between two sets, is used as an indicator to quantify the authenticity of the mutation-generated results for transaction order dependency vulnerabilities. Finally, the Jaccard similarity coefficient between the mutated vulnerability and the original contract with the vulnerability is calculated to determine the authenticity of the mutated vulnerability generated by the mutation tool. Summary of the Invention

[0005] This invention comprises three main steps: TOD vulnerability location, TOD vulnerability remediation, and authenticity assessment of TOD vulnerability mutation results. First, the input contract is translated into a three-address code. Since the `transfer` function in the smart contract performs the function of transferring funds, static analysis of the three-address code identifies the function that internally calls the `transfer` function, denoted as `tFun`. The amount and object of the transfer statement in `tFun` are analyzed. If one or more of these parameters are global variables, all functions that modify this global variable are identified, denoted as `cFun`, forming a set `CFUN={cFun1,cFun2,…}`. Next, symbolic execution generates multiple transaction sequences containing `tFun` and `cFun`. The positions of `tFun` and `cFun` are swapped to generate multiple transaction sequences. The contract is deployed on the local private blockchain, and the transaction sequences are executed. The execution results of the original sequence and the swapped sequence are compared to see if they are equal, marking the `tFun` and `cFun` combinations with unequal results. Finally, global variables are used to restrict the execution order of the two functions. The first step is to initialize a global variable `gl` to 0. The second step is to add an assignment statement to `tFun` to set the value of `gl` to 1. The third step is to add an assertion statement to `cFun` to check if the value of `gl` is 1. If it is 1, the transaction is rolled back. This rolls back transactions where `cFun` occurs after the transfer in `tFun`, indirectly restricting `cFun` to occur before `tFun`, thus fixing the transaction order dependency vulnerability. Then, the fixed smart contract is given to a TOD vulnerability mutation tool for mutation. The mutation result is compared with the TOD vulnerability detected in the original contract. If the mutation location matches the locking location, it indicates that the mutation result can simulate a real-world TOD vulnerability. Finally, the Jaccard similarity coefficient between the mutation tool's mutated vulnerability and the original contract with the vulnerability is calculated. Specifically, this method includes the following steps:

[0006] 1) TOD Vulnerability Location: Take the target contract tc as input, and output a set of function pairs TM=MAP containing the TOD vulnerability.<tFun,CFUN> First, the input contract is converted into a three-address code. This three-address code is used to locate the function `tFun` that calls `transfer` within the contract. Next, the transfer amount `amount` and the receiving account `recipient` are extracted from `transfer`. The three-address code is used to analyze whether these are affected by global variables. All globally influential variables are stored in a set `G={g1,g2,…}`. It is then analyzed whether elements in `G` can be assigned values ​​by other functions. If other functions can assign values ​​to elements in `G`, this function is denoted as `cFun`, forming a set `CFUN_c={cFun1,cFun2,…}`. Then, symbolic execution techniques are used to generate multiple transaction sequences containing `tFun` and `cFun`, denoted as the original sequences. The execution order of `tFun` and `cFun` in the swapped transaction sequences is used to generate the swapped sequence. Each original sequence and swapped sequence constitute a transaction sequence control group. The main focus is on changes in the number of tokens within the contract and between different accounts. If different accounts have different token quantities due to different transaction orders, a TOD vulnerability is considered to have occurred. Therefore, by observing the control group for each transaction sequence, if there is a discrepancy between the original sequence result and the exchanged sequence result, it is considered that there is a TOD vulnerability in cFun and tFun. The cFun corresponding to each tFun is added to its respective CFUN, forming an element [tFun, CFUN] of the TM. After all tFuns have been processed, the TM is returned.

[0007] 2) TOD Vulnerability Remediation: The input is the set of function pairs TM containing the TOD vulnerability generated in the previous step, where TM = MAP<tFun,CFUN> The output consists of the fixed TOD vulnerability function pair set TMR and the fixed contract tcR, where TMR = MAP.<tFunR,CFUNR> First, an empty map is initialized to store the results TMR. Next, the elements in TM are traversed. For each element, a unique global variable `gl` is created and initialized to 0. Since the `cFun` function changes the amount or recipient of `transfer` in the `tFun` function, fixing the transaction order dependency vulnerability requires restricting operations that change the transaction amount or recipient to be completed before `transfer`, meaning all `cFun` operations must execute before `tFun`. Before entering any branch in the `tFun` function, an assignment statement is added, setting the previously created unique global variable `gl` to 1. The modified `tFun` is denoted as `tFunR`. Then, an assertion statement is added at the beginning of each `cFun` function to check `gl`. If `gl` is 0, the transaction can continue, indicating that the `tFun` function was not executed before `cFun`. If `gl` is 1, it indicates that the `tFun` function has been executed before `cFun`, the assertion statement takes effect, and the transaction is rolled back. Finally, the fixed `cFun` is added to `CFUNR`, and combined with `tFunR`, it is added to `TMP`. After all elements in TM have been processed, the output results are TMR and tcR, which is obtained by replacing all tFunR and cFun with tFun and cFun.

[0008] 3) Authenticity Assessment of TOD Vulnerability Mutation Results: Using the TMR and tcR generated in the previous step as input, the output is the Jaccard similarity coefficient between the original contract with the TOD vulnerability and the vulnerability mutated by the TOD vulnerability mutation tool. First, let A be the set of TOD vulnerabilities mutated by the mutation tool, and B be the set of TOD vulnerabilities in the original contract. Create three integer variables M1, M2, and M3, initialized to 0, with M1=A∩B, M2=AB, and M3=BA. The Jaccard similarity coefficient is calculated as JSC= |A∩B| / |A∪B|=M1 / (M1+M2+M3). Second, input the tcR into the mutation tool to obtain the mutation result tcM. Next, the elements in the TMR are traversed. For each cFun in CFUNR, the assertion statement written when fixing the vulnerability is found. If the assertion statement is mutated and broken in tcM, or if the gl assignment statement written when fixing the vulnerability in tFunR is mutated and broken in tcM, it is considered that the mutation tool has successfully mutated the real TOD vulnerability in the original contract, and the count of M1 is incremented by one. If the statement injected in the TMR is not broken in tcR, it is considered that the vulnerability has not been identified by the mutation tool, and the count of M3 is incremented by one. After all elements in all TMRs have been traversed, the remaining vulnerabilities mutated in tcR are considered to be vulnerabilities mutated autonomously by the mutation tool, and their count is assigned to M2. Finally, the Jaccard similarity coefficient JSC between the vulnerabilities mutated by the mutation tool and the vulnerabilities in the original contract is given as JSC = M1 / ​​(M1 + M2 + M3).

[0009] Furthermore, the specific steps of step 1) above are as follows:

[0010] Step 1)-1: Initial state;

[0011] Step 1)-2: Input the target contract tc;

[0012] Step 1)-3: Locate all functions tFun in tc that call transfer;

[0013] Step 1)-4: Iterate through each tFun;

[0014] Steps 1)-5: Through data flow analysis, find all global variables G that affect amount or recipient in tFun;

[0015] Step 1)-6: Check if G is empty. If it is empty, skip tFun and go to step 1)-4.

[0016] Step 1)-7: Iterate through each global variable g in G;

[0017] Step 1)-8: Locate the set of all functions in contract tc that can modify g, CFUN_c;

[0018] Step 1)-9: Check if CFUN_c is empty. If it is empty, skip tFun and go to Step 1)-4.

[0019] Step 1)-10: Iterate through each function cFun in CFUN_c;

[0020] Step 1)-11: Construct the initial transaction sequence set INIT_SEQ based on tFun and cFun. All transaction sequences in INIT_SEQ must contain the two functions tFun and cFun.

[0021] Step 1)-12: Swap the positions of the tFun and cFun functions in all transaction sequences in INIT_SEQ to obtain SWAP_SEQ;

[0022] Step 1)-13: Deploy the contract on the local private chain and execute INIT_SEQ and SWAP_SEQ to obtain the states init_state and swap_state;

[0023] Step 1)-14: Determine if init_state and swap_state are equal. If they are not equal, add cFun to the set CFUN. If they are equal, go to step 1)-10.

[0024] Step 1)-15: When the CFUN_c traversal is complete, add [tFun,CFUN] to the output set TM;

[0025] Step 1)-16: When all tFun functions in tc have been traversed, output the set of function pairs containing the TOD vulnerability, TM=MAP.<tFun,CFUN> ;

[0026] Step 1)-17: End state.

[0027] Furthermore, the specific steps of step 2) above are as follows:

[0028] Step 2)-1: Initial state;

[0029] Step 2)-2: Input the set of function pairs containing the TOD vulnerability TM=MAP<tFun,CFUN> ;

[0030] Steps 2)-3: Initialize an empty result set TMR = {};

[0031] Steps 2)-4: Copy the TC contract to generate the TCR contract as the repaired contract;

[0032] Step 2)-5: Iterate through each element [tFun, CFUN] in TM;

[0033] Step 2)-6: Iterate through each cFun in CFUN;

[0034] Step 2)-7: Create a unique global variable gl and initialize it to 0;

[0035] Step 2)-8: Add an assertion statement at the beginning of the cFun function to judge gl. Roll back the transaction when gl is 1.

[0036] Step 2)-9: Add the assignment statement gl = 1; at the beginning of the tFun function, and the modified function is tFunR;

[0037] Step 2)-10: Add the repaired cFun to CFUNR and replace the original cFun code segment in tcR with cFun;

[0038] Step 2)-11: When the CFUN traversal is finished, add [tFunR,CFUNR] to the output set TMR, and replace the original tFun code segment in tcR with tFunR;

[0039] Step 2)-12: When the TM traversal is complete, output the results TMR and tcR;

[0040] Step 2)-13: End state;

[0041] Furthermore, the specific steps of step 3) above are as follows:

[0042] Step 3)-1: Initial state;

[0043] Step 3)-2: Input tcR into the variant tool to be evaluated to obtain the output result tcM;

[0044] Step 3)-3: Initialize M1, M2, M3 = 0;

[0045] Steps 3)-4: Input the TMR result obtained in Step 2;

[0046] Steps 3)-5: Iterate through the elements [tFunR, CFUNR] in the TMR;

[0047] Steps 3)-6: Iterate through each cFun in CFUNR;

[0048] Step 3)-7: Check whether the gl assertion statement is broken in the function corresponding to tcM of cFun or whether the gl assignment statement is broken in the function corresponding to tcM of tFunR;

[0049] If any one of the conditions is met, it means that the mutation tool has successfully mutated the real TOD vulnerability in the original contract, the M1 quantity is incremented by one, and the vulnerability is marked in tcM.

[0050] If neither of the two conditions is met, it means that the vulnerability has not been discovered by the mutation tool, and the number of M3s is incremented by one.

[0051] Step 3)-8: After all elements in TMR have been traversed, check the number of remaining unmarked mutation vulnerabilities in tcM and assign it to M2;

[0052] Step 3)-9: Calculate the Jaccard similarity coefficient between the mutation tool's mutation vulnerability and the original contract with the vulnerability: JSC = M1 / ​​(M1 + M2 + M3).

[0053] Step 3)-10: Output the Jaccard similarity coefficient (JSC);

[0054] Step 3)-11: End state. Attached Figure Description

[0055] Figure 1 This is a flowchart illustrating an evaluation method for the authenticity of mutation generation results oriented towards smart contract transaction sequence dependency vulnerabilities, as implemented in this invention.

[0056] Figure 2 for Figure 1 A flowchart for locating the TOD vulnerability in China.

[0057] Figure 3 for Figure 1 A flowchart for fixing the TOD vulnerability in China.

[0058] Figure 4 for Figure 1 A flowchart for assessing the authenticity of the mutation results of the TOD vulnerability in China. Detailed Implementation

[0059] To better understand the technical content of this invention, specific embodiments are described below in conjunction with the accompanying drawings.

[0060] Figure 1 This is a flowchart illustrating an evaluation method for the authenticity of mutation generation results oriented towards smart contract transaction sequence dependency vulnerabilities, as implemented in this invention.

[0061] A method for evaluating the authenticity of mutation generation results posed by smart contract transaction sequence dependency vulnerabilities, characterized by comprising the following steps.

[0062] Step S1 takes the target contract tc as input and identifies all functions tFun containing transfer operations, denoted as TFUN. Iterate through the TFUN set, extracting the amount and recipient involved in the transfer operations within tFun. Identify the set of global variables G={g1,g2,…} that affect amount and recipient. Find the function cFun that modifies elements in G; all cFun corresponding to tFun form the set CFUN. Iterate through the CFUN set, using symbolic execution to generate the original sequence containing tFun and cFun, and obtain the swapped sequence by exchanging the order of tFun and cFun. Execute both sets of sequences and obtain the execution results. If the original sequence result differs from the swapped sequence result, it is considered that a TOD vulnerability exists in cFun and tFun. Add the cFun corresponding to tFun to its corresponding CFUN, forming an element [tFun,CFUN] of TM. Finally, after all iterations are completed, output the result TM.

[0063] S2 This step takes the set of function pairs TM containing the TOD vulnerability as input, and iterates through each...<tFun,CFUN> For each function pair [tFun, cFun] containing the TOD vulnerability, create a unique global variable gl and initialize it to 0. Add an assignment statement `gl = 1;` at the beginning of the tFun function, making the modified function tFunR. Add the repaired cFun to CFUNR and replace the original cFun code segment in tcR with cFun. When CFUN traversal ends, add [tFunR, CFUNR] to the output set TMR and replace the original tFun code segment in tcR with tFunR. When TM traversal ends, output the results TMR and tcR.

[0064] Step S3 takes TMR and tcR as input and initializes M1, M2, and M3 to 0. M1 represents the number of real vulnerabilities successfully identified by the tool, M2 represents the number of vulnerabilities autonomously mutated by the mutation tool, and M3 represents the number of real TOD vulnerabilities not mutated by the mutation tool. The quantities of M1, M2, and M3 are obtained by comparing the cFun and tFun components in tcR and TMR. The Jaccard similarity coefficient JSC is then calculated between the vulnerabilities mutated by the mutation tool and the vulnerabilities in the original contract: JSC = M1 / ​​(M1 + M2 + M3). Finally, the Jaccard similarity coefficient JSC is output.

[0065] Figure 2The flowchart for locating the TOD vulnerability is as follows: Taking the target contract `tc` as input, identify all functions `tFun` containing transfer operations, denoted as `TFUN`. Iterate through the `TFUN` set, extracting the `amount` and `recipient` involved in the `transfer` operation within `tFun`. Find the set of global variables `G={g1,g2,…}` that affect `amount` and `recipient`. Find the function `cFun` that modifies elements in `G`; all `cFun`s corresponding to `tFun` form the set `CFUN`. Iterate through the `CFUN` set, using symbolic execution to generate the original sequence containing `tFun` and `cFun`, and obtain the swapped sequence by exchanging the order of `tFun` and `cFun`. Execute both sets of sequences and obtain the execution results. If the results of the original sequence and the swapped sequence are inconsistent, it is considered that a TOD vulnerability exists in `cFun` and `tFun`. Add the `cFun` corresponding to `tFun` to its corresponding `CFUN`, forming an element [tFun,CFUN] of `TM`. Finally, after all iterations are completed, output the result `TM`. The specific steps are as follows:

[0066] Step 1: Initial state; Step 2: Input target contract tc; Step 3: Find all functions tFun in tc that call transfer; Step 4: Iterate through each tFun; Step 5: Through data flow analysis, find all global variables G that affect amount or recipient in tFun; Step 6: Check if G is empty. If empty, skip the tFun and go to step 4; Step 7: Iterate through each global variable g in G; Step 8: Find the set of functions CFUN_c in contract tc that can change g; Step 9: Check if CFUN_c is empty. If empty, skip the tFun and go to step 4; Step 10: Iterate through each function cFun in CFUN_c; Step 11: Based on tFun and cFun Construct an initial transaction sequence set INIT_SEQ, where all transaction sequences must contain the functions tFun and cFun; Step 12: Swap the positions of the tFun and cFun functions in all transaction sequences of INIT_SEQ to obtain SWAP_SEQ; Step 13: Deploy the contract on the local private chain and execute INIT_SEQ and SWAP_SEQ to obtain the states init_state and swap_state; Step 14: Determine if init_state and swap_state are equal. If they are not equal, add cFun to the set CFUN. If they are equal, proceed to step 10; Step 15: When CFUN_c has finished traversing, add [tFun, CFUN] to the output set TM; Step 16: When all tFun in tc has finished traversing, output the function pair set TM = MAP containing the TOD vulnerability.<tFun,CFUN> Step 17: End state.

[0067] Figure 3 A flowchart for fixing the TOD vulnerability. Taking the set of function pairs TM containing the TOD vulnerability as input, iterates through each...<tFun,CFUN> For each function pair [tFun, cFun] containing the TOD vulnerability, create a unique global variable gl and initialize it to 0. Add an assignment statement `gl = 1;` at the beginning of the tFun function, making the modified function tFunR. Add the repaired cFun to CFUNR and replace the original cFun code segment in tcR with cFun. When CFUN iteration ends, add [tFunR, CFUNR] to the output set TMR and replace the original tFun code segment in tcR with tFunR. When TM iteration ends, output the results TMR and tcR. The specific steps are as follows:

[0068] Step 1: Initial state; Step 2: Input the set of function pairs TM=MAP containing the TOD vulnerability.<tFun,CFUN> Step 3: Initialize an empty result set TMR = {}; Step 4: Copy the TC contract to generate the TCR contract as the repaired contract; Step 5: Iterate through each element [tFun, CFUN] in TM; Step 6: Iterate through each cFun in CFUN; Step 7: Create a unique global variable gl and initialize it to 0; Step 8: Add an assertion statement at the beginning of the cFun function to judge gl, and roll back the transaction when gl is 1; Step 9: Add an assignment statement gl = 1; at the beginning of the tFun function, and the modified function is tFunR; Step 10: Add the repaired cFun to CFUNR, and replace the original cFun code segment in tcR with cFun; Step 11: When the CFUN iteration ends, add [tFunR, CFUNR] to the output set TMR, and replace the original tFun code segment in tcR with tFunR; Step 12: When the TM iteration ends, output the results TMR and tcR; Step 13: End state;

[0069] Figure 4 This is a flowchart for evaluating the authenticity of TOD vulnerability mutation results. Using TMR and tcR as inputs, initialize M1, M2, and M3 = 0. M1 represents the number of real vulnerabilities successfully identified by the tool, M2 represents the number of vulnerabilities autonomously mutated by the mutation tool, and M3 represents the number of real TOD vulnerabilities not mutated by the mutation tool. By comparing the cFun and tFun components in tcR and TMR, the quantities of M1, M2, and M3 are obtained. The Jaccard similarity coefficient JSC = M1 / (M1+M2+M3) between the mutated vulnerabilities and the original contract with vulnerabilities is calculated. Finally, the Jaccard similarity coefficient JSC is output. The specific steps are as follows:

[0070] Step 1: Initial state; Step 2: Input TCR into the mutation tool to be evaluated to obtain the output result tcM; Step 3: Initialize M1, M2, M3 = 0; Step 4: Input the result TMR obtained in Step 2; Step 5: Traverse the elements [tFunR, CFUNR] in TMR; Step 6: Traverse each cFun in CFUNR; Step 7: Check cFun Check if the gl assertion statement is broken in the function corresponding to tcM or if the gl assignment statement is broken in the function corresponding to tFunR in tcM; if either condition is met, it means that the mutation tool has successfully mutated the real TOD vulnerability in the original contract, increment the count of M1 by one, and mark the vulnerability in tcM; if neither condition is met, it means that the vulnerability has not been mutated by the mutation tool, increment the count of M3 by one; Step 8: When all elements in TMR have been traversed, check the number of remaining unmarked mutated vulnerabilities in tcM and assign them to M2; Step 9: Calculate the Jaccard similarity coefficient JSC between the mutated vulnerability by the mutation tool and the vulnerability in the original contract = M1 / ​​(M1 + M2 + M3); Step 10: Output the Jaccard similarity coefficient JSC; Step 11: End state.

[0071] In summary, this invention addresses the problem that existing smart contract transaction order dependency vulnerability mutation tools cannot effectively verify the authenticity of the vulnerabilities they generate. It proposes a systematic method for authenticity assessment. By automatically repairing real-world TOD (Transaction Order Dependency) vulnerability contracts and then re-injecting the vulnerability using a mutation tool, the consistency of the structure and behavior of the mutated vulnerability with the original real vulnerability is compared, thus achieving a quantitative assessment of the authenticity of the mutated vulnerability. This provides direction for the development of smart contract transaction order dependency vulnerability mutation tools.

Claims

1. This invention comprises three main steps: TOD vulnerability location, TOD vulnerability remediation, and TOD vulnerability mutation result authenticity assessment. First, the input contract is translated into a three-address code. Since the transfer function in the smart contract performs the function of transferring funds, static analysis of the three-address code identifies the function that internally calls the transfer function, denoted as tFun. The amount and object of the transfer statement in tFun are analyzed. If one or more of these parameters are global variables, all functions that modify this global variable are identified, denoted as cFun, forming a set CFUN={cFun1,cFun2,…}. Next, symbolic execution is used to generate multiple transaction sequences containing tFun and cFun. The positions of tFun and cFun are swapped to generate multiple transaction sequences. The contract is deployed on the local private chain, and the transaction sequences are executed. The execution results of the original sequence and the swapped sequence are compared to see if they match. The method first marks the tFun and cFun combinations with unequal results. Then, it uses a global variable to restrict the execution order of the two functions. The first step is to initialize a global variable gl to 0. The second step is to add an assignment statement in tFun to set the value of gl to 1. The third step is to add an assertion statement in cFun to determine if the value of gl is 1. If it is 1, the transaction is rolled back. This allows the transaction where cFun occurs after the tFun transfer to be rolled back, indirectly restricting cFun to occur before tFun, thus fixing the transaction order dependency vulnerability. The fixed smart contract is then given to a TOD vulnerability mutation tool for mutation. The mutation result is compared with the TOD vulnerability detected in the original contract. If the mutation location matches the locking location, it indicates that the mutation result can simulate a real-world TOD vulnerability. Finally, the similarity coefficient between the mutation tool's mutation vulnerability and the original contract with the vulnerability is calculated. Specifically, this method includes the following steps: TOD vulnerability location: Taking the target contract tc as input, the output is a set of function pairs TM=MAP containing the TOD vulnerability.<tFun,CFUN> First, the input contract is converted into a three-address code. The three-address code is used to locate the function `tFun` that calls `transfer` within the contract. Next, the transfer amount `amount` and the receiving account `recipient` are extracted from `transfer`. The three-address code is used to analyze whether these are affected by global variables. All global variables that might be affected are stored in a set `G={g1,g2,…}`. It is then analyzed whether elements in `G` can be assigned values ​​by other functions. If other functions can assign values ​​to elements in `G`, this function is denoted as `cFun`, forming a set `CFUN_c={cFun1,cFun2,…}`. Finally, symbolic execution techniques are used to generate multiple transaction sequences containing `tFun` and `cFun`, denoted as the original... The initial sequence; the execution order of tFun and cFun in the exchange transaction sequence, the generated transaction sequence is denoted as the exchange sequence, and each original sequence and exchange sequence constitute a transaction sequence control group; the main focus is on the changes in the number of tokens within the contract and between different accounts. If the number of tokens in different accounts is different due to different transaction order, it is considered that a TOD vulnerability has occurred; therefore, each transaction sequence control group is observed. If there is an inconsistency between the original sequence result and the exchange sequence result, it is considered that a TOD vulnerability exists in cFun and tFun; the cFun corresponding to each tFun is added to its respective CFUN, forming an element [tFun, CFUN] of TM with tFun; after all tFun has been processed, TM is returned; 1) TOD Vulnerability Remediation: The input is the set of function pairs TM containing the TOD vulnerability generated in the previous step, where TM = MAP<tFun,CFUN> The output consists of the fixed TOD vulnerability function pair set TMR and the fixed contract tcR, where TMR = MAP.<tFunR,CFUNR> First, initialize an empty map to store the result TMR. Next, iterate through the elements in TM. For each element, create a unique global variable `gl` and initialize it to 0. Since the `cFun` function changes the amount or recipient of `transfer` in the `tFun` function, to fix the transaction order dependency vulnerability, it's necessary to restrict operations that change the transaction amount or recipient to be completed before `transfer`, meaning all `cFun` operations must be executed before `tFun`. Before entering any branch in the `tFun` function, add an assignment statement to set the previously created unique global variable `gl` to 1. The modified `tFun` is denoted as `tFunR`. Then, add an assertion statement at the beginning of each `cFun` function to check `gl`. If `gl` is 0, the transaction can continue, indicating that the `tFun` function was not executed before `cFun`. If `gl` is 1, it indicates that the `tFun` function was executed before `cFun`, the assertion statement takes effect, and the transaction is rolled back. Finally, add the fixed `cFun` to `CFUNR`, and combine it with `tFunR` to add it to `TMP`. After all elements in TM have been processed, the output results are TMR and tcR, which is obtained by replacing all tFunR and cFunR with tFun and cFun. 3) Authenticity Assessment of TOD Vulnerability Mutation Results: Using the TMR and tcR generated in the previous step as input, the output is the Jaccard similarity coefficient between the original contract with the TOD vulnerability and the vulnerability mutated by the TOD vulnerability mutation tool. First, let A be the set of TOD vulnerabilities mutated by the mutation tool, and B be the set of TOD vulnerabilities in the original contract. Create three integer variables M1, M2, and M3, initialized to 0, with M1 = A ∩ B, M2 = AB, and M3 = BA. The Jaccard similarity coefficient is calculated using the formula JSC = ... |A∩B| / |A∪B|=M1 / (M1+M2+M3); Next, input tcR into the mutation tool to obtain the mutation result tcM; then, traverse the elements in TMR, for each cFun in CFUNR, find the assertion statement written when fixing the vulnerability. If the assertion statement is mutated and broken in tcM or the gl assignment statement written when fixing the vulnerability in tFunR is mutated and broken in tcM, it is considered that the mutation tool has successfully mutated the real TOD vulnerability in the original contract, and the number of M1 is incremented by one; If the injected statement in the TMR is not corrupted in the TCR, it is considered that the vulnerability has not been identified by the mutation tool, and the number of M3 is incremented by one; after all elements in all TMRs have been traversed, the remaining vulnerabilities mutated in the TCR are considered to be vulnerabilities mutated autonomously by the mutation tool, and their number is assigned to M2; finally, the Jaccard similarity coefficient JSC = M1 / ​​(M1 + M2 + M3) between the mutation tool's mutated vulnerabilities and the original contract with vulnerabilities is given.

2. The method for locating transaction sequence dependency vulnerabilities according to claim 1, characterized in that, In step 1), taking the target contract tc as input, identify all functions tFun that contain transfer operations, and denote the set as TFUN; traverse the TFUN set and extract the amount and recipient involved in transfer in tFun; find the set of global variables G={g1,g2,…} that affect amount and recipient; find the function cFun that changes the elements in G, and all cFun corresponding to tFun constitute the set CFUN; traverse the CFUN set, use symbolic execution technology to generate the original sequence containing tFun and cFun, and obtain the swapped sequence by swapping the order of tFun and cFun; execute the two sets of sequences respectively and obtain the execution results. If there is a discrepancy between the original sequence result and the swapped sequence result, it is considered that there is a TOD vulnerability in cFun and tFun; Add the cFun corresponding to tFun to its CFUN, forming an element [tFun, CFUN] of TM with tFun; finally, output the result TM after all traversals are completed.

3. The method for fixing transaction order dependency vulnerabilities according to claim 1, characterized in that, In step 2), taking the set of function pairs TM containing the TOD vulnerability as input, iterates through each...<tFun,CFUN> For each function pair [tFun, cFun] containing the TOD vulnerability, create a unique global variable gl and initialize it to 0. Add an assignment statement gl = 1; at the beginning of the tFun function, and the modified function is tFunR. Add the repaired cFun to CFUNR and replace the original cFun code segment in tcR with cFun. When the CFUN traversal ends, add [tFunR, CFUNR] to the output set TMR and replace the original tFun code segment in tcR with tFunR. When the TM traversal ends, output the results TMR and tcR.

4. The method for analyzing variation test results according to claim 1, characterized in that, In step 3), with TMR and tcR as input, initialize M1, M2, M3 = 0; M1 represents the number of real vulnerabilities successfully identified by the tool, M2 represents the number of vulnerabilities autonomously mutated by the mutation tool, and M3 represents the number of real TOD vulnerabilities that the mutation tool did not mutate; by comparing the cFun and tFun parts in tcR and TMR, obtain the respective quantities of M1, M2, and M3, calculate the Jaccard similarity coefficient JSC = M1 / ​​(M1 + M2 + M3) between the vulnerabilities mutated by the mutation tool and the vulnerabilities in the original contract; finally, output the Jaccard similarity coefficient JSC.

Images