Intelligent contract vulnerability repairing method and device, computer equipment and storage medium

Abstract

The invention relates to an intelligent contract vulnerability repairing method and device, computer equipment and a storage medium. The method relates to the field of computer software, and solves the problem that the intelligent contract vulnerability repairing effect and efficiency are low. The method comprises the following steps: receiving a query request, wherein the query request carries a contract file to be detected; searching a long-term memory storage system, and obtaining an optimal repair scheme matched with the query request; and generating a user response to the query request according to the optimal repair scheme. The technical scheme provided by the invention is suitable for the smart contract, efficient bug repair is realized, and the accuracy of bug repair is guaranteed.

Description

Technical Field

[0001] This disclosure relates to the field of computer software, specifically to a method, apparatus, computer device, and storage medium for fixing smart contract vulnerabilities. Background Technology

[0002] Smart contracts are dedicated programs that execute on a blockchain. Their core characteristic is immutability; once deployed to the blockchain, a smart contract cannot be modified. This immutability places far higher security demands on smart contracts than on traditional programs. Any vulnerabilities or errors in a smart contract can lead to substantial financial losses and erode public trust in the blockchain ecosystem.

[0003] Vulnerabilities in smart contracts are not entirely unpredictable; they are typically limited in number and exhibit identifiable patterns. This regularity enables the automation of vulnerability detection and remediation, significantly reducing the need for manual code reviews while improving the efficiency and accuracy of the remediation process. Importantly, the technologies developed for smart contract vulnerability remediation are not limited to blockchain applications; they can also be applied to enhance the security of traditional software. For example, by adjusting security requirements and removing the minimum Global Access Server (Gas) consumption limit, methods used to identify and automatically remediate vulnerability patterns in smart contracts can be reused for static analysis and remediation of general code vulnerabilities. Therefore, research on smart contract remediation not only plays a crucial role in ensuring the secure and efficient operation of blockchain systems but can also act as a catalyst for broader advancements in software security. By exploring smart contract remediation, researchers can not only enhance blockchain security but also contribute to the wider field of software development, having a profound impact on the entire industry.

[0004] Smart contract vulnerabilities can be patched using Large Language Models (LLMs), which are trained on data such as vulnerabilities and solutions. In practice, when users pose complex questions with multiple requirements to LLMs, the models often simplify their responses due to various limitations, failing to fully meet all user needs and thus reducing the effectiveness and efficiency of vulnerability patching. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this disclosure provides a method, apparatus, computer equipment, and storage medium for repairing smart contract vulnerabilities.

[0006] According to a first aspect of the present disclosure, a method for fixing smart contract vulnerabilities is provided, comprising:

[0007] Receive a query request, which carries the contract file to be tested;

[0008] Search long-term memory storage systems to obtain the optimal repair solution that matches the query request;

[0009] Based on the optimal repair solution, a user response to the query request is generated.

[0010] Furthermore, after the step of receiving the query request, the method further includes:

[0011] If there is no optimal repair solution matching the query request in the long-term memory storage system, the process enters the inference phase to obtain multiple repair solutions matching the query request.

[0012] Select one of the multiple repair solutions as the optimal repair solution;

[0013] The optimal repair solution is stored in the long-term memory storage system.

[0014] Furthermore, the step of entering the inference phase and obtaining multiple repair solutions matching the query request includes:

[0015] Based on the contract file to be detected in the query request, identify the cause and / or location of the vulnerability;

[0016] The system queries a pre-defined domain resource library to generate the multiple repair solutions.

[0017] Furthermore, the step of selecting one of the plurality of repair solutions as the optimal repair solution includes:

[0018] Based on a preset domain resource library, at least one repair solution compatible with the current operating environment version is selected from the multiple repair solutions.

[0019] Based on the preset domain resource library, calculate the execution resource consumption of each repair scheme that is compatible with the current runtime environment version;

[0020] Select the optimal repair solution from at least one repair solution that is compatible with the current operating environment version, as it has lower execution resource consumption.

[0021] Furthermore, the method also includes:

[0022] Construct a Chained Thinking Transcription (CoT) database, and annotate remediation schemes for different vulnerability types in the CoT database using a small number of CoT annotations;

[0023] Construct a domain knowledge base, and add runtime environment version knowledge and / or execution resource consumption knowledge to the domain knowledge base to provide retrieval support;

[0024] Based on the CoT database and the domain knowledge base, construct the domain resource library.

[0025] Furthermore, the step of storing the optimal repair solution in the long-term memory storage system includes:

[0026] Extract the object data of the optimal repair solution, wherein the object data includes at least one or more of the following information:

[0027] Vulnerability type, error location, fix location, version compatibility information, and the difference in execution resource consumption between the fix and the source code;

[0028] The object data is stored in the long-term memory storage system.

[0029] Furthermore, the step of generating a user response to the query request based on the optimal repair scheme includes:

[0030] Convert the object data of the optimal repair solution into text data in string format;

[0031] The user response is generated based on the text data.

[0032] According to a second aspect of the present disclosure, a smart contract vulnerability repair apparatus is provided, comprising:

[0033] A receiving module is used to receive query requests, which carry the contract file to be detected.

[0034] The long-term memory detection module is used to search the long-term memory storage system and obtain the optimal repair solution that matches the query request.

[0035] The response module is used to generate a user response to the query request based on the optimal repair solution.

[0036] Furthermore, the device also includes:

[0037] The inference module is used to enter the inference phase and obtain multiple repair solutions that match the query request when there is no optimal repair solution matching the query request in the long-term memory storage system.

[0038] The solution selection module is used to select one of the multiple repair solutions as the optimal repair solution;

[0039] A storage module is used to store the optimal repair solution in the long-term memory storage system.

[0040] Furthermore, the inference module includes:

[0041] The analysis submodule is used to identify the cause and / or location of the vulnerability based on the contract file to be detected in the query request.

[0042] The repair submodule is used to query a preset domain resource library to generate the multiple repair solutions.

[0043] Furthermore, the scheme selection module includes:

[0044] The filtering submodule uses a preset domain resource library to select at least one repair solution that is compatible with the current operating environment version from the multiple repair solutions.

[0045] The resource consumption calculation submodule is used to calculate the execution resource consumption of each repair scheme that is compatible with the current runtime environment version, based on a preset domain resource library.

[0046] The selection submodule is used to select the optimal repair solution from at least one repair solution that is compatible with the current runtime environment version, as the one with lower execution resource consumption.

[0047] Furthermore, the device also includes:

[0048] The database construction module is used to build the CoT database, in which remediation schemes for different vulnerability types are annotated with a small number of CoT samples.

