A pattern-driven automatic repair method and system for Ethereum locking vulnerabilities

Abstract

This invention discloses a pattern-driven automatic repair method and system for Ethereum Locked Vulnerabilities. The method involves: performing static analysis on the target smart contract to extract structural features related to fund reception, fund transfer, and external calls; semantically trimming the source code of the target smart contract based on these structural features, retaining only the core code segments related to fund flow and withdrawal logic; matching the target smart contract with vulnerability patterns using a pre-built Ethereum Locked Vulnerability Pattern Library; constructing structured repair hints based on the matched vulnerability patterns to guide a large language model to generate repair patches that meet the required format; applying the repair patches to the source code of the target smart contract and performing compilation verification; if compilation fails, a reflective repair mechanism is triggered to perform minimal syntax correction until compilable contract code with the vulnerability eliminated is generated. This invention helps reduce the operational cost of manually repairing Ethereum Locked Vulnerabilities and improves vulnerability repair efficiency.

Description

Technical Field

[0001] This invention belongs to the field of blockchain smart contract security technology, specifically a pattern-driven automatic repair method and system for a vulnerability in the logic of locking Ethereum in smart contracts. Background Technology

[0002] Blockchain smart contracts are automated programs deployed on blockchain networks that enable asset transfers, transaction settlements, and business logic execution without the need for a trusted third-party institution. In blockchain systems, exemplified by the Ethereum platform, smart contracts are widely used in decentralized finance (DeFi), digital asset management, supply chain management, and digital identity authentication. Because smart contracts typically control large amounts of digital assets, security vulnerabilities can easily lead to severe economic losses.

[0003] Unlike traditional software, smart contracts are typically immutable or unupgradeable once deployed to a blockchain. Therefore, any potential vulnerabilities can persist and be exploited by attackers for a long time. In recent years, research on smart contract vulnerabilities has increased, and static analysis tools, symbolic execution tools, and formal verification methods have become quite effective at detecting typical vulnerabilities such as reentrancy attacks, integer overflows, and access control errors. However, compared to the rapid development of vulnerability detection technologies, automated remediation technologies for smart contract vulnerabilities are still in their early stages of research, especially for complex logic vulnerabilities, where automated remediation methods remain scarce.

[0004] In smart contract security, the Ether-locking vulnerability is a typical and serious logical vulnerability. This vulnerability manifests as follows: the contract can receive Ether normally, but due to the lack of an effective withdrawal mechanism, unreachable withdrawal logic, or failure of dependent external components, the Ether within the contract cannot be legally withdrawn, thus permanently locking it within the contract. Unlike reentrancy attacks and other vulnerabilities that require active exploitation by attackers, the Ether-locking vulnerability can be triggered naturally even during normal contract operation, making it highly concealed and causing long-lasting harm. According to smart contract security statistics reports, this vulnerability has caused significant asset losses in recent years and is listed as one of the key vulnerability types in the OWASP 2025 smart contract security risk list.

[0005] Current technologies still have significant gaps in addressing vulnerabilities related to Ethereum locking: 1) Existing mainstream static analysis tools, such as Slither and Mythril, are mainly used for detecting and reporting vulnerabilities, but they cannot provide automated remediation solutions. After receiving a vulnerability report, developers still need to manually analyze the fund flow path and design a remediation plan, which is a complex process and can easily introduce new security issues.

[0006] 2) Most current smart contract auto-repair methods primarily target local syntax-level vulnerabilities such as reentrancy and integer overflow, and their remediation strategies typically rely on rule or template matching. However, the Ether locking vulnerability is a global logic vulnerability, and its causes involve multiple aspects such as fund flow reachability, state variable constraints, and access control semantics, making traditional template-based remediation methods difficult to apply.

[0007] 3) In recent years, large language models have shown strong capabilities in the field of code generation. However, when using large language models directly to fix vulnerabilities in smart contracts, there are often problems such as unstable generated code structure, excessive modification scope, easy destruction of the original contract semantics, and may even lead to code compilation failure.

[0008] Therefore, how to automatically repair the logic vulnerability of locking Ether while ensuring that the original business logic of the smart contract is not destroyed has become an important technical problem that urgently needs to be solved in the field of blockchain smart contract security. Summary of the Invention

[0009] To address the issues of disconnect between detection and repair, lack of targeted research, and poor stability of code generated by large language models in the automated repair of Ethereum-locked logic vulnerabilities in smart contracts, the present invention aims to provide a pattern-driven automatic repair method and system for Ethereum-locked vulnerabilities.

