Papers
Topics
Authors
Recent
Search
2000 character limit reached

A Rust-to-Lean Verification Pipeline with AI Provers: An Experience Report

Published 28 May 2026 in cs.LO | (2605.30106v1)

Abstract: We describe a verification pipeline that takes production Rust cryptographic code and produces machine-checked correctness proofs in Lean 4. The pipeline combines three components: symbolic extraction tools (Charon and Aeneas, or Hax) that lift Rust into Lean 4; formal cryptographic specification libraries (ArkLib and CompPoly, from the Verified zkEVM project) that provide the mathematical targets; and AI provers (Aristotle from Harmonic AI and Aleph from Logical Intelligence) that close the resulting proof obligations. Every proof is checked by the Lean kernel, so AI output cannot compromise soundness. Within the scope of the Ethereum Foundation's zkEVM Verification Project, we applied the pipeline to cryptographic primitives in Plonky3 (FRI folding, Mersenne31 and KoalaBear field arithmetic, Horner polynomial evaluation) and RISC Zero (Merkle inclusion verification). In addition, Aleph authored proofs of two bounds-style theorems in Plonky3's compute_log_arity_for_round that previously stood as sorry. The paper describes the architecture, walks through a running example based on Aleph's two proofs, reports which classes of proof obligations AI closed and which required manual work, and discusses the engineering gaps we encountered: Lean 4 toolchain drift across tools and specific Aeneas/Hax extraction limits. We also document concrete missing lemmas, tactic gaps, and code-generation friction points discovered during proof development. We hope this contribution lowers the barrier to adoption of formal verification and facilitates more effective use of AI in this pipeline. The result is a working pipeline for formal verification of Rust, with kernel-checked proofs and reproducible artefacts.

Summary

  • The paper's main contribution is a scalable Rust-to-Lean verification pipeline that employs neurosymbolic AI provers to verify production cryptographic code.
  • It details a modular approach combining symbolic extraction tools, formal cryptographic libraries, and kernel-checked Lean proofs to ensure precise verification.
  • Empirical results demonstrate that while AI efficiently closes structural proof obligations, complex invariants still require significant manual expertise.

Rust-to-Lean Formal Verification Pipeline with AI Provers: Architecture, Empirical Insights, and Implications

Pipeline Overview and Architectural Integration

The paper introduces a verification workflow that targets production Rust cryptographic code, extracting it to Lean 4 for kernel-checked proofs. The pipeline consists of three principal modules: symbolic extraction tools (Charon/Aeneas, Hax), formal cryptographic specification libraries (ArkLib, CompPoly), and neurosymbolic AI provers (Aristotle, Aleph). Extraction mechanisms translate safe Rust into pure functional Lean 4, leveraging LLBC for semantic fidelity. Formal specifications are sourced both manually and from libraries architected for SNARKs and polynomial theory, including protocols central to zkVM stacks.

Every proof obligation is ultimately checked by the Lean kernel, preserving foundational soundness regardless of proof provenance. The pipeline was applied in the context of the Ethereum Foundation's zkEVM Verification Project, spanning arithmetic, polynomial computation, FRI folding, and Merkle inclusion checks across Plonky3 and RISC Zero. Notably, Aleph closed two previously unproven bounds in Plonky3's compute_log_arity_for_round, demonstrating concrete AI automation for cryptographically-significant Rust.

Empirical Use of AI Provers

The running example centers on verification of compute_log_arity_for_round, a function critical in FRI round scheduling. The extraction via Hax presents Lean code entailing monadic control flow and checked arithmetic. Two correctness theorems were posed: arity does not exceed a maximum bound and does not exceed the distance to an execution target. Aleph, using a decomposition and planning approach, produced both proofs autonomously, introducing helper lemmas for monad inversion and conditional bounds extraction. This demonstrates capability in AI-driven proof closure for structural and control-flow invariants.

Through systematic experimentation, three classes of proof obligations were reliably closed by AI: structural lemmas (monadic and conditional reasoning), tractable linear arithmetic, and simp-closeable boilerplate. However, domain-specific algebraic identities, loop invariants, and obligations requiring external interface axiomatization remained of higher complexity and necessitated substantial manual intervention. AI provers thus functioned as productivity multipliers on certain obligation classes, without fundamentally altering the verification bottlenecks around specification design and deep invariant discovery.

Case Studies and Verification Results

The pipeline was applied to eight consensus-critical targets, with public repositories housing code, specs, and proofs. Strong numerical results included:

  • Plonky3 FRI round scheduling (compute_log_arity_for_round): 6 theorems, 2 AI-closed, verifying bounds and boundary consistency.
  • Plonky3 arity-2 FRI fold (fold_step): Verified equivalence between Rust implementation and ArkLib folding specification, with ensured no overflow across 13 checked operations.
  • Field arithmetic and polynomial evaluation: Lean proofs grounded in extracted Rust models were constructed and kernel-checked, demonstrating correspondence to mathematical abstractions from ArkLib or CompPoly.

