A Flaky Repair and Verification Method for Smart Contracts with Root Cause Targeting Transaction Sequence Dependencies

Abstract

The application provides a smart contract Flaky repair and verification method for transaction order-dependent root cause. First, through static data dependency analysis, the Root Cause closely related to the shared contract state variable setter function is accurately identified. Then, taking the setter function as the target, a protection statement, i.e. a lock, is embedded in the setter function to ensure that the contract performs state checking before modifying the state variable. Finally, the modified contract is taken as the test object, the statements with write operations on the state variable are taken as the key nodes, and the execution paths containing these nodes are defined as the key paths. Taking these key paths as the test target, we perform repeated testing to observe the performance of the contract under different states, thereby verifying the effectiveness of the repair patch. The purpose of the application is to improve the reliability of the smart contract, enhance the stability of the test results, optimize the development process, and promote the healthy development of the blockchain technology, and ensure the safety of the smart contract.

Description

Technical Field

[0001] This invention belongs to the field of smart contract testing in software testing, and is particularly applicable to the field of stability testing in smart contract testing. Its purpose is to enhance the stability of test results, improve the reliability of smart contracts, thereby optimizing the development process of smart contracts and promoting the healthy development of blockchain technology. Background Technology

[0002] Against the backdrop of rapid development in blockchain technology, smart contracts, with their automatic execution and self-verification features, have become crucial for decentralized applications. However, with the widespread deployment of smart contracts, ensuring their code quality and reliability has become paramount. The frequent occurrence of the Flaky phenomenon during smart contract testing poses a significant challenge to developers. The Flaky phenomenon refers to inconsistent test results produced by the same code version in different testing environments, i.e., a Flaky test. The Flaky phenomenon not only reduces the credibility of test results but also severely impacts testing efficiency. More seriously, the failure of a Flaky test can mislead developers, causing them to debug code unrelated to the actual problem. Therefore, to enhance the stability of test results, improve the reliability of smart contracts, optimize the smart contract development process, and promote the healthy development of blockchain technology, addressing the root cause of Flaky tests in smart contracts is of utmost importance.

[0003] Unlike traditional software, smart contracts run on a blockchain, and their behavior is influenced by the blockchain's state. In a decentralized distributed ledger system, the blockchain maintains consistency across nodes for transaction-driven states such as account balances and smart contract states through a consensus mechanism. However, during the consensus process, factors such as gas mechanisms and network propagation speed can cause discrepancies between the order initiation and actual execution of transactions. This results in the blockchain's state change process and final state being undetermined under the same transaction sequence. This uncertainty leads to the emergence of Flaky Tests for smart contracts, where the test execution of a smart contract depends on an uncertain transaction order.

[0004] To effectively address this issue, this paper proposes a Flaky repair and verification method for smart contracts that rely on a root cause for transaction order dependence. For each contract state variable, a set of setter functions sharing that variable is identified, and protective statements are added to them to achieve Flaky repair for smart contracts that rely on a root cause for transaction order dependence. These protective statements are called locks. Based on this, a transaction sequence is constructed using setter functions. The repair result for the root cause dependence is verified by observing the changes in the contract's state variable values ​​under the same transaction sequence after the addition of protective statements.

[0005] Specifically, this paper's method first identifies Flaky Test Root Causes caused by transaction order dependencies through static data dependency analysis. These causes are typically closely related to setter functions of shared contract state variables, making setter functions the key entry points for modifying state variables. Next, targeting these setter functions, a protective statement, i.e., a lock, is embedded within them to ensure the contract performs state checks before modifying state variables. Finally, the modified contract is used as the test object, marking statements affected by state variables as critical nodes, and defining the execution paths containing these nodes as critical paths. By using critical paths as test targets and repeatedly executing tests, the changes in the contract's output under different state variables can be observed, thereby verifying the effectiveness of the repaired contract. Summary of the Invention

