A method, device and system for generating automated formal proof for Rust / Verus program

Abstract

This invention discloses an automated formal proof generation method, apparatus, and system for Rust / Verus programs. It constructs a knowledge base of verified code, parses verified Verus / Rust code, and divides it into blocks according to proof semantics rather than fixed line counts, complete files, or complete functions. Upon inputting the program to be verified, the system first calls the Verus verifier to obtain the verification result. Type-aware retrieval yields fine-grained proof constructions. For loop-related tasks, a structured hint synthesis module for loop invariants is provided. Hint word construction, LLM patch generation, and Verus loop closure repair reduce retrieval noise, focusing hint words on reusable proof patterns; improve the matching degree between evidence and proof obligations; restore necessary logical dependencies without introducing whole-file noise; compensate for the problem of LLM easily missing boundaries, frame conditions, and termination metrics; the generated results are constrained by the formal verifier; and it can significantly reduce manual proof costs and improve the first-time generation success rate and batch verification efficiency.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and formal verification, and in particular to an automated formal proof generation method, apparatus and system for Rust / Verus programs. Background Technology

[0002] As Rust is increasingly used in operating systems, embedded software, cloud infrastructure, blockchain, cryptographic libraries, and highly reliable system software, software developers are paying more and more attention to the stringent guarantees of functional correctness, security, and reliability. Rust provides strong memory safety guarantees at compile time through ownership, borrowing checks, and lifecycle mechanisms; however, memory safety is not equivalent to functional correctness. For safety-critical software, programs not only need to avoid memory errors but also need to meet precise functional specifications, such as whether array operations produce expected results, whether loops maintain invariants, whether sorting functions preserve order, and whether data structure operations satisfy abstract semantics.

[0003] Formal verification is a rigorous verification technique based on mathematical logic and automated solvers, which can prove whether a program implementation satisfies given specifications. Verus is a formal verification framework for Rust programs that allows developers to write formal specifications and proof annotations such as requires, ensures, invariants, declines, assertions, and proof fn in Rust programs, and automatically verify the program using the SMT solver. With Verus, developers can prove function preconditions, loop invariants, data structure properties, and auxiliary lemmas at the Rust program level, thus providing rigorous correctness guarantees for highly reliable Rust software.

[0004] However, in practice, when using Verus for program verification, function implementations and user-provided preconditions / postconditions are often insufficient. Developers frequently need to manually construct numerous auxiliary proofs, including loop invariants, assertions, proof blocks, auxiliary lemmas, quantifier triggering conditions, termination measures, and intermediate properties. These proofs are highly specialized, requiring developers to understand Rust program semantics, the Verus reduction language, SMT solver proof conventions, and the inductive structure of specific algorithms. For programs containing loops, sequences, arrays, vectors, quantifiers, or complex data structures, proofs are often difficult to write correctly on the first try and typically require multiple rounds of iterative "write-verify-report errors-fix" processes.

[0005] In recent years, large-scale language models have demonstrated strong capabilities in code generation and program repair, leading to the emergence of several LLM-based methods for automatically generating Verus proofs. These methods typically include the program to be verified, error messages, and a few examples in a prompt, which the LLM then uses to generate missing proof annotations. The Verus verifier is then called to check the generated result. If verification fails, the error message is fed back to the LLM for repair.

[0006] This generation-verification-repair process can reduce the burden of manual proof to some extent, but it still has problems such as unstable proof generation, proof construction not being in line with Verus requirements, and lack of key inductive relations for loop invariants in complex tasks.

[0007] Meanwhile, retrieval-enhanced generation techniques are used to provide external reference code or proof examples for LLMs. The basic idea is to retrieve examples similar to the current task from existing codebases and input them into the LLM as context to improve generation quality.

