Rust-to-Lean Verification Pipeline

• The Rust-to-Lean formal verification pipeline is a method that extracts and translates production-grade Rust code into Lean 4 to construct and check formal proofs of functional correctness.
• It employs a modular architecture using components like Charon, Aeneas/Hax, specification libraries, and AI-assisted proof tactics while confining trust to the Lean kernel.
• Demonstrated on cryptographic applications, the pipeline optimizes verification by efficiently handling invariants and reducing manual proof burden by approximately 30%.

The Rust-to-Lean formal verification pipeline refers to a tool-supported process for extracting Rust programs—particularly those written in a production or cryptographic context—into Lean 4, where functional correctness and related properties are verified by constructing proofs that are checked by the Lean kernel. This approach leverages recent advances in formal translation, symbolic extraction, domain-specific verification libraries, and AI-assisted proof construction to make the verification of real-world Rust code practical, scalable, and reusable across distinct domains, especially in zero-knowledge (zkSNARK) and cryptographic protocol implementations (Ho et al., 2022, Klaus et al., 28 May 2026).

1. Pipeline Architecture and Components

The pipeline consists of a series of components that process Rust programs and produce Lean 4 definitions, specifications, and formal proofs. The architecture segregates trusted and untrusted components, ensuring that all critical proof checking occurs within the Lean kernel. The main components include:

• Rust source code: Typically from mature crates such as Plonky3 or RISC Zero.
• Charon: Extracts Rust code into LLBC (Low-Level Borrow Calculus), a typed MIR-lite representation that encodes borrow-checker semantics.
• Aeneas/Hax: Translate LLBC or the higher-level THIR into pure Lean 4 code, erasing all memory and pointer reasoning while preserving ownership and lifetime invariants at the semantic level.
• Specification libraries: Math/crypto specifications (e.g., ArkLib and CompPoly) provide reference models for fields, polynomials, or other algebraic structures.
• AI-assisted proof search: Tools such as Aristotle and Aleph construct and propose proof terms.
• Lean 4 kernel: The only trusted component; typechecks and certifies all resulting proofs.

The entire data flow can be summarized as:

$\rho\,\tau$0 All transformations and proof obligations are tracked in Lean source files and verified artifacts, ensuring reproducibility and soundness (Klaus et al., 28 May 2026).

2. Extraction: From Rust to Lean 4

Extraction operates in two main variants, depending on program features and desired guarantees:

• Charon + Aeneas Path: Targets safe Rust. Charon emits LLBC, which preserves static borrow-checker invariants at the type level. Aeneas translates LLBC into Lean, erasing explicit memory while encoding functional and ownership properties in pure or monadic Lean code (e.g., Result, RustM). Numerical checks (e.g., for overflows) and error cases are retained as monadic branches.
• Hax Path: For more general or trait-heavy Rust, Hax extracts from the THIR and uses attribute-based selection to emit Lean models, packaged with lemmas about monadic bind, error handling, and semantic invariants.

Loops in Rust are encoded as recursive functions in Lean, requiring explicit termination proofs. All checked integer operations are accompanied by auxiliary lemmas (e.g., toNat monotonicity for subtractions) that are discharged once per type and reused (Ho et al., 2022, Klaus et al., 28 May 2026). Ownership and lifetimes are assured by the Rust borrow checker at extraction time; the translation omits low-level memory representations.

Example Translation

A function from Plonky3,

$\rho\,\tau$1 is extracted as

$\rho\,\tau$2 Where monadic binds explicitly encode failure and arithmetic invariants (e.g., subtraction precondition) become part of the proof context (Klaus et al., 28 May 2026).

3. Formal Semantics: LLBC and Functional Translation

At the core of the pipeline is the use of LLBC, a value-based, ownership-centric calculus that formalizes a Rust-like core:

• Base types: $b ::= bool \mid u32 \mid i32 \mid \dots$
• Borrow types: $\rho\,\tau$ for (mutable/shared) borrows with region $\rho$
• Semantic invariants: No outer loans at assignment/move sites; borrows are modeled via loan-ids in value representations (e.g., $\ell v$).
• Operations: Moves, copies, borrows, and writes are specified by ghost-updating a value store $\Omega$, eliminating reasoning about explicit memory or pointers.

Aeneas translates LLBC into a pure $\lambda$-calculus, with symbolic semantics for function calls and region manipulation: each call introduces region abstractions and employs "forward" and "backward" translation rules to encode the semantic flow of borrows and returns. This schema is embedded in Lean via a combination of custom inductive datatypes and monadic combinators, allowing proof engineers to reason about Rust code in a memory-abstract, ownership-preserving manner (Ho et al., 2022).

4. Specification and Target Domains

The pipeline is designed for formal verification within complex domains such as SNARKs and cryptographic primitives. The specification step involves:

• Math/crypto specifications: ArkLib and CompPoly define formal targets for finite fields, polynomial arithmetic, and core primitives like FRI folding, Mersenne31 field operations, and Merkle inclusion proofs.
  • For example, Mersenne31 field arithmetic is modeled as

  $$p = 2^{31} - 1,\quad \mathbb{F}_p = \{x \in \mathbb{N}\mid 0 \leq x < p\}$$

  with operations modulo $p$ (Klaus et al., 28 May 2026). - FRI folding primitives (e.g., foldNth) and soundness lemmas are specified for end-to-end zero-knowledge protocol verification.

• Spec import: Extracted Lean code directly invokes the imported specifications as correctness targets, enabling property statements such as "the Rust field addition matches its mathematical definition over $\mathbb{F}_p$" or "FRI schedule computation respects all required monotonicity theorems."

5. Proof Construction and AI Integration

Proof obligations induced from the translation are handled via a combination of manual tactics and AI-augmented proof search:

• Manual tactic application: Standard Lean 4 tactics (simp, ring, nlinarith, etc.) are used for arithmetic, structural destructuring, and case analysis.

• AI provers: Aristotle and Aleph, interfaced as command-line tools, consume Lean goals and synthesize proof terms that are then re-verified by the kernel. AI provers cover:

  • 100% closure of structural lemmas (monad structurals, if-bounds, Option splitting)
  • 90% of pure linear-arithmetic conditions post-hypothesis
  • All simp/ring boilerplate
  • Not yet automated: domain-specific identities, loop invariants, or high-level abstraction design

A typical Lehman statement follows the structure: $\rho\,\tau$3 AI provers can synthesize such proofs, reducing manual effort by approximately 30% in case studies (Klaus et al., 28 May 2026).

6. Soundness and Trusted Computing Base

The pipeline is explicitly engineered to restrict trust to the Lean 4 kernel (~7KLoC). All extraction tools, symbolic executors, and AI-driven proof tactics sit outside the trusted computing base (TCB). Theoretical soundness follows from:

• Kernel rechecking: Every proof (manual or AI-generated) must be typechecked by Lean 4; invalid proofs are rejected.
• Admissibility of extracted definitions: The correctness of the extraction is itself verified in Lean. Ownership and lifetime invariants, guaranteed by Rust’s static analysis, are reflected but not reconstructed at the Lean level.
• Artifact reproducibility: Extracted Lean proof artifacts can be rebuilt from scratch by any user, ensuring reproducibility and verifiability (Klaus et al., 28 May 2026, Ho et al., 2022).

7. Engineering Experience and Results

Empirical evaluation covers eight cryptographic or systems targets from Ethereum Foundation’s zkEVM project and related infrastructures. Summary data:

Target	Pipeline	Verified Property	Rust→Lean Size & Check Time
FRI round scheduling	Aeneas+Hax	bounds/monotonicity (6 thms; 2 AI)	120 Rust → 250 Lean; ~0.4 s
FRI fold_step vs ArkLib	Aeneas+ArkLib	foldNth 2 equivalence (mod $p$)	80 Rust → 200 Lean; ~0.3 s
Mersenne31 field add/mul	Aeneas	spec matching, no overflow	100 Rust → 180 Lean; ~0.2 s
KoalaBear field arithmetic	Hax	extraction correctness only	90 Rust → 160 Lean; ~0.2 s
Horner polynomial evaluation	Hax+CompPoly	eval = poly eval	70 Rust → 140 Lean; ~0.25 s
Single-step FRI folding	Hax	round soundness	130 Rust → 260 Lean; ~0.5 s
RISC Zero Merkle inclusion	Hax	root/branch equivalence	110 Rust → 220 Lean; ~0.4 s
32-bit ADC	Hax+bv_decide	bit-level carry correctness	60 Rust → 120 Lean; ~0.15 s

In total, ~760 lines of Rust yielded ~1,530 lines of Lean, with complete proof checking in under 3 seconds on commodity hardware. This suggests that scale and automation are practical for real-world cryptographic software verification (Klaus et al., 28 May 2026).

Noted engineering obstacles included Lean 4 version drift across ecosystem packages (e.g., Aeneas, Mathlib4, ArkLib) and extraction boundaries (e.g., generic Rust, trait bounds, Rust I/O). Typical remediations involved upstream patches, monomorphic model crates, or explicit recursion measures for loops.

8. Lessons and Future Outlook

Key findings demonstrate that the pipeline can bridge real-world Rust cryptographic code and formal mathematical specifications in Lean with kernel-checked proofs. AI provers significantly reduce manual proof burden for routine structural properties but are not yet capable of automating deeper algorithmic or domain-specific invariants. Maintaining consistent toolchain versions is identified as critical for practical workflow. The modular approach—enabling small, handwritten Rust models for constructs outside extraction scope—remains vital.

Anticipated future developments include automated CI integration of AI proof search on new obligations, extended support for unsafe/external Rust, and broader domain adaptation. A plausible implication is that domain-specific AI tactics for polynomial and field arithmetic could further amplify automation benefits (Klaus et al., 28 May 2026).

---

References:

• (Ho et al., 2022) "Aeneas: Rust Verification by Functional Translation"
• (Klaus et al., 28 May 2026) "A Rust-to-Lean Verification Pipeline with AI Provers: An Experience Report"