[0006] This invention provides a Flaky repair and verification method for smart contracts that rely on Root Cause for transaction order dependence. This method effectively solves the problems of unstable test results and unreliable smart contracts caused by Flaky Test, thereby avoiding the misleading influence of Flaky Test on developers, optimizing the smart contract development process, and promoting the healthy development of blockchain technology.

[0007] To achieve the above objectives, this method first identifies Flaky Test Root Causes caused by transaction order dependencies through static data dependency analysis. These causes are typically closely related to setter functions of shared contract state variables, making setter functions the key entry point for modifying state variables. Next, targeting these setter functions, a protective statement (i.e., a lock) is embedded within them to ensure the contract performs state checks before modifying state variables. Finally, the modified contract is used as the test object, with paths containing the embedded protective statement in the setter functions as test generation targets. The tests are repeatedly executed to observe changes in the contract's output under different state variables, thus verifying the effectiveness of the repaired contract. Finally, the repaired smart contract `repairedScut` and the verification results are output. Specifically, this method includes the following steps.

[0008] 1) Transaction order is determined by the Root Cause. Given a contract scut to be tested, analyze and obtain a dictionary map_settecr_stmts containing the set of statements (stmts) that have write operations on state variables in the public function setter of the contract scut. First, initialize map_settecr_stmts to empty, and then generate the abstract syntax tree (AST) of the contract scut to be tested. scut Then from AST scut Extract the common function set ListShare_Setters. Then construct the data dependency graph dfg of the state variables of the contract under test scut. scut dfg scut This indicates the definition and usage of state variables in the contract statements. Next, it iterates through each public function `Setter` in `ListShare_Setters`, using data flow analysis to identify the set of statements `stmts` that have write operations on state variables. It then checks if `stmts` is empty; if not, it sets the state variable to `stmts`.<setter,stmts> Add it to map_state_setters; otherwise, continue iterating through the ListShare_Setters collection until it is empty. Finally, output map_setter_stmts.

[0009] 2) Smart Contract Repair. Given a target contract `targetScut` and its dictionary `map_settecr_stmts`, repair the contract without altering the semantics of `targetScut`, obtaining the repaired contract `repairedScut`. First, find the specific location of the public function `Setter` by iterating through the keys in `map_settecr_stmts`. SetterThen, locate the stmts corresponding to the setter function, analyze the stmts to obtain the set of state variables, states, that are affected by the setter. Next, add an additional parameter, lock, to each state in the setter parameters. state The protective lock state It has the same type as the state variable (state). Iterate through each statement (stmt) in the stmts to find the specific location (location) within the stmt. stmt Add a guardStmt statement to stmt to ensure that the current value of the state variable corresponds to the expected value passed by the caller, and finally output the repaired contract repairedScut.

[0010] 3) Smart contract test generation for the critical path. Given the repaired contract `repairedScut` and its dictionary `map_settecr_stmts`, a test case set `tests` is generated. Test cases containing different transaction orders are generated to cover the modified statements. First, the control flow graph `cfg` of `repairedScut` is constructed. repairedScut cfg repairedScut This illustrates the control flow transfer relationships between the various statements within the contract. Then, in cfg... repairedScut Find the nodes containing `stmts`, and define the paths containing these nodes and with branches as critical paths. Then, use the critical paths as the test generation targets and use fuzzing to generate a test case set `tests`.

[0011] 4) Smart Contract Flaky Test Root Cause Repair Result Verification. Given a repaired contract `repairedScut` and a test case set `tests`, test and verify the repaired contract `repairedScut`. Repeatedly execute the test case set `tests` until a preset number of times `L` is reached. For each test case, observe the output changes of the contract `repairedScut` under different state variables and record the output result of the current execution. i and the output result of the next execution. j Compare results i and result j Check for consistency. If the test case consistently yields consistent results across multiple runs, the Flaky Test can be considered successfully fixed. Finally, output the fixed contract `repairedScut`.

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

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

[0014] Step 1)-2: Input the contract to be tested, scut;

