Smart contract Flaky repair and verification method oriented to transaction sequence dependent on Root Case

Abstract

The invention provides an intelligent contract Flaky repairing and verifying method oriented to a transaction sequence and depending on Root Case. The method comprises the following steps: firstly, accurately identifying Root Case closely related to a setter function of a shared contract state variable through static data dependency analysis; and then, by taking the setter function as a target, embedding a protection statement, namely a lock, in the setter function, so as to ensure that the contract is subjected to state check before modifying the state variable. And finally, taking the modified contract as a test object, taking a statement with write operation on a state variable as a key node, and defining an execution path containing the node as a key path. And taking the key paths as test targets, repeatedly testing, and observing the performance of the contract in different states, so as to verify the validity of the repair patch. The objective of the invention is to improve the reliability of the smart contract, enhance the stability of the test result, optimize the development process, promote the healthy development of the block chain technology, and ensure the security of the smart contract.

Description

Technical Field

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

[0002] In the context of the rapid development of blockchain technology, smart contracts have become the key to decentralized applications with their automatic execution and self-verification characteristics. However, with the widespread deployment of smart contracts, the guarantee of their code quality and reliability is particularly important. In the process of testing smart contracts, the frequent occurrence of the Flaky phenomenon poses a huge challenge to developers. Among them, the Flaky phenomenon refers to the inconsistent test results produced by the same code version under different test environments, namely the Flaky Test. The Flaky phenomenon not only reduces the credibility of the test results, but also seriously affects the efficiency of the test. More seriously, the failure of the Flaky Test may mislead developers and cause them to mistakenly debug code that is not related to the actual problem. Therefore, in order to enhance the stability of test results, improve the reliability of smart contracts, optimize the development process of smart contracts, and promote the healthy development of blockchain technology, it is crucial to fix the root cause of the Flaky Test in smart contracts, namely the RootCause.

[0003] Unlike traditional software, smart contracts run on the blockchain, and their behavior is affected by the state of the blockchain. In a decentralized distributed accounting system, the blockchain maintains the consistency of transaction-driven states such as account balances and smart contract states on each node through a consensus mechanism. However, during the consensus process, due to factors such as the gas mechanism and network transmission rate, the order in which transactions are initiated may be inconsistent with the actual execution order, resulting in the inability to uniquely determine the state change process and final state of the blockchain under the same transaction sequence. This uncertainty leads to the emergence of smart contract flaky tests, that is, when the test execution of a smart contract depends on an uncertain transaction sequence, flaky tests may occur.

[0004] In order to effectively solve this problem, this paper proposes a method for Flaky repair and verification of smart contracts for transaction order dependency Root Cause. For each contract state variable, identify the setter function set that shares the variable, and add protection statements to it to implement Flaky repair of smart contracts for transaction order dependency Root Cause. These protection statements are called locks. On this basis, setter functions are used to build a transaction sequence. By observing the changes in the state variable values ​​of the contract under the same transaction sequence after the protection statements are added, the repair results of the transaction order dependency Root Cause can be verified.

[0005] Specifically, the method in this paper first identifies the Flaky Test Root Cause caused by transaction order dependency through static data dependency analysis. These causes are usually closely related to the setter function of the shared contract state variable, so the setter function is the key entry point for modifying the state variable. Next, with 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 a state check before modifying the state variable. Finally, the modified contract is used as the test object, the statements affected by the state variables are marked as critical nodes, and the execution path containing these nodes is defined as the critical path. By using the critical path as the test generation target and repeatedly executing the test, it is possible to observe the output changes of the contract under different state variables, thereby verifying the validity of the repaired contract. Summary of the invention

[0006] The present invention provides a smart contract flaky repair and verification method for transaction order dependent root cause to effectively solve the problems of unstable smart contract test results and unreliable smart contracts caused by flaky test, thereby avoiding the misleading of developers by flaky test, optimizing the development process of smart contracts and promoting the healthy development of blockchain technology.

