On February 11, 2026, the Ethereum Foundation convened the inaugural L1-zkEVM breakout call — the first formal coordination meeting for what may become the most consequential architectural transformation in Ethereum's post-Merge history. At its core, EIP-8025 proposes a fundamental inversion of h...
"Instead of repeating the computation, you verify a cryptographic proof. A zkAttester does not need to hold EL state. It does not need to sync the full execution layer chain." — ladislaus.eth, Ethereum Foundation
ETH Price: ~$2,010 | Market Cap: $242.6B | Total ETH Staked: 36.6M (30% of supply) | Active Validators: ~1.15M | Current Gas Limit: 60M | Glamsterdam Target: 200M | L1-zkEVM Workshop #1: February 11, 2026, 15:00 UTC
On February 11, 2026, the Ethereum Foundation convened the inaugural L1-zkEVM breakout call — the first formal coordination meeting for what may become the most consequential architectural transformation in Ethereum's post-Merge history. At its core, EIP-8025 proposes a fundamental inversion of how Ethereum validates blocks: rather than requiring every validator to independently re-execute every transaction in every block, the protocol will allow validators to verify compact zero-knowledge proofs that attest to correct execution. The shift from computation to verification is not incremental. It is categorical.
The implications cascade across every layer of the Ethereum stack. Solo stakers and home validators — the decentralization backbone of Ethereum's security model — would no longer need to run full execution layer clients or store the complete chain state. Syncing would reduce to downloading proofs for recent blocks since the last finalization checkpoint. Hardware requirements that currently scale linearly with gas limit increases would decouple entirely, enabling Ethereum to scale L1 throughput to 10,000 TPS via the Glamsterdam upgrade's 200M gas limit without proportionally increasing the burden on individual validators.
But the transition introduces a new class of risk. Proof generation currently requires approximately 12 GPUs and 7 seconds per block. If proving concentrates in specialized infrastructure providers, Ethereum may trade one centralization vector — the cost of re-execution — for another: access to GPU-intensive prover networks. The community now faces a design challenge as fundamental as the Merge itself: can zero-knowledge infrastructure be made accessible enough to preserve the decentralization properties that make Ethereum's security guarantees meaningful?
Today — February 11, 2026, at 15:00 UTC — marks the formal beginning of the L1-zkEVM development phase. The inaugural breakout call convened by the Ethereum Foundation represents the transition from research concept to active engineering coordination. This is not a theoretical discussion. The Ethereum Foundation has already published a comprehensive 2026 roadmap, identified six development workstreams, and engaged zkVM vendors including RISC Zero, openVM, and ZisK to build against standardized interfaces[^1][^2].
The timing is deliberate. The Glamsterdam hard fork — scheduled for May or June 2026 — will introduce two critical dependencies for the L1-zkEVM system: Enshrined Proposer-Builder Separation (ePBS) and Block Access Lists enabling parallel transaction processing. Without ePBS, the proving window spans only 1–2 seconds, creating unrealistic constraints for real-time proof generation. ePBS extends this window to 6–9 seconds through block pipelining, making single-slot proving feasible for production deployment[^1][^3].
The call marks the starting gun for what the Ethereum Foundation has described as "one of the most significant architectural updates in Ethereum's history"[^4].
Ethereum's current validation model requires every node on the network to independently re-execute every transaction in every block. This brute-force approach has served the network well since genesis: it provides maximal security guarantees, ensures all nodes maintain identical state, and eliminates trust dependencies between participants.
But the model has a fatal flaw in a scaling context. As the gas limit increases — from 30M to 60M following Fusaka in December 2025, and to a targeted 200M with Glamsterdam — the computational burden on each validator increases proportionally. Every doubling of the gas limit approximately doubles the processing power, storage, and bandwidth required to validate the chain. This creates a direct tension between scaling and decentralization: raising the gas limit to enable more transactions risks pricing out solo stakers and home validators who cannot afford to upgrade their hardware in lockstep with network growth[^5].
The current numbers illustrate the pressure. Post-Fusaka, Ethereum's gas limit sits at 60M — double the previous 30M cap. The result was transformative for users: average gas prices collapsed from ~8 gwei to 0.041 gwei, and average transaction fees dropped from $2.15 to approximately $0.17. Daily L1 transactions surged to a record 2.2 million. But for validators, the increase meant commensurately higher resource requirements. The upcoming 3.3x increase to 200M gas under Glamsterdam would amplify this burden further — potentially pushing home validation beyond the reach of consumer-grade hardware under the current re-execution model[^5][^6].
The L1-zkEVM proposal resolves this fundamental tension by decoupling validation cost from execution complexity.
EIP-8025 introduces an optional framework for zero-knowledge-based block validation. The specification modifies block processing to allow a new class of validator — termed "zkAttesters" — to verify cryptographic proofs rather than execute transactions directly[^1][^2].
The validation pipeline operates through four coordinated stages:
Stage 1: Execution Witness Generation
Execution layer clients generate an ExecutionWitness — a structured data package containing all necessary information for block validation without requiring access to the full chain state. This witness encapsulates the inputs and outputs of each transaction, the relevant state trie branches, and the resulting state transitions.
Stage 2: Guest Program Processing
A standardized guest program processes the ExecutionWitness to validate state transitions. This program is deterministic and implementation-agnostic — it produces identical outputs regardless of which client implementation generated it.
Stage 3: zkVM Proving A zero-knowledge virtual machine (zkVM) executes the guest program and generates a compact cryptographic proof of correct execution. This proof mathematically guarantees that the block's state transitions are valid without revealing the underlying computation.
Stage 4: Proof Verification Consensus layer clients verify the submitted proofs instead of calling execution clients to repeat the full computation. Proof verification is computationally trivial compared to re-execution — taking milliseconds regardless of block complexity.
To preserve client diversity — a core Ethereum security property — EIP-8025 implements a preliminary 3-of-5 threshold. An attester accepts a block's execution as valid once it has verified three of five independent proofs generated by different execution-layer client implementations[^1][^7]. This design prevents any single client implementation from becoming a single point of failure, mirroring the multi-client philosophy that has defined Ethereum's approach to resilience since before the Merge.
The Ethereum Foundation's 2026 L1-zkEVM roadmap is organized across six interdependent workstreams, each targeting a critical component of the system[^1][^2]:
1. Execution Witness and Guest Program Standardization
Defining the format and semantics of the ExecutionWitness to ensure interoperability across client implementations. This workstream establishes the canonical input format that all zkVMs will process.
2. zkVM-Guest API Standardization Creating a standardized interface between the guest program and the zkVM runtime. This abstraction layer allows different zkVM implementations (RISC Zero, openVM, ZisK) to execute the same guest program, enabling vendor competition without protocol fragmentation.
3. Consensus Layer Integration Modifying the beacon chain's attestation and finalization logic to accept cryptographic proofs as valid attestations. This is the most protocol-sensitive workstream, as it directly modifies Ethereum's consensus rules.
4. Prover Infrastructure Designing the distributed infrastructure for proof generation. The design assumes a 1-of-N liveness model: as long as one honest prover is operational, the chain continues to function. This is a deliberately low liveness threshold designed to resist censorship and single-point-of-failure risks[^1].
5. Benchmarking and Metrics Establishing a rigorous framework for measuring proving performance, including mapping gas consumption to proving cycles and proving time. This data is essential for potential gas repricing — adjusting the cost of specific EVM operations based on their proving complexity rather than their execution cost[^2].
6. Security and Formal Verification Formal mathematical verification of the guest program and proof system to ensure cryptographic soundness. Given that the proof system will underpin Ethereum's entire security model, this workstream carries the highest stakes for protocol integrity.
The L1-zkEVM system cannot function in production without the Glamsterdam hard fork's implementation of Enshrined Proposer-Builder Separation (ePBS). The dependency is architectural, not merely scheduling convenience[^3][^8].
Under Ethereum's current block production flow, the entire process — proposal, attestation, and finalization — occurs within a 12-second slot. A validator attesting to a block must verify its execution within approximately 1–2 seconds of receiving it. This window is adequate for re-execution but catastrophically insufficient for proof generation, which currently requires approximately 7 seconds on high-end GPU hardware[^7].
ePBS restructures block production by separating the roles of block proposal and block building into distinct, enshrined protocol functions. The critical innovation for zkEVM purposes is block pipelining: rather than requiring attestation within the same slot as proposal, ePBS enables a proving window of 6–9 seconds — sufficient for current-generation provers to generate and propagate proofs before the attestation deadline[^1][^3].
| Feature | Current State | Glamsterdam Target | |---------|--------------|-------------------| | Gas Limit | 60M | 200M | | Transaction Processing | Sequential | Parallel (Block Access Lists) | | Block Production | Combined Proposer-Builder | Enshrined PBS | | Throughput | ~21 TPS | ~10,000 TPS target | | Proving Window | 1–2s (insufficient) | 6–9s (feasible) |
The parallel execution capability — enabled by Block Access Lists that declare which state each transaction will read or write — is complementary to the zkEVM transition. Parallel processing increases L1 throughput, while zkEVM ensures that the validation of this higher throughput does not centralize the validator set[^8].
The most consequential unresolved challenge in the L1-zkEVM transition is hardware accessibility for proof generation. Current benchmarks indicate that proving a full Ethereum block requires approximately 12 GPUs and approximately 7 seconds of computation[^7][^9].
This hardware profile creates a class structure within the validator ecosystem:
zkAttesters (verifiers): Lightweight participants who verify proofs. Minimal hardware requirements — consumer-grade machines can verify proofs in milliseconds. This is the decentralization win: solo stakers need less hardware, not more.
Provers (generators): Resource-intensive participants who generate the proofs that zkAttesters verify. Current requirements place proving firmly in the domain of professional infrastructure operators with access to GPU clusters.
The centralization concern is direct: if Ethereum transitions from "everyone re-executes" to "few prove, many verify," the network's security model shifts from broadly distributed computation to concentrated proof generation. As CryptoSlate reported: "Today's constraint is 'can you afford to run an execution layer client?' Tomorrow's might be 'can you access GPU clusters or prover networks?'"[^9]
Several design decisions partially address this risk:
The 1-of-N Liveness Model: The system requires only one honest prover to maintain chain operation. This dramatically lowers the failure threshold compared to requiring majority honest execution[^1].
Multi-Client Proof Diversity: The 3-of-5 threshold ensures proofs must come from multiple independent client implementations, preventing any single prover entity from monopolizing attestation[^7].
Hardware Trajectory: GPU costs continue to decline, and proving-specific ASICs are under development by multiple teams. The Ethereum Foundation has stated that "proving should remain viable outside of data centre infrastructure," signaling a commitment to consumer-accessible proving over time[^9].
Competitive zkVM Market: With RISC Zero, openVM, ZisK, and other vendors competing on the standardized interface, proving efficiency is expected to improve through market competition — analogous to how MEV-boost competition improved block building efficiency[^1].
However, these mitigations remain theoretical until benchmarked at scale. The February 11 breakout call's benchmarking and metrics workstream is specifically designed to generate the empirical data needed to assess whether the centralization risk is manageable or structural.
For Ethereum's approximately 1.15 million active validators, the L1-zkEVM transition represents the most significant operational change since the Merge eliminated proof-of-work mining.
Under the current model, home validators must:
Under the zkEVM model, zkAttesters:
This decoupling is transformative. As the gas limit scales from 60M to 200M under Glamsterdam — and potentially higher in subsequent upgrades — the validation burden for zkAttesters remains constant. A home validator running proof verification in 2028, when gas limits may reach 500M or beyond, faces the same computational requirements as one running today. The linear scaling curse is broken.
Ethereum's current staking distribution underscores why this matters. Of the 36.6 million ETH staked (30% of total supply), institutional providers dominate: Binance holds 3.29M ETH (9.1%), ether.fi holds 2.15M ETH (6.0%), Coinbase holds 1.84M ETH (5.1%), Figment holds 1.48M ETH (4.1%), and Kraken holds 1.35M ETH (3.7%)[^10]. The combined share of exchange and institutional staking providers continues to grow, in part because solo staking's hardware requirements create a barrier that institutional operators can absorb more easily. By lowering the floor for participation, the zkEVM transition could slow or reverse this centralization trend.
The L1-zkEVM roadmap's standardized interface design has created an open market for zero-knowledge virtual machine implementations. Three vendors have already engaged with the development process[^1]:
RISC Zero — A venture-backed zkVM built on the RISC-V instruction set architecture. RISC Zero's approach leverages a well-understood hardware ISA, enabling potential future hardware acceleration through RISC-V compatible chips.
openVM — An open-source zkVM implementation emphasizing transparency and community auditability. The open-source model aligns with Ethereum's broader commitment to publicly verifiable infrastructure.
ZisK — A zkVM focused on proving efficiency and throughput optimization. ZisK's architecture prioritizes minimizing the proof generation time — directly targeting the 7-second benchmark that currently constrains the system.
The standardized zkVM-guest API means these implementations compete on performance, not protocol compatibility. This mirrors Ethereum's execution layer client diversity: multiple independent implementations of the same specification, providing resilience through heterogeneity.
This ecosystem could become the largest zero-knowledge application globally. The addressable market encompasses every block ever produced on Ethereum — a continuous, high-throughput stream of proofs required 24/7/365. The economic incentives for prover optimization are substantial, and the competitive dynamics should drive rapid performance improvements.
The L1-zkEVM initiative redefines Ethereum's competitive positioning against alternative Layer 1 networks that have marketed throughput as their primary differentiator.
Solana — Currently processes approximately 4,000 TPS with $9.2 billion in DeFi TVL. Solana's architecture achieves throughput through aggressive hardware requirements (high-end CPUs, 256+ GB RAM), accepting higher centralization in exchange for raw performance. Ethereum's zkEVM path aims to match or exceed this throughput (10,000 TPS target) while preserving a decentralized validator set through proof-based validation[^8].
Alternative zkEVM L2s (zkSync, Starknet, Scroll) — These networks have built their value propositions on bringing ZK proof verification to Ethereum as Layer 2s. If ZK proving becomes a native L1 feature, the differentiation argument for general-purpose zkEVM L2s weakens considerably — reinforcing Vitalik Buterin's recent assertion that the "rollup excuse is fading" and L2s must specialize rather than simply provide throughput.
DeFi TVL Context: Ethereum still commands approximately 68% of all DeFi TVL, which has grown from $123.6 billion in mid-2025 to an estimated $150–176 billion range in early 2026. The L1-zkEVM upgrade aims to ensure this dominance is sustained as throughput demands increase[^11].
The 12-GPU requirement creates a natural oligopoly in proof generation. If this hardware requirement does not decrease substantially before mandatory adoption (targeted 2027), proving could concentrate among a small number of infrastructure providers — creating a new centralization vector that undermines the very decentralization benefits the system is designed to provide.
The entire validation system rests on the soundness of the zero-knowledge proof scheme. A breakthrough in cryptanalysis that compromises the proof system's soundness assumptions would undermine Ethereum's security model at the protocol level. Formal verification (Workstream 6) is designed to mitigate this risk, but no proof system can be proven secure against future mathematical discoveries.
The L1-zkEVM system touches every layer of Ethereum's stack: execution, consensus, networking, and client implementation. The coordination required across six workstreams, multiple client teams, and multiple zkVM vendors is substantial. Delays in any critical-path workstream — particularly ePBS delivery in Glamsterdam — would cascade across the entire timeline.
The benchmarking workstream may reveal that certain EVM operations are dramatically more expensive to prove than to execute. If gas costs are repriced to reflect proving complexity rather than execution cost, existing smart contracts optimized for current gas economics may become prohibitively expensive — creating backward compatibility challenges.
The opt-in phase is targeted for 2026, with mandatory adoption by 2027. This is an aggressive timeline for a system that fundamentally restructures how Ethereum validates blocks. Slippage is likely, and any delay in Glamsterdam's ePBS delivery directly blocks the entire zkEVM production path.
February 11, 2026 marks the formal start of L1-zkEVM development — the first breakout call convened by the Ethereum Foundation to coordinate the most significant validation architecture change since the Merge.
EIP-8025 replaces transaction re-execution with zero-knowledge proof verification, allowing validators to confirm blocks through cryptographic proofs rather than recomputing every transaction. A 3-of-5 multi-client threshold preserves Ethereum's client diversity guarantees.
Solo stakers are the primary beneficiaries. zkAttesters will not need to store execution layer state, sync the full chain, or scale hardware linearly with gas limit increases — breaking the fundamental tension between L1 scaling and validator accessibility.
The Glamsterdam hard fork (May–June 2026) is a critical dependency. Without ePBS extending the proving window to 6–9 seconds, real-time proof generation is infeasible with current technology.
Prover centralization is the system's most significant unresolved risk. Current benchmarks of 12 GPUs per block proof place generation firmly in professional infrastructure territory. Whether hardware improvements and competitive zkVM markets can democratize proving remains an open question.
The opt-in phase begins in 2026 with mandatory adoption targeted for 2027. This aggressive timeline positions Ethereum to deliver native ZK verification ahead of most competing L1 architectures.
The zkVM vendor ecosystem (RISC Zero, openVM, ZisK) is already building against standardized interfaces, creating competitive dynamics that should drive proving efficiency improvements.
The L1-zkEVM initiative represents a philosophical as much as a technical transformation. Since Ethereum's inception, security has been guaranteed through redundancy: every node performs the same computation, and consensus emerges from agreement on the result. This brute-force approach was effective when blocks contained a few dozen transactions and gas limits were measured in single-digit millions. It cannot survive the 200M gas limit era, where every validator would need data-center-class hardware to keep pace with network throughput.
Zero-knowledge proofs offer an escape from this scaling trap by replacing redundant computation with mathematical verification. A single proof, generated once, can convince any number of validators that a block's execution is correct — in milliseconds, on consumer hardware, without access to the full chain state. The economics of verification scale logarithmically, not linearly.
But the transition is not without cost. Proof generation is computationally intensive, and the risk of prover centralization is real. The Ethereum community faces the same fundamental challenge it has navigated throughout its history: can a globally distributed, permissionless network adopt cutting-edge cryptographic infrastructure without concentrating power in the hands of those with the most resources?
The February 11 breakout call is the first step toward answering that question. The six workstreams provide a structured path from concept to production. The Glamsterdam upgrade provides the infrastructure prerequisites. And the zkVM vendor ecosystem provides the competitive pressure needed to drive proving costs down.
If Ethereum executes on this roadmap, it will emerge as the first major blockchain to embed zero-knowledge proof verification directly into its consensus layer — combining the throughput of high-performance L1s with the decentralization guarantees that have made Ethereum the settlement layer of choice for $150+ billion in DeFi value. The re-execution era is ending. The verification era begins today.
[^1]: Ethereum Adopts Zero-Knowledge Proof Validation in 2026 L1-zkEVM Roadmap Shift — Blockonomi [^2]: Ethereum Plans Major Upgrade to Use ZK Proofs for Faster Block Validation — Coinpedia [^3]: Ethereum's Big ZK Reveal Tomorrow: What to Expect — BeInCrypto [^4]: February 11, 2026, Is Pivotal Date for Ethereum: Key Architectural Shift — Bitcoin Ethereum News [^5]: The Great Layer-2 Reckoning — Webthreepedia / Maze2 SA (prior report) [^6]: Ethereum 2026: Glamsterdam and Hegota Forks, L1 Scaling — CoinTelegraph [^7]: Ethereum Wants Home Validators to Verify Proofs but a 12 GPU Reality Raises a New Threat — CryptoSlate [^8]: Ethereum Glamsterdam Upgrade: The Next Frontier in L1 Efficiency and MEV Reform — CryptoAPIs [^9]: Ethereum Wants Home Validators to Verify Proofs but a 12 GPU Reality Raises a New Threat — Bitcoin Ethereum News [^10]: Top 10 Ethereum Staking Statistics and Trends in 2026 — DataWallet [^11]: Decentralized Finance (DeFi) Market Statistics 2026 — CoinLaw [^12]: L1-zkEVM Roadmap 2026: Integrating zkEVM Proofs into Ethereum's Core Protocol — Ethereum Magicians