All verification artefacts exhibited reproducibility, and the synergy between extraction tools, formal specs, and AI provers enabled end-to-end proofs for production cryptographic code.

Engineering Challenges and Solutions

The integration surfaced several engineering friction points: toolchain drift across Lean 4 versions, extraction gaps in Aeneas/Hax due to Rust semantics (e.g., generics, external crates), and collision issues in dependent libraries. Solutions included upstream fixes, extraction of semantically equivalent models for problematic Rust code, and layering of verification tools for unsafe Rust. Notably, pipeline modularity permitted targeted interventions, minimizing barriers to practical cryptographic verification.

Theoretical and Practical Implications

This work reifies a scalable neurosymbolic pipeline for cryptographic software verification, evidenced by kernel-certified Lean proofs of real-world Rust implementations. It contrasts with landmark, whole-system verification efforts (seL4, CompCert) by focusing on modular, specification-driven engagement with minimal coupling. AI provers are empirically shown to close structural verification gaps but do not obviate the need for experts in specification design and domain abstraction.

From a theoretical perspective, the trust boundary remains anchored at the Lean kernel, with AI contributions reducible to auditable proof fragments. Practically, the pipeline lowers the entry barrier for formal assurance in Rust cryptographic stacks. This suggests future trajectories for broader adoption and tighter CI/CD integration of neurosymbolic proof automation.

Future Developments

Immediate next steps include extending the pipeline towards formal verification of the Signal messaging protocol as part of the Signal Shot initiative, and integrating AI provers more deeply in the verification workflow to automatically address newly introduced proof gaps. The maturation of AI provers capable of handling richer invariants and domain-specific abstractions is anticipated, potentially shifting the verification landscape and further reducing human proof engineering requirements.

Conclusion

The described pipeline delivers a public, reproducible, kernel-certified workflow for verifying Rust cryptographic code against Lean 4 formal specifications, with practical contributions to the Ethereum Foundation's zkEVM Verification Project. The integration of Rust extraction, formal cryptographic libraries, and neurosymbolic AI provers was empirically validated, illuminating both automation potential and ongoing engineering bottlenecks. The work has immediate implications for industrial adoption of formal methods in consensus-critical protocol stacks and sets the stage for broader scaling of machine-aided verification in cryptography and secure systems.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

What this paper is about (in simple terms)

This paper explains how the authors built a “verification assembly line” that takes real Rust code used in cryptography and proves, with math, that it does exactly what it should. They use:

  • translators that turn Rust programs into math-friendly Lean 4 code,
  • clear math definitions of what “correct” means,
  • AI helpers that suggest proof steps,
  • and a very strict checker (the Lean kernel) that re-checks every proof so nothing wrong slips through.

The big idea: make it practical to get rock-solid, machine-checked guarantees for important Rust code that powers zero-knowledge systems (like zkVMs), where even tiny bugs can break security.

The goals and questions

The paper sets out to:

  • Build a full pipeline from Rust code to Lean proofs that a computer checks.
  • Try it on real, important crypto code (from Plonky3 and RISC Zero).
  • See what kinds of proofs AI tools can handle and where humans still need to step in.
  • Record “engineering pain points” (version mismatches, missing tools, tricky Rust features) and share fixes and workarounds.

How the pipeline works (with everyday analogies)

Think of it like an assembly line with four stations:

  1. Translate Rust into math-ready Lean:
    • Tools like Charon + Aeneas or Hax act like translators. They convert safe Rust into clean Lean 4 functions.
    • When Rust code might crash or overflow, the translated version says so explicitly (like returning “ok value” or “error”)—this makes hidden problems visible.
  2. Define what “correct” means:
    • For simple functions, they write a clear math formula that the Rust code should match.
    • For crypto-specific parts (like polynomial folding or Merkle checks), they reuse precise definitions from two Lean libraries:
      • ArkLib: math specs for cryptographic protocols (e.g., FRI).
      • CompPoly: math for polynomials and finite fields.
  3. Prove the Rust code matches the spec:
    • Humans write some proofs.
    • AI provers (Aristotle and Aleph) suggest proof steps or even full proofs.
    • Regular Lean tactics handle arithmetic or algebra steps.
    • Important: the “Lean kernel” re-checks every single proof, so an AI can’t “bluff.”
  4. Re-check everything:
    • The Lean kernel is like a head referee. It accepts a proof only if every step follows the rules.

A small running example:

  • A function called compute_log_arity_for_round decides how much to “fold” in one round of a FRI protocol (a key piece in zk proofs). Two key facts were proved:
    • The chosen fold amount never exceeds a maximum limit.
    • It also never exceeds how much is left to reach the final target.
  • An AI prover (Aleph) filled in two missing proofs here by breaking the problem into small, reusable lemmas (mini-facts) and composing them neatly—then the Lean kernel checked the results.

