Formal Verification Audit Document
Rahul Dalal, Tamir Hemo, Eugene Rabinovich, Ron D. Rothblum — Succinct
The security properties of the VEIL protocol have been formally verified in Lean 4. Specifically, the axioms, definitions, and theorem statements from the paper have been encoded in Lean, and the proofs have been machine-checked. The formalization was produced primarily by AI (Claude Opus 4.6 and 4.7) under human supervision. However, there is no formal guarantee that the Lean statements faithfully match the VEIL paper or any implementation—this correspondence must be audited by humans.
This document is designed to make auditing correspondence with the paper as easy as possible. It presents all major definitions and theorems alongside their Lean formalizations. Click any Lean link to view the formal statement side-by-side. Within the Lean code, hoverable identifiers show the definitions they depend on.
To verify the proofs, clone the source repository and run lake exe cache get && lake build to compile and type-check all theorems and also verify that no spurious axioms were added. For independent kernel-level validation, run lake env leanchecker afterward. See the Lean reference on validating proofs for standard guidelines (note: some instructions on that page may be outdated).
Each protocol section below is split into definitions (green boxes) followed by theorems (blue boxes).
Every protocol is defined in LEAN using the same core objects. Together they should fully specify what the protocol does:
realView and cheatingView produce a VerifierView, and verifierAccepts takes only a VerifierView.VerifierView. Defines the protocol flow: commitment phase (padding, oracle construction), interaction phase (prover/verifier messages), and query phase.VerifierView. Lists the algebraic checks the verifier performs on the transcript.VerifierView. A CheatingProver is a collection of response functions, each producing one part of the transcript. The function arguments encode the round structure: they show exactly which verifier challenges the cheating prover has seen when generating each response. For example, a field respond : F → Vec F n means the prover's response may depend on one challenge, while a constant field β : F means it is fixed before any challenge is seen. The oracle is committed upfront and is immutable — query responses are lookups into this fixed table.Each protocol proves three properties, stated in terms of the definitions above:
verifierAccepts(realView(...)) always holds when the claim is true.verifierAccepts(cheatingView(...)) holds with low probability when the claim is false.realView(...) over the prover's randomness.Compiles an arithmetically partially-zk IOP into a fully-zk IOP by hiding exposed messages with a random masking vector and delegating acceptance to a circuit evaluation scheme.