[0007] To achieve the above goals, this method first identifies the Flaky Test Root Cause caused by transaction order dependency through static data dependency analysis. These causes are usually closely related to the setter function of the shared contract state variable, so the setter function is the key entry point for modifying the state variable. Then, taking the setter function as the target, embed a protection statement, i.e., a lock, in the setter function to ensure that the contract performs a status check before modifying the state variable. Finally, the modified contract is used as the test object, and the path containing the embedded protection statement in the setter function is used as the test generation target. The test is repeatedly executed to observe the output changes of the contract under different state variables, thereby verifying the validity of the repaired contract. Finally, the repaired smart contract repairedScut and the verification result are output. Specifically, the method includes the following steps.

[0008] 1) Transaction order depends on Root Cause identification. Given the contract scut to be tested, analyze and obtain the dictionary map_settecr_stmts of the statement set stmts that the public function Setter in the contract to be tested has write operations on the state variables. First, initialize map_settecr_stmts to empty and generate the abstract syntax tree AST of the contract scut to be tested. scut , then from the AST scut Extract the public function set ListShare_Setters from the test contract. Then construct the data dependency graph dfg of the state variables of the test contract scut. scut , dfg scut It shows the definition and usage of the state variables in the contract. Next, we traverse each public function Setter in ListShare_Setters, identify the statement set stmts that has write operations on the state variables based on data flow analysis, and determine whether stms is empty. If stmts is not empty,<setter,stmts> Add to map_state_setters, otherwise continue to traverse the collection ListShare_Setters until it is empty. Finally, output map_setter_stmts.

[0009] 2) Smart contract repair. Given the target contract targetScut and the dictionary map_settecr_stmts of the target contract, repair the contract without changing the semantics of the target contract targetScut to obtain the repaired contract repairedScut. First, find the specific location of the public function Setter by traversing the key in map_settecr_stmts. SetterThen find the stmts corresponding to the Setter function, analyze stmts to get the state variable set states affected by the Setter. Then, add an additional parameter lock to each state in the setter parameter. state , the protection lock lock state The same type as the state variable state. Traverse each statement stmt in stmts and find the specific location of stmt stmt , add a protection statement guardStmt for 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) Critical path-oriented smart contract test generation. Given the repaired contract repairedScut and the dictionary map_settecr_stmts of the contract, get the test case set tests. Generate test cases containing different transaction sequences to cover the modified related statements. First, build the control flow graph cfg of repairedScut. repairedScut , cfg repairedScut It indicates the control flow transfer relationship between the statements in the contract. repairedScut Find the nodes nodes containing stmts, define the paths containing these nodes and with branches as critical paths criticalPaths. Then use the critical paths criticalPaths as the test generation target, and use fuzz testing to generate test case sets tests.

[0011] 4) Verification of the repair result of the smart contract Flaky Test Root Cause. Given the repaired contract repairedScut and the test case set tests, test and verify the repaired contract repairedScut. Repeat the test case set tests until the 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 result i and result j Is it consistent? If the test case has consistent results in multiple runs, it can be considered that the Flaky Test has been successfully repaired. Finally, the repaired contract repairedScut is output.

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

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

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

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

[0016] Step 1)-4: Generate the abstract syntax tree AST of the contract scut to be tested scut ;

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

[0018] Step 1)-6: Construct the data dependency graph dfg of the state variables of the contract to be tested scut scut ;

[0019] Step 1)-7: Traverse each public function Setter in ListShare_Setters;

[0020] Step 1)-8: Identify the statement set stmts that has write operations on state variables based on data flow analysis;

[0021] Step 1)-9: Determine whether stms is empty, if not, execute the next step, if yes, execute step 1)-12;

[0022] Step 1)-10:<setter,stmts> Added to map_state_setters;

[0023] Step 1)-11: Determine whether the public function set ListShare_Setters has been traversed. If so, execute the next step. If not, return to step 1)-7;

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

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

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

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

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

[0029] Step 2)-3: Traverse the key in map_settecr_stmts to find the specific location of the public function Setter Setter ;

[0030] Step 2)-4: Find the stmts corresponding to the Setter function;

