Assurance Boundaries: Proofs Shift Trust To Kernels, Specs, And Translation Tooling
Sources: 1 • Confidence: Medium • Updated: 2026-03-25 17:58
Key takeaways
- Even if properties are proven about a Lean model of Rust code, the trusted computing base can still include the Rust compiler and LLVM optimizations, which can contain bugs and can break properties like constant-time behavior across versions.
- Because production ZKVMs can decouple witness generation from constraints, the current verification does not prove that the production witness generator always produces a witness satisfying the verified constraints, and addressing this gap is an active effort.
- The project extracts the official RISC-V specification written in SAIL into Lean via a SAIL-to-Lean backend that is treated as part of the trusted boundary and supports all RISC-V extensions.
- Alex Hicks joined the Ethereum Foundation in June 2024 to lead a formal verification effort intended to involve the broader ZK ecosystem and backed by substantial resources.
- AI-assisted contribution workflows are described as already in use, including scripts that open issues for missing proofs and contributors using tools like Claude or Codex to generate Lean proofs that are accepted if they verify.
Sections
Assurance Boundaries: Proofs Shift Trust To Kernels, Specs, And Translation Tooling
- Even if properties are proven about a Lean model of Rust code, the trusted computing base can still include the Rust compiler and LLVM optimizations, which can contain bugs and can break properties like constant-time behavior across versions.
- Formal verification is described as producing a machine-checkable proof of a theorem-like statement, including statements about software behavior.
- Proof assistants are described as compiling proof code to a small kernel that checks proofs, making kernel size and correctness central to trust.
- Proof assistants based on simpler logics can have very small kernels, while dependent-type systems like Lean and Coq have more complex kernels and thus potentially larger soundness-risk surfaces.
- Verifying software is described as often reducing to proving equivalence or refinement between an implementation and a specification, and specification correctness is described as the dominant risk factor.
- Formal verification of code translated from mainstream languages is constrained by the lack of fully formal semantics for many languages, requiring trusted models or restricted subsets rather than full-language equivalence proofs.
Operational Bottlenecks: Constraint Ingestion, Witness Generation, Ci Drift, And Scale Limits
- Because production ZKVMs can decouple witness generation from constraints, the current verification does not prove that the production witness generator always produces a witness satisfying the verified constraints, and addressing this gap is an active effort.
- There is currently no robust CI pipeline that re-extracts constraints into Lean and reruns proofs on every change, creating a risk that proofs only apply to a specific commit.
- For some components, extracting full constraints into Lean is impractical at scale, with Plonky3 Keccak constraints producing an approximately 1.4GB file in one cited example.
- A described workaround for large constraints is translating Rust to Roc, proving properties at the program level, and checking that it generates identical constraints.
- Circuit constraints are brought into Lean by extracting an AST from the source constraint language or DSL and printing it into Lean, and this translation step is treated as part of the trusted boundary.
- Lean proofs rely on Mathlib, and library churn can break proofs as a maintenance issue even if it does not compromise soundness.
Risc-V Formalization Pipeline And Hedging Via Equivalence Proofs
- The project extracts the official RISC-V specification written in SAIL into Lean via a SAIL-to-Lean backend that is treated as part of the trusted boundary and supports all RISC-V extensions.
- There is an explicitly stated trust tradeoff between relying on a SAIL-to-Lean extraction backend versus relying on a handwritten RISC-V specification in Lean.
- A handwritten, bitblastable RISC-V spec in Lean has been proven equivalent to the extracted SAIL spec, including pure instructions and side-effecting instructions such as loads and stores.
- The SAIL specification and its Lean extraction introduce layered trust boundaries, including the RISC-V Foundation specification choices, the SAIL implementation, and correctness of the SAIL-to-Lean backend translation.
Ef Formal Verification Is Now A Resourced Program Tied To Zk Practicality
- Alex Hicks joined the Ethereum Foundation in June 2024 to lead a formal verification effort intended to involve the broader ZK ecosystem and backed by substantial resources.
- The Lean Ethereum vision targets end-to-end formal verification across the ZK stack, spanning RISC-V, ZK-VMs, circuits/constraint systems, compilers, and cryptographic primitives.
- LeanVM is not yet in production, so current formal verification work is focused on RISC-V-based ZKVM execution layers rather than LeanVM itself.
Ai Changes Proof-Production Throughput Under Verification-Gated Acceptance
- AI-assisted contribution workflows are described as already in use, including scripts that open issues for missing proofs and contributors using tools like Claude or Codex to generate Lean proofs that are accepted if they verify.
- A specialized AI model developed by Logical Intelligence reportedly proved the Polischuk–Spielman theorem in about eight hours for roughly $200 of compute.
Watchlist
- Because production ZKVMs can decouple witness generation from constraints, the current verification does not prove that the production witness generator always produces a witness satisfying the verified constraints, and addressing this gap is an active effort.
- There is currently no robust CI pipeline that re-extracts constraints into Lean and reruns proofs on every change, creating a risk that proofs only apply to a specific commit.
Unknowns
- What concrete, publicly verifiable deliverables (repositories, proofs, specs, audited artifacts) have been released by the formal verification effort since June 2024, and what components do they cover end-to-end?
- To what extent do major production ZKVMs adopt these verified semantics and constraint proofs, and do they treat them as release gates?
- How is the SAIL-to-Lean backend validated, and what is the process for detecting regressions when the upstream SAIL spec changes?
- What is the current coverage of the RISC-V equivalence proof across extensions, and how is coverage tracked over time?
- What concrete methodology is being used to close the gap between verified constraints and production witness generation, and what measurable correctness guarantees will result?