[0015] Steps 1)-3: Initialize map_settecr_stmts to empty;

[0016] Steps 1)-4: Generate the Abstract Syntax Tree (AST) of the contract to be tested (scut). scut ;

[0017] Steps 1)-5: From AST scut Extract the common function collection ListShare_Setters;

[0018] Steps 1)-6: Construct the data dependency graph (dfg) of the state variables of the contract under test (scut). scut ;

[0019] Steps 1)-7: Iterate through each public function Setter in ListShare_Setters;

[0020] Steps 1)-8: Identify the set of statements (stmts) that have write operations on state variables based on data flow analysis;

[0021] Step 1)-9: Check if stms is empty. If not, proceed to the next step. If it is, proceed to step 1)-12.

[0022] Step 1)-10: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require the full context.]<setter,stmts> Add to map_state_setters;

[0023] Step 1)-11: Determine if the public function collection ListShare_Setters has been completely traversed. If yes, proceed to the next step; otherwise, return to Step 1)-7.

[0024] Steps 1)-12: Output map_setter_stmts;

[0025] Step 1)-13: End state.

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

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

[0028] Step 2)-2: Input the target contract targetScut and the dictionary map_settecr_stmts of the target contract;

[0029] Steps 2)-3: Iterate through the keys in map_settecr_stmts to find the specific location of the public function Setter. Setter ;

[0030] Steps 2)-4: Locate the stmts corresponding to the setter function;

[0031] Steps 2)-5: Analyze stmts to obtain the set of state variables, states, affected by the Setter;

[0032] Steps 2)-6: Based on location Setter In the setter function, add an additional parameter, namely the lock, for each state variable. state ;

[0033] Steps 2)-7: Iterate through each statement in the stmts file and find the specific location of the stmt. stmt ;

[0034] Steps 2)-8: Based on location stmt Add a guardStmt statement to stmt;

[0035] Step 2)-9: Determine if the stmts has been completely traversed. If so, proceed to the next step; otherwise, return to Step 2)-7.

[0036] Step 2)-10: Determine if map_settecr_stmts has been completely traversed. If so, proceed to the next step; otherwise, return to Step 2)-3.

[0037] Step 2)-11: Output the repaired contract (repairedScut);

[0038] Step 2)-12: End state.

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

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

[0041] Step 3)-2: Input the repaired contract repairedScut, and the set of statements stmts corresponding to each setter function;

[0042] Step 3)-3: Construct the control flow graph (cfg) of repairedScut repairedScut ;

[0043] Steps 3)-4: Traverse cfg repairedScut The nodes in the text;

[0044] Steps 3)-5: In cfg repairedScut Find the nodes containing stmts;

[0045] Steps 3)-6: Define the paths containing these nodes and with branches as critical paths;

[0046] Steps 3)-7: Determine cfg repairedScut If the traversal has ended, proceed to the next step; otherwise, return to steps 3)-4.

[0047] Steps 3)-8: Use critical paths as the test generation target and fuzz testing to generate test case sets (tests);

[0048] Step 3)-9: Output tests;

[0049] Step 3)-10: End state.

[0050] Furthermore, the specific steps of step 4) above are as follows:

[0051] Step 4)-1: Initial state;

[0052] Step 4)-2: Given the repaired contract repairedScut and the test case set tests;

[0053] Step 4)-3: Repeat the test case set tests 10 to 100 times;

[0054] Step 4)-4: Record the output result of the current execution. i and the output result of the next execution. j ;

[0055] Steps 4)-5: Determine the result i and result j If they are consistent, proceed to the next step; if they are consistent, proceed to steps 4)-7.

[0056] Steps 4)-6: Print the error message that the contract has not been repaired;

[0057] Steps 4)-7: Output the repaired contract repairedScut;

[0058] Step 4)-8: End state. Attached Figure Description

[0059] Figure 1This is a flowchart illustrating a method for repairing and verifying Flaky smart contracts that rely on Root Causes for transaction order dependencies, as implemented in this invention.