[0049] Furthermore, a domain knowledge base is constructed, and runtime environment version information and / or execution resource consumption information are added to the domain knowledge base to provide retrieval support.

[0050] Then, based on the CoT database and the domain knowledge base, the domain resource library is constructed.

[0051] Furthermore, the storage module includes:

[0052] The object data extraction submodule is used to extract the object data of the optimal repair solution, wherein the object data includes at least one or more of the following information:

[0053] Vulnerability type, error location, fix location, version compatibility information, and the difference in execution resource consumption between the fix and the source code;

[0054] The long-term memory storage submodule is used to store the object data in the long-term memory storage system.

[0055] Furthermore, the response module includes:

[0056] The text conversion submodule is used to convert the object data of the optimal repair solution into text data in string format;

[0057] The response generation submodule is used to generate the user response based on the text data.

[0058] According to a third aspect of the present disclosure, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described smart contract vulnerability repair method.

[0059] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described smart contract vulnerability repair method.

[0060] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:

[0061] Upon receiving a query request carrying the contract file to be tested, the system searches the long-term memory storage system to obtain the optimal remediation solution matching the query request. Then, based on the optimal remediation solution, a user response to the query request is generated. By leveraging the long-term memory storage system, the optimal remediation solution for a specific vulnerability is quickly extracted, achieving efficient vulnerability remediation and ensuring the accuracy of the remediation.

[0062] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0063] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0064] Figure 1 This is a flowchart illustrating a smart contract vulnerability repair method according to an exemplary embodiment.

[0065] Figure 2 This is a flowchart illustrating yet another smart contract vulnerability repair method according to an exemplary embodiment.

[0066] Figure 3 This is a flowchart illustrating yet another smart contract vulnerability repair method according to an exemplary embodiment.

[0067] Figure 4 This is a flowchart illustrating yet another smart contract vulnerability repair method according to an exemplary embodiment.

[0068] Figure 5This is a flowchart illustrating yet another smart contract vulnerability repair method according to an exemplary embodiment.

[0069] Figure 6 This is a flowchart illustrating yet another smart contract vulnerability repair method according to an exemplary embodiment.

[0070] Figure 7 This is an illustration of two reentrancy vulnerability remediation cases across different runtime environment versions, based on an exemplary embodiment.

[0071] Figure 8 This is a logical schematic diagram illustrating yet another smart contract vulnerability repair method according to an exemplary embodiment.

[0072] Figure 9 This is an example of the application of a short-term memory storage system and a long-term memory storage system according to an exemplary embodiment.

[0073] Figure 10 This is a block diagram illustrating a smart contract vulnerability repair device according to an exemplary embodiment.

[0074] Figure 11 This is a block diagram illustrating yet another smart contract vulnerability repair device according to an exemplary embodiment.

[0075] Figure 12 This is a structural block diagram of the inference module 1004 according to an exemplary embodiment.

[0076] Figure 13 This is a structural block diagram of a scheme selection module 1005 according to an exemplary embodiment.

[0077] Figure 14 This is a block diagram illustrating yet another smart contract vulnerability repair device according to an exemplary embodiment.

[0078] Figure 15 This is a structural block diagram of a storage module 1006 according to an exemplary embodiment.

[0079] Figure 16 This is a structural block diagram of a response module 1003 according to an exemplary embodiment.

[0080] Figure 17 This is a block diagram of a computer device according to an exemplary embodiment.

[0081] In the picture:

[0082] 1700 - Computer equipment; 1701 - Calculation unit; 1702 - ROM; 1703 - RAM; 1704 - Bus; 1705 - Input / output interface; 1706 - Input unit; 1707 - Output unit; 1708 - Storage unit; 1709 - Communication unit. Detailed Implementation

[0083] Smart contract remediation techniques can be divided into two types: source code rewriting and bytecode rewriting. These typically rely on predefined remediation templates and large amounts of remediation data, lacking universality for various vulnerabilities. Furthermore, remediation techniques primarily focus on deployed smart contracts, neglecting to fix vulnerabilities in undeployed contracts. While manual auditing can resolve these vulnerabilities, this approach is often inefficient and error-prone. In recent years, breakthroughs in LLMs (Local Level Management Systems) for code generation have opened new research avenues for smart contract vulnerability remediation. Unlike traditional methods, LLMs can not only fix vulnerabilities in deployed contracts but also automatically resolve issues discovered during pre-deployment audits. This capability expands the application scenarios of vulnerability remediation, significantly improves remediation efficiency, and reduces the cost and risk of manual intervention.

[0084] For common vulnerability types in smart contracts, effective remediation can be achieved simply by collecting relevant data for each vulnerability. Unlike traditional algorithms such as neural machine translation, LLMs possess powerful inference capabilities and can learn remediation strategies with only a small amount of data, thus reducing reliance on large-scale training datasets. Therefore, LLMs have broad application prospects in the field of smart contract vulnerability remediation.

[0085] Although LLMs have demonstrated powerful reasoning capabilities, some problems still exist in practical applications, such as:

[0086] 1. Difficulty in handling diverse and complex user needs;

[0087] 2. The chosen repair solution was inadequate;

[0088] 3. High time cost.

[0089] To address the aforementioned issues, embodiments of this disclosure provide a method, apparatus, computer device, and storage medium for fixing smart contract vulnerabilities.

[0090] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0091] An exemplary embodiment of this disclosure provides a method for remediating smart contract vulnerabilities. The process of automatically identifying and remediating vulnerabilities in smart contracts using this method is as follows: Figure 1 As shown, it includes:

[0092] Step 101: Receive query request.

[0093] In this step, the repair system (e.g., FlowMemRep) receives a query request initiated by the user, which carries the contract file to be detected.

[0094] According to one exemplary implementation, the query request also includes a prompt word, and the prompt word for each agent consists of three standardized components: role specification, task description (containing specific task requirements), and input / output specifications.

[0095] Step 102: Search the long-term memory storage system to obtain the optimal repair solution that matches the query request.

[0096] In this embodiment, the remediation system includes a short-term memory storage system and a long-term memory storage system. The short-term memory storage system stores the results generated at each stage or step in the remediation scheme generation process, while the long-term memory storage system stores the optimal remediation scheme corresponding to a specific vulnerability type.

[0097] Based on the retrieval needs of computer memory, a hierarchical memory storage mechanism was implemented through short-term memory and long-term memory storage systems, dividing data into short-term memory and long-term memory. During memory retrieval, the system prioritizes processing long-term memory content that has already been processed, rather than short-term memory content (conceptually, short-term memory stores short-term content that may be forgotten; while long-term memory stores long-term content, thereby improving the accuracy of LLMs).