What they found and why it matters

Main results:

  • The pipeline works end-to-end on real code. They proved properties about:
    • FRI folding steps and round scheduling (Plonky3),
    • arithmetic in special finite fields (Mersenne31, KoalaBear),
    • polynomial evaluation (Horner’s method),
    • Merkle inclusion proofs (RISC Zero),
    • and even a 32-bit “add with carry” (bit-level correctness).
  • AI provers were genuinely helpful. They were especially good at:
    • untangling control flow (ifs, matches),
    • simple-to-medium arithmetic bounds,
    • boilerplate reasoning around the translated code.
  • Some things still needed humans:
    • deeper algebra linking code to high-level math definitions,
    • inventing loop invariants (the “story” that stays true in each loop step),
    • choosing the right abstractions and specs.

Why this is important:

  • Crypto code is safety-critical: a tiny mistake can silently break proofs. Machine-checked proofs reduce that risk for all possible inputs, not just the ones you test.
  • The Lean kernel re-check makes the system trustworthy. Even if the AI suggests a proof, the kernel serves as the ultimate judge.
  • This lowers the cost and time of formal verification in practice by combining translators, math libraries, and AI.

Engineering lessons (the practical bits that matter in real projects):

  • Tool versions drifted; they coordinated to align Lean 4 versions.
  • Translators (Aeneas/Hax) don’t support every Rust pattern yet. Three reliable workarounds:
    • fix the gap upstream when possible,
    • extract a smaller, clean “model” of the function that captures the math,
    • layer other tools for unsafe Rust parts.

What this means for the future

  • This approach can help teams add strong, math-backed guarantees to important Rust code without spending years per project.
  • AI provers already boost productivity but don’t replace human judgment—especially for choosing the right specs and key ideas.
  • The authors plan to:
    • apply the pipeline to the Signal protocol code (another high-impact, security-critical target),
    • wire AI provers into continuous integration (so new “holes” in proofs get auto-attempted by AI and reviewers immediately see what’s solved).