[0060] Figure 2 for Figure 1 A flowchart illustrating how the transaction order depends on the identification of the Root Cause.

[0061] Figure 3 for Figure 1 A flowchart for smart contract repair in China.

[0062] Figure 4 for Figure 1 A flowchart for generating smart contract tests oriented towards the critical path.

[0063] Figure 5 for Figure 1 A flowchart for verifying the Flaky Test Root Cause repair results of a smart contract. Detailed Implementation

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

[0065] Figure 1 This is a flowchart illustrating a method for repairing and verifying Flaky smart contracts that rely on Root Causes for transaction order dependencies, as implemented in this invention.

[0066] A method for Flaky repair and verification of smart contracts with transaction order dependency root cause is characterized by the following steps.

[0067] S1 Transaction Order Dependency Root Cause Identification: This step identifies Flaky Test Root Causes caused by transaction order dependencies through static data dependency analysis. These causes are usually closely related to the setter functions of shared contract state variables, so the setter functions are the key entry points for modifying state variables.

[0068] S2 smart contract repair involves adding protective statements to the contract without altering its original functionality. These statements verify that state variables meet expectations. These protective statements, called locks, ensure that the contract must pass lock verification before continuing execution, preventing Flaky Tests due to transaction order dependencies.

[0069] S3 focuses on generating smart contract tests for critical paths. This step uses the modified contract as the test object, marks the code segments affected by state variables as critical nodes, and defines the execution paths containing these nodes as critical paths. By using the critical paths as the test generation targets, fuzzing is used to generate a test case set `tests`.

[0070] The S4 smart contract Flaky Test Root Cause Repair Result Verification step involves repeatedly executing the generated test case set (tests) to observe the changes in the contract's output under different state variables. The test case set output is evaluated based on consistent results across multiple runs, matching the expected outcome. Finally, the repaired contract (repairedScut) and verification results are output.

[0071] Figure 2 The flowchart illustrates the identification of Root Causes for transaction order dependencies. For the contract under test, static data dependency analysis identifies Flaky Test Root Causes caused by transaction order dependencies. These causes are typically closely related to setter functions of shared contract state variables, which are key entry points for modifying these state variables. The specific steps are as follows:

[0072] Step 1: Initial state; Step 2: Given the contract under test (scut), analyze and obtain the dictionary map_settecr_stmts containing the set of statements (stmts) that have write operations on state variables in the public function Setter of the contract under test; Step 3: Initialize map_settecr_stmts to empty; Step 4: Generate the abstract syntax tree (AST) of the contract under test (scut). scut Step 5: From AST scut Extract the common function set ListShare_Setters; Step 6: Construct the data dependency graph dfg of the state variables of the contract under test scut. scut Step 7: Iterate through each public function `Setter` in `ListShare_Setters`; Step 8: Identify the set of statements `stmts` that have write operations on the state variables based on data flow analysis; Step 9: Check if `stms` is empty. If not, proceed to the next step; otherwise, proceed to step 12; Step 10: ...<setter,stmts> Add to map_state_setters; Step 11: Check if the public function collection ListShare_Setters has been traversed. If yes, proceed to the next step; otherwise, return to step 7; Step 2: Output map_setter_stmts; Step 13: End status.

[0073] Figure 3The flowchart for smart contract repair is as follows. For the target contract `targetScut`, without changing the original functionality, protective statements are added to the contract to verify whether the state variables meet expectations. These protective statements are called locks, and they ensure that the contract must pass lock verification before continuing execution, preventing Flaky Tests due to transaction order dependencies. The specific steps are as follows:

