How L1 zkEVM Rewrites the Ethereum Specification: Evolution from Rollup to Verifiable Computation

Since 2025, the Ethereum developer community has demonstrated unprecedented intensity in updates and rethinking its role within the crypto ecosystem. Amid discussions about ETH’s price dynamics, the Ethereum Foundation unveiled an ambitious roadmap (Strawmap) outlining the protocol’s technical evolution over the coming years. This specification is not just about technical enhancements — it represents a qualitative transformation of Ethereum itself: from a rollup data layer to a verifiable trust foundation for the entire decentralized economy.

This transformation means that every state execution step on L1 can be compressed and verified using zero-knowledge proofs. It’s not about copying L2 zkEVM projects (zkSync, Starknet, Scroll), but about a fundamentally different goal: transforming Ethereum’s execution layer into a ZK-compatible system. If L2 zkEVM is building a ZK world on top of Ethereum, then L1 zkEVM is about transforming Ethereum itself into that level.

Three directions of transformation: from programmable registry to verifiable infrastructure

Ethereum’s development over the past decade has been accompanied by a gradual evolution of its conceptual foundation and technical priorities. The first period (2015–2020) focused on Ethereum as a programmable ledger capable of more than Bitcoin. Smart contracts, DeFi, NFTs, DAOs — all grew from this core story of universal blockchain computation.

The second period (2021–2023) shifted focus to scaling via Layer 2 solutions. As gas prices rose, ordinary users couldn’t afford L1 transactions, and rollup solutions began to dominate. Ethereum gradually redefined itself as a data and finality layer, providing a secure base for L2. The Merge and EIP-4844 served precisely this purpose.

The third period (2024–2025) signals deeper reflection. The paradox was that the rise of L2 led to a devaluation of L1: users migrated to Arbitrum, Base, Optimism, and interacted rarely directly with L1. This raised a critical question in the community: where does L1’s value come from if L2 is taking all users?

Analyzing key technological directions of the Strawmap provides an answer. Verkle Trees, Stateless Clients, formal verification of EVM, native ZK support — all these vectors point in one direction: endowing Ethereum L1 with its own verifiability. This is a qualitative change that will culminate in L1 zkEVM.

Specification as the foundation: why 8 workstreams are changing Ethereum architecture

The interconnectedness of the technical changes in Strawmap is best understood by viewing the 8 workstreams as a unified architectural system, where each component supports the others.

Workstream 1: Formal specification of the EVM as a foundation

A specification is not an abstract concept — it’s a mathematical definition of each instruction and state transformation rule. Currently, EVM behavior is defined by client implementations (Geth, Nethermind), not by a formal spec. This means behavior can differ in edge cases. For zero-knowledge circuits, working with an imprecise system is impossible. Therefore, the first and most crucial workstream is to formalize every aspect of the EVM so it can be mathematically verified.

Workstream 2: Replacing hash functions with ZK-compatible ones

Ethereum actively uses Keccak-256, which is costly for ZK circuits. The main task is to gradually replace Keccak with ZK-friendly functions (Poseidon, Blake series) in core components, especially in state trees and Merkle proofs. This systemic change is necessary because hash functions permeate the entire protocol.

Workstream 3: Verkle Trees instead of Merkle Patricia Trees

Verkle Trees replace hash chains with vector commitments, reducing proof sizes by an order of magnitude. For L1 zkEVM, this means fewer data to prove per block, faster proof generation, and Verkle Trees becoming a key prerequisite for implementing L1 zkEVM at all.

Workstream 4: Stateless clients

Stateless clients can verify blocks without storing the full state database — only witness data is needed. This is tightly linked to Verkle Trees, as practical implementation depends on proof size. For L1 zkEVM, this has a dual effect: reducing hardware requirements for nodes and providing clear input data bounds for proofs.

Workstream 5: Standardization of ZK proofs

L1 zkEVM requires a mature proof generation ecosystem, but the ZK field is highly fragmented. The goal is to define a standardized protocol-level interface, enabling different systems to compete. The PSE (Privacy and Scaling Explorations) team has extensive experience here.

Workstream 6: Decoupling execution and consensus layers

Currently, execution (EL) and consensus (CL) interact via the Engine API. In L1 zkEVM, each state change requires generating a ZK proof, which could exceed the interval between blocks. It’s necessary to decouple execution from proof generation without breaking consensus — execution remains fast, proofs are generated asynchronously.

Workstream 7: Recursive and aggregated proofs

Generating a proof for a single block is costly, but recursive aggregation of multiple blocks into one proof can significantly reduce verification costs. Progress here will directly determine the cost of verifying L1 zkEVM.

Workstream 8: Developer tools and EVM compatibility

All lower-level upgrades must be transparent to smart contract developers: tens of thousands of contracts should not become unusable. This workstream is often underestimated but is the most time-consuming. Every EVM upgrade has required extensive backward compatibility testing. The changes for L1 zkEVM surpass previous ones, and tooling efforts will multiply.

Why now: rethinking Ethereum as a verifiable infrastructure

The release of Strawmap coincides with a period of doubt about ETH’s price dynamics, but its true value lies in rethinking Ethereum as a long-term infrastructure.

For developers, Strawmap offers clarity and confidence in investment. For users, these improvements translate into a tangible experience: transactions confirmed in seconds, assets seamlessly moving between L1 and L2, privacy built-in rather than added later.

Objectively, L1 zkEVM will not appear overnight — full implementation is expected around 2028–2029 or later. However, it fundamentally redefines Ethereum’s value proposition. If successful, Ethereum will cease to be just a rollup data layer and become a verifiable trust foundation for all of Web3, enabling any state chain to mathematically trace back to Ethereum’s ZK proofs.

This also impacts the long-term positioning of the L2 ecosystem. When L1 has its own ZK capabilities, the role of L2 will evolve — from a “scaling solution” to a “specialized execution environment.” Which L2s will find their place in this new architecture will be the most exciting evolutionary process in the coming years.

Most importantly, L1 zkEVM demonstrates Ethereum’s unique ability: to advance eight interdependent technical workstreams simultaneously, each a multi-year project, while maintaining a decentralized way to coordinate. This is true engineering ambition.

Evolution through specification: from rollup-oriented to verifiable computations

Ethereum’s narrative evolution — from the “rollup-centric” model of 2021 to Strawmap 2026 — reflects a clear trajectory: scaling cannot rely solely on L2; L1 and L2 must develop together and synergistically.

The eight L1 zkEVM workstreams are a technical translation of this shift in mindset. Each aims to provide exponential increases in mainnet performance without sacrificing decentralization. This is not a rejection of L2 pathways but an enhancement and organic complement.

Over the next three years, the ecosystem will undergo seven protocol branches, replacing many components of its architecture. By 2029, we may see a true “global verifiable layer of computation” — fast, secure, private, and open to all. Specification is not just a mechanism — it’s a promise that Ethereum will remain a foundational infrastructure for a decentralized future.