[0010] The technical solution of this invention is as follows: A pattern-driven automatic remediation method for Ethereum locking vulnerabilities includes the following steps: Static analysis is performed on the target smart contract to extract structural features related to fund receipt, fund transfer, and external calls; Based on the extracted structural features, the source code of the target smart contract is semantically trimmed, retaining only the core code segments related to fund flow and withdrawal logic; Using a pre-built library of locked Ether vulnerability patterns, vulnerability pattern matching is performed on the target smart contract; Based on the vulnerability patterns obtained from the matching, a structured remediation suggestion is constructed to guide the large language model to generate remediation patches that meet the format requirements; The patch is applied to the source code of the target smart contract and compiled for verification. If compilation fails, a reflexive repair mechanism is triggered to perform minimal syntax corrections until compileable contract code with the vulnerability eliminated is generated.

[0011] Preferably, the structural features include fund inflow features, fund outflow features, external dependency features, and access control features.

[0012] Preferably, the core code snippet includes: the target smart contract's payment collection function code, the existing withdrawal function code, ETH transfer-related code, delegatecall external call-related code, key state variable definition code, and access control logic code.

[0013] Preferably, the retained core code segments are subjected to format standardization and syntax completion processing to supplement contract version declarations, import library statements, and state variable definitions, so that they have a complete semantic structure and avoid semantic loss caused by the pruning operation.

[0014] Preferably, the vulnerability patterns in the Ethereum vulnerability pattern library include missing withdrawal mechanism, external dependency failure, and unreachable withdrawal path, and a set of corresponding core semantic features are set for each vulnerability pattern; the missing withdrawal mechanism means that the contract has the ability to receive legitimate ETH, but there is no valid withdrawal path; the external dependency failure means that the withdrawal function relies on the delegatecall instruction to call an external third-party library, and there is no independent withdrawal path; the unreachable withdrawal path means that the contract has ETH transfer statements, but the withdrawal triggering conditions cannot be met.

[0015] Preferably, the method for performing vulnerability pattern matching on the target smart contract is as follows: matching the core code fragment with the core semantic features of each vulnerability pattern in the Ethereum vulnerability pattern library, and determining the vulnerability pattern that matches the target smart contract based on the matching results.

[0016] Preferably, the method for generating the repair patch is as follows: First, by using the first round of pattern determination prompts, the core code fragment is input into the large language model, which is limited to outputting only the unique optimal pattern and a brief reason for determination from the preset vulnerability patterns, thus providing semantic constraints for patch generation; then, by using the second round of structured repair prompts, the structured repair patch that conforms to the structural specifications is output based on the results of the first round of pattern determination and combined with the source code of the target smart contract.

[0017] A pattern-driven automatic repair system for Ethereum-locked vulnerabilities is characterized by comprising a static analysis module, a semantic trimming module, a patch generation module, and a verification and reflection repair module. The static analysis module is used to perform static analysis on the target smart contract and extract structural features related to fund reception, fund transfer and external calls. The semantic trimming module is used to perform semantic trimming on the source code of the target smart contract based on the extracted structural features, retaining only the core code segments related to the flow of funds and withdrawal logic; The patch generation module is used to perform vulnerability pattern matching on the target smart contract using a pre-built Ethereum vulnerability pattern library; and to build structured repair prompts based on the matched vulnerability patterns to guide the large language model to generate repair patches that meet the format requirements. The verification and remediation module is used to apply the patch to the source code of the target smart contract and perform compilation verification. If the compilation fails, the remediation mechanism is triggered to perform minimal syntax correction until compilable contract code with the vulnerability eliminated is generated.

[0018] A computing device, characterized in that it comprises: a processor and a memory storing a computer program, wherein the computer program, when run by the processor, executes the method described above.

[0019] A computer-readable storage medium, characterized in that it stores instructions that, when executed on a computer, cause the computer to perform the above-described method.