[0074] Step 1: Initial state; Step 2: Given the target contract `targetScut` and its dictionary `map_settecr_stmts`; Step 3: Iterate through the keys in `map_settecr_stmts` to find the specific location of the public function `Setter`. Setter Step 4: Locate the stmts corresponding to the setter function; Step 5: Analyze the stmts to obtain the set of state variables (states) affected by the setter; Step 6: Based on the location... Setter In the setter function, add an additional parameter, namely the lock, for each state variable. state Step 7: Iterate through each statement in the stmts file and find the specific location of the stmt. stmt Step 8: Based on location stmt Add a guardStmt statement to stmt; Step 9: Check if stmts has been traversed. If yes, proceed to the next step; otherwise, return to step 7; Step 10: Check if map_settecr_stmts has been traversed. If yes, proceed to the next step; otherwise, return to step 3; Step 11: Output the repaired contract repairedScut; Step 12: End status.

[0075] Figure 4 This is a flowchart for generating smart contract tests oriented towards critical paths. The modified contract (repairedScut) is used as the test object. Code segments affected by state variables are marked as critical nodes, and execution paths containing these nodes are defined as critical paths. By using the critical path as the test generation target, fuzzing is used to generate a test case set (tests). The specific steps are as follows:

[0076] Step 1: Initial state; Step 2: Given the repaired contract `repairedScut` and the statement set `stmts` for each setter function; Step 3: Construct the control flow graph `cfg` of `repairedScut`. repairedScut Step 4: Traverse cfg repairedScut Nodes in cfg; Step 5: In cfg repairedScutStep 6: Find the nodes containing stmts; Step 7: Define the paths containing these nodes and with branches as critical paths; Step 8: Determine the cfg... repairedScut Is the traversal complete? If yes, proceed to the next step; otherwise, return to step 4. Step 8: Use the critical paths as the test generation target and generate a test case set (tests) using fuzz testing. Step 9: Output the test cases. Step 10: End status.

[0077] Figure 5 This is a flowchart for verifying the Flaky Test Root Cause repair results of a smart contract. The generated test case set `tests` is executed repeatedly to observe the changes in the contract's output under different state variables. The output results are analyzed; if the test cases consistently produce consistent results across multiple runs and match the expected outcome, the repaired contract `repairedScut` and the verification results are output. The specific steps are as follows:

[0078] Step 1: Initial state; Step 2: Given the repaired contract `repairedScut` and the test case set `tests`; Step 3: Repeatedly execute the test case set `tests` 10 to 100 times; Step 4: Record the output result of the current execution. i and the output result of the next execution. j Step 5: Determine the execution result. i and result j If they are consistent, proceed to the next step; if they are consistent, proceed to step 7. Step 6: Output the error message that the contract has not been repaired. Step 7: Output the repaired contract repairedScut. Step 8: End status.

[0079] In summary, this invention solves the Flaky Test problem caused by transaction order dependencies in smart contracts, effectively improving the reliability and stability of smart contract testing. Furthermore, it optimizes the smart contract development process and promotes the continued healthy development of blockchain technology, thereby more effectively ensuring the security of smart contracts.

Claims

