A multi-indicator feedback-driven smart contract fuzz testing method and related device

Abstract

The present invention provides a multi-indicator feedback-driven smart contract fuzz testing method and related devices. By obtaining a given smart contract and applying static analysis technology to extract its semantic information, a transaction sequence seed is generated and placed in a seed pool. Then, a test transaction sequence is taken out from the pool, the test is performed on the plugged EVM and multi-indicator execution feedback information is collected. The fitness of the test transaction sequence is calculated based on this information, and those that meet the set conditions are selected as the next generation seeds. The rest are discarded, and the seeds are randomly mutated to make up the number, and then a new seed pool is obtained by combining them. The test steps are repeated in a continuous cycle until the stop condition is met, and the test of the smart contract is completed. Driven by multi-indicator feedback, the present invention can generate test cases more comprehensively and accurately, effectively cover the complex code branches of smart contracts, improve vulnerability detection efficiency, reduce economic losses caused by smart contract vulnerabilities, and enhance the security and reliability of smart contract applications.

Description

Technical Field

[0001] The present invention belongs to the field of Ethereum smart contract security technology, and specifically relates to a multi-indicator feedback-driven smart contract fuzz testing method and related devices. Background Art

[0002] Due to the immutable and decentralized nature of blockchains and smart contracts, they are being used to build a wide range of applications, including decentralized finance, supply chains, voting, and gaming. These smart contracts manage a vast amount of assets on the blockchain. For example, the total market capitalization of Ethereum and the smart contracts running on it has exceeded $100 billion. However, as smart contracts become increasingly complex in terms of functionality and the businesses they support, their code size has also grown. Vulnerabilities in smart contracts have also become more diverse and complex, resulting in billions of dollars in economic losses. Therefore, smart contract vulnerabilities have become a significant and urgent challenge that needs to be addressed.

[0003] Fuzz testing, a common method for software vulnerability discovery, has become an important technical approach for smart contract vulnerability detection. A fuzz testing framework is an automated method for testing smart contract vulnerabilities. The framework analyzes the smart contract interface to generate inputs that conform to the call syntax of the smart contract under test. The framework then algorithmically generates a series of random inputs and initiates transactions to the corresponding contract, attempting to cover as many contract code branches as possible. It also uses manually defined rules, known as oracles, to analyze whether the input sequence triggers contract vulnerabilities. However, most current fuzz testing tools for smart contracts still have some issues. For example, many branches with strict protection conditions require a very long time to generate test cases that cover them, or even fail to cover them at all. This reduces the vulnerability detection rate and practicality of fuzz testing, and ultimately makes fuzz testing results uncertain. Many research works have proposed feedback metrics to help algorithms generate test cases more effectively and improve the efficiency of tools in covering strict branches. However, the feedback metrics used by existing methods are based on different considerations and still suffer from certain inefficiencies. Summary of the Invention

[0004] In view of this, the present invention addresses the feedback indicator limitations of various current studies and proposes a multi-indicator feedback-driven smart contract fuzz testing method and related devices to help fuzz testing tools more efficiently cover smart contract code branches and improve vulnerability detection efficiency.

[0005] In order to achieve the above object, the technical solution provided by the present invention is as follows:

[0006] In a first aspect, the present invention provides a multi-metric feedback-driven smart contract fuzz testing method, comprising the following steps:

[0007] Get the given smart contract;

[0008] Use static analysis techniques to extract semantic information of smart contracts;

[0009] Generate a number of transaction sequence seeds based on semantic information and put them into the initial transaction sequence seed pool;

[0010] Extract the test transaction sequence from the transaction sequence seed pool, execute the test on the instrumented EVM, and collect multi-metric execution feedback information;

[0011] Calculate the fitness for each test trading sequence taking into account the execution feedback information of multiple indicators;

[0012] Select the test transaction sequences whose fitness meets the set conditions as the seeds of the next generation of test cases, and discard the rest;

[0013] Randomly mutate the test case seeds to generate several new test cases to make up for the number of discarded test cases;

[0014] Combine all current test case seeds to obtain a new transaction sequence seed pool;