[0098] In this step, after receiving a query request, the repair system first searches the long-term memory storage system to obtain the optimal repair solution in the long-term memory that matches the query request.

[0099] When there is no optimal repair solution matching the query request in the long-term memory storage system, it is necessary to enter the inference phase to generate the optimal repair solution.

[0100] 103. Generate a user response to the query request based on the optimal repair solution.

[0101] In this step, a user response to the query request is generated based on the optimal repair solution.

[0102] According to one exemplary implementation, the user response includes a specific fix for the vulnerability.

[0103] This embodiment of the disclosure, upon receiving a query request carrying a contract file to be tested, searches a long-term memory storage system to obtain the optimal remediation solution matching the query request, and then generates a user response to the query request based on the optimal remediation solution. By leveraging the long-term memory storage system, the optimal remediation solution for a specific vulnerability is quickly extracted, achieving efficient vulnerability remediation and ensuring the accuracy of the remediation.

[0104] An exemplary embodiment of this disclosure also provides a method for fixing smart contract vulnerabilities. This method, when no optimal fix is ​​found in the long-term memory storage system to match the query request, enters the inference phase, combines a preset domain resource library to obtain the optimal fix for the vulnerability in the contract, and stores it long-term. The specific process is as follows: Figure 2 As shown, it includes:

[0105] Step 201: Receive query request.

[0106] In this step, the repair system (e.g., FlowMemRep) receives a query request initiated by the user, which carries the contract file to be detected.

[0107] According to one exemplary implementation, the query request also includes a prompt word, and the prompt word for each agent consists of three standardized components: role specification, task description (containing specific task requirements), and input / output specifications.

[0108] Step 202: Search the long-term memory storage system to obtain the optimal repair solution that matches the query request.

[0109] Step 203: If there is no optimal repair solution matching the query request in the long-term memory storage system, proceed to the inference stage to obtain multiple repair solutions matching the query request.

[0110] In this step, if no optimal repair solution matches the query request in the long-term memory storage system, the process proceeds to the inference phase. A multi-agent workflow composed of multiple LLMs is used to enhance the completeness of smart contract repair, and the accuracy of the repair is improved by integrating thought chain technology with retrieval-enhanced generation technology.

[0111] This step is detailed as follows: Figure 3 As shown, it includes:

[0112] Step 301: Identify the cause and / or location of the vulnerability based on the contract file to be detected in the query request.

[0113] In this step, the vulnerable features and types in the smart contract can be identified through audit reports or vulnerability detection tools.

[0114] According to one exemplary implementation, this step is the analysis phase. The main task of the analysis phase is to identify the cause and / or location of the error (e.g., the specific line of code with the vulnerability) to pinpoint the faulty path. Users can provide faulty function fragments and vulnerability classification information through tools such as audit reports. The role of the analysis phase is to integrate this information to help the remediation phase understand the input. Therefore, the analysis phase plays a bridging role and typically does not require additional intervention.

[0115] Step 302: Query the preset domain resource library to generate the multiple repair solutions.

[0116] According to one exemplary implementation, the domain resource repository includes a CoT database and a domain knowledge base. The CoT database contains remediation schemes for different vulnerability types annotated with a small sample of CoT data; the domain knowledge base includes runtime environment version information and / or execution resource consumption information to provide retrieval support.

[0117] In this step, the preset domain resource library contains remediation solutions for different vulnerability types, and each vulnerability type has at least one information solution.

[0118] According to one exemplary implementation, this step is the remediation phase. By querying the CoT database, corresponding code remediation cases are obtained, and multiple remediation solutions are generated accordingly. Because the CoT database was pre-built, the computational resource requirements for generating remediation solutions in this step are significantly reduced, thus lowering the performance requirements of the LLMs used to generate multiple remediation solutions, resulting in lower implementation costs and higher reliability.

[0119] Step 204: Select one of the multiple repair solutions as the optimal repair solution.

[0120] In this step, to further improve the quality and efficiency of the remediation, multiple remediation solutions for the same vulnerability type are further screened to obtain the optimal solution. The specific process is as follows: Figure 4 As shown, it includes:

[0121] Step 401: Based on the preset domain resource library, select at least one repair solution that is compatible with the current operating environment version from the multiple repair solutions.

[0122] According to one exemplary implementation, this step is a filtering phase. The core task of the filtering phase is to check the compatibility of each remediation scheme with the runtime environment version (e.g., Solidity version). By performing vector similarity retrieval and comparison between the remediation scheme and the content in the domain knowledge base, incompatible schemes are eliminated, thereby reducing the computational burden on subsequent execution resources.

[0123] Step 402: Based on the preset domain resource library, calculate the execution resource consumption of each repair scheme that is compatible with the current operating environment version.

[0124] In this step, the resource consumption of at least one repair scheme selected in step 401 is calculated to determine the resource messages for using different repair schemes.

[0125] According to one exemplary implementation, this step is a resource consumption calculation stage, specifically a Gas calculation stage. First, the repair plan is compared with the faulty lines identified in the analysis stage to find the repaired lines. Then, Gas calculation is performed using zero-sample hints, guiding LLMs to calculate Gas consumption as the execution resource consumption, and the calculation results are sorted.

[0126] Step 403: Select the optimal repair solution from at least one repair solution that is compatible with the current operating environment version, as the repair solution with lower execution resource consumption.

[0127] In this step, after sorting the repair schemes according to their execution resource consumption, the repair scheme with the lowest or lowest execution resource consumption is selected as the optimal repair scheme.

[0128] Step 205: Store the optimal repair solution in the long-term memory storage system.

[0129] In this step, after determining the optimal repair solution, the optimal repair solution can be stored so that it can be retrieved and used directly from the long-term memory storage system later.

[0130] The specific process is as follows: Figure 5 As shown, it includes:

[0131] Step 501: Extract the object data of the optimal repair scheme.

[0132] The object data includes at least one or more of the following information:

[0133] Vulnerability type, error location, fix location, version compatibility information, and the difference in execution resource consumption between the fix and the source code.

[0134] The vulnerability type can be a "classification" object, which contains information about the vulnerability type.

[0135] The bug location can be a "bug_location" object, which contains information about the location of the vulnerability, such as line x of the code.

[0136] The fix location can be a "fix_location" object, which contains information about the optimal fix, such as the nth fix for a certain vulnerability type.

[0137] Version compatibility information indicates whether the fix adopted (e.g., including the fix number) meets compatibility requirements, and can include two states: correct and incorrect.