[0020] The advantages of this invention are as follows: First, a pattern-driven automated remediation method is specifically proposed for the Ether-locking logic vulnerability in smart contracts. This method abstracts the vulnerability into three formalizable vulnerability patterns, providing a structured and reproducible automated remediation path for this type of global logic vulnerability, thus solving the problem of traditional methods being difficult to adapt to. Second, by semantically pruning irrelevant code, constraining the remediation direction with vulnerability patterns, and standardizing the patch output format, the method effectively reduces contextual interference and randomness in the generation of remediation code from large language models, improving the consistency and executability of the remediation results. Third, the constructed compilation verification and reflective remediation closed-loop mechanism can promptly correct syntax errors in the remediation code, ensuring that the remediated contract can be compiled normally, while verifying the vulnerability remediation effect, thus improving the reliability of the remediation solution. This method helps reduce the operational cost of manually remediating Ether-locking vulnerabilities and improves the efficiency of vulnerability remediation. Attached Figure Description

[0021] Figure 1 This is an overall flowchart of the method of the present invention.

[0022] Figure 2 This is a flowchart of a method according to an embodiment of the present invention.

[0023] Figure 3 This is a system diagram of the present invention. Detailed Implementation

[0024] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0025] like Figure 1 As shown, an optional embodiment of the present invention provides a pattern-driven automatic repair method for Ethereum locking vulnerabilities, the steps of which include: Static analysis is performed on the target smart contract to extract structural features related to fund receipt, fund transfer, and external calls; Based on the extracted structural features, the source code of the target smart contract is semantically trimmed, retaining only the core code segments related to fund flow and withdrawal logic; Using a pre-built library of locked Ether vulnerability patterns, vulnerability pattern matching is performed on the target smart contract; Based on the vulnerability patterns obtained from the matching, a structured remediation suggestion is constructed to guide the large language model to generate remediation patches that meet the format requirements; The patch is applied to the source code of the target smart contract and compiled for verification. If compilation fails, a reflexive repair mechanism is triggered to perform minimal syntax corrections until compileable contract code with the vulnerability eliminated is generated.

[0026] One embodiment of the present invention models and classifies Ethereum-locked vulnerabilities from the perspective of fund flow accessibility semantics, and combines static analysis technology with the code generation capability of large language models to realize a complete closed-loop repair process of vulnerability feature extraction, semantic trimming, vulnerability pattern matching, structured patch generation, and automated verification. This achieves automated repair of Ethereum-locked vulnerabilities while ensuring that the original business logic of the smart contract remains basically unchanged.

[0027] This invention discloses a pattern-driven automatic repair method for smart contract Ethereum locking logic vulnerabilities, comprising five core steps: static analysis feature extraction, semantic trimming, vulnerability pattern matching, pattern-guided structured patch generation, compilation verification, and reflective repair. First, structural features such as the contract's payable function, ETH transfer statements, and delegatecall calls are extracted through static analysis. Then, semantic trimming is performed based on these features, retaining core vulnerability-related fragments to reduce noise. Next, three predefined vulnerability patterns—Missing Withdrawal, External Dependency Failure, and Unreachable Transfer Logic—are matched. The pattern-based approach guides a large language model to generate structured repair patches, clearly defining the modification type and execution rules. Finally, compilation verification is performed; failure triggers reflective repair to complete minimal syntax correction. Simultaneously, a repair system integrating these five modules is constructed to achieve automated and controllable repair of Ethereum locking vulnerabilities.

[0028] An embodiment of the present invention provides a pattern-driven automatic repair method for Ethereum-locked vulnerabilities, comprising the following steps: 1) Perform static analysis on the target smart contract to extract structural features related to fund receipt, fund transfer, and external calls; 2) Based on the extracted structural features, the source code of the target smart contract is semantically trimmed, retaining only the core code segments related to the flow of funds and withdrawal logic; 3) Use a pre-built Ethereum lock vulnerability pattern library to perform vulnerability pattern matching on the target smart contract; 4) Based on the vulnerability patterns obtained from the matching, construct structured remediation suggestions to guide the large language model to generate remediation patches that meet the format requirements; 5) Apply the patch to the original code of the target smart contract to generate the patched contract source code and compile and verify it. If the compilation is successful, further use vulnerability detection tools to verify whether the Ethereum locking vulnerability has been eliminated and check whether the original core functional semantics of the contract remain consistent. After verification, output the final patched contract. If the compilation fails, extract the compilation error information and feed it back to the large language model to trigger the reflection and repair mechanism. Under the constraint of minimizing syntax repair, only the syntax problems that caused the compilation failure are locally corrected, the patch is regenerated and applied to the target smart contract source code again, and the compilation verification and reflection and repair are executed in a loop until a complete, compileable, vulnerability-eliminated and usable patched contract is obtained.