[0015] Based on the new transaction sequence seed pool, the test steps are repeated until the set stop condition is reached, completing the test of the given smart contract.

[0016] Furthermore, the multi-indicator execution feedback information includes at least:

[0017] Execution path constraints, code coverage, branch condition distances, read and write memory locations, and data flow relationships.

[0018] Furthermore, multiple indicators of execution feedback information are collected, including:

[0019] Use taint analysis technology to introduce conditional symbol constraints when executing conditional branch statements, and obtain the execution path constraints of smart contract code branches based on the conditional symbol constraints;

[0020] Track and record the program counter of the EVM during execution and calculate the coverage;

[0021] When a conditional branch statement is executed, the difference between the value of the branch condition variable and the value that the branch condition variable should satisfy is recorded, thereby calculating the branch condition distance;

[0022] When the storage read and write instructions are executed, the storage location corresponding to the read and write is recorded to obtain the read and write storage location;

[0023] The read and write storage locations of each transaction in the transaction sequence are compared and analyzed, and the data flow relationship between the transactions is obtained based on the overlapping parts of the read and write locations.

[0024] Furthermore, before obtaining a new transaction sequence seed pool, if the coverage rate does not improve after multiple iterations, the following steps are also included:

[0025] Use the symbolic constraint solver to solve the conditional symbolic constraints collected when running the test case, obtain the test input that can satisfy the conditional symbolic constraints, and add it to the next generation of test cases.

[0026] Furthermore, the transaction sequence seed includes a first transaction sequence seed generated using deep learning technology. The deep learning technology uses semantic information as model input and utilizes a pre-trained neural network model to generate key information of the transaction sequence, thereby obtaining the first transaction sequence seed.

[0027] Furthermore, the transaction sequence seed also includes a second transaction sequence seed generated using random combined with data flow analysis technology. The random combined with data flow analysis technology is to generate a number of transactions by randomly applying a binary interface, and then combine transactions that may have dependencies through data flow analysis technology to obtain the second transaction sequence seed.

[0028] Furthermore, all current test case seeds are combined, including:

[0029] Combine all current test case seeds in a random manner and / or use data flow relationships as input to the deep learning model to combine transaction sequences that the deep learning model believes are correlated.

[0030] In a second aspect, the present invention provides a multi-metric feedback-driven smart contract fuzz testing method, comprising the following steps:

[0031] Contract acquisition module, used to obtain a given smart contract;

[0032] Semantic information extraction module, used to extract semantic information of smart contracts using static analysis technology;

[0033] The seed pool generation module is used to generate a number of transaction sequence seeds based on semantic information and put them into the initial transaction sequence seed pool;

[0034] The test execution module is used to extract the test transaction sequence from the transaction sequence seed pool, execute the test on the instrumented EVM, and collect multi-indicator execution feedback information;

[0035] The seed pool update module is used to calculate the fitness of each test transaction sequence, taking into account multi-metric execution feedback information. It is also used to select test transaction sequences whose fitness meets the set conditions as the next generation of test case seeds, and discard the rest. It is also used to randomly mutate the test case seeds to generate several new test cases to make up for the number of discarded test cases. It is also used to combine all current test case seeds to obtain a new transaction sequence seed pool.

[0036] The loop test module is used to repeat the test steps based on the new transaction sequence seed pool until the set stop condition is reached, thus completing the test of the given smart contract.

[0037] In a third aspect, the present invention provides a computer device, comprising a processor and a memory:

[0038] The memory is used to store computer programs and send instructions of the computer programs to the processor;

[0039] The processor executes a multi-indicator feedback-driven smart contract fuzz testing method as described in the first aspect according to instructions of the computer program.

[0040] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements a multi-indicator feedback-driven smart contract fuzz testing method as described in the first aspect.

