2/🔹 Phase 1: Stateless Client (Q4 2025) zkEVM proofs are optional. Clients can choose to verify them but aren’t required to. This phase is for early adopters and prototyping the tech without affecting consensus.

3/🔹 Phase 2: Mandatory Proofs (Q2 2026) zkEVM proofs become required for attestations. Clients will reject blocks that lack a valid proof. Security tightens, but consensus still runs outside the zk machinery.

4/🔹 Phase 3: Enshrinement (~2027–2028) zkEVM provers and verifiers become part of Ethereum’s core consensus. Proofs must meet strict standards: • Fully audited • Formally verified • 128-bit security or better

5/🛑 A clear stance: No recursive Groth16 wrapping. Why? • Trusted setup is fragile • Poor post-quantum security • Adds complexity Instead, the goal is raw STARKs or universal-setup SNARKs directly verified by L1.

6/📦 Proof size guidance: • Target: ≤300 kB • Ideal: ≤128 kB This keeps things viable for stateless clients, where every byte affects sync time and UX. Most projects report raw proof sizes between 270 kB and 1 MB — optimization ongoing.

7/ 📘 Projects could publish an “executable spec”. This bridges academic papers and real-world code: • Captures all optimizations • Avoids ambiguities • Allows independent reimplementation of verifiers Specs can be formal or richly-commented code — as long as they’re precise

8/ 🔄 Verifier upgrades must follow a strict rule: No new verifier can be adopted unless it’s as formally verified and audited as the last one. Once proofs are mandatory (Phase 2), this becomes a consensus requirement.

9/🧪 Formal verification (FV) plan: • Starts partially during optional-proof phase • Must be complete before enshrinement • Includes both circuits and verifiers • Estimated effort: 6–12 person-months per prover

10/🧠 The community is moving away from shaky conjectures like “8-STARK security”. The medium-term goal: • Proof systems grounded in provable security • Or rely on better-understood assumptions (e.g., list-decoding bounds)

11/ 📉 Wrapping tradeoffs were debated: • Groth16 offers tiny proofs (~2 kB) but requires setup and is not post-quantum safe • STARKs are larger but more robust Consensus: Accept larger raw proofs and remove wrapping for long-term simplicity and security.

12/ ⚙️ Engineering realities: • Some teams (@RiscZero, @SuccinctLabs, @Scroll_ZKP) show raw STARKs between 270 kB and 1.5 MB • Tuning params, batching, and removing wrapping can bring them under 300 kB • Spec and verifier logic must match to avoid transcript mismatches

13/💡 Critical separation: • Protocol-level optimizations affect consensus and must be specified • Engineering tweaks (e.g. parallelism) can vary per implementation Verifiers must agree at the protocol level regardless of code internals.

14/ 🔍 Bug example: a missed edge case in a linear combination due to optimization in backend. Takeaway: If it affects the transcript, it must be in the spec. Optimizations must never change protocol behavior.

15/ 📈 Long-term expectations for enshrinement: • Raw proofs directly verified by L1 • No unverified optimizations • Full formal verification • Strict EIP/ACD process for verifier updates • 128-bit security minimum

16/ ⚠️ Open questions ahead: • What’s the final proof size limit? • Can grinding recover bits if weaker assumptions are used? • How to streamline FV tooling for teams? • How to set hardware/power constraints for provers?

17/ 🛠️ Meanwhile, other workstreams continue in parallel: • "Prover-killer" work on availability/DoS • Slot-time halving and gas bump discussions • Bug bounties to scale once proofs affect consensus

18/📣 Summary: Ethereum is laying the groundwork to bring zkEVM proofs into consensus — step by step, with verifiable security, no wrapping, and developer-aligned specs. Next steps include refining milestones and sharing a draft guideline ahead of Devcon.