[0029] Furthermore, this invention also provides an automated repair system for implementing the above-described method. This system includes: a static analysis module, a semantic trimming module, a patch generation module, and a verification and remedial repair module. These modules work together to achieve automated repair of Ethereum vulnerabilities.

[0030] The core content of this invention is as follows: First, it abstracts the semantic layer pattern of Ethereum locking vulnerability from the core dimensions of fund flow accessibility and withdrawal semantics, constructing three types of vulnerability patterns; then, it combines the four major categories of vulnerability features extracted from static analysis—fund inflow, fund outflow, external dependencies, and access control—with semantic trimming technology to accurately preserve vulnerability-related code fragments while ensuring the integrity of the core semantics of the contract; next, it constrains the large language model through a two-round interactive prompt word architecture, using the determined unique optimal vulnerability pattern as the core to guide the generation of standardized patching that follows the principle of minimum modification; finally, it forms a closed loop through compilation verification and reflection repair mechanisms to ensure the syntactic legality of the patching, the effectiveness of vulnerability repair, and the semantic consistency of the original core functions of the contract, ultimately achieving efficient, secure, and automated vulnerability repair.

[0031] The overall flow of the method provided in one embodiment of the present invention is as follows: Figure 2 As shown, the specific steps include: S1. Static analysis to extract vulnerability features Static analysis is performed on target smart contracts with Ether-locking vulnerabilities. Based on the contract's source code and abstract syntax tree, all execution paths and key instructions are traversed. Four main categories of structural features closely related to the vulnerability are extracted according to pre-defined Ether-locking vulnerability detection rules, providing data support for subsequent semantic trimming and pattern matching. These four categories of structural features are as follows: 1) Fund inflow characteristics: This involves detecting the contract's ability to receive Ether. The key is to identify whether there are functions modified with "payable", "receive", or "fallback" in the contract. These functions are the core entry point for the contract to receive Ether and are also the prerequisite for locking Ether vulnerabilities. 2) Fund outflow characteristics: The core detection is the Ethereum transfer implementation logic of the contract. The key is to identify whether there is a valid path that can trigger ETH withdrawal. Specifically, this includes native transfer function calls (transfer, send, call with value parameter), user-defined transfer function calls, fund transfer mechanisms during contract destruction (selfdestruct), etc. This kind of logic is the core carrier of fund withdrawal. Its absence, unreachability, or execution failure are the key factors for locking Ethereum vulnerabilities. 3) External dependency characteristics: whether the contract uses the delegatecall instruction to call external libraries. If such calls exist, the association information of the external libraries needs to be further recorded. Such calls may lead to an external dependency failure-type Ethereum locking vulnerability. 4) Access control features: These include status variables that record fund balances in the contract, administrator address variables, and the logical structure corresponding to access control modifiers such as onlyOwner. This type of information directly affects the legality of withdrawal permissions and the accessibility of fund flows.

[0032] The specific rules for static feature extraction are shown in Table 1.

[0033] Table 1 shows the static feature extraction rules. S2, Feature-based semantic trimming Based on the structural features extracted in step S1, semantic trimming is performed on the target smart contract source code. The core of this step is to remove redundant code unrelated to the Ethereum locking vulnerability while ensuring the semantic integrity of the contract's fund flow and key logic. Only core code segments directly related to the vulnerability formation mechanism and repair path are retained, thereby reducing the contextual complexity in the subsequent large language model processing, reducing the interference of irrelevant code on the repair results, and improving the stability and semantic consistency of the repair process.

[0034] Retain code snippets directly related to the Ethereum locking vulnerability, specifically covering the target smart contract's payment function code (including functions modified with `payable`, `receive` functions, and `fallback` functions), existing withdrawal function code, ETH transfer-related code (including native transfer function calls, user-defined transfer functions and related logic, and fund transfer code during contract destruction), delegatecall-related external call code, definition code of key state variables (including fund balance record variables, administrator address variables, etc.), and access control logic code. Simultaneously, remove code snippets unrelated to the vulnerability, specifically including auxiliary functions without business relevance, logging functions, pure data query functions, state variable definitions unrelated to fund flow and withdrawal semantics, unrelated event declarations, and non-core logic code.

[0035] After the trimming is completed, the retained core code segments are subjected to format standardization and syntax completion. By supplementing necessary contextual information such as contract version declarations, import library statements, and state variable definitions, the semantic loss caused by the trimming operation is avoided to the greatest extent, ensuring that the retained core code segments have a complete semantic structure and can be accurately parsed by the large language model to understand their internal logical connections and functional intentions.