[0041] In summary, the present invention provides a multi-indicator feedback-driven smart contract fuzz testing method and related devices. By obtaining a given smart contract and applying static analysis technology to extract its semantic information, a transaction sequence seed is generated and placed in a seed pool. Then, a test transaction sequence is taken from the pool, the test is executed on the stub EVM, and multi-indicator execution feedback information is collected. This information is combined to calculate the fitness of the test transaction sequence, and those that meet the set conditions are selected as the next generation of seeds. The rest are discarded, and the seeds are then randomly mutated to make up the number, and then combined to obtain a new seed pool. The test steps are repeated in a continuous cycle until the stop condition is met, completing the test of the smart contract. Driven by multi-indicator feedback, the present invention can generate test cases more comprehensively and accurately, effectively cover the complex code branches of smart contracts, improve vulnerability detection efficiency, reduce economic losses caused by smart contract vulnerabilities, and enhance the security and reliability of smart contract applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0043] Figure 1 A flowchart of a multi-metric feedback-driven smart contract fuzz testing method provided by an embodiment of the present invention;

[0044] Figure 2 A test flow chart based on selected multi-indicator execution feedback information provided by an embodiment of the present invention;

[0045] Figure 3 A block diagram of a multi-indicator feedback-driven smart contract fuzz testing device provided by an embodiment of the present invention;

[0046] Figure 4 A block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0047] In order to make the purposes, features, and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0048] The following first explains some of the technical terms involved in the technical solution of the present invention, as follows:

[0049] (1) Blockchain: It is a distributed ledger technology that packages transaction records into blocks and links them in chronological order to form an immutable chain of records. Each block contains the hash value of the previous block, thus ensuring the integrity and security of the data. The decentralized nature of blockchain technology enables all participating nodes to share ledger information, ensuring data transparency and tamper-proofing. It is widely used in fields such as cryptocurrency, finance, and supply chain management.

[0050] (2) Smart Contract: An automated agreement running on a blockchain that can automatically execute terms and actions when specific conditions are met. Smart contracts are written in a programming language and deployed on a blockchain network. The blockchain's decentralization and immutability ensure the reliability and transparency of contract execution. Once a smart contract is deployed on a blockchain, it cannot be modified. Smart contracts are commonly used in scenarios such as automated transactions, protocol execution, and the development of decentralized applications.

[0051] (3) Fuzz testing: Generate transactions for executing smart contracts through certain rules (or randomly). In addition to the code coverage indicator, the execution process of the smart contract will also generate corresponding state changes and corresponding logs. These indicators can be used to detect vulnerabilities in smart contracts.

[0052] (4) Evolutionary Algorithms: Evolutionary algorithms in fuzz testing refer to a type of optimization technology that draws on the biological evolution process in nature to automatically generate and improve fuzz test cases. These algorithms simulate biological phenomena such as natural selection, inheritance, and mutation, starting from initial random or predefined test cases, and through an iterative process gradually evolve effective inputs that are more likely to trigger specific paths within the software or expose potential defects. Evolutionary algorithms can explore a wider input space without a clear vulnerability model, improve the coverage and efficiency of fuzz testing, and thus enhance the ability to detect software defects.

[0053] This invention only targets smart contracts written in Solidity and targeting the Ethereum blockchain, which are executed using the EVM (Ethereum Virtual Machine).

[0054] See also Figure 1 This embodiment provides a multi-indicator feedback-driven smart contract fuzz testing method, including the following steps:

[0055] S1: Get the given smart contract.

[0056] It should be noted that this step obtains the given smart contract and determines it as the object of this test.

[0057] S2: Use static analysis techniques to extract semantic information of smart contracts.