In short: the paper shows a practical path to make real-world cryptographic Rust code provably correct, with AI as a helpful assistant and a strict math checker ensuring everything stays sound.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a single, concrete list of what remains missing, uncertain, or unexplored in the paper, framed so future researchers can act on it.

  • Safe-Rust-only coverage: The pipeline currently excludes unsafe Rust; the proposed “layered tools” approach (e.g., cargo-anneal) is not integrated or demonstrated. Open question: design and evaluate a principled integration for unsafe blocks that preserves end-to-end soundness and developer ergonomics.
  • External crate and I/O extraction: Calls into non-workspace crates (e.g., byteorder, std::io::Read/Write) are not extractable because Charon/Hax do not see their MIR/THIR. Gap: a mechanism to stub, inline, or symbolically model external APIs while retaining semantic faithfulness; evaluate impact on cryptographic code that depends on streaming or serialization.
  • Generics and trait bounds: Aeneas requires monomorphized types; generic functions with trait bounds (e.g., F: Field + TwoAdicField) don’t extract, forcing manual monomorphic “model” rewrites. Open task: extend extraction to handle common trait-bound patterns, or provide a verified monomorphization pass with formal semantic preservation.
  • Loop termination automation: Rust while loops become Lean recursion with termination measures, but the pipeline lacks automated derivation or verification of these measures. Gap: develop tactics or synthesis methods that infer well-founded measures for common Rust loop idioms and prove their correctness.
  • Hax semantic reliability: Work stays within a “pure, bounded-loop” fragment due to known semantic gaps. Open question: precisely characterize and prove the semantic preservation of Hax for a broader Rust subset (iterators, pattern-matching edge cases, integer/panic semantics), and publish a conformance test suite.
  • Arithmetic side-condition automation: Proofs involving casts to wider integer types (u128) in modular arithmetic generate side conditions that omega cannot close, requiring ad hoc nlinarith steps. Gap: domain-specific tactics/lemmas that uniformly discharge cast-related bounds and modular range obligations.
  • Bitvector/Mathlib naming collisions: The documented BitVec.toNat_pow conflict was fixed upstream once, but the broader issue of cross-library name/instance collisions remains. Open task: define and enforce naming conventions and module-level scoping policies across Aeneas/Hax/Mathlib/CSLib to avoid recurrent breakage.
  • Toolchain drift management: Coordination achieved for Lean 4 versions (4.26.0 vs. 4.28.0), but no general solution to ongoing drift across Aeneas, Hax, ArkLib, CompPoly, Mathlib4. Gap: a multi-repo version-lock and CI policy (e.g., shared Lake manifests, nightly compatibility dashboards) with automated bisecting of breakages.
  • Specification coverage and provenance: The pipeline verifies equality to ArkLib/CompPoly abstractions, but it does not assess the sufficiency/completeness of those specs for end-to-end protocol security. Open question: formally connect local primitive proofs (fold_step, merkle inclusion) to global zkVM soundness theorems and quantify coverage gaps.
  • Call-site precondition propagation: Case studies assume strong input preconditions (e.g., p2 ≤ 264 − 1, inputs < p); the paper does not show these are enforced throughout production call graphs. Gap: static analysis or proof obligations that propagate and discharge preconditions across crate boundaries and configuration paths.
  • Incomplete theorem set for FRI round scheduling: Four stated properties (e.g., arity_respects_next_input, folding_respects_final_height, round_consistency_preserved) remain at sorry. Action: complete these proofs, document proof strategies, and identify missing library lemmas blocking automation.
  • End-to-end FRI correctness: The paper proves one-step folding equivalences and bounds, but does not provide a full multi-round FRI soundness proof connecting implementation to ArkLib’s global protocol semantics. Open task: compose per-round correctness into a full FRI verifier proof, including challenge sampling and domain handling.
  • Merkle verification scope: The RISC Zero Merkle inclusion effort reports root recomputation and inclusion verification, but does not discuss adversarial edge cases (duplicate leaves, tree shape invariants, hash-domain separation). Gap: specify and prove these properties, including collision-resistance assumptions and domain separation modeling.
  • Hax-only field extraction without proofs: For Mersenne31/KoalaBear fields extracted via Hax, the paper does not report algebraic correctness proofs (carry/borrow, reduction, range invariants) analogous to the Aeneas Mersenne31 model. Action: add full field arithmetic correctness proofs for Hax extractions and reconcile differences with Aeneas-based models.
  • Panic/non-termination obligations: While the monadic encoding (ok/fail/div) exposes failure modes, the paper does not systematically prove absence of fail/div beyond isolated case studies. Open question: provide per-function and per-module meta-theorems guaranteeing panic-freedom and termination under stated invariants.
  • AI prover generalization and evaluation: Empirical evidence is limited (two PRs, small local experiments) and focuses on structural lemmas. Gap: a systematic benchmark of obligations arising from this pipeline (categories, difficulty, resource budgets), with comparative results across Aristotle/Aleph configurations and ablations.
  • AI-in-the-loop governance and safety: The kernel rechecks proofs, but the paper does not specify policy constraints (e.g., disallowing non-conservative axioms, controlling opaque proofs, tracking provenance). Action: define proof hygiene policies, audit tooling that flags nonconservative axioms/unsafe features, and add reproducible pipelines that record AI plan/proof artifacts.
  • CI/CD integration: AI provers are invoked per PR; the planned automatic invocation on fresh sorrys is not implemented. Gap: a robust CI service that triggers provers, caches failures/successes, surfaces diffs to reviewers, and guards against flaky automation (e.g., timeouts, nondeterminism).
  • Performance and scalability: No data on prover runtime, memory footprint, or developer throughput on larger modules. Open question: measure and optimize end-to-end performance (extraction, spec linkage, proof search) at the scale of full crates (e.g., Plonky3 FRI end-to-end, Signal protocol libraries).
  • Concurrency and stateful code: The pipeline focuses on pure, functional cores; it does not address concurrency, synchronization, or mutable state beyond what Aeneas can encode. Gap: extend the approach to stateful cryptographic code (e.g., transcript management, streaming hashing) with appropriate models and proofs.
  • Trust assumptions documentation: The paper places the trust boundary at the Lean kernel but does not catalog all assumptions (e.g., Rust compiler correctness for MIR/THIR, extraction correctness, spec soundness, cryptographic hardness). Action: publish an explicit, layered threat/assumption model for the pipeline and tie each layer to evidence (tests, proofs, audits).
  • Library/tactic deficits: The paper mentions missing lemmas and tactic gaps encountered during development but does not publish a consolidated “needed lemmas” backlog. Action: curate and upstream a checklist of missing algebraic, bitvector, monadic, and modular-arithmetic lemmas/tactics that would unlock automation for this pipeline.
  • Reproducibility across versions: Artefacts are public, but build reproducibility depends on aligned toolchain pins; there is no “one-click” reproducible environment (e.g., Nix/containers) across all repos. Gap: provide containerized/Nixified builds for each case study, with pinned transitive dependencies and automated verification runs.
View Paper Prompt  View All Prompts 

Practical Applications

Immediate Applications

