Ethereum Foundation's zkEVM Verification

• The Ethereum Foundation's zkEVM Verification Project is a formal verification pipeline that translates Rust code into Lean 4, ensuring machine-checked correctness of cryptographic components.
• It employs a staged process featuring symbolic extraction, formal specification, AI-assisted proof construction, and a kernel re-check to validate SNARK/STARK primitives and polynomial routines.
• The workflow verifies critical cryptographic targets, including SNARK/STARK primitives, polynomial evaluations, and Merkle proofs, to secure robust zkEVM and Layer 1 rollup infrastructures.

The Ethereum Foundation's zkEVM Verification Project provides an integrated, production-grade pipeline for formally verifying cryptographic Rust codebases underpinning zero-knowledge virtual machines (zkVMs) in the Ethereum ecosystem. Through a staged extraction, specification, and kernel-checked proof generation process—leveraging both symbolic analysis tooling and AI-powered automated theorem provers—the project demonstrates end-to-end, machine-checked correctness for complex SNARK/STARK primitives, polynomial evaluation routines, and Merkle inclusion proofs. This initiative underpins the formal guarantee of cryptographic invariants for emerging high-assurance rollup and Layer 1 zkEVM infrastructures.

1. Pipeline Architecture and Methodology

The verification pipeline integrates four tightly-coupled stages:

1. Symbolic Extraction (Rust → Lean 4):
   • Charon transforms Rust crates into a λ-calculus-like intermediate representation (LLBC) derived from Rust’s MIR.
   • Aeneas compiles LLBC into functional Lean 4, explicitly encoding branching, panics, and checked arithmetic into monadic return types (e.g., Result/RustM).
   • Alternative workflows use Hax, which extracts Lean 4 models from Rust’s THIR, supporting panics/divergence via monadic encapsulation.
2. Cryptographic Specification in Lean 4:
   • Functionality is specified by hand for primitive cases (e.g., field/range constraints).
   • High-level abstractions use ArkLib (covering SNARK-level constructs like FRI, Sum-Check, and folding) and CompPoly (computational polynomial and field theory).
   • Verification targets are tied to extracted code under explicit preconditions (overflow freedom, valid input ranges).
3. Proof Construction (Human + AI Collaboration):
   • Aeneas and Mathlib4 supply foundational tactics (progress, scalar_tac, simp, ring, omega, nlinarith).
   • Automated provers: Aristotle (general IMO-level reasoning), Aleph (proof plan decomposition, lemma generation, refinement).
   • All proof objects—irrespective of origin—are checked for soundness in the Lean 4 kernel.
4. Kernel Re-Check:
   • The Lean kernel acts as a strict trust boundary: only well-typed, sound proofs are accepted.

This pipeline constitutes the first end-to-end workflow linking production Rust to Lean 4 formal specifications for consensus-critical zkVM components (Klaus et al., 28 May 2026).

2. Verified Cryptographic Targets

The scope covers eight consensus-critical Rust modules, categorized as follows:

Target Type	Example Functions	Specification Source
Plonky3 (STARK toolkit)	compute_log_arity_for_round, fold_step, field ops	ArkLib + Lean spec
Polynomial Evaluation	Horner’s rule (generic loop)	CompPoly
Merkle Inclusion	RISC Zero Merkle-tree root recomputation/verification	Lean, Ad-hoc
Bit-Vector Arithmetic	32-bit ADC (add-with-carry)	Lean, via bv_decide

Key proofs include:

• FRI round scheduling: Upper-bounds and distance constraints for compute_log_arity_for_round (both fully discharged by Aleph).
• Arity-2 folding step: Mathematical equivalence of Rust’s implementation with ArkLib’s definition, alongside explicit overflow guards.
• Field arithmetic: Correctness and overflow-freedom for Mersenne31 and KoalaBear field operations, mapped to u32/u64 representations.
• Polynomial evaluation: Lean 4/Hax-extracted Horner loop, proved equal to CompPoly’s canonical polynomial evaluation scheme over $\mathbb{Z}/p\mathbb{Z}$.
• Merkle proofs: Correctness of Merkle root reconstruction per binary proof specification.
• Bit-vector arithmetic: Automated bit-level correctness for add-with-carry via dedicated tactic.

This set demonstrates comprehensive coverage for primary zkEVM cryptographic subroutines (Klaus et al., 28 May 2026).