[0058] It should be noted that static analysis technology refers to the analysis of code syntax, control flow, data dependencies, and other aspects without actually executing the program code. Semantic information refers to the deeper meaning contained in smart contract code, such as the Application Binary Interface (ABI, which describes the specifications for how the contract interface is called), the storage variable list (the variables defined in the contract for storing data), the code abstract syntax tree (a tree-like representation of the code syntax structure, facilitating analysis of the code's logical relationships), and the code control flow graph (which shows the execution order of statements in the code and possible branching flows).

[0059] This step uses static analysis techniques to perform lexical and syntactic analysis on the smart contract code, constructing structures such as abstract syntax trees, and then extracting the aforementioned semantic information from them. For example, by scanning the variable definitions in the code to obtain a list of stored variables, and analyzing function call relationships to obtain information related to the application binary interface, etc. This provides a critical data foundation for subsequent operations such as generating transaction sequence seeds, understanding contract logic, and determining test coverage, and helps to understand the internal structure and functional characteristics of the contract.

[0060] S3: Generate a number of transaction sequence seeds based on semantic information and put them into the initial transaction sequence seed pool.

[0061] It should be noted that a transaction sequence seed is an initial template or basic example of a series of transaction behaviors that simulate user interactions with smart contracts. These transactions are arranged in a certain order. The transaction sequence seed pool is a collection container for storing these seeds, from which they are subsequently selected for testing operations.

[0062] This step uses semantic information extracted from the smart contract, such as the contract's function interfaces and input and output parameter requirements, to construct a series of transaction sequences according to specific rules and strategies. These sequences are then placed into a specially created transaction sequence seed pool as seeds. This step builds a basic set of test materials for the initial fuzz testing phase. Subsequent operations such as mutation and combination of these seeds enrich the test case set, allowing for more comprehensive testing of the smart contract.

[0063] S4: Extract the test transaction sequence from the transaction sequence seed pool, execute the test on the instrumented EVM, and collect multi-metric execution feedback information.

[0064] It should be noted that EVM is the runtime environment used to execute smart contract bytecode in Ethereum, and stub is a technical means of inserting specific code snippets (stub code) into program code or runtime environment to implement information collection, monitoring and other functions. Stub EVM means obtaining various relevant information during the contract execution process through stub in the EVM runtime environment.

[0065] Multi-indicator execution feedback information refers to the relevant feedback information collected from multiple dimensions during the execution of a smart contract test transaction sequence.

[0066] This step extracts one or more test transaction sequences from the transaction sequence seed pool and runs them in an instrumented EVM environment. During execution, pre-inserted stub code captures and records the aforementioned multi-metric execution feedback in real time. This step allows the test transaction sequence to be executed and obtains multi-dimensional feedback from the actual operation. This information serves as an important basis for subsequent decision-making, such as evaluating the quality of the test transaction sequence and deciding whether to continue using it. It helps to accurately guide the optimization and generation of test cases.

[0067] S5: Calculate the fitness considering multi-indicator execution feedback information for each test transaction sequence.

[0068] It should be noted that in evolutionary algorithms, fitness is used to measure the performance of an individual (in this example, a test transaction sequence) in a test environment. By comprehensively considering the collected multi-indicator execution feedback information, a numerical value is assigned to each test transaction sequence to represent its fitness through a specific calculation method. A higher value indicates that the test transaction sequence is more in line with the desired test objectives.

[0069] This step uses a pre-defined fitness calculation function, taking the collected multi-metric execution feedback as input parameters and calculating the fitness value for each test transaction sequence according to appropriate weighting and scoring rules. This step quantitatively evaluates the quality of each test transaction sequence, facilitating subsequent screening and selection of more valuable test transaction sequences to further expand the test case set.

[0070] S6: Select the test transaction sequences whose fitness meets the set conditions as the next generation of test case seeds, and discard the rest.

[0071] It should be noted that this step compares the fitness of each test transaction sequence calculated in the previous step with pre-set conditions (such as fitness thresholds, etc.). Test transaction sequences that meet the set conditions (such as fitness greater than a certain threshold) are selected and recognized as having the value of continuing to serve as test case seeds for further expansion and evolution. Those that do not meet the conditions are discarded and no longer participate in subsequent operations.

[0072] This step can screen the test transaction sequences, retaining those with the potential to better discover potential problems in the smart contract as core seeds, so that the subsequently generated test cases can focus more on valuable directions, avoid a large number of meaningless and invalid tests, and improve test efficiency and effectiveness.

[0073] S7: Randomly mutate the test case seeds to generate several new test cases to make up for the number of discarded test cases.

[0074] It should be noted that for the selected test case seeds, new transaction sequences, that is, new test cases, are generated by performing random modification operations on their transaction sequences (such as changing the input parameter values ​​of transactions, adjusting the order of transactions, adding or subtracting certain transactions, etc.). The number of generated test cases is based on the number of test cases discarded in the previous steps, ensuring that the size of the test case set is relatively stable and constantly updated.

[0075] This step enriches the diversity of test cases through mutation, simulates more different actual usage scenarios and possible abnormal situations, further expands the test coverage, and increases the probability of discovering hidden vulnerabilities in smart contracts and other problems.

[0076] S8: Combine all current test case seeds to obtain a new transaction sequence seed pool.

[0077] It should be noted that this step will reintegrate all test case seeds that have been screened and mutated to form new transaction sequences. These new transaction sequences will constitute a new transaction sequence seed pool to prepare basic materials for the next round of test iterations.

[0078] This step further creates more complex and diverse test scenarios through combined operations, uncovering potential problems that may not be discovered by a single test case seed, making the test more comprehensive and in-depth.

[0079] S9: Based on the new transaction sequence seed pool, the test steps (i.e., S4-S8) are repeated until the set stop condition is reached, completing the test of the given smart contract.

[0080] It should be noted that the stopping conditions are some pre-set judgment criteria, such as reaching a certain number of test rounds, reaching the upper limit of the test time, and the number of problems found no longer increasing.

[0081] This step continuously uses the newly generated transaction sequence seed pool to cyclically execute a series of operations, including extracting test transaction sequences, executing tests to collect feedback, calculating fitness, screening, mutation, and combination. Each round of iteration will update the test case seed pool. During each iteration, it will check whether the set stop condition is met. Once it is met, the entire test process will be stopped.

[0082] Through continuous iteration, we continuously optimize and enrich the test case set, and gradually conduct comprehensive testing of smart contracts until the stopping conditions are met, ensuring that possible vulnerabilities, errors and other problems in smart contracts are detected as comprehensively as possible, thereby improving the quality and reliability of smart contracts.

[0083] The fuzz testing method proposed in this embodiment is based on an evolutionary algorithm. Starting with an initial transaction sequence seed, the method continuously executes tests, collects multi-metric feedback, and calculates fitness based on the feedback to select optimal seeds. These seeds are then mutated and combined to generate new test cases and seed pools. This iterative cycle simulates a large number of different transaction scenarios to execute smart contracts. Multi-metric feedback guides the evolution of test cases, thereby achieving comprehensive and in-depth testing of smart contracts and uncovering as many issues as possible. Unlike traditional testing methods that focus solely on a single metric (such as crashes), this embodiment comprehensively considers multiple execution metrics to evaluate the quality of test transaction sequences. This results in a more comprehensive and objective evaluation of test cases and more accurately guides their evolution toward uncovering more types of hidden issues. Furthermore, using an iterative approach similar to an evolutionary algorithm, the test case set is continuously optimized, enriching the diversity of test scenarios and test cases. Compared to a one-time generation of fixed test cases for testing, this method can more deeply explore potential issues in smart contracts, improving the effectiveness and adequacy of testing. It is particularly suitable for testing complex smart contracts.

[0084] In one embodiment, the multi-index execution feedback information includes at least: execution path constraints, code coverage, branch condition distance, read and write storage locations, and data flow relationships.

[0085] This embodiment calculates the fitness of test cases by comprehensively considering feedback indicators from multiple angles, including code coverage, branch condition distance, storage location reading and writing, and data flow relationships. It can achieve good coverage efficiency for both strictly conditional branches in a single transaction and branches that require coverage by combining multiple transactions.

[0086] Based on the multi-indicator execution feedback information provided in the aforementioned embodiment, in a further embodiment, collecting the multi-indicator execution feedback information includes:

[0087] 1) Use taint analysis technology to introduce conditional symbol constraints when executing conditional branch statements, and obtain the execution path constraints of smart contract code branches based on the conditional symbol constraints.