[0031] Step 2)-5: Analyze stmts to obtain the state variable set states affected by Setter;

[0032] Step 2)-6: According to location Setter Add an additional parameter, the protection lock, to each state variable in the function Setter parameter state ;

[0033] Step 2)-7: Traverse each statement stmt in stmts and find the specific location of stmt stmt ;

[0034] Step 2)-8: According to location stmt Add a protection statement guardStmt to stmt;

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

[0036] Step 2)-10: Determine whether map_settecr_stmts has been traversed. If so, execute 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] Further, the specific steps of the above step 3) are as follows:

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

[0041] Step 3)-2: Input the repaired contract repairedScut and the statement set stmts corresponding to each Setter function;

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

[0043] Step 3)-4: Traverse cfg repairedScut Nodes in nodes;

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

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

[0046] Step 3)-7: Determine cfg repairedScut Check if the traversal is finished. If so, proceed to the next step. If not, return to step 3)-4.

[0047] Step 3)-8: Use the critical path criticalPaths as the test generation target and use fuzz testing to generate the test case set tests;

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

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

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

[0051] Step 4)-1: Starting 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 tests10 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] Step 4)-5: Determine the result i and result j Are they consistent? If not, proceed to the next step. If yes, proceed to steps 4)-7;

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

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

[0058] Step 4)-8: End state. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1The present invention is a flowchart of a method for Flaky repair and verification of smart contracts based on transaction order dependency Root Cause in the implementation of the present invention.

[0060] Figure 2 for Figure 1 Flowchart in which transaction sequence depends on Root Cause identification.

[0061] Figure 3 for Figure 1 Flowchart of smart contract repair in [2].

[0062] Figure 4 for Figure 1 Flowchart of critical path-oriented smart contract test generation in .

[0063] Figure 5 for Figure 1 Flowchart of verification of Flaky Test Root Cause repair results of smart contract. DETAILED DESCRIPTION

[0064] In order to better understand the technical content of the present invention, a specific implementation is given and described as follows with reference to the accompanying drawings.

[0065] Figure 1 The present invention is a flowchart of a method for Flaky repair and verification of smart contracts based on transaction order dependency Root Cause in the implementation of the present invention.

[0066] A method for repairing and verifying flaky issues in smart contracts based on transaction order dependency root causes, comprising the following steps.

[0067] S1 transaction sequence dependency root cause identification. This step identifies the Flaky Test root cause caused by transaction sequence dependency 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.

[0068] S2 Smart Contract Repair, this step adds protection statements to the contract without changing the original function of the contract to verify whether the state variables meet expectations. These protection statements are called locks, which ensure that the contract must pass the lock verification before continuing to execute, preventing Flaky Tests due to transaction order dependence.

[0069] S3 generates smart contract tests for critical paths. In this step, the modified contract is used as the test object, the code segments affected by the 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.

[0070] S4 Smart Contract Flaky Test Root Cause Repair Result Verification: This step will repeatedly execute the generated test case set tests, which can observe the output changes of the contract under different state variables and the output results of the test case set. If the test case results are consistent in multiple runs and are consistent with the expected results, the repaired contract repairedScut and verification results will be output at last.

[0071] Figure 2 Flowchart for identifying the root cause of transaction sequence dependency. For the contract under test, the flaky test root cause caused by transaction sequence dependency is identified through static data dependency analysis. These causes are usually closely related to the setter functions of shared contract state variables. These setter functions are the key entry points for modifying state variables. The specific steps are as follows:

[0072] Step 1: Starting state; Step 2: Given the contract scut to be tested, analyze and obtain the dictionary map_settecr_stmts of the statement set stmts that has write operations on the state variables in the public function Setter in the contract to be tested; Step 3: Initialize map_settecr_stmts to be empty; Step 4: Generate the abstract syntax tree AST of the contract scut to be tested scut :Step 5: From AST scut Extract the public function set ListShare_Setters from the test contract; Step 6: Construct the data dependency graph dfg of the state variables of the contract to be tested scut scut ; Step 7: Traverse each public function Setter in ListShare_Setters; Step 8: Based on data flow analysis, identify the statement set stmts that has write operations on state variables; Step 9: Determine whether stms is empty, if not, execute the next step, if so, execute step 12; Step 10:<setter,stmts> Add to map_state_setters; Step 11: Determine whether the public function set ListShare_Setters has been traversed, if so, execute the next step, if not, return to step 7; Step 2: Output map_setter_stmts; Step 13: End state.