The following applications can be deployed now by leveraging the paper’s pipeline (Rust → Lean 4 via Aeneas/Hax, ArkLib/CompPoly specs, AI provers with kernel re-check), proven case studies (Plonky3, RISC Zero), and documented engineering practices.

  • Verified cryptographic primitives in zkVM stacks (software, blockchain/DeFi)
    • Use case: Ship kernel-checked proofs for FRI components, finite-field arithmetic (Mersenne31/KoalaBear), Horner evaluation, and Merkle inclusion used in RISC Zero and Plonky3.
    • Tools/workflow: Charon/Aeneas or Hax to extract Rust; ArkLib/CompPoly specs; Aleph/Aristotle to close structural lemmas; Lean kernel as the trust boundary.
    • Impact: Reduces consensus-critical risk (silent proof invalidation), strengthens audit posture for zk rollups, bridges, and provers.
    • Dependencies/assumptions: Code is in the supported fragment of safe Rust; preconditions (e.g., field bounds) are explicit; Lean toolchain versions aligned across repos.
  • “Proof-aware CI” for Rust cryptographic crates (software engineering, DevSecOps)
    • Use case: Add a CI job that auto-runs extraction + proof scripts, invokes AI provers on new sorries, and fails builds if regressions or proof gaps appear.
    • Tools/workflow: Lake-based Lean projects; a GitHub bot (as demonstrated by aleph-prover[bot]) that posts proof diffs or highlights remaining obligations.
    • Impact: Shifts formal proof left; reduces manual boilerplate proofs; provides reproducible artifacts for code review and audits.
    • Dependencies/assumptions: Compute budget for prover runs; stable extraction configuration; agreed Lean version pins.
  • Model-extraction pattern for verification of generic Rust (software, cryptography)
    • Use case: When deep generics/traits or external crates block extraction, rewrite the mathematical core into a small, monomorphic model crate that extracts cleanly (e.g., fold_step from fold_matrix).
    • Tools/workflow: “Model crate” alongside production crate; proof of equivalence to the abstract spec (ArkLib/CompPoly) and checks for overflow/return-range.
    • Impact: Enables verification without redesigning production code; isolates semantic core for audits.
    • Dependencies/assumptions: The model is semantically equivalent; reviewers accept a model-based proof strategy.
  • Overflow/bounds hardening for performance-critical arithmetic (software, embedded/IoT)
    • Use case: Machine-checked proofs that 64-bit modular arithmetic in field operations cannot overflow and stays in-range under stated primes (e.g., Mersenne31).
    • Tools/workflow: Aeneas extraction; scalar_tac/nlinarith for side-conditions; ring/omega for algebraic identities.
    • Impact: Removes an entire bug class in hot loops; supports high-assurance cryptographic libraries.
    • Dependencies/assumptions: Correct, tight arithmetic preconditions; proof scripts part of release gates.
  • Auditable Merkle inclusion verification in infrastructure (software, storage/infra security)
    • Use case: Prove that inclusion checks recompute roots correctly; deploy verified Merkle verification in validators, light clients, archival systems.
    • Tools/workflow: Hax extraction; Lean proofs of equality to recomputation spec; integration into CI.
    • Impact: Stronger integrity guarantees for content-addressed data (block headers, proofs of inclusion).
    • Dependencies/assumptions: No reliance on external IO during extraction; use pure core recomputation routines.
  • Education and workforce training modules (academia, developer education)
    • Use case: Course labs that start with the public repositories to teach “neurosymbolic” verification on real Rust code (FRI folding, Horner, Merkle).
    • Tools/workflow: Curated branches with staged sorries; AI provers as “copilots” to demonstrate proof planning and helper-lemma discovery.
    • Impact: Lowers the learning curve; expands the pool of engineers comfortable with specification and proof repair.
    • Dependencies/assumptions: Stable teaching snapshots; platform access to Lean/Mathlib4.
  • Targeted audits with proof obligations as tickets (cybersecurity, consulting)
    • Use case: Turn remaining sorries and spec gaps into audit items; auditors fix proofs or adjust specs with explicit rationale.
    • Tools/workflow: Issue trackers linked to Lean obligations; delta reviews of proof patches.
    • Impact: Makes audits measurable and reproducible; improves communication between implementers and auditors.
    • Dependencies/assumptions: Shared understanding of spec scope; governance for accepting spec changes.
  • Bit-vector routine verification for embedded paths (software, robotics/embedded)
    • Use case: Apply the same pipeline to verify small but critical bit-level routines (e.g., 32-bit ADC add-with-carry).
    • Tools/workflow: Hax + bv_decide; integrate into firmware CI for arithmetic kernels.
    • Impact: Reduces subtle carry/overflow bugs; improves reliability in control loops.
    • Dependencies/assumptions: Routines are pure and bounded; no hardware-specific intrinsics in the core logic.
  • Documentation and upstreaming of missing lemmas and tactics (academia, tool ecosystems)
    • Use case: Close “engineering friction points” by contributing missing lemmas to Mathlib4/CompPoly/ArkLib; record extraction gaps and workarounds.
    • Tools/workflow: Focused upstream PRs; version alignment coordination.
    • Impact: Compounding returns for the community; smoother future verifications.
    • Dependencies/assumptions: Maintainer bandwidth; adherence to library contribution standards.
  • Policy-ready proof artifacts for regulated crypto services (policy, finance/DeFi)
    • Use case: Include machine-checked proofs in security disclosures or listings; satisfy procurement checklists requiring formal evidence for consensus-critical code.
    • Tools/workflow: Publish Lean proof bundles and build recipes; traceability from crate version to theorem statements.
    • Impact: Facilitates compliance and risk underwriting; differentiates exchanges, L2s, and custodians.
    • Dependencies/assumptions: Regulators/auditors accept Lean as a recognized formal method; reproducibility guaranteed.