[0088] Taint analysis is a technique used to analyze the flow of data within a program and track whether it has been contaminated during transmission. This step involves introducing symbolic markers into the contract input and using a separate symbol stack to simulate the operation path based on the executed bytecode. This allows us to obtain the conditional symbolic constraints on the input variables when executing a conditional branch statement.

[0089] 2) Track and record the program counter of the EVM instrumented during execution and calculate the coverage.

[0090] 3) When a conditional branch statement is executed, the difference between the value of the branch condition variable and the value that the branch condition variable should satisfy is recorded, thereby calculating the branch condition distance.

[0091] 4) When the storage read and write instructions are executed, the storage location corresponding to the read and write is recorded to obtain the read and write storage location.

[0092] 5) Compare and analyze the read and write storage locations of each transaction in the transaction sequence, and obtain the data flow relationship between transactions based on the overlap of read and write locations.

[0093] This embodiment selects the above information as multi-indicator execution feedback information, which can achieve precise control of each key link of smart contract testing, and also helps to comprehensively cover different execution scenarios, accurately evaluate the adequacy of testing, deeply explore boundary conditions, troubleshoot storage-related issues, and sort out data correlations between transactions. Overall, it greatly improves the depth, breadth and accuracy of smart contract testing, can more effectively explore potential vulnerabilities and problems, and optimize test quality. The process of testing based on the above selected multi-indicator execution feedback information Figure 2 As shown in the figure, this testing method first uses data flow analysis and deep learning to generate a high-quality initial seed pool, and then uses the instrumented EVM to collect feedback indicators such as test case code coverage, branch condition distance, storage location reading and writing, and data flow relationship. Combined with symbolic execution and deep learning technology, it further improves the coverage efficiency of smart contract fuzz testing and can increase the number of vulnerabilities detected by smart contract fuzz testing in the same amount of time.