[0138] The difference in execution resource consumption between the repair solution and the source code can be represented as "condition_n", indicating the difference in execution resource consumption between the nth repair solution and the original faulty source code. When using gas consumption to measure execution resource consumption, it can specifically be the gas consumption difference.

[0139] The optimal repair solution is described using object data, and the optimal repair solution can be restored based on the object data, and a user response can be generated.

[0140] Step 502: Store the object data in the long-term memory storage system.

[0141] In this step, object data is stored using a long-term storage mechanism. According to one exemplary implementation, object data can be stored in a long-term memory storage system.

[0142] Step 206: Generate a user response to the query request based on the optimal repair solution.

[0143] In this step, based on the obtained optimal repair solution, a user response to the query request can be generated, carrying information such as the optimal repair solution and the repair process. The specific process is as follows: Figure 6 As shown, it includes:

[0144] Step 601: Convert the object data of the optimal repair scheme into text data in string format.

[0145] In this step, the object data is converted into text data in string format.

[0146] Step 602: Generate the user response based on the text data.

[0147] In this step, LLMs generate the final user response based on text data. This design effectively reduces system latency while ensuring that the repair solution meets both user needs and accuracy expectations.

[0148] According to one exemplary implementation, the analysis phase, repair phase, filtering phase, and resource consumption calculation phase can be implemented by different agents. These different agents can be implemented using one or more LLMs.

[0149] An exemplary embodiment of this disclosure also provides a method for remediating smart contract vulnerabilities, which further improves the efficiency of generating remediation solutions by pre-building a domain resource library. The specific construction method is as follows:

[0150] Domain resource repositories include the CoT database and / or domain knowledge bases.

[0151] 1. The CoT database serves as a resource repository for remediation solutions, enabling remediation systems to retrieve and generate optimal solutions. Furthermore, to ensure that the remediation system fully understands the logic process of vulnerability remediation, CoT hints can be used to enhance the reasoning capabilities of LLMs and facilitate their learning of vulnerability remediation strategies.

[0152] CoT hints originate from the CoT database. When constructing the CoT database, smart contracts with reentrancy vulnerabilities are categorized into several different typical vulnerability / error types, and then a small sample of CoT annotations is used to specify the corresponding remediation scheme for each vulnerability / error type. Figure 7 Two typical reentrancy vulnerability remediation cases are shown across different runtime environment versions (e.g., language versions, specifically Solidity versions). The main goal of both cases is to minimize execution resource consumption (e.g., gas consumption). Figure 7 The upper part of the diagram shows the fix for Solidity version 0.8.0. The root cause of this vulnerability is that the balance reduction operation (see line 9) lacks reentrancy protection, allowing attackers to exploit it through repeated calls. The optimal fix is ​​to remove line 9 and insert the balance reduction operation in line 7, implementing the logic of "reducing the balance before transferring funds." This solution not only meets the version requirements but also minimizes additional gas consumption (i.e., zero gas difference).

[0153] against Figure 7 The issues raised, and the main reference information for performing few-shot CoT annotation (e.g., Few-shot CoT), are as follows:

[0154] (1) Faulty line: "balances[msg.sender]-=amount;" (line 9), the vulnerability is in "-=".

[0155] (2) The relevant line is: “msg.sender.transfer(amount);” (line 8), where the relevant function is “transfer()”.

[0156] (3) Repair line: "Insert balances[msg.sender]-=amount; before line 8, and delete the original line 9.

[0157] Here is a specific example of few-sample CoT annotation:

[0158] ① / / Provides fixes for problematic functions}, followed by "problematic functions".

[0159] ②Let's think step by step. The problematic line is "balances[msg.sender]-=amount;", with the error occurring at the "-=" position. The relevant line is "msg.sender.transfer(amount);", with the relevant position being "transfer()". It is followed by "Fixed Function".

[0160] ③Let's think step by step. The repair line is "balances[msg.sender]-=amount;", inserted before the relevant line.

[0161] The " / / " format is used as a prefix to indicate smart contract comments. Additionally, "Let's think step by step." can be used as a prompt, which, based on previous research, suggests that LLMs can better provide reasoning. This code-fixing scheme provides a more complex case for few-sample CoT annotation, requiring multi-line comments and consideration of the variability of the fix. For example, LLMs may not recognize the semantic similarity between "-=" and "+=" during the fix, leading to incorrect fixes. To ensure the completeness and accuracy of few-sample CoT annotations, it is crucial that the system annotates smart contract vulnerabilities of different vulnerability / error types. Finally, all annotation solutions are aggregated and processed through text segmentation. Due to the specific nature of the code, attention must be paid to the coherence of the context during segmentation to prevent the CoT hints from becoming separated from the code itself, thus rendering the annotations invalid.

[0162] 2. The domain knowledge base is constructed to provide knowledge retrieval support for the filtering and resource consumption calculation phases, enabling it to provide accurate responses based on scenario requirements. The domain knowledge base must contain at least one or more of the following:

[0163] Knowledge of runtime environment version and execution resource consumption.

[0164] In this embodiment, Solidity version is used as the runtime environment version, and Gas consumption is used as the execution resource consumption for illustration.

[0165] (1) Solidity version knowledge, including the differences between different Solidity versions and their standard documentation.

[0166] Due to the nature of smart contracts, Solidity continuously releases new features to meet user needs while ensuring security and compatibility. Different Solidity versions require different fixes when repairing smart contracts. For example, in... Figure 2 In the lower half, if using Solidity version 0.8.26, it can be done by... Figure 7 The `call` function in line 7 of the code was replaced with the `transfer` function to fix the reentrancy vulnerability. This change was made after the DAO vulnerability incident; Solidity aggregated the gas consumption of basic operations (such as logging) and set the gas cap for the transfer function to 2300 Gas. However, this fix is ​​not applicable to Solidity versions prior to 0.8.0. Therefore, if the version number changes, we need to consider using a "check-impact-interact" approach (such as...). Figure 7 The vulnerability is patched (as shown in the upper part). It's important to note that if the version number is higher than 0.8.0, modifying the function is a more effective patching approach, as it helps LLMs better understand the patching logic and achieve higher accuracy.

[0167] To build Solidity version knowledge, we can use the standard release announcements officially published by Solidity, combined with version comparison documents retrieved from the internet. Due to the massive amount of version-related information and the complexity of version numbers, we can first use LLMs to convert the collected version information data into easily parsed and readable object data, and then verify the acquired data to confirm the accuracy of the documents. Next, we perform text segmentation, taking care to avoid losing important information such as version numbers to ensure convenient retrieval of the knowledge base. On the other hand, with each version update, some features will also change. When the version number does not match the feature, a typical vulnerability—the deprecated feature vulnerability—may occur. Therefore, while collecting version knowledge, it is also necessary to track version and feature changes, annotate the collected content according to the CoT's prompts, and store it in the CoT database.