[0008] However, directly using traditional RAG for Verus proof synthesis presents a significant granularity mismatch problem. If the entire file or function is used as the search unit, the search results usually contain a large amount of implementation details, reduction fragments, and proof code that are irrelevant to the current proof obligation. This can easily lead to excessive noise in the prompt words, making it difficult for LLM to locate truly reusable proof patterns.

[0009] For Verus proof tasks, the truly useful information is often not a complete file or function, but a short but crucial proof construct, such as a loop invariant template, an assertion pattern, a proof block structure, or an auxiliary lemma.

[0010] Therefore, how to extract, retrieve, expand, and inject hint words from the verified code at an appropriate granularity during the LLM-assisted Verus proof synthesis process has become a key issue in improving the success rate of automatic proofs.

[0011] Existing technologies mainly fall into three categories: methods for manually writing Verus proofs, LLM proof generation methods based on fixed example hints, and proof generation methods based on coarse-grained retrieval enhancement. However, none of these methods adequately address the "mismatch between retrieval granularity and proof obligation" problem in Verus proof tasks. They each suffer from the following drawbacks: manual proof methods, while reliable, are costly and difficult to scale; fixed example hint methods are simple to implement but have limited context coverage and unstable generation results; coarse-grained RAG methods can incorporate external code knowledge but suffer from excessively coarse retrieval granularity, high hint noise, and unfocused proof patterns; while simple fine-grained retrieval can locate local proof fragments, it easily loses necessary context such as parent contracts, sibling invariants, and related assertions.

[0012] In summary, existing technologies all have certain limitations, especially when it comes to the automated proof generation task for complex Rust / Verus programs. Existing methods struggle to simultaneously ensure the accuracy, context relevance, interpretability, and scalability of proof generation.

[0013] Therefore, a solution is needed that strikes a good balance between refined proof construction, contextual integrity, utilization of verification feedback, and automatic generation of loop invariants. Specifically, a new technical approach is urgently needed that leverages the code understanding and proof generation capabilities of LLM while simultaneously constraining and guiding its output through semantic proof construction chunking, type-aware retrieval, hierarchical context expansion, and structured loop hints, thereby improving the success rate and stability of automated formal verification of Rust / Verus programs.

[0014] Ultimately, this will drive the application of highly reliable Rust software development and formal methods in operating systems, embedded systems, aerospace, intelligent vehicles, and safety-critical industrial software. Summary of the Invention

[0015] This invention proposes an automated formal proof generation method for Rutt / Verus programs, which can effectively solve the problems mentioned in the background art.

[0016] To achieve the above objectives, the present invention adopts the following technical solution: An automated formal proof generation method for Rust / Verus programs is proposed, integrating a verified code knowledge base, semantic proof construction blocks, type-aware retrieval, hierarchical context expansion, loop invariant hint synthesis, LLM patch generation, and Verus verification and repair. This method takes the Rust / Verus program to be verified and the verified code knowledge base as input, and outputs a repaired program that passes Verus verification.

[0017] Semantic proof construction chunking: During the knowledge base construction phase, this invention first parses the verified Verus / Rust code and chunks it according to proof semantics rather than fixed line counts, complete files, or complete functions. The system splits the code into proof constructions such as Function, Lemma, Contract, LoopInvariant, ProofBlock, and Assertion. Each construction serves as an independent retrieval unit, simultaneously recording its type, source code location, parent function, verification status, neighboring context, and embedding vector.

[0018] By using this block-based approach, the present invention transforms the verified codebase into a typed, fine-grained, and searchable proof construction library, enabling subsequent searches to directly align with the current proof obligation, rather than searching for a large amount of irrelevant implementation code.

[0019] Type-aware retrieval: When a program to be verified is input, the system first calls the Verus validator to obtain the verification result. If the program has passed verification, it is output directly; if verification fails, the system analyzes the error message, code structure, and missing proof location to identify the current query type. Query types include Contract, LoopInvariant, Lemma, ProofBlock, Assertion, and Function.