[0094] Please refer again Figure 2 In one embodiment, before obtaining a new transaction sequence seed pool, if the coverage rate does not improve after multiple iterations, the following steps are further included:

[0095] Use the symbolic constraint solver to solve the conditional symbolic constraints collected when running the test case, obtain the test input that can satisfy the conditional symbolic constraints, and add it to the next generation of test cases.

[0096] For branches that are difficult to cover with random mutations, this embodiment uses symbolic execution technology to directly solve the corresponding test inputs (i.e., uses a symbolic constraint solver to solve the conditional symbolic constraints collected when running the test case before), and uses new inputs to change the test path, so that the test case can cover more contract code areas, thereby improving the code coverage rate and enabling the test to detect the smart contract more comprehensively and deeply.

[0097] In one embodiment, the transaction sequence seed includes a first transaction sequence seed generated using deep learning technology. The deep learning technology uses semantic information as model input and utilizes a pre-trained neural network model to generate key information of the transaction sequence, thereby obtaining the first transaction sequence seed.

[0098] Taking the multi-indicator feedback information provided in the aforementioned embodiment as an example, through deep learning technology, the application binary interface, storage variable list, code abstract syntax tree and code control flow graph are used as the input of the neural network model, so that the model outputs the contract interface called in the transaction sequence, call parameters, caller address and the amount of Ether sent in the transaction, thereby generating a certain number of transaction sequence seeds (i.e., the first transaction sequence seed).

[0099] In one embodiment, the transaction sequence seed also includes a second transaction sequence seed generated using a random combination of data flow analysis technology. The random combination of data flow analysis technology is to generate a number of transactions by randomly applying a binary interface, and then combine transactions that may have dependencies through data flow analysis technology to obtain the second transaction sequence seed.

[0100] This paper generates an initial seed pool for fuzz testing through static analysis of smart contracts, combining data flow analysis and deep learning models. The high-quality initial seed pool can effectively improve the smart contract code coverage.

[0101] In one embodiment, all current test case seeds are combined, including:

[0102] Combine all current test case seeds in a random manner and / or use data flow relationships as input to the deep learning model to combine transaction sequences that the deep learning model believes are correlated.

[0103] When combining test cases, this embodiment uses data flow relationships as input and uses deep learning models to guide transaction combination, so that the combined transaction sequences can more easily cover complex contracts.

[0104] Based on the same inventive concept, the present application also provides a multi-indicator feedback-driven smart contract fuzz testing device for implementing the multi-indicator feedback-driven smart contract fuzz testing method mentioned above. The implementation solution provided by this device is similar to the implementation solution described in the above method. Therefore, the specific limitations of the multi-indicator feedback-driven smart contract fuzz testing device embodiment provided below can be found in the above-mentioned limitations of the multi-indicator feedback-driven smart contract fuzz testing method, and will not be repeated here.