[0168] (2) Gas consumption knowledge, covering the logic behind gas calculations and gas consumption data based on opcodes. The formula for calculating gas consumption is as follows:

[0169]

[0170] Here, "Gas" represents gas consumption, "N" represents the number of operation types, "Op" represents the number of operations, and "Cost" represents the cost per operation. "Op" requires LLMs to translate the source code into opcodes, and "N" is derived by statistically counting the number of translated opcodes. Therefore, these two parts require enhancing the reasoning capabilities of LLMs. To improve the accuracy of LLMs in opcode compilation, an opcode compilation resource library can be built using relevant EVM opcode documentation and recent research papers. "Cost" represents the cost per opcode and is a key component of the gas cost stage knowledge base. It should be noted that the EVM opcodes have undergone several changes and additions since the project's release in 2021. Therefore, necessary modifications and updates can be made according to relevant guidelines. The cost table is typically presented as a dataset, with each row converted into an embedding vector. LLMs retrieve relevant tabular data through vector similarity and calculate the gas cost using the method specified in the hints.

[0171] By building a domain resource library, strong data support is provided for reasoning to generate repair solutions and reading long-term memory to obtain repair solutions, thereby ensuring the accuracy and efficiency of automatic vulnerability repair.

[0172] An exemplary embodiment of this disclosure also provides a method for remediating smart contract vulnerabilities. FlowMemRep, which includes an inference phase and a retrieval and generation phase, calls the appropriate phase based on the application environment to achieve efficient and accurate automatic remediation of smart contract vulnerabilities. In this embodiment, a reentrant vulnerability is used as an example; Gas consumption is used as the execution resource consumption, and the Solidity version is used as version compatibility information. The implementation process is as follows: Figure 8 As shown.

[0173] FlowMemRep consists of two main phases: 1. Inference phase, Figure 8 The blue box indicates the part; 2. Search generation stage, Figure 8 The red boxes indicate the regions represented in the diagram. During the inference phase, a multi-agent workflow consisting of multiple LLMs (represented by the yellow low-shading) is used to enhance the model's integrity and accuracy. In the retrieval and generation phase, a memory mechanism (represented by the green boxes) integrates the workflow results from the inference phase, further improving model efficiency.

[0174] The goal of the reasoning phase is to enhance the integrity of smart contract repair through a multi-agent mechanism and improve the accuracy of repair by integrating thought chain technology with retrieval-enhanced generation technology.

[0175] 1. Multi-Agent System Based on Process Engineering (PE). Vulnerable functions and types in smart contracts can be identified through audit reports or vulnerability detection tools. Therefore, vulnerability remediation in real-world projects is carried out under the condition that the vulnerability location and cause are known. In this process, remediation must comprehensively consider the root cause of the vulnerability, version requirements, and gas consumption to obtain the lowest cost and highest accuracy solution. However, when users raise complex problems with multiple requirements to LLMs, LLMs often simplify their responses due to various limitations and cannot fully meet all the user's needs. Therefore, a single interaction with a single LLM is insufficient to meet the remediation requirements. In this embodiment, the remediation task is decomposed and processed in stages by LLMs, effectively solving this complex problem. At the same time, experiments show that LLMs can usually include the correct optimal solution among multiple candidate remediation solutions, but they perform poorly in selecting the best solution. Therefore, while utilizing LLMs for optimal solution selection, the reasoning ability of LLMs is enhanced, and their domain knowledge in smart contract remediation is improved to increase the accuracy of remediation. Given the determinism required for smart contract remediation solutions—a good remediation solution must simultaneously consider the cause of the vulnerability, version compatibility, and gas consumption efficiency—this disclosure employs a workflow-based approach to handle smart contract vulnerability remediation.

[0176] like Figure 8 As shown, the smart contract vulnerability remediation process is divided into four stages: analysis stage, remediation stage, filtering stage, and gas calculation stage. The specific tasks of each stage are as follows:

[0177] (1) Analysis Phase. The main task of the analysis phase is to identify the cause of the error and the specific line of code containing the vulnerability. Users can provide the error location (e.g., the faulty function fragment) and vulnerability type (e.g., vulnerability classification information) through tools such as audit reports. The role of the analysis phase is to integrate this information to help the remediation phase understand the input. Therefore, the analysis phase plays a bridging role and usually does not require additional intervention.

[0178] (2) Repair Phase. The repair phase generates as many repair solutions as possible based on the code repair cases provided by the CoT database. According to one exemplary implementation, the CoT database is built using Retrieval Enhancement Generation (RAG). This ensures that even when using lower-performance LLMs, repair solutions containing optimal solutions can be generated during the repair phase.

[0179] (3) Filtering Phase. The core task of the filtering phase is to check the compatibility of the repair scheme with the Solidity version. By performing vector similarity retrieval and comparison between the repair scheme and the content in the domain knowledge base, incompatible schemes are eliminated, thereby reducing the computational burden of the subsequent Gas cost phase. Finally, the filtering phase passes the compatible repair schemes to the Gas calculation phase.

[0180] (4) Gas Calculation Stage. The Gas Calculation Stage calculates the Gas consumption of the repair schemes selected after the Filtering Stage.

[0181] First, the repair solutions are compared with the faulty lines identified in the analysis phase to find the corrected lines. Then, gas calculations are performed using zero-sample hints to guide LLMs in calculating gas consumption, and the multiple repair solutions are ranked according to the gas consumption calculation results.

[0182] Finally, the system summarizes the results of each stage and generates a response, which users can view through the chatbot's reply. The inference stage primarily addresses the issues of completeness and accuracy. Furthermore, among the four stages of prompt word design, the Gas calculation stage is the most complex because it requires comparing and analyzing the code before and after the fix, and generating CoT prompt words containing Gas consumption calculation logic. According to one exemplary implementation, the standardized prompt word framework requires each agent's prompt words to consist of three standardized components: role specification, task description (containing specific task requirements), and input / output specifications. This unified standardized prompt word framework ensures the reliability of the results generated by each agent. For specific prompt word content, readers can refer to the project resources provided in the data availability statement at the end of the article.