[0020] During retrieval, the system combines the program fragment to be verified, the Verus error message, and the query type into a query text, calculates the query embedding vector, and performs similarity calculations with the embedding vectors of each proof construct in the construct library. The system further introduces type bias and verification state bias to give a comprehensive score to the candidate constructs.

[0021] Furthermore, the system can also combine term overlap, parent context matching, variable name similarity, and structural pattern similarity for reordering to improve the matching degree between retrieved evidence and the current proof obligation.

[0022] Hierarchical Context Expansion: Type-aware retrieval yields fine-grained proof constructions. To avoid isolated fragments lacking proof dependencies, this invention expands the retrieval results with bounded context based on a construction hierarchy graph. For a retrieved construction c, the system selects parent construction, child construction, sibling construction, and local context for expansion based on the query type t and the construction type type(c).

[0023] For example, when the query type is LoopInvariant and the retrieved construct is also LoopInvariant, the system expands its parent function contract, sibling loop invariants, and related assertions; when the query type is Contract and a Contract construct is retrieved, the system expands its parent function and sibling contract clauses; when an Assertion or ProofBlock is retrieved, the system expands its parent function or parent proof block.

[0024] The expansion process sets context budget constraints, such as allowing each retrieval construct to expand a maximum number of parent / child / sibling nodes, or limiting the total number of tokens to a preset threshold. This allows the system to retain the logical dependencies required for proof reuse while avoiding the injection of large amounts of irrelevant code.

[0025] Structured hint synthesis for loop invariants: For loop-related tasks, this invention provides a structured hint synthesis module for loop invariants. This module does not directly replace the LLM to complete all semantic proofs, but automatically derives candidate basic invariants such as boundaries, frame conditions, and termination metrics from the program structure, providing a proof skeleton for the LLM.

[0026] This module first identifies loop structures transformed from while, loop, or for loops, extracting the loop condition, loop variable, variable update statement, array or vector access expression, and variables modified within the loop body. Then, it generates boundary candidates based on the loop condition and access expression; frame condition candidates based on unmodified variables; and termination metric candidates based on the monotonic change of the loop variable.

[0027] These structural candidate hints can help LLM retain the basic structure required for Verus proofs while focusing its main generative capabilities on semantic relations, such as sequence subrange, add, array element preservation relations, and inductive properties.

[0028] Confirmation word construction, LLM patch generation, and Verus loop closure repair: This invention combines the program to be verified, Verus error messages, query type, retrieved proof construction, expanded context, loop structure hints, and output format constraints into structured prompt words, which are then input into a large language model. The LLM generates candidate proof patches, which may include adding or modifying loop invariants, enhancing require / ensures / decreases, adding assert or assert by, adding proof blocks, or adding auxiliary lemmas.

[0029] The system applies the candidate patch to the current program and calls the Verus validator for verification. If verification is successful, the fixed program is output; if verification fails, the system re-identifies the query type, re-retrieves the proof construction, re-expands the context, and generates the patch again based on the new Verus error information. This process continues until the program passes verification or reaches the maximum number of iterations.

[0030] Advantages compared to existing technologies: The beneficial effects of this invention are mainly reflected in the following aspects: First, the semantic proof construction block reduces retrieval noise, allowing prompts to focus on reusable proof patterns; second, type-aware retrieval improves the matching degree between evidence and proof obligations; third, hierarchical context expansion restores necessary logical dependencies without introducing noise from the entire document; fourth, cyclic invariant prompt synthesis compensates for the problem that LLM is prone to missing boundaries, frame conditions, and termination metrics; fifth, Verus verification closure ensures that the generated results are constrained by the formal verifier; sixth, the system can significantly reduce the cost of manual proof, improve the first generation success rate, and increase batch verification efficiency. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the process of the present invention; Figure 2 This is an overall flowchart of the present invention; Figure 3 The following are the evaluation results of different methods of the present invention on VerusBench; Figure 4 This represents the overall success rate of the invention across different large language model backends. Detailed Implementation