[0105] See also Figure 3, an embodiment of the present invention provides a multi-indicator feedback-driven smart contract fuzz testing device, comprising:

[0106] Contract acquisition module, used to obtain a given smart contract;

[0107] Semantic information extraction module, used to extract semantic information of smart contracts using static analysis technology;

[0108] The seed pool generation module is used to generate a number of transaction sequence seeds based on semantic information and put them into the initial transaction sequence seed pool;

[0109] The test execution module is used to extract the test transaction sequence from the transaction sequence seed pool, execute the test on the instrumented EVM, and collect multi-indicator execution feedback information;

[0110] The seed pool update module is used to calculate the fitness of each test transaction sequence, taking into account multi-metric execution feedback information. It is also used to select test transaction sequences whose fitness meets the set conditions as the next generation of test case seeds, and discard the rest. It is also used to randomly mutate the test case seeds to generate several new test cases to make up for the number of discarded test cases. It is also used to combine all current test case seeds to obtain a new transaction sequence seed pool.

[0111] The loop test module is used to repeat the test steps based on the new transaction sequence seed pool until the set stop condition is reached, thus completing the test of the given smart contract.

[0112] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0113] Reference Figure 4An embodiment of the present invention further provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory. When the computer program is executed on the processor, a multi-indicator feedback-driven smart contract fuzz testing method as described in any one of the above methods is implemented.

[0114] The computer device may be a desktop computer, notebook computer, PDA, cloud server or other computing device. The computer device may include, but is not limited to, a processor and a memory. It will be understood by those skilled in the art that Figure 4 The computer device is merely an example and does not constitute a limitation on the computer device. The computer device may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the computer device may also include input and output devices, network access devices, etc.

[0115] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0116] In some embodiments, the memory may be an internal storage unit of the computer device, such as a hard drive or memory of the computer device. In other embodiments, the memory may also be an external storage device of the computer device, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped with the computer device. Furthermore, the memory may include both an internal storage unit of the computer device and an external storage device. The memory is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of the computer program. The memory may also be used to temporarily store data that has been output or is about to be output.

[0117] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements a multi-indicator feedback-driven smart contract fuzz testing method as described in any one of the above methods.

[0118] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by using a computer program to instruct the relevant hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a camera / terminal device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, removable hard drives, magnetic disks, or optical disks. In some jurisdictions, based on legislation and patent practice, computer-readable media cannot be electric carrier signals or telecommunication signals.

[0119] An embodiment of the present invention provides a computer program product, including a computer program, which, when executed by a processor, implements a multi-indicator feedback-driven smart contract fuzz testing method as described in any one of the above methods.

[0120] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0121] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0122] In the embodiments disclosed in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0123] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A multi-indicator feedback-driven smart contract fuzz testing method, characterized in that: The steps include: Get the given smart contract; Extracting semantic information of the smart contract using static analysis techniques; Generate a number of transaction sequence seeds based on the semantic information and place them into an initial transaction sequence seed pool; Extracting a test transaction sequence from the transaction sequence seed pool, executing the test on the instrumented EVM, and collecting multi-metric execution feedback information; Calculating the fitness for each of the test transaction sequences taking into account the multi-indicator execution feedback information; Select the test transaction sequence whose fitness meets the set conditions as the next generation test case seed, and discard the rest; Randomly mutating the test case seed to generate several new test cases to make up for the number of discarded test cases; Combining all the current test case seeds to obtain a new transaction sequence seed pool; Based on the new transaction sequence seed pool, the test steps are repeated until the set stop condition is reached, thereby completing the test of the given smart contract; The multi-indicator execution feedback information at least includes: Execution path constraints, code coverage, branch condition distances, read and write memory locations, and data flow relationships; Collect multi-metric execution feedback information, including: Use taint analysis technology to introduce conditional symbol constraints when executing conditional branch statements, and obtain the execution path constraints of the smart contract code branches based on the conditional symbol constraints; Tracking and recording the program counter of the EVM instrumentation during the execution process, and calculating the coverage rate; When a conditional branch statement is executed, the difference between the value of the branch condition variable and the value that the branch condition variable should satisfy is recorded, thereby calculating the branch condition distance; When executing a storage read / write instruction, recording the storage location corresponding to the read / write instruction, and obtaining the read / write storage location; The read and write storage positions of each transaction in the transaction sequence are compared and analyzed, and the data flow relationship between the transactions is obtained based on the overlapping parts of the read and write positions.