[0183] 2. The main task of the retrieval generation stage is to effectively solve the high latency problem caused by the workflow while ensuring the integrity and accuracy of the reasoning in the previous stage. This phenomenon not only exists in the continuity of the workflow, but is also a common feature of reasoning-based LLMs when handling complex tasks. From the perspective of talent analogy, reasoning-based LLMs can be regarded as generalists with rich knowledge reserves, while the non-reasoning model "ChatGPT-4o-mini" used in the subsequent experimental workflow can be compared to an expert. Although experts can only handle relatively simple tasks, they can effectively solve complex problems through standardized data design and process-based collaboration mechanisms, similar to an assembly line operation. On the other hand, optimizing the accuracy of large-scale inference models is more complex. Both accuracy improvement and latency cost control require continuous research and development, and breakthroughs are difficult to achieve in the short term. The embodiments of this disclosure adopt a customized workflow and memory mechanism to balance inference accuracy and latency cost. While relying on the memory mechanism cannot balance accuracy and latency, the effective memory obtained is used to promote the generation of LLMs, and the memory mechanism is linked to the workflow. According to one exemplary implementation, the retrieval generation phase is divided into two aspects: (a) the memory mechanism of FlowMemRep and (b) the interconnection of reasoning-retrieval-generation (RRG).

[0184] (a) Memory mechanisms. For example... Figure 8 As shown, the memory mechanism consists of three core components: memory encoding, memory storage, and memory retrieval. Based on the retrieval requirements of computer memory, embodiments of this disclosure implement a hierarchical memory storage system, including: a short-term memory storage system for processing short-term memory and a long-term memory storage system for processing long-term memory. During memory retrieval, the system prioritizes processing already processed long-term memory rather than short-term memory content (conceptually, short-term memory stores short-term memory content that may be forgotten; while long-term memory stores long-term memory content, thereby improving the accuracy of LLMs). Memory is stored in two formats: object data in key-value pair (KV) format and text data in string format.

[0185] The specific implementation process is as follows: Each stage of the vulnerability remediation process corresponds to an agent. Specifically, the analysis stage corresponds to an analysis agent, the remediation stage to a remediation agent, the filtering stage to a filtering agent, and the gas calculation stage to a gas calculation agent. Each agent encodes the received information and generated text data into object data, such as... Figure 8 As shown by the dashed line.

[0186] In such Figure 9In Algorithm 1, each agent performs different forms of memory encoding based on its role (see line 1): The object data encoded by the analysis agent includes: the "role", "classification", "bugline", and "buglocation" of the vulnerability remediation scheme (see line 4). The object data encoded by the remediation agent includes: the "role", "bug location", "fixed_line_n", and "fix_location_n" of multiple generated remediation schemes (see line 6). Then, the object data encoded by the filtering agent includes: the "role" of each remediation scheme provided by the remediation agent, the "version" of Solidity, the "fix_location_n" of each remediation scheme provided by the remediation agent, and the "condition_n" (status, including correct and incorrect) indicating whether each remediation scheme passes the filtering agent (see line 8). Finally, the object data encoded by the Gas agent includes: the "role" of each remediation scheme provided by the remediation agent, the "fix_location_n" of each remediation scheme provided by the remediation agent, and the difference between each remediation scheme and the "Gas_n" in the source code (see line 10).

[0187] After the data is converted into a structured format, the system enters the memory storage phase. See [link / reference]. Figure 9 (See line 12 of Algorithm 1). The storage structure consists of short-term memory and long-term memory. Object data generated by each agent is initially stored in short-term memory (see line 15). Then, the system searches for the nth remediation scheme corresponding to the vulnerability location, which has passed the detection of the filtering agent and has the minimum gas consumption (see line 16). The object data of the optimal remediation scheme is extracted, including the vulnerability remediation's "classification", "bug_location", "fix_location", "condition_n", and the "Gas_n" difference between the remediation scheme and the source code (see line 17). This data is stored in the long-term memory storage system (see line 18) or subsequently retrieved and generated by LLMs. The extraction agent retrieves the object data row corresponding to the error location of the error function F from the long-term memory storage system (see line 22). After successful data loading, the system converts the object data into text data in string format. LLMs generate the final user response based on this text data. This design effectively reduces system latency while ensuring that the remediation scheme meets both user needs and accuracy expectations.

[0188] (b) RRG Interconnection. The memory mechanism alone cannot fully achieve deep integration between the inference and retrieval-generation stages; therefore, an additional linkage mechanism is required. For specific implementation details, please refer to... Figure 9 The Interconnect-RRG function in Algorithm 1. The following outlines the specific workflow of this architecture in a user question-and-answer scenario: When a user submits a query ① to the FlowMemRep system, the query is first processed by the decision agent. The decision agent extracts key information from the query and searches long-term memory to determine if relevant memories exist in the system (see line 28), then the system proceeds to branch ②. If the decision agent finds that the buggy function F already exists in long-term memory, the system proceeds to the extraction generation stage ③B and directly executes the Extract function (see line 30). Experimental data shows that this stage reduces latency to approximately 8 seconds (s), a significant improvement compared to the 38-second (s) latency of the reasoning stage. If the retrieval is unsuccessful, the system proceeds to the reasoning stage ③A (see line 32). As shown in the Reasoning function of Algorithm 1, the memory collection process includes the following steps: First, the problematic function F goes through four reasoning stages—analysis, repair, filtering, and gas consumption—to generate an answer (see line 37). Then, the system records the string format corresponding to each role (see line 38) for subsequent encoding operations.

[0189] An exemplary embodiment of this disclosure also provides a smart contract vulnerability remediation method, which automatically remediates vulnerabilities using FlowMemRep, a two-stage approach comprising an inference stage and a retrieval generation stage. In the inference stage, a CoT database based on smart contract remediation data using few-sample CoT hints is constructed, along with a domain knowledge base containing Solidity standards, gas calculation logic, and opcode-based gas consumption data. The automatic vulnerability remediation process is divided into four stages—"analysis, remediation, filtering, and gas consumption"—each optimized using RAG and fast tuning. To avoid high latency caused by reliance on multiple LLMs, an encoding-storage-retrieval memory mechanism is used, which records inference results and retrieves them via LLMs. Then, the agent determines whether a remediation solution exists in memory, dividing the process into a memoryless inference stage and a memory-based retrieval generation stage. This mechanism seamlessly connects the two stages, ensuring the completeness and accuracy of the remediation while significantly reducing latency.

[0190] The technical solution provided in this disclosure can effectively improve the completeness and accuracy of the repair solution, save computational costs, and has better scalability. Specifically:

[0191] (1) Completeness and accuracy: Semantic similarity analysis of 205 vulnerability cases showed completeness between 60% and 92%, while ablation studies confirmed the highest accuracy (93%) in version assessment and gas sorting. FlowMemRep achieved a 75% fix accuracy even in the “ChatGPT-4o-mini” environment.