Long-Term Applications

These applications require further research, scaling, or maturation of tools (e.g., broader Rust coverage, stronger AI proving, richer specs).

  • End-to-end verified zkVMs and rollup pipelines (software, blockchain/DeFi)
    • Use case: Compose proofs from field arithmetic → polynomial algorithms → FRI → commitment → protocol to achieve whole-pipeline guarantees.
    • Tools/workflow: Larger ArkLib/CompPoly specs; proof-carrying interfaces; modular CI with proof budgets.
    • Dependencies/assumptions: Better extraction of generics/iterators/extern crates; scalable Lean automation for loops and invariants.
  • Proof-gated releases and Continuous Formal Verification (CFV) at scale (DevSecOps)
    • Use case: “Zero-sorry” policies; nightly bots that propose proof patches; proof debt dashboards and SLOs.
    • Tools/workflow: Resource-aware orchestration for AI provers; caching across PRs; flaky-proof mitigation strategies.
    • Dependencies/assumptions: Stable, predictable prover performance; organizational buy-in for CFV gates.
  • Verification-as-a-Service for Rust ecosystems (software tooling)
    • Use case: Hosted pipelines that accept crates and return proof artifacts and badges (e.g., crates.io “formally verified” tag).
    • Tools/workflow: Managed Charon/Aeneas/Hax + Lean cluster; result caching; SBOM integration.
    • Dependencies/assumptions: Standardized spec schemas; IP/licensing clarity for generated proofs.
  • Layered verification of unsafe Rust (systems programming)
    • Use case: Combine safe-core proofs (Aeneas/Hax) with cargo-anneal-like tools to discharge unsafe blocks and aliasing invariants.
    • Tools/workflow: Contracts at FFI/unsafe boundaries; compositional proofs; memory model assurances.
    • Dependencies/assumptions: Mature unsafe-Rust verification frameworks; idioms for bridging memory models into Lean.
  • AI-driven invariant discovery and spec synthesis (AI for formal methods)
    • Use case: Move beyond structural lemmas to automatic loop invariants, ghost-state design, and spec inference from tests/examples.
    • Tools/workflow: Hybrid symbolic–neural search; counterexample-guided synthesis; data from this paper’s repositories.
    • Dependencies/assumptions: Better model reliability and alignment; benchmarks and reward shaping for real-world proofs.
  • Formal guarantees for messaging/security stacks (security, communications)
    • Use case: Apply the pipeline to Signal (as flagged by “Signal Shot”) and other secure messaging ecosystems; verify protocol, crypto, and state machines.
    • Tools/workflow: Protocol-level specs; session types; property sets (secrecy, forward secrecy, deniability).
    • Dependencies/assumptions: Richer cryptographic spec libraries; scalable treatment of stateful protocols.
  • Verified primitives in storage, networking, and TEEs (cloud, infra)
    • Use case: Formally verified hashing/Merkle in storage backends; networking handshakes; TEE attestation flows.
    • Tools/workflow: Extraction-friendly models of IO-bound code; equational reasoning for protocol transcripts.
    • Dependencies/assumptions: Better support for external crates/IO abstraction; validated specifications for systems properties.
  • Standardization and regulatory acceptance of proof artifacts (policy, compliance)
    • Use case: Mandate machine-checked proof bundles for critical infrastructure and financial protocols; incorporate proofs into SBOMs.
    • Tools/workflow: Proof artifact formats; cryptographic signing; archival with reproducible builds.
    • Dependencies/assumptions: Consensus on standards; auditor training; legal frameworks acknowledging formal evidence.
  • Cross-language verification and interop (software, compilers)
    • Use case: Extend beyond Rust via rocq-of-rust/F* backends; verify cross-language components with shared mathematical targets.
    • Tools/workflow: Spec libraries as lingua franca; cross-extractor compatibility; proof translations.
    • Dependencies/assumptions: Stable multi-backend extractors; semantic preservation theorems.
  • Education at scale and professional certification (academia, workforce)
    • Use case: Degrees/certificates in neurosymbolic verification; industry practicums on real codebases (zkVMs, crypto libraries).
    • Tools/workflow: Cloud lab environments; evolving challenge sets; collaborations with tool maintainers.
    • Dependencies/assumptions: Sustainable funding; curriculum standards; accessible tooling.
  • Insurance and risk pricing for verified systems (finance, cyber insurance)
    • Use case: Premium discounts for systems with kernel-checked proofs of critical paths (bridges, custody, exchanges).
    • Tools/workflow: Proof audits as underwriting inputs; standardized risk models tied to formal guarantees.
    • Dependencies/assumptions: Historical loss correlations; insurer comfort with formal methods as actuarial evidence.