[0032] Example 1, refer to Appendix Figure 1-4 An automated formal proof generation method for Rutt / Verus programs includes the following steps: S1. Offline knowledge base construction: Build a knowledge base with verified code.

[0033] S1.1 First, obtain the verified Rust / Verus codebase and construct blocks for semantic proof of the code within it.

[0034] The S1.1.1 system breaks down the code into the following proof constructs: Function, Lemma, Contract, LoopInvariant, ProofBlock, Assertion, etc. See Table 1 for details.

[0035] S1.1.2 Each construct is treated as an independent retrieval unit, and its type, source code location, parent function, verification status, neighboring context, and embedding vector are recorded.

[0036] Table 1 Semantic Proof Construction Type Table

[0037] S1.2. Divide the code into proof constructions, which include functions, contracts, auxiliary lemmas, loop invariants, proof blocks, and assertions, thereby forming a knowledge base of proof constructions that can be retrieved and reused.

[0038] By using a block-based approach to constructing semantic proof types, this invention transforms the verified codebase into a typed, fine-grained, and searchable proof construction library, enabling subsequent searches to directly align with the current proof obligation, rather than retrieving a large amount of irrelevant implementation code.

[0039] S2, Online proof generation process.

[0040] S2.1. Input the program to be verified.

[0041] S2.2 The system receives the Rust / Verus program to be verified and first calls the Verus verifier to perform initial verification.

[0042] S2.3 When the program fails verification, the system performs type-aware retrieval based on the Verus error message and program structure, and retrieves the relevant proof construction and its context from the proof construction knowledge base.

[0043] S2.3.1 If the program has passed verification, it will be output directly; if verification fails, the system will analyze the error message, code structure, and location of missing proofs to identify the current query type. Query types include Contract, LoopInvariant, Lemma, ProofBlock, Assertion, and Function. See Table 2 for details.

[0044] During retrieval, the system combines the program fragment to be verified, the Verus error message, and the query type into a query text, calculates the query embedding vector, and performs similarity calculations with the embedding vectors of each proof construct in the construct library. The system further introduces type bias and verification state bias to give a comprehensive score to the candidate constructs.

[0045] S2.3.2 The system can combine term overlap, parent context matching, variable name similarity and structural pattern similarity to reorder the data, so as to improve the matching degree between the retrieved evidence and the current proof obligation.

[0046] Table 2 Query Type Identification and Priority Retrieval Construction Table

[0047] S2.3.3 Type-aware retrieval yields fine-grained proof constructions. To avoid isolated fragments lacking proof dependencies, the retrieval results are expanded with bounded context based on the construction hierarchy graph, and a context budget constraint is set during the expansion process.

[0048] S2.3.4 For the retrieved constructor c, the system selects the parent constructor, child constructor, sibling constructor, and local context for expansion based on the query type t and the constructor type (c). This expansion process sets a context budget constraint.

[0049] The context budget constraint means that each retrieved construct can be extended by a maximum of a certain number of parent / child / sibling nodes, or the total number of tokens cannot exceed a preset threshold; thus, the system can retain the logical dependencies required for proof reuse while avoiding the injection of a large amount of irrelevant code.

[0050] (1) When the query type is LoopInvariant and the retrieved constructor is also LoopInvariant, the system extends the parent function contract, sibling loop invariants and related assertions.

[0051] (2) When the query type is Contract and a Contract constructor is retrieved, the system expands its parent function and sibling contract clauses; when an Assertion or ProofBlock is retrieved, the system expands its parent function or parent proof block.

[0052] S2.4 Subsequently, the system combines the loop structure in the program to generate structured hints for loop invariants, and inputs the program to be verified, verification errors, retrieved evidence, extended context and loop hints into a large language model, which then generates candidate proof patches.