3. Automation Strategy: AI Provers versus Human Input

Out of approximately 50 proof obligations, the division is as follows:

Obligation Type	Closed by AI (Aleph/Aristotle)	Human Guidance Required
Control-flow/structural (monad inv.,	✔
Option splits, arithmetic guards)
Linear arithmetic (bounds, min/max)	✔
Boilerplate code simplification	✔
Algebraic identities (fold equivalence)		✔
Loop invariants		✔
Specification, axiomatisation		✔

AI proved all lemmas concerning control-flow and arithmetic (e.g., monad inversion, case splitting, min/max bounds), reliably handling "boilerplate" code. Domain-specific invariants, algebraic rewrites, and loop reasoning remained outside AI reach. Each proof, regardless of automation, typechecks in under 200 ms.

Notable Aleph-closed theorems (Plonky3/FRI):

• arity_respects_max_bound: If compute_… = .ok result then $result \leq max\_log\_arity$.
• arity_respects_target_distance: If … = .ok result and $log\_current\_height > log\_final\_height$ then $$result.toNat \leq log\_current\_height.toNat - log\_final\_height.toNat$$.

Both proofs required compact (<30 lines) lemma synthesis and affine case analysis, with main steps reducible to repeated monadic unwrapping and application of "min" bounding principles.

4. Lean 4 Lemma Patterns and Proof Mechanization

Two mechanistic patterns underlie most AI-driven proofs:

• Monad Inversion:

theorem RustM_bind_eq_ok {α β : Type} (x : RustM α) (f : α → RustM β) (r : β) : x.bind f = .ok r → ∃ a, x = .ok a ∧ f a = .ok r := by cases x with | ok a => ... | fail e => ... | div => ...

Used for peeling bind chains in extracted monadic Rust logic.

• Bounding the "min" Expression:

theorem RustM_ok_ite_decide_lt_le_right (a b r : USize64) : (if decide (a < b) then RustM.ok a else RustM.ok b) = RustM.ok r → r ≤ b := by intro h; by_cases hlt : a < b; ...

Proofs for the main Plonky3 scheduling logic combine these tactics: definitions are unfolded, binds/analyzers are applied, and term-wise bounds are composed into the specification predicate (Klaus et al., 28 May 2026).

5. Engineering Gaps and Toolchain Observations

The project identified and addressed several limitations:

1. Lean 4 toolchain heterogeneity: Initial incompatibility between Aeneas, Hax, Mathlib4, ArkLib, CompPoly (divergent minor versions); resolved with coordinated upgrades (to 4.28.0 for Aeneas, 4.26.0 for Hax work).
2. Extraction incompleteness: Symbolic extractors are limited to "safe Rust"; unsupported cases include deep generics, external interfaces (e.g., std::io::Read), and certain integer casts (e.g., u128, requiring extra arithmetic guards).
3. Manual extraction models: Extraction-friendly, monomorphic models (u64-only versions) written for core algorithms.
4. Tactics gaps, missing lemmas: Additional field-theoretic and bounds lemmas contributed to CompPoly/ArkLib; opportunities noted for more sophisticated loop-invariant tactics.
5. Dealing with "unsafe" Rust: Proposed solution is to layer complementary tools (e.g., cargo-anneal, Anodized) atop the base symbolic pipeline.

This experience highlights the interplay between tool maturity, language evolution, and formal modeling requirements for Rust-to-Lean program extraction (Klaus et al., 28 May 2026).

6. Significance and Future Implications

By delivering a working pipeline with kernel-checked proofs and reproducible Lean 4 artifacts spanning cryptographic subroutines vital for zkEVM/rollup security, the project establishes a model for scalable, high-assurance verification in the Rust cryptography ecosystem. The empirical breakdown demonstrates the mature capabilities of AI provers for control and arithmetic obligations, while underscoring human input necessity for specialized algebraic and invariance reasoning.

Planned future extensions include:

• Automated integration of AI provers for CI/CD workflows (auto-closing new sorrys).
• Extension to unsafe Rust modules via additional verification layers.
• Broader application, e.g., to end-to-end verification of the full Signal codebase under the Beneficial AI Signal Shot program.

This pipeline is poised to distinctly lower barriers for formal verification adoption in critical zkVM deployments and provides a rigorous path to integrating Rust cryptographic kernels into fully-verified proof stacks for next-generation Ethereum scaling solutions (Klaus et al., 28 May 2026).