2. The multi-indicator feedback driven smart contract fuzz testing method according to claim 1 is characterized in that: Before obtaining the new transaction sequence seed pool, if the coverage rate does not improve after multiple iterations, the following steps may be further performed: A symbolic constraint solver is used to solve the conditional symbolic constraints collected when running the test case, to obtain a test input that can satisfy the conditional symbolic constraints, and to add the test input to the next generation of test cases.

3. The multi-indicator feedback driven smart contract fuzz testing method according to claim 1 is characterized in that: The transaction sequence seed includes a first transaction sequence seed generated using deep learning technology. The deep learning technology uses the semantic information as a model input and uses a pre-trained neural network model to generate key information of the transaction sequence, thereby obtaining the first transaction sequence seed.

4. The multi-indicator feedback driven smart contract fuzz testing method according to claim 1 is characterized in that: The transaction sequence seed also includes a second transaction sequence seed generated using a random combination of data flow analysis technology. The random combination of data flow analysis technology generates a number of transactions by randomly applying a binary interface, and then combines transactions that may have dependencies using data flow analysis technology to obtain the second transaction sequence seed.

5. The multi-indicator feedback driven smart contract fuzz testing method according to claim 1 is characterized in that: Combine all the current test case seeds, including: All current test case seeds are combined in a random manner and / or data flow relationships are used as input to a deep learning model to combine transaction sequences that the deep learning model believes to be correlated.

6. A multi-indicator feedback-driven smart contract fuzz testing device, characterized in that: include: Contract acquisition module, used to obtain a given smart contract; A semantic information extraction module, configured to extract semantic information of the smart contract using static analysis technology; A seed pool generation module, configured to generate a number of transaction sequence seeds based on the semantic information and place them into an initial transaction sequence seed pool; A test execution module, configured to extract a test transaction sequence from the transaction sequence seed pool, execute the test on the instrumented EVM, and collect multi-indicator execution feedback information; A seed pool update module is configured to calculate the fitness of each test transaction sequence taking into account the multi-indicator execution feedback information; select the test transaction sequences whose fitness meets set conditions as the next generation of test case seeds, and discard the rest; perform random mutations on the test case seeds to generate several new test cases to make up for the number of discarded test cases; and combine all current test case seeds to obtain a new transaction sequence seed pool; A loop testing module, configured to continuously repeat the testing steps based on the new transaction sequence seed pool until a set stop condition is reached, thereby completing the testing of the given smart contract; The multi-indicator execution feedback information at least includes: Execution path constraints, code coverage, branch condition distances, read and write memory locations, and data flow relationships; Collect multi-metric execution feedback information, including: Use taint analysis technology to introduce conditional symbol constraints when executing conditional branch statements, and obtain the execution path constraints of the smart contract code branches based on the conditional symbol constraints; Tracking and recording the program counter of the EVM instrumentation during the execution process, and calculating the coverage rate; When a conditional branch statement is executed, the difference between the value of the branch condition variable and the value that the branch condition variable should satisfy is recorded, thereby calculating the branch condition distance; When executing a storage read / write instruction, recording the storage location corresponding to the read / write instruction, and obtaining the read / write storage location; The read and write storage positions of each transaction in the transaction sequence are compared and analyzed, and the data flow relationship between the transactions is obtained based on the overlapping parts of the read and write positions.

7. A computer device, characterized in that: The device includes a processor and a memory: The memory is used to store the computer program and send instructions of the computer program to the processor; The processor executes a multi-indicator feedback-driven smart contract fuzz testing method according to any one of claims 1 to 5 according to the instructions of the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements a multi-indicator feedback-driven smart contract fuzz testing method according to any one of claims 1 to 5.

Images