[0192] (2) Time and Gas Consumption: The memory mechanism reduces time costs by 80%, making FlowMemRep 52% ​​faster than methods based on a single LLM. In addition, 90% of the fixes keep the increase in gas consumption between 0% and 1%, in line with user expectations.

[0193] (3) Scalability: Memory extrapolation improves repair efficiency. While maintaining accuracy, the time cost only increases by 16% (about 1 second), which is still significantly lower than inference methods based on a single LLM.

[0194] An exemplary embodiment of this disclosure also provides a smart contract vulnerability repair device, the structure of which is as follows: Figure 10 As shown, it includes:

[0195] The receiving module 1001 is used to receive a query request, wherein the query request carries a contract file to be detected;

[0196] The long-term memory detection module 1002 is used to search the long-term memory storage system and obtain the optimal repair solution that matches the query request.

[0197] The response module 1003 is used to generate a user response to the query request based on the optimal repair solution.

[0198] Furthermore, the device is as follows Figure 11 As shown, it also includes:

[0199] The inference module 1004 is used to enter the inference stage and obtain multiple repair solutions that match the query request when there is no optimal repair solution matching the query request in the long-term memory storage system.

[0200] The scheme selection module 1005 is used to select one of the multiple repair schemes as the optimal repair scheme;

[0201] Storage module 1006 is used to store the optimal repair solution in the long-term memory storage system.

[0202] Furthermore, the structure of the inference module 1004 is as follows: Figure 12 As shown, it includes:

[0203] Analysis submodule 1201 is used to identify the cause and / or location of the vulnerability based on the contract file to be detected in the query request.

[0204] The repair submodule 1202 is used to query a preset domain resource library to generate the multiple repair solutions.

[0205] Furthermore, the structure of the scheme selection module 1005 is as follows: Figure 13 As shown, it includes:

[0206] The filtering submodule 1301 uses a preset domain resource library to select at least one repair scheme that is compatible with the current operating environment version from the multiple repair schemes.

[0207] The resource consumption calculation submodule 1302 is used to calculate the execution resource consumption of each repair scheme that is compatible with the current running environment version based on the preset domain resource library.

[0208] Selection submodule 1303 is used to select the optimal repair solution from at least one repair solution that is compatible with the current runtime environment version, as the repair solution with lower execution resource consumption.

[0209] Furthermore, the device is as follows Figure 14 As shown, it also includes:

[0210] Database construction module 1007 is used to construct a chain-thinking CoT database, in which remediation schemes for different vulnerability types are annotated using a small number of CoT samples.

[0211] Furthermore, a domain knowledge base is constructed, and runtime environment version information and / or execution resource consumption information are added to the domain knowledge base to provide retrieval support.

[0212] Then, based on the CoT database and the domain knowledge base, the domain resource library is constructed.

[0213] Furthermore, the structure of the storage module 1006 is as follows: Figure 15 As shown, it includes:

[0214] The object data extraction submodule 1501 is used to extract the object data of the optimal repair scheme, wherein the object data includes at least one or more of the following information:

[0215] Vulnerability type, error location, fix location, version compatibility information, and the difference in execution resource consumption between the fix and the source code;

[0216] Long-term memory storage submodule 1502 is used to store the object data in the long-term memory storage system.

[0217] Furthermore, the structure of the response module 1003 is as follows: Figure 16 As shown, it includes:

[0218] The text conversion submodule 1601 is used to convert the object data of the optimal repair scheme into text data in string format;

[0219] The response generation submodule 1602 is used to generate the user response based on the text data.

[0220] Each module in the aforementioned smart contract vulnerability repair device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0221] In one exemplary embodiment, a computer device is provided, including a processor and a memory, the memory storing a computer program, and the processor executing the computer program implementing any of the above-described smart contract vulnerability repair methods.

[0222] In one exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements any of the smart contract vulnerability remediation methods described above. The computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, or optical data storage device, etc.

[0223] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the above-described smart contract vulnerability repair methods.

[0224] refer to Figure 17 The following is a structural block diagram of a computer device that can serve as a smart contract vulnerability repair apparatus according to the present disclosure. The computer device includes a computing unit 1701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 1702 or a computer program loaded from a storage unit 1708 into a random access memory (RAM) 1703. The RAM 1703 may also store various programs and data required for the operation of the computer device 1700. The computing unit 1701, ROM 1702, and RAM 1703 are interconnected via a bus 104. An input / output (I / O) interface 1705 is also connected to the bus 1704.

[0225] Multiple components in computer device 1700 are connected to I / O interface 1705, including: input unit 1706, output unit 1707, storage unit 1708, and communication unit 1709. Input unit 1706 can be any type of device capable of inputting information into computer device 1700. Input unit 1706 can receive input numerical or character information and generate key signal inputs related to user settings and / or function control of computer device 1700, and may include, but is not limited to, a mouse, keyboard, touchscreen, trackpad, trackball, joystick, microphone, and / or remote control. Output unit 1707 can be any type of device capable of presenting information, and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 1708 may include, but is not limited to, a hard disk and an optical disk. The communication unit 1709 allows the computer device 1700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices and / or the like.

[0226] The computing unit 1701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1701 performs the various methods and processes described above, such as smart contract vulnerability remediation methods. For example, in some embodiments, the smart contract vulnerability remediation method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1708. In some embodiments, part or all of the computer program may be loaded and / or installed on the computer device 1700 via ROM 1702 and / or communication unit 1709. When the computer program is loaded into RAM 1703 and executed by the computing unit 1701, one or more steps of the smart contract vulnerability remediation method described above may be performed. Alternatively, in other embodiments, computing unit 1701 may be configured to execute smart contract vulnerability remediation methods by any other suitable means (e.g., by means of firmware).

[0227] Computer device 1700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the smart contract vulnerability remediation method described above.

[0228] This disclosure provides a method, apparatus, computer device, and storage medium for patching smart contract vulnerabilities. Upon receiving a query request carrying a contract file to be tested, the method searches a long-term memory storage system to obtain the optimal patching solution matching the query request. Then, based on the optimal patching solution, a user response to the query request is generated. By leveraging the long-term memory storage system, the optimal patching solution for a specific vulnerability is quickly extracted, achieving efficient vulnerability patching and ensuring the accuracy of the patching.

[0229] A CoT database based on a small sample size was pre-built, which reduced the amount of computation required to generate multiple remediation solutions for vulnerabilities, lowered resource consumption, reduced the cost of implementing the solutions, and improved reliability.