[0053] For loop-related tasks, it provides structured hints for loop invariants. Instead of directly replacing the LLM in performing all semantic proofs, it automatically derives candidate basic invariants, including boundary conditions, frame conditions, and termination metrics, from the program structure, providing a proof skeleton for the LLM.

[0054] S2.4.1 The system first identifies the loop structure after while, loop or for is transformed, and extracts the loop condition, loop variable, variable update statement, array or vector access expression and the variable modified in the loop body.

[0055] S2.4.2 Generate boundary candidates based on loop conditions and access expressions; generate frame condition candidates based on unmodified variables; generate termination metric candidates based on monotonic changes in loop variables. See Table 3 for details.

[0056] These structural candidate hints can help LLM retain the basic structure required for Verus proofs while focusing its main generative capabilities on semantic relations, such as sequence subrange, add, array element preservation relations, and inductive properties.

[0057] Table 3. Candidate list of structured loop invariants in the rotate_right example.

[0058] S2.4.3. Combine the program to be verified, the Verus error message, the query type, the retrieved proof construction, the expanded context, the loop structure hints, and the output format constraints into a structured hint word, and input it into the large language model. The LLM generates candidate proof patches, which may include adding or modifying loop invariants, enhancing requires / ensures / decreases, adding assert or assert by, adding proof blocks, or adding auxiliary lemmas.

[0059] S2.5 After applying the candidate proof patch to the current program, the system calls the Verus verifier again for verification. If the verification passes, the verified program is output. If the verification fails, the retrieval, prompt construction, and patch generation process are re-executed based on the new verification error until the program passes the verification or reaches the preset number of iterations.

[0060] Example 2 presents an automated formal proof generation method for Rust / Verus programs, applying the automatic synthesis direction of loop invariants in the `rotate_right` function. This function takes a non-empty vector `list` and a rotation step number `n` as input and outputs a new vector `new_list` rotated `list` n positions to the right. Its postcondition can be expressed as: the output sequence is equal to the concatenation of the suffix and prefix of the input sequence. The function body typically contains two loops: the first loop iterates from `split_index` to `list.len()`, adding the suffix of the input sequence to `new_list`; the second loop iterates from 0 to `split_index`, adding the prefix of the input sequence to `new_list`.

[0061] With only function postconditions, Verus cannot automatically prove that the concatenation relationship between `new_list@` and the input sequence holds after two loops. Traditional LLM methods may generate simple invariants such as `index <= list.len()` and `new_list.len() == index - split_index`, but they are prone to missing key semantic relationships.

[0062] When using the method of this invention, the system first identifies the query type as LoopInvariant based on the Verus error; then it retrieves LoopInvariant constructs related to semantics such as Vec, subrange, add, and index from the verified codebase; subsequently, it extends the contract of its parent function and sibling invariants; and then the loop invariant hint module generates the boundary, frame condition, and termination metric. Guided by the above evidence and hints, LLM generates the following key semantic invariants: in the first loop, new_list@ == list@.subrange(split_index as int, index as int); in the second loop, new_list@ == list@.subrange(split_index as int, list.len() asint).add(list@.subrange(0, index as int)).

[0063] The system applies the generated invariants to the program and calls the Verus validator to check them. If errors still exist, the system continues to repair them; if the verification is successful, the verified program is output. This embodiment illustrates that the present invention can combine structural invariant hints with semantic construction retrieval to generate cyclic invariants that meet the requirements of Verus inductive proof.

[0064] Example 3 illustrates an automated formal proof generation method for Rust / Verus programs, applied to proof generation in a benchmark scenario: It employs 150 VerusBench nontrivial verification tasks, covering four benchmark suites: CloverBench, Diffy, MBPP, and Misc. Each task contains Rust / Verus executable code and a user-provided specification, but lacks necessary proof annotations.