1. A method for Flaky repair and verification of smart contracts with transaction order dependency root cause, characterized in that, For the contract under test, firstly, static data dependency analysis identifies Flaky TestRoot Causes caused by transaction order dependencies. These causes are usually closely related to setter functions of shared contract state variables, which are the key entry points for modifying state variables. Next, targeting these setter functions, protective statements, i.e., locks, are embedded within them to ensure that the contract performs state checks before modifying state variables. Finally, the modified contract is used as the test object, marking statements affected by state variables as critical nodes, and defining the execution paths containing these nodes as critical paths. By using critical paths as test targets and repeatedly executing tests, the output changes of the contract under different state variables can be observed, thereby verifying the effectiveness of the repaired contract. Finally, the repaired contract `repairedScut` is output. This method includes the following steps: 1) Transaction order depends on Root Cause identification; given the contract under test scut, analyze and obtain the dictionary map_settecr_stmts of the set of statements stmts in the public function Setter of the contract under test that have write operations on state variables; first, initialize map_settecr_stmts to empty, and generate the abstract syntax tree AST of the contract under test scut. scut Then from AST scut Extract the common function set ListShare_Setters; then construct the data dependency graph dfg of the state variables of the contract under test scut. scut dfg scut This indicates the definition and usage of state variables in the contract statements; next, it iterates through each public function `Setter` in `ListShare_Setters`, identifies the set of statements `stmts` that have write operations on state variables based on data flow analysis, and checks if `stmts` is empty. If `stmts` is not empty, then...<setter,stmts> Add it to map_state_setters; otherwise, continue iterating through the collection ListShare_Setters until it is empty; finally, output map_setter_stmts. 2) Smart Contract Repair; Given a target contract `targetScut` and its dictionary `map_settecr_stmts`, repair the contract without changing the semantics of `targetScut`, obtaining the repaired contract `repairedScut`; first, find the specific location of the public function `Setter` by iterating through the keys in `map_settecr_stmts`. Setter Then, find the stmts corresponding to the setter function, analyze the stmts to obtain the set of state variables, states, that are affected by the setter; next, add an additional parameter lock to each state in the setter parameters. state The protective lock state It has the same type as the state variable; iterate through each statement in the stmts to find the specific location of the stmt. stmt Add a guardStmt statement to stmt to ensure that the current value of the state variable corresponds to the expected value passed by the caller. Finally, output the repaired contract repairedScut. 3) Smart contract test generation for the critical path; given the repaired contract `repairedScut` and its dictionary `map_settecr_stmts`, obtain the test case set `tests`; generate test cases containing different transaction orders to cover the modified statements; first, construct the control flow graph `cfg` of `repairedScut`. repairedScut cfg repairedScut This indicates the control flow transfer relationships between the various statements within the contract; then in cfg repairedScut Find the nodes containing stmts, define the paths containing these nodes and with branches as critical paths; then use critical paths as test generation targets and use fuzz testing to generate test case sets tests. 4) Smart Contract Flaky Test Root Cause Repair Result Verification; Given a repaired contract `repairedScut` and a test case set `tests`, test and verify the repaired contract `repairedScut`; repeatedly execute the test case set `tests` until a preset number of times `L` is reached; for each test case, observe the output changes of the contract `repairedScut` under different state variables, and record the output result of the current execution `result`. i and the output result of the next execution. j Compare results i and result j Check for consistency; if the test case consistently yields consistent results across multiple runs, the Flaky Test can be considered successfully fixed; finally, output the fixed contract repairedScut.

2. The method for Flaky repair and verification of smart contracts with transaction order dependency root cause as described in claim 1, characterized in that, In step 1), the transaction order dependency root cause is identified. For the contract under test, the Flaky Test Root Cause caused by the transaction order dependency is identified through static data dependency analysis. These causes are usually closely related to the setter function of the shared contract state variable. Therefore, the setter function is the key entry point for modifying the state variable.

3. The method for Flaky repair and verification of smart contracts with transaction order dependency root cause as described in claim 1, characterized in that, In step 2), smart contract repair is performed. For the target contract targetScut, protective statements are added to the contract without changing its original functionality to verify whether the state variables meet expectations. These protective statements are called locks, and they ensure that the contract must pass the lock verification before it can continue to execute, preventing Flaky Tests due to transaction order dependencies.

4. The method for Flaky repair and verification of smart contracts with transaction order dependency root cause as described in claim 1, characterized in that, In step 3), smart contract test generation is performed for the critical path; for the patched contract repairedScut, the code segments affected by state variables are marked as critical nodes, and the execution paths containing these nodes are defined as critical paths; by using the critical path as the test generation target, fuzz testing is used to generate test case sets tests.

5. The method for Flaky repair and verification of smart contracts with transaction order dependency root cause as described in claim 1, characterized in that, In step 3), the smart contract Flaky Test Root Cause repair result is verified; for the generated test case set tests, the generated test case set tests are executed repeatedly to observe the output changes of the contract under different state variables, and observe the output results of the test case set. If the test case results are consistent in multiple runs and match the expected results; finally, the repaired contract repairedScut and the verification results are output.

Images