Notes on shared assumptions and dependencies

  • Trust boundary is Lean’s kernel; all automation (including AI) sits outside it.
  • Extraction coverage: today’s pipeline best supports pure, safe Rust with bounded loops; deep generics, iterators, external IO/crates, and unsafe blocks require modeling or layered tools.
  • Version alignment across Lean/Mathlib4/CSLib/Aeneas/Hax is operationally critical.
  • Specifications must be correct and complete; proofs only establish conformance to the stated spec.
  • Compute resources and determinism: AI prover runs should be resource-budgeted and reproducible for CI and audits.
View Paper Prompt  View All Prompts 

Glossary

  • Aeneas: A Rust-to-Lean translator that turns Rust’s LLBC into pure functional Lean 4 while leveraging Rust’s borrow semantics. "Aeneas~\cite{ho2022aeneas} takes LLBC and produces pure functional Lean~4 code."
  • Aleph: An AI prover from Logical Intelligence that plans, proves, and refines Lean proofs. "Aleph authored proofs of two bounds-style theorems in Plonky3's compute_log_arity_for_round that previously stood as sorry."
  • Aristotle: An AI prover from Harmonic AI that generates Lean proofs and candidate lemmas. "Aristotle~\cite{achim2025aristotle} from Harmonic AI reports gold-medal-equivalent performance on the 2025 International Mathematical Olympiad"
  • ArkLib: A Lean 4 library of formal specifications for cryptographic protocols (e.g., SNARKs, FRI) used as verification targets. "ArkLib~\cite{arklib} formalises succinct non-interactive arguments of knowledge (SNARKs), cryptographic proof systems that allow a prover to convince a verifier that a computation was performed correctly without the verifier re-executing it."
  • Charon: A translator from Rust to LLBC, preserving typed structure for verification. "Charon~\cite{charon} translates safe Rust into LLBC~\cite{ho2022aeneas}, a typed intermediate representation derived from Rust's MIR."
  • CompCert: A formally verified optimizing C compiler, often cited as a landmark in verification. "Landmark systems such as seL4~\cite{klein2009sel4} and CompCert~\cite{leroy2009compcert} demonstrated that production-quality software can be fully verified"
  • CompPoly: A Lean 4 library for computational polynomial and finite-field theory underpinning cryptographic specs. "CompPoly~\cite{comppoly} provides computational polynomial and finite-field theory, including univariate, multivariate, and multilinear polynomial representations with equivalences to Mathlib's algebraic types, used both directly and as a foundation under ArkLib."
  • FRI: The Fast Reed–Solomon Interactive Oracle Proof of Proximity, a low-degree testing protocol central to STARKs. "It provides finite field implementations (Mersenne31, BabyBear, KoalaBear), the Fast Reed-Solomon Interactive Oracle Proof of Proximity (FRI) protocol~\cite{bensasson2018starks}, and the polynomial commitment infrastructure that zkVMs build on."
  • Interactive Oracle Reductions (IORs): A compositional framework for reducing complex proofs to simpler interactive protocols. "ArkLib builds on the theory of Interactive Oracle Reductions (IORs), a compositional framework in which a complex proof system is decomposed into a sequence of simpler interactive protocols, each reducing one relation to another~\cite{chiesa2019ior}."
  • Kani: A bounded model checker for Rust programs that complements formal proof. "Verus~\cite{lattuada2023verus}, Prusti~\cite{astrauskas2022prusti}, Kani~\cite{kani}, and Creusot~\cite{denis2022creusot} have lowered the entry barrier by embedding specifications directly in Rust source code and automating common proof obligations through SMT solvers and model checking."
  • Lean 4: An interactive theorem prover and programming language used as the target for extracted code and proofs. "The target prover is Lean~4 with Mathlib4 as its mathematical library."
  • Lean 4 kernel: The trusted proof-checking core of Lean that re-verifies every proof term. "The Lean kernel re-checks every proof, constituting the trust boundary of the described pipeline: regardless of whether a proof was written by a human, generated by an AI prover, or assembled from automated tactics, the kernel accepts it only if it typechecks."
  • LLBC: A typed intermediate representation (from Rust) that Aeneas consumes to generate Lean code. "LLBC~\cite{ho2022aeneas}, a typed intermediate representation derived from Rust's MIR."
  • Mathlib4: The community-maintained mathematical library for Lean 4, providing core algebra and automation. "The foundation is Mathlib4, the community-maintained mathematical library~\cite{mathlib4}"
  • Merkle inclusion: A verification that a given leaf is part of a Merkle tree via an authentication path. "Within the scope of the Ethereum Foundation's zkEVM Verification Project, we applied the pipeline to cryptographic primitives in Plonky3~\cite{plonky3} (FRI folding, Mersenne31 and KoalaBear field arithmetic, Horner polynomial evaluation) and RISC~Zero (Merkle inclusion verification)."
  • MIR: Rust’s Mid-level Intermediate Representation used by compilers and analysis tools. "LLBC~\cite{ho2022aeneas}, a typed intermediate representation derived from Rust's MIR."
  • Polynomial commitment: A cryptographic primitive enabling succinct commitments to polynomials with efficient evaluation proofs. "It provides finite field implementations (Mersenne31, BabyBear, KoalaBear), the Fast Reed-Solomon Interactive Oracle Proof of Proximity (FRI) protocol~\cite{bensasson2018starks}, and the polynomial commitment infrastructure that zkVMs build on."
  • Result monad: A monadic structure modeling success, failure (panic), or non-termination in extracted Lean code. "Each Rust function becomes a Lean function in the Result\ α\alpha monad, whose three constructors ok, fail, div distinguish successful return, panic, and non-termination."
  • RISC Zero: A production zkVM system based on the RISC-V ISA that leverages STARK proofs. "RISC~Zero~\cite{risczero} and SP1~\cite{sp1} are two production zkVMs built on the RISC-V instruction set."
  • Rocq: A proof assistant (the Coq system) targeted by some Rust-to-proof pipelines. "rocq-of-rust~\cite{rocqofrust} translates Rust into Rocq via THIR."
  • RustM monad: A monadic encoding used by Hax’s Lean backend to represent Rust computations and checked operations. "Hax extracts this into Lean~4, wrapping each checked subtraction in a RustM monad and representing each conditional as a Lean if/then/else."
  • seL4: A fully verified operating system microkernel, a landmark formal verification project. "Landmark systems such as seL4~\cite{klein2009sel4} and CompCert~\cite{leroy2009compcert} demonstrated that production-quality software can be fully verified"
  • SMT solvers: Automated theorem provers for Satisfiability Modulo Theories used to discharge verification conditions. "Verus~\cite{lattuada2023verus}, Prusti~\cite{astrauskas2022prusti}, Kani~\cite{kani}, and Creusot~\cite{denis2022creusot} have lowered the entry barrier by embedding specifications directly in Rust source code and automating common proof obligations through SMT solvers and model checking."
  • SNARKs: Succinct Non-interactive Arguments of Knowledge, proof systems enabling short, easily verifiable proofs. "ArkLib~\cite{arklib} formalises succinct non-interactive arguments of knowledge (SNARKs), cryptographic proof systems that allow a prover to convince a verifier that a computation was performed correctly without the verifier re-executing it."
  • STARK proof systems: Scalable Transparent ARguments of Knowledge, a zero-knowledge proof paradigm underlying several zkVMs. "Both rely on STARK proof systems~\cite{bensasson2018starks} whose arithmetic backbone is implemented in Plonky3~\cite{plonky3}."
  • Sum-Check: An interactive proof protocol used within algebraic PCP/IOP frameworks and formalized in ArkLib. "The library includes formalisations of Sum-Check, FRI, WHIR, and other protocols at the abstract level, together with the polynomial machinery (folding, evaluation domains) they depend on."
  • Termination measures: Well-founded measures used to justify termination of recursive functions extracted from loops. "Rust while loops become recursive functions in Lean and require explicit termination measures."
  • THIR: Rust’s Typed High-level Intermediate Representation used by Hax and rocq-of-rust. "Its frontend hooks into the Rust compiler and exports the THIR (Typed High-level Intermediate Representation) as JSON;"
  • Verus: A Rust verification system using ghost types and SMT backends to prove specifications. "For Rust specifically, recent verifiers such as Verus~\cite{lattuada2023verus}, Prusti~\cite{astrauskas2022prusti}, Kani~\cite{kani}, and Creusot~\cite{denis2022creusot} have lowered the entry barrier"
  • WHIR: A cryptographic protocol formalized in ArkLib alongside Sum-Check and FRI. "The library includes formalisations of Sum-Check, FRI, WHIR, and other protocols at the abstract level, together with the polynomial machinery (folding, evaluation domains) they depend on."
  • zkEVM: A zero-knowledge Ethereum Virtual Machine effort to which the paper’s verification targets belong. "Within the scope of the Ethereum Foundation's zkEVM Verification Project, we applied the pipeline to cryptographic primitives in Plonky3~\cite{plonky3} and RISC~Zero~\cite{risczero}."
  • zkVM: A zero-knowledge virtual machine that produces succinct proofs of correct program execution. "A bug in one round of FRI folding silently corrupts every proof a zero-knowledge virtual machine (zkVM) emits."
View Paper Prompt  View All Prompts 

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Generate Now

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 2 tweets with 121 likes about this paper.

Sign Up for Free