[0065] See the appendix for evaluations of different methods on VerusBench. Figure 2 For the overall success rate under different large language model backends, please refer to the appendix. Figure 3 As can be seen from the above results, this invention achieves a higher verification success rate compared to AutoVerus (without retrieval), Basic RAG (with coarse-grained retrieval), and RagVerus (with item-level retrieval). Under the gpt-4o backend, this invention successfully verified 122 / 150 tasks, a significant improvement compared to AutoVerus's 69 / 150 and RagVerus's 85 / 150.

[0066] Example 4: An automated formal proof generation method device for Rust / Verus programs, including a verified code knowledge base construction module, a semantic proof construction block module, a type-aware retrieval module, a hierarchical context extension module, a loop invariant structured hint synthesis module, a hint word construction module, a large language model proof patch generation (LLM) module, a Verus verification and iterative repair module, and a result output module.

[0067] The knowledge base construction module and semantic chunking module are responsible for extracting proof constructs, including functions, contracts, loop invariants, auxiliary lemmas, proof blocks, and assertions, from verified Rust / Verus code.

[0068] The type-aware retrieval module and the hierarchical context extension module are responsible for retrieving relevant proof fragments and supplementing necessary context based on the error information and proof requirements of the program to be verified.

[0069] The Loop Cue Synthesis module is used to generate structured cues for loop-related tasks, including boundaries, frame conditions, and termination metrics.

[0070] The large language model proof patch generation module and the Verus verification and iterative repair module are responsible for generating candidate proof patches and performing closed-loop checks through the Verus verifier until a verified program is output or the current error message is returned.

[0071] Example 5: An automated formal proof generation method system for Rust / Verus programs, including a user interface, a proof generation backend, a verified code knowledge base, a proof construction index, a retrieval and context expansion service, a loop invariant hint synthesis service, an LLM call interface, a Verus verifier, and a result display module.

[0072] Users can submit Rust / Verus programs for verification via a web interface, command line, or containerized deployment. The system backend first calls Verus to obtain the verification result. If verification fails, it performs retrieval, context expansion, and prompt construction based on the error message. Then, it calls the large language model to generate a proof patch and calls Verus again for verification. If verification fails again, it proceeds to the next round of repair; if verification succeeds, it returns the verified program to the user.

Claims

1. A method for generating automated formal verification of RUST / VERUS programs, characterized in that, Includes the following steps: S1. Offline knowledge base construction: Building a knowledge base with verified code; S1.1 First, obtain the verified Rust / Verus codebase and construct blocks by performing semantic proof on the code within it; S1.2 Divide the code into proof constructions, which include functions, contracts, auxiliary lemmas, loop invariants, proof blocks, and assertions, thereby forming a knowledge base of proof constructions that can be retrieved and reused; S2, Online Certificate Generation Process; S2.1, Input the program to be verified; S2.2 The system receives the Rust / Verus program to be verified and first calls the Verus verifier to perform initial verification; S2.3 When the program fails verification, the system performs type-aware retrieval based on the Verus error message and program structure, and retrieves the relevant proof construction and its context from the proof construction knowledge base; S2.4 Subsequently, the system combines the loop structure in the program to generate structured hints of loop invariants, and inputs the program to be verified, verification errors, retrieved evidence, extended context and loop hints into the large language model, which then generates candidate proof patches. S2.5 After applying the candidate proof patch to the current program, the system calls the Verus verifier again for verification. If the verification passes, the verified program is output. If the verification fails, the retrieval, prompt construction, and patch generation process are re-executed based on the new verification error until the program passes the verification or reaches the preset number of iterations.

2. The method of claim 1, wherein the method is a method for automatically generating formal proofs for RUST / VERUS programs. S1.1 includes the following steps: The S1.1.1 system breaks down the code into the following proof constructs: Function, Lemma, Contract, LoopInvariant, ProofBlock, Assertion; S1.1.2 Each construct is treated as an independent retrieval unit, and its type, source code location, parent function, verification status, neighboring context, and embedding vector are recorded.