[0073] Figure 3Flowchart for smart contract repair. For the target contract targetScut, without changing the original function of the contract, add protection statements to the contract to verify whether the state variables meet expectations. These protection statements are called locks, which ensure that the contract must pass the lock verification before continuing to execute, preventing FlakyTests due to transaction order dependency. The specific steps are as follows:

[0074] Step 1: Starting state; Step 2: Given the target contract targetScut and the dictionary map_settecr_stmts of the target contract; Step 3: Traverse the key in map_settecr_stmts to find the specific location of the public function Setter Setter ; Step 4: Find the stmts corresponding to the Setter function; Step 5: Analyze stmts to get the state variable set states affected by Setter; Step 6: According to location Setter Add an additional parameter, the protection lock, to each state variable in the function Setter parameter state ; Step 7: Traverse each statement stmt in stmts and find the specific location of stmt stmt ; Step 8: According to location stmt Add a protection statement guardStmt to stmt; Step 9: Determine whether stmts has been traversed, if so, execute the next step, otherwise return to step 7; Step 10: Determine whether map_settecr_stmts has been traversed, if so, execute the next step, otherwise return to step 3; Step 11: Output the repaired contract repairedScut; Step 12: End state.

[0075] Figure 4 A flowchart generated for critical path-oriented smart contract testing. For the repaired contract repairedScut, the modified contract is used as the test object, the code segments affected by the 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 the test case set tests. The specific steps are as follows:

[0076] Step 1: Starting state; Step 2: Given the repaired contract repairedScut and the statement set stmts corresponding to each Setter function; Step 3: Construct the control flow graph cfg of repairedScut repairedScut ; Step 4: Traverse cfg repairedScut Nodes in cfg; Step 5: repairedScutFind the nodes containing stmts in nodes; Step 6: Define the paths containing these nodes and with branches as critical paths criticalPaths; Step 7: Determine cfg repairedScut Check whether the traversal is finished. If so, proceed to the next step. If not, return to step 4. Step 8: Use the critical path criticalPaths as the test generation target and use fuzz testing to generate the test case set tests. Step 9: Output tests. Step 10: End state.

[0077] Figure 5 This is a flowchart for verifying the repair results of the Flaky Test Root Cause of the smart contract. For the generated test case set tests, the generated test case set tests are repeatedly executed to observe the output changes of the contract under different state variables and the output results of the test case set. If the test case results are consistent in multiple runs and are consistent with the expected results, the repaired contract repairedScut and verification results are finally output. The specific steps are as follows:

[0078] Step 1: Starting state; Step 2: Given the repaired contract repairedScut and the test case set tests; Step 3: Repeat the test case set tests10 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 result of the execution i and result j Are they consistent? If not, proceed to the next step. If so, 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 state.

[0079] In summary, the present invention solves the problem of Flaky Test caused by transaction order dependency in smart contracts, effectively improving the reliability of smart contracts and the stability of tests. In addition, it also optimizes the development process of smart contracts and promotes the sustainable and healthy development of blockchain technology, thereby more effectively ensuring the security of smart contracts.

Claims