[0230] While large language models (LLMs) have achieved initial success in areas such as smart contract auditing, vulnerability detection, and program repair, their application in smart contract vulnerability repair is still in its early stages. Furthermore, existing research primarily focuses on fine-tuning methods, such as retrieval enhancement generation, hint engineering, and low-rank adaptation, often neglecting the potential of memory mechanisms to improve model efficiency and accuracy. The technical solution disclosed in this publication combines a deterministic workflow with retrieval enhancement techniques to improve the logical reasoning capabilities of LLMs, thereby increasing repair accuracy. In addition, a memory mechanism is introduced to optimize the efficiency of LLMs in handling similar tasks, significantly shortening repair time. This not only improves the efficiency of smart contract repair but also provides new insights for the wider application of LLMs in code repair and related fields.

[0231] The execution of smart contracts is limited by computing resources (such as gas consumption). The technical solution provided in this disclosure ensures code security while optimizing gas consumption, minimizing computational costs and avoiding resource waste.

[0232] Those skilled in the art will understand that all or part of the steps in the above methods can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. Optionally, all or part of the steps in the above embodiments can also be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiments can be implemented in hardware or as a software functional module. This invention is not limited to any particular combination of hardware and software.

[0233] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the following claims.

[0234] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for fixing smart contract vulnerabilities, characterized in that, The method comprises: receiving a query request, wherein the query request carries a contract file to be detected; searching a long-term memory storage system to obtain an optimal repair scheme matched with the query request; generating a user response to the query request according to the optimal repair scheme. 2.The smart contract vulnerability repairing method of claim 1, wherein, After the step of searching the long-term memory storage system to obtain the optimal repair scheme matched with the query request, the method further comprises: in the case that there is no optimal repair scheme matched with the query request in the long-term memory storage system, entering an inference stage to obtain a plurality of repair schemes matched with the query request; selecting one of the plurality of repair schemes as the optimal repair scheme; storing the optimal repair scheme in the long-term memory storage system. 3.The smart contract vulnerability repairing method of claim 2, wherein, The step of entering the inference stage to obtain the plurality of repair schemes matched with the query request comprises: identifying a bug error cause and / or a bug location according to the contract file to be detected in the query request; querying a preset domain resource library to generate the plurality of repair schemes. 4.The smart contract vulnerability repairing method of claim 2, wherein, The step of selecting one of the plurality of repair schemes as the optimal repair scheme comprises: filtering at least one repair scheme compatible with a current running environment version from the plurality of repair schemes according to the preset domain resource library; respectively calculating execution resource consumptions of the repair schemes compatible with the current running environment version according to the preset domain resource library; selecting a repair scheme with a lower execution resource consumption from the at least one repair scheme compatible with the current running environment version as the optimal repair scheme.

5. The smart contract vulnerability fixing method of claim 3 or 4, wherein, The method further comprises: constructing a chain-of-thought (CoT) database, wherein repair schemes of different bug types are annotated by a few-shot CoT in the CoT database; constructing a domain knowledge base, wherein running environment version knowledge and / or execution resource consumption knowledge are added to the domain knowledge base to provide retrieval support; constructing the domain resource library according to the CoT database and the domain knowledge base. 6.The smart contract vulnerability repairing method of claim 2, wherein, The step of storing the optimal repair scheme in the long-term memory storage system comprises: extracting object data of the optimal repair scheme, wherein the object data at least includes any one or any combination of the following information: a bug type, a bug location, a repair location, version compatibility information, and an execution resource consumption difference between a repair scheme and source code; storing the object data in the long-term memory storage system. 7.The smart contract vulnerability repairing method of claim 1, wherein, The step of generating a user response to the query request according to the optimal repair scheme comprises: converting the object data of the optimal repair scheme into text data in a string format; generating the user response according to the text data.

8. An intelligent contract vulnerability fixing apparatus, characterized by comprising: The apparatus comprises: a receiving module configured to receive a query request, wherein the query request carries a contract file to be detected; a long-term memory detection module configured to search a long-term memory storage system to obtain an optimal repair scheme matched with the query request; a response module configured to generate a user response to the query request according to the optimal repair scheme.

9. The smart contract vulnerability fixing apparatus according to claim 8, wherein The apparatus further comprises: The reasoning module is configured to enter a reasoning stage when there is no optimal repair scheme matched with the query request in the long-term memory storage system, and obtain a plurality of repair schemes matched with the query request. The scheme selection module is configured to select one of the plurality of repair schemes as the optimal repair scheme. The storage module is configured to store the optimal repair scheme in the long-term memory storage system. 10.The smart contract vulnerability fixing apparatus of claim 9, wherein, The reasoning module comprises: The analysis submodule is configured to identify error causes and / or error positions of vulnerabilities according to the contract file to be detected in the query request. The repair submodule is configured to query a preset domain resource library to generate the plurality of repair schemes. 11.The smart contract vulnerability fixing apparatus of claim 9, wherein, The scheme selection module comprises: The filtering submodule is configured to filter at least one repair scheme compatible with a current running environment version from the plurality of repair schemes according to the preset domain resource library. The resource consumption calculation submodule is configured to calculate execution resource consumption of each repair scheme compatible with the current running environment version according to the preset domain resource library. The selection submodule is configured to select a repair scheme with lower execution resource consumption from the at least one repair scheme compatible with the current running environment version as the optimal repair scheme.

12. The smart contract vulnerability fixing apparatus according to claim 10 or 11, wherein, The apparatus further comprises: The database construction module is configured to construct a chain-of-thought (CoT) database and a domain knowledge base. The CoT database is annotated with repair schemes of different vulnerability types by a few-shot CoT. The domain knowledge base is added with running environment version knowledge and / or execution resource consumption knowledge to provide retrieval support.

13. The smart contract vulnerability fixing apparatus of claim 9, wherein Then, the domain resource library is constructed according to the CoT database and the domain knowledge base. The storage module comprises: The object data extraction submodule is configured to extract object data of the optimal repair scheme, the object data comprising at least any one or any combination of the following information: vulnerability type, error position, repair position, version compatibility information, and execution resource consumption difference between the repair scheme and source code. 14.The smart contract vulnerability fixing apparatus of claim 8, wherein, The long-term memory storage submodule is configured to store the object data in the long-term memory storage system. The response module comprises: The text conversion submodule is configured to convert the object data of the optimal repair scheme into text data in a string format.

15. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The response generation submodule is configured to generate the user response according to the text data.

16. A computer readable storage medium having stored thereon a computer program, characterized in that, The processor executes the computer program to implement the method in any one of claims 1 to 7. The computer program is executed by the processor to implement the method in any one of claims 1 to 7.

Images