3. The method of claim 1, wherein the method is a method for automatically generating formal proofs for RUST / VERUS programs. S2.3 includes the following steps: S2.3.1 If the program has passed the verification, it will be output directly; if the verification fails, the system will analyze the error message, code structure and missing proof location to identify the current query type. S2.3.2 The system can combine term overlap, parent context matching, variable name similarity and structural pattern similarity to reorder, so as to improve the matching degree between the retrieved evidence and the current proof obligation; S2.3.3 Type-aware retrieval yields fine-grained proof constructions; to avoid isolated fragments lacking proof dependencies, bounded context expansion is performed on the retrieval results based on the construction hierarchy graph, with context budget constraints set during the expansion process; S2.3.4 For the retrieved constructor c, the system selects the parent constructor, child constructor, sibling constructor, and local context for expansion based on the query type t and the constructor type (c); (1) When the query type is LoopInvariant and the retrieved constructor is also LoopInvariant, the system extends the parent function contract, sibling loop invariants and related assertions; (2) When the query type is Contract and a Contract constructor is retrieved, the system expands its parent function and sibling contract clauses; when an Assertion or ProofBlock is retrieved, the system expands its parent function or parent proof block.

4. The method of claim 1, wherein the method is a Rust / Verus program oriented automated formal verification generation method. S2.4 includes the following: for loop-related tasks, it provides structured hints about loop invariants; Instead of directly replacing the LLM to complete all semantic proofs, it automatically derives candidates for basic invariants, including boundary conditions, frame conditions, and termination metrics, from the program structure, providing a proof skeleton for the LLM. S2.4.1 The system first identifies the loop structure after while, loop or for is transformed, and extracts the loop condition, loop variable, variable update statement, array or vector access expression and the variable modified in the loop body; S2.4.2 Generate boundary candidates based on loop conditions and access expressions; generate frame condition candidates based on unmodified variables; Candidate termination metrics are generated based on the monotonic changes of the loop variable. These structural candidate hints can help LLM retain the basic structure required for Verus proofs while focusing the main generative capabilities on semantic relations; S2.4.3 Combine the program to be verified, Verus error messages, query type, retrieved proof construction, expanded context, loop structure hints, and output format constraints into structured hint words, and input them into a large language model; LLM generates candidate proof patches.

5. The device for automatic generation of formal proof for Rust / Verus program-oriented according to claim 1, characterized in that: It includes a verified code knowledge base building module, a semantic proof construction module, a type-aware retrieval module, a hierarchical context extension module, a loop invariant structured hint synthesis module, a hint word construction module, a large language model proof patch generation module, a Verus verification and iterative repair module, and a result output module; The knowledge base construction module and the semantic block module are responsible for extracting proof constructs, including functions, contracts, loop invariants, auxiliary lemmas, proof blocks, and assertions, from verified Rust / Verus code. The type-aware retrieval module and the hierarchical context extension module are responsible for retrieving relevant proof fragments and supplementing necessary context based on the error information and proof requirements of the program to be verified. The loop cue synthesis module is used to generate structured cues for loop-related tasks, including boundaries, frame conditions, and termination metrics. The large language model proof patch generation module and the Verus verification and iterative repair module are responsible for generating candidate proof patches and performing closed-loop checks through the Verus verifier until a verified program is output or the current error message is returned.

6. The automated formal proof generation system for Rust / Verus programs according to claim 1, characterized in that: It includes a user interaction interface, a proof generation backend, a verified code knowledge base, a proof construction index, a retrieval and context extension service, a cycle invariant hint synthesis service, an LLM call interface, a Verus validator, and a result display module; Users can submit Rust / Verus programs to be verified via a web interface, command line, or containerized deployment. The system backend first calls Verus to obtain the verification result. If the verification fails, it performs retrieval, context expansion, and prompt construction based on the error information. Then, it calls the large language model to generate a proof patch and calls Verus again for verification. If the verification fails, it proceeds to the next round of repair. If the verification succeeds, it returns the verified program to the user.

Images