1. A method for repairing and verifying the flaky problem of smart contracts based on the root cause of transaction order dependency, characterized in that: For the contract to be tested, firstly, the flaky test root cause caused by transaction sequence dependency is identified through static data dependency analysis. These causes are usually closely related to the setter functions of the shared contract state variables, which are the key entry points for modifying the state variables. Then, with 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 a state check before modifying the state variables. Finally, the modified contract is used as the test object, the statements affected by the state variables are marked as key nodes, and the execution path containing these nodes is defined as the key path. By taking the key path as the test generation target and repeatedly executing the test, the output changes of the contract under different state variables can be observed, thereby verifying the validity of the repaired contract. Finally, the repaired contract repairedScut is output. The method comprises the following steps: 1) Transaction order depends on Root Cause identification; Given the contract scut to be tested, analyze and obtain the dictionary map_settecr_stmts of the statement set stmts that the public function Setter in the contract to be tested has write operations on the state variables; First, initialize map_settecr_stmts to empty and generate the abstract syntax tree AST of the contract scut to be tested scut , then from the AST scut Extract the public function set ListShare_Setters from the test contract; then construct the data dependency graph dfg of the state variables of the test contract scut scut , dfg scut It shows the definition and usage of the state variables in the contract. Next, it traverses each public function Setter in ListShare_Setters, identifies the statement set stmts that has write operations on the state variables based on data flow analysis, and determines whether stms is empty. If stmts is not empty,<setter,stmts> Add to map_state_setters, otherwise continue to traverse the collection ListShare_Setters until it is empty; finally output map_setter_stmts; 2) Smart contract repair: Given the target contract targetScut and the dictionary map_settecr_stmts of the target contract, repair the contract without changing the semantics of the target contract targetScut to obtain the repaired contract repairedScut; first find the specific location of the public function Setter by traversing the key in map_settecr_stmts Setter , then find the stmts corresponding to the Setter function, analyze stmts to get the state variable set states affected by the Setter; then, add an additional parameter lock to each state in the setter parameter state , the protection lock lock state The same type as the state variable state; traverse each statement stmt in stmts and find the specific location of stmt stmt , add a guardStmt for 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; 3) Smart contract test generation for critical paths; Given the repaired contract repairedScut and the dictionary map_settecr_stmts of the contract, get the test case set tests; Generate test cases containing different transaction sequences to cover the modified related statements; First build the control flow graph cfg of repairedScut repairedScut , cfg repairedScut It indicates the control flow transfer relationship between the statements in the contract; then in cfg repairedScut Find the nodes nodes containing stmts, define the paths containing these nodes and with branches as critical paths criticalPaths; then use the critical paths criticalPaths as the test generation target, and use fuzz testing to generate the test case set tests; 4) Verification of the repair result of the smart contract Flaky Test Root Cause; Given the repaired contract repairedScut and the test case set tests, test and verify the repaired contract repairedScut; Repeat the test case set tests until the 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 result i and result j Whether they are consistent; if the test case has consistent results in multiple runs, it can be considered that the Flaky Test has been successfully repaired; finally, the repaired contract repairedScut is output.

2. The method for repairing and verifying the flaky smart contract based on the root cause of transaction order dependency according to claim 1 is characterized in that: In step 1), the transaction sequence dependency root cause is identified; for the contract to be tested, the flaky test root cause caused by the transaction sequence dependency is identified through static data dependency analysis. These causes are usually closely related to the setter function of the shared contract state variable, so the setter function is the key entry point for modifying the state variable.

3. The method for repairing and verifying the flaky smart contract based on the root cause of transaction order dependency according to claim 1 is characterized in that: In step 2), the smart contract is repaired; for the target contract targetScut, without changing the original function of the contract, a protection statement is added to the contract to verify whether the state variables meet expectations; these protection statements are called locks, which ensure that the contract must pass the lock verification before continuing to execute, preventing Flaky Tests due to transaction order dependence.

4. The method for repairing and verifying the flaky smart contract based on the transaction order-dependent root cause according to claim 1 is characterized in that: In step 3), smart contract tests are generated for critical paths; for the patched contract repairedScut, the code segments affected by the state variables are marked as critical nodes, and the execution paths containing these nodes are defined as critical paths; by taking the critical path as the test generation target, fuzz testing is used to generate a test case set tests.

5. The method for repairing and verifying the flaky smart contract based on the root cause of transaction order dependency according to claim 1 is 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 repeatedly executed to observe the output changes of the contract under different state variables and the output results of the test case set. If the test case results are consistent in multiple runs and are consistent with the expected results; finally, the repaired contract repairedScut and the verification results are output.

Images