[0036] S3, Vulnerability Pattern Classification A standardized Ethereum lock-up vulnerability pattern library was pre-constructed based on the core dimensions of fund flow accessibility and withdrawal semantics. This library contains three categories of formally defined and quantifiable Ethereum lock-up vulnerability patterns. Each pattern clearly defines its core semantic features, typical vulnerability manifestations, and precise remediation targets, providing a unified and executable basis for subsequent vulnerability pattern matching and structured remediation, ensuring the accuracy of matching results and the consistency of remediation directions. The specific definitions, vulnerability manifestations, and remediation targets of the three vulnerability patterns are shown in Table 2.

[0037] Table 2 is a classification table of Ethereum vulnerability locking modes. By constructing the above pattern classification, we can achieve accurate semantic-level categorization of Ethereum locking vulnerabilities, rather than relying solely on code syntax features. In the subsequent matching process, based on the core contract fragments trimmed in step S2, we compare them one by one with the core semantic features of each pattern in Table 2 to determine the unique optimal vulnerability pattern corresponding to the target smart contract. This provides a clear constraint for the subsequent pattern-guided patch generation.

[0038] S4, Patch Generation for Mode-Driven Programming This step employs a dual-round interactive prompting architecture to guide the large language model, combining its intelligent semantic understanding capabilities to generate a structured patch that meets the requirements for automated execution. It strictly adheres to the three core design principles of minimal modification, verifiability, and controllable structure, ensuring that the patch only precisely modifies the vulnerability-related logic without altering the semantic features of the target smart contract's original core functionality, while also guaranteeing that the patch can be securely parsed and executed by the program.

[0039] Specifically, the first round of pattern-based warning words is used to input the semantically trimmed core code snippet of the contract into a large language model. This model is then constrained to output only the unique optimal pattern and a brief reasoning from three preset Ethereum locking vulnerability patterns, providing clear semantic constraints for patch generation. The second round of structured repair warning words, based on the results of the first round of pattern-based warning words and combined with the target smart contract's original code, outputs a structured repair patch that conforms to the structural specifications. The warning words are shown below: [Phase 1: Vulnerability Pattern Determination and Hints] enter: - Smart contract code Contract Prompt template: Please analyze whether the following smart contracts contain vulnerabilities that lock up Ether, and select the most matching pattern from the following: A. Missing Withdrawal Mechanism B. External Dependency Failure C. Unreachable Withdrawal Logic Require: 1) Select only the most suitable vulnerability pattern; 2) Briefly explain the basis for your selection; 3) The output format is: Pattern X: reason.

[0040] Contract Code: Contract " Output: - Vulnerability pattern identifier P ∈ {A, B, C} - Judgment basis [Phase Two: Pattern-Driven Repair Generation Prompts] enter: - Smart contract code Contract - Vulnerability Mode P Prompt template: "Based on the identified vulnerability patterns, the following smart contracts are patched."

[0041] Vulnerability Mode: P Contract Code: Contract Please generate the fix patch according to the following requirements: 1) Only modify the code related to the vulnerability; 2) Keep the original business logic unchanged; 3) Follow Solidity syntax rules; 4) Output structured patches.

[0042] Output format (JSON): { "contracts": [ { "name": "Contract Name", "placeholders": [ { "id": "Unique identifier for the element", "type": "add / modify / remove", "code": "Complete code snippet", "after": "Insert position (only used when adding)" } ] } ] } " Output: - Structured fix patch.

[0043] To ensure that the generated repair patches can be accurately parsed, located, and automatically applied by subsequent modules, in this embodiment, the structured repair patches are organized using a unified hierarchical output structure, as follows: The `contracts` field represents the collection of smart contract objects involved in the patch. Its data type is an array, and each element in the array corresponds to a smart contract that has been modified.

[0044] Each contract object in the `contracts` array must include at least two fields: `name` and `placeholders`. The `name` field identifies the target contract for which the patch is being performed, ensuring accurate identification of the contract file or entity to which the patch belongs in a multi-contract scenario. The `placeholders` field represents the collection of all code elements in the target contract for which patch operations are to be performed. This collection is also an array, with each element corresponding to a specific code modification.

[0045] In the `placeholders` field, the `id` field is used to represent a unique identifier for the current code element. This unique identifier is used to uniquely locate the code element to be operated on within the target smart contract, thereby avoiding matching ambiguities caused by duplicate code snippets, similar names, or similar structures. The unique identifier can be a node identifier generated based on a syntax tree, a code element path identifier, a symbol name and position combination identifier, or other location identifiers that can uniquely identify the target code element.

[0046] The `type` field indicates the type of fix operation corresponding to the current modification, and its value is limited to `add`, `modify`, or `remove`. `add` indicates adding code to the target smart contract; `modify` indicates replacing existing code elements in the target smart contract; and `remove` indicates deleting a specified code element from the target smart contract. By explicitly setting the operation type, the patch application module can clearly distinguish between the three different fix behaviors of adding, replacing, and deleting, thereby improving the determinism and controllability of patch execution.

[0047] The `code` field carries the code content corresponding to the current modification. In the `modify` type, the `code` field represents the complete code snippet of the target code element after modification. That is, the content carried by this field should be the complete final version that can directly replace the original target element, rather than just containing local differences or incremental modifications, to avoid incomplete syntax, compilation failures, or replacement errors due to missing context information. In the `add` type, the `code` field represents the new code snippet to be inserted into the target location. This code snippet should have syntactic integrity and be able to form a valid Solidity program together with the original contract code after insertion. In the `remove` type, the `code` field can be empty, a null string, or not used depending on implementation needs, because the core semantics of this type is to delete the target code element uniquely identified by the `id` field, rather than providing new replacement content.

[0048] The `after` field indicates the insertion reference position for the new code, primarily used in the `add` type. Specifically, the `after` field indicates which existing code element the new code should follow, providing a clear and stable positioning basis for the patch application process and ensuring that the new code is inserted in the correct location. In some implementations, the insertion reference position indicated by the `after` field can be a unique identifier of the target code element, a syntax node identifier, a function name, a statement block identifier, or other information that can stably identify the insertion reference point. When the `type` field is set to `modify` or `remove`, the `after` field typically does not participate in patch execution and can be empty or omitted.

[0049] During patch generation and application, the structured patch preferably contains only the contract objects and code elements that have actually been modified, excluding unmodified contract content or code parts unrelated to vulnerability repair. This reduces the size of the patch data, minimizes redundant information, and facilitates subsequent automated parsing, difference comparison, patch verification, and repair tracking.

[0050] S5, Compilation Verification and Reflection Fix The compliant structured patch generated in step S4 is automatically applied to the source code of the target smart contract, generating the repaired contract source code. The repaired contract code is then compiled and verified, forming a closed-loop mechanism of "patch generation - compilation and verification - remediation and repair," ensuring the effectiveness of the repair and the availability of the contract. The specific process is as follows: (1) Compilation verification: Call the Solidity compiler (corresponding to the language version of the contract, such as 0.8.x) to compile the repaired contract code and record the compilation results in detail; (2) Reflection and Repair: If the compilation is successful, further verify whether the Ethereum vulnerability has been completely repaired by a vulnerability detection tool (such as Slither) and whether the original core function semantics of the contract have not deviated. After confirming that there are no errors, output the final repaired contract to complete the vulnerability repair. If the compilation fails, extract the specific compilation error information (such as syntax error, undefined variable, type mismatch, etc.) and feed it back to the large language model to trigger the reflection and repair mechanism.

[0051] The remediation and repair phase strictly follows the principle of "minimizing syntax repairs". Only the large language model is allowed to correct the syntax problems that caused the compilation failure. Modification of the contract's business logic, fund flow path and access control semantics is strictly prohibited. After the correction, the repair patch is regenerated and the compilation verification is performed again. The above process is repeated until the contract is successfully compiled and finally a complete and usable repaired contract is output.

[0052] like Figure 3 As shown, an optional embodiment of the present invention provides a pattern-driven automatic repair system for Ethereum locking vulnerabilities, characterized in that it includes a static analysis module, a semantic trimming module, a patch generation module, and a verification and reflection repair module; The static analysis module is used to perform static analysis on the target smart contract and extract structural features related to fund reception, fund transfer and external calls. The semantic trimming module is used to perform semantic trimming on the source code of the target smart contract based on the extracted structural features, retaining only the core code segments related to the flow of funds and withdrawal logic; The patch generation module is used to perform vulnerability pattern matching on the target smart contract using a pre-built Ethereum vulnerability pattern library; and to build structured repair prompts based on the matched vulnerability patterns to guide the large language model to generate repair patches that meet the format requirements. The verification and remediation module is used to apply the patch to the source code of the target smart contract and perform compilation verification. If the compilation fails, the remediation mechanism is triggered to perform minimal syntax correction until compilable contract code with the vulnerability eliminated is generated.

[0053] An optional embodiment of the present invention provides a computing device, characterized in that it includes: a processor and a memory storing a computer program, wherein the computer program is executed by the processor to perform the above-described method.

[0054] An optional embodiment of the present invention provides a computer-readable storage medium, characterized in that it stores instructions that, when executed on a computer, cause the computer to perform the above-described method.

[0055] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A pattern-driven automatic remediation method for Ethereum locking vulnerabilities, comprising the following steps: Static analysis is performed on the target smart contract to extract structural features related to fund receipt, fund transfer, and external calls; Based on the extracted structural features, the source code of the target smart contract is semantically trimmed, retaining only the core code segments related to fund flow and withdrawal logic; Using a pre-built library of locked Ether vulnerability patterns, vulnerability pattern matching is performed on the target smart contract; Based on the vulnerability patterns obtained from the matching, a structured remediation suggestion is constructed to guide the large language model to generate remediation patches that meet the format requirements; The patch is applied to the source code of the target smart contract and compiled for verification. If compilation fails, a reflexive repair mechanism is triggered to perform minimal syntax corrections until compileable contract code with the vulnerability eliminated is generated.

2. The method according to claim 1, characterized in that, The structural features include fund inflow features, fund outflow features, external dependency features, and access control features.

3. The method according to claim 1, characterized in that, The core code snippets include: the target smart contract's payment collection function code, the existing withdrawal function code, ETH transfer-related code, delegatecall external call-related code, key state variable definition code, and access control logic code.

4. The method according to claim 1, 2, or 3, characterized in that, The core code snippets that are retained are formatted and syntax-completed, and contract version declarations, import statements, and state variable definitions are added to give them a complete semantic structure and avoid semantic loss caused by the pruning operation.

5. The method according to claim 1, 2, or 3, characterized in that, The vulnerability patterns in the Ethereum vulnerability pattern library include missing withdrawal mechanism, external dependency failure, and unreachable withdrawal path. A set of corresponding core semantic features is set for each vulnerability pattern. The missing withdrawal mechanism refers to a contract having the ability to receive legitimate ETH, but without any valid withdrawal path; the failure of external dependencies refers to the withdrawal function relying on the delegatecall instruction to call an external third-party library, without an independent withdrawal path; the unreachable withdrawal path refers to the existence of ETH transfer statements in the contract, but the withdrawal triggering conditions cannot be met.

6. The method according to claim 5, characterized in that, The method for performing vulnerability pattern matching on the target smart contract is as follows: the core code fragment is matched with the core semantic features of each vulnerability pattern in the Ethereum vulnerability pattern library, and the vulnerability pattern matching the target smart contract is determined based on the matching result.

7. The method according to claim 1, characterized in that, The method for generating the repair patch is as follows: First, the core code snippet is input into the large language model through the first round of pattern judgment prompts, and it is limited to outputting only the unique optimal pattern and a brief judgment reason from the preset vulnerability patterns, so as to provide semantic constraints for patch generation; then, through the second round of structured repair prompts, the structured repair patch that conforms to the structure specification is output based on the first round of pattern judgment results and combined with the source code of the target smart contract.

8. A pattern-driven automatic repair system for Ethereum locking vulnerabilities, characterized in that, It includes a static analysis module, a semantic trimming module, a patch generation module, and a verification and remediation module; The static analysis module is used to perform static analysis on the target smart contract and extract structural features related to fund reception, fund transfer and external calls. The semantic trimming module is used to perform semantic trimming on the source code of the target smart contract based on the extracted structural features, retaining only the core code segments related to the flow of funds and withdrawal logic; The patch generation module is used to perform vulnerability pattern matching on the target smart contract using a pre-built Ethereum vulnerability pattern library; and to build structured repair prompts based on the matched vulnerability patterns to guide the large language model to generate repair patches that meet the format requirements. The verification and remediation module is used to apply the patch to the source code of the target smart contract and perform compilation verification. If the compilation fails, the remediation mechanism is triggered to perform minimal syntax correction until compilable contract code with the vulnerability eliminated is generated.

9. A computing device, characterized in that, include: A processor, a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A storage instruction that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.

Images