Ethereum L2 Multiprover Working Group

# Working Group to Accelerate L2 Multiproving [ToC] ## TL;DR - Ethereum rollups already secure billions in user funds; multiproving is how we ensure those funds are never at the mercy of a single bug, team, or cryptographic assumption. - Our **north star** is to make multiproving the default security model for Ethereum L2s with non-trivial value. - We will follow three guiding principles: 1. **Pareto principle** — prioritize the top 80% of users first. 2. **Research engineering** — progress via PoCs to uncover unknowns, not by designing for the end state by day 1. 3. **No logos** — this is about shared architecture, not marketing. - **Immediate goals**: OP Stack multiprover PoC, Arbitrum Orbit multiprover PoC, and a design goals document for a multiprover market interface. - **Longer-term goals**: reach ≥90% of L2 TVL, converge on a generalized multiprover architecture, and build a shared open-source codebase. ----- ## Why Multiproving Matters ### Rollups and Proofs [Rollups are Ethereum’s path to scalability](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698). They execute transactions offchain, compress results, and regularly post data and proofs back to Ethereum L1. This allows cheap transactions while inheriting Ethereum’s security guarantees. For a deeper dive, see the [Incomplete Guide to Rollups](https://vitalik.eth.limo/general/2021/01/05/rollup.html). At the center of this model is the proving system — the mechanism that convinces L1 that offchain execution was valid. ### Risks of a Single Prover Relying on a single proving system introduces a single point of failure with distinct risk vectors: - **Soundness Risk:** A bug in the prover's code or underlying cryptography could allow it to generate a proof for an **invalid state transition**. This is a catastrophic failure that could lead to the theft of all funds on the L2. - **Liveness Risk:** The single prover could fail to produce proofs for **valid state transitions**. This could happen due to a non-critical bug, operator error, or a hardware failure, causing the entire chain to halt. - **Centralization Risk:** A single team controls the proving system's code and its upgrades. This centralizes power, creating a target for external pressure (e.g., censorship demands) and requiring users to trust that team's competence and incentives indefinitely. In short: **A single prover is a single point of failure** that forces the ecosystem to bet billions on a single piece of code written by a single team. ### Multiproving as the Solution Multiproving directly mitigates these risks by removing the single point of failure. It provides: - **Redundancy for Liveness:** If one prover goes offline or fails to produce a proof, another independent prover can step in. This ensures the chain remains live and continues to finalize transactions. - **Diversity for Soundness:** Using two or more provers built by **different teams from different codebases** (e.g., a ZK prover and an Optimistic prover) makes it astronomically unlikely they would share the same critical soundness bug. An invalid state transition approved by one would be rejected by the other. - **Trust Minimization:** Multiproving replaces trust in a single team with the much weaker and safer assumption that *at least one* of the prover implementations is correct and honest. This moves the system from trusting a specific entity to trusting a decentralized security model. ### Pragmatic Fast Finality Rollup and bridge operators, as well as market makers, all want the fastest possible finality in their proofs. Operators need to reduce the risk of prover failures, while market makers care about shorter settlement times so they can take more risk and provide better fees. A promising solution is outlined in [A simple L2 security and finalization roadmap](https://ethereum-magicians.org/t/a-simple-l2-security-and-finalization-roadmap/23309) by Vitalik Buterin. This approach, called **Pragmatic Fast Finality**, uses a **2-of-3 multiprover architecture** between ZK, optimistic, and [TEE](https://www.google.com/url?sa=E&source=gmail&q=https://www.cloudflare.com/learning/bots/what-is-a-trusted-execution-environment-tee/) provers with: - **Immediate finality** if ZK + TEE agree on a state root. - **Delayed finality** if only one agrees, resolved by the optimistic challenge game. - **Upgrade safety** with a security council: TEE logic can be updated instantly, while ZK and OP require a 30-day delay. This design delivers fast finality, reducing bridging and settlement times to around an hour or less, while meeting [Stage 2 trustlessness](https://www.google.com/url?sa=E&source=gmail&q=https://ethereum.org/en/roadmap/centralization/) by ensuring semi-trusted components cannot override correct ZK + OP results. It also provides resilience through diversity, since ZK and OP provers are fundamentally different, lowering the risk of correlated bugs compared to relying on two ZK systems. ----- ## North Star Our north star is to **make multiproving the default security model for Ethereum L2s**. Multiproving is not just an optimization — it is critical infrastructure for the world computer. By combining diverse proving systems, we can deliver redundancy, resilience, and trustless fast finality that makes L2s safer and more reliable at scale. ### North Star Metrics Progress will be measured by: - **Adoption**: % of L2 TVL running multiprover designs. - **Diversity**: independent implementations across OP, ZK, and TEE families. - **Performance**: Settlement and bridging times reduced to \~1 hour or less in production. ## How Do We Get There The building blocks already exist: multiple zk proving systems such as [Succinct](https://succinct.xyz/), [RiscZero](https://www.risczero.com/), and others are rapidly improving with hardware acceleration. TEE-based provers also exist and are production-ready. What we lack is the **shared architecture and market structure** that make multiproving plug-and-play. Our task is to connect the dots: prove out multiproving in practice, and then converge on a generalized, open architecture. ### Guiding Principles 1. **Pareto principle** — target the top 80% of Ethereum L2 TVL first to deliver maximum impact before broadening to the long tail. 2. **Research engineering** — we do not attempt to design the perfect end state up front. Instead, we progress through proof-of-concepts that reveal unknowns, then generalize from real-world results. 3. **No logos** — this effort is about shared architecture, not marketing. ### Immediate Goals (PoC Phase) 1. **[OP Stack](https://stack.optimism.io/) multiprover implementation** — OP Stack secures \~$21B in TVL. 2. **[Arbitrum Orbit](https://arbitrum.io/orbit) multiprover implementation** — Arbitrum secures \~$20B in TVL. 3. **Design goals document for a multiprover market interface** — outlining how provers, clients, and marketplaces can interact. These two stacks alone cover \~80% of Ethereum L2 TVL (per [L2BEAT](https://l2beat.com/scaling/)), so focusing here first follows the Pareto principle: maximize impact quickly, then expand. Other stacks are welcome to build PoCs in parallel, but lack of coverage elsewhere will not block WG progress. ### Longer-Term Goals (Generalizable Architecture) - **Coverage of ≥90% of TVL** across Ethereum L2s. - **One generalized multiprover architecture** that works across OP Stack, Arbitrum, and other major stacks. - **A shared open-source codebase** for multiprover infrastructure, enabling interoperability and collective auditability. --- ## Working Group Call Log - [Call #0](https://hackmd.io/y0DqrsmkR-iq-tvKdwWokw?both)