The story of Ethereum is being rewritten: when will the next revolution come as L1 zkEVM becomes final?

From a sensory perspective, since 2025, the Ethereum core developer community has been updating at an exceptionally rapid pace.

From the Fusaka upgrade to Glamsterdam, and to long-term plans over the next three years focusing on kEVM, quantum-resistant cryptography, Gas Limit, and other topics, Ethereum has released multiple roadmaps covering three to five years within just a few months.

This pace itself is a signal.

If you carefully read the latest roadmap, you’ll notice a clearer and more aggressive direction emerging: Ethereum is transforming itself into a verifiable computer, and the ultimate goal of this path is L1 zkEVM.

1. The Three Shifts in Ethereum Narrative Focus

On February 26, Ethereum Foundation researcher Justin Drake posted on social media that the Foundation proposed a draft roadmap called Strawmap, outlining the upgrade directions for Ethereum’s L1 protocol in the coming years.

The roadmap sets out five core goals: faster L1 (finality within seconds), a “Gigagas” L1 capable of 10,000 TPS via zkEVM, high-throughput L2 based on Data Availability Sampling (DAS), quantum-resistant cryptography, and native privacy transfer functions; it also plans seven protocol forks by 2029, averaging about once every six months.

It can be said that, over the past decade, Ethereum’s development has always been accompanied by continuous evolution in both narrative and technical roadmap.

The first phase (2015–2020) was about a programmable ledger.

This was Ethereum’s initial core narrative: “Turing-complete smart contracts.” At that time, Ethereum’s biggest advantage was that, compared to Bitcoin, it could do more things—such as DeFi, NFTs, DAOs—all products of this narrative. A large number of decentralized financial protocols began operating on-chain, from lending and DEXs to stablecoins, gradually making Ethereum the main clearing network in the crypto economy.

The second phase (2021–2023) saw the narrative shift to Layer 2.

As Ethereum’s mainnet gas fees soared, ordinary users found transaction costs hard to bear, and rollups became the main scaling solution. Ethereum gradually repositioned itself as a settlement layer, providing a secure foundation for Layer 2 solutions.

In simple terms, most computation was migrated to Layer 2 via rollups, with Layer 1 responsible only for data availability and final settlement. The Merge and EIP-4844 served this narrative, aiming to make Layer 2 cheaper and more secure by leveraging Ethereum’s trust assumptions.

The third phase (2024–2025) focuses on narrative introspection and refinement.

As is well known, the prosperity of Layer 2 has brought an unexpected problem: Ethereum L1 itself has become less important. Users are increasingly operating on Arbitrum, Base, Optimism, and rarely directly on L1. The price performance of ETH also reflects this anxiety.

This has led the community to debate: if Layer 2 is dividing all users and activity, where is the value capture for Layer 1? Until the internal turbulence within Ethereum in 2025 and the series of roadmaps unveiled in 2026, this logic is undergoing profound evolution.

In fact, reviewing the core technical directions since 2025, Verkle Trees, Stateless Clients, formal verification of EVM, native ZK support, and other recurring themes all point to the same goal: making Ethereum L1 itself verifiable. It’s important to note that this isn’t just about enabling ZK proofs of Layer 2 to be verified on L1, but about ensuring every step of L1’s state transition can be compressed and verified via zero-knowledge proofs.

This is precisely the ambition of L1 zkEVM. Unlike Layer 2 zkEVMs (like zkSync, Starknet, Scroll), L1 zkEVM (on-chain zkEVM) means integrating zero-knowledge proof technology directly into Ethereum’s consensus layer.

It’s not a replication of L2 zkEVMs; rather, it involves transforming Ethereum’s execution layer itself into a ZK-friendly system. So, if L2 zkEVM is building a ZK world on Ethereum, then L1 zkEVM is turning Ethereum itself into that ZK world.

Once this goal is achieved, Ethereum’s narrative will shift from a Layer 2 settlement layer to a “root of verifiable computation.”

This will be a qualitative leap, not just a quantitative change like in previous years.

2. What Exactly Is L1 zkEVM?

It’s a familiar topic: in traditional models, validators need to “re-execute” each transaction to verify a block. Under zkEVM, validators only need to verify a ZK proof, allowing Ethereum to increase Gas Limit to 100 million or even higher without adding node burden (see also “ZK Roadmap ‘Dawn’: Is Ethereum’s Finality Accelerating?”).

However, transforming Ethereum L1 into zkEVM is not a single breakthrough; it requires simultaneous progress across eight directions, each a multi-year engineering effort.

Workstream 1: Formalization of EVM

All ZK proofs rely on having a precise mathematical definition of what’s being proved. Today’s EVM behavior is defined by client implementations (Geth, Nethermind, etc.), not by a formal specification. Different clients may behave inconsistently in edge cases, making it extremely difficult to write ZK circuits for EVM, since you cannot prove a system with fuzzy definitions.

The goal of this workstream is to formalize every instruction and state transition rule of the EVM into a machine-verifiable formal specification. This is the foundation of the entire L1 zkEVM project. Without it, everything else is built on sand.

Workstream 2: Replacing Hash Functions with ZK-Friendly Alternatives

Ethereum currently heavily relies on Keccak-256. Keccak is very ZK-unfriendly, with high computational costs that significantly increase proof generation time and costs.

The core task here is to gradually replace Keccak with ZK-friendly hash functions (like Poseidon, Blake series), especially in state trees and Merkle proof paths. This is a highly interconnected change, as hash functions permeate every corner of the Ethereum protocol.

Workstream 3: Replacing Merkle Patricia Tree with Verkle Tree

One of the most anticipated changes in the 2025–2027 roadmap. Ethereum currently uses Merkle Patricia Trees (MPT) for global state storage. Verkle Trees, using vector commitments, can reduce witness sizes by orders of magnitude.

For L1 zkEVM, this means significantly reducing the data volume needed for proofs per block, greatly speeding up proof generation, and making Verkle Trees a critical infrastructure for L1 zkEVM feasibility.

Workstream 4: Stateless Clients

Stateless clients mean nodes can verify blocks without storing the full Ethereum state database, relying only on witness data attached to blocks.

This workstream is deeply tied to Verkle Trees, as small witnesses make stateless clients feasible. It also reduces hardware requirements for nodes, aiding decentralization, and provides clear input boundaries for ZK proofs—proof generators only need to handle witness data, not the entire state.

Workstream 5: Standardization and Integration of ZK Proof Systems

L1 zkEVM requires a mature ZK proof system to generate proofs for block execution. Currently, the ZK field is highly fragmented, with no universally accepted optimal solution. The goal here is to define a standardized proof interface at the Ethereum protocol layer, allowing multiple proof systems to compete for integration rather than relying on a single one.

This maintains openness and leaves room for continuous evolution of proof systems. The Ethereum Foundation’s PSE (Privacy and Scaling Explorations) team has already accumulated significant groundwork in this area.

Workstream 6: Decoupling Execution and Consensus Layers (Engine API evolution)

Ethereum’s execution layer (EL) and consensus layer (CL) currently communicate via the Engine API. Under L1 zkEVM, each state transition must generate a ZK proof, which could take longer than a block time.

The key challenge is to decouple execution and proof generation without disrupting consensus—allowing execution to proceed quickly, with proof generation lagging asynchronously, and validators finalizing blocks at appropriate times. This involves deep modifications to the finality model.

Workstream 7: Recursive Proofs and Proof Aggregation

Generating a ZK proof for a single block is costly, but if multiple proofs can be recursively aggregated into one, verification costs drop dramatically. Progress here will directly determine how low the operational costs of L1 zkEVM can go.

Workstream 8: Developer Toolchains and EVM Compatibility

All underlying technical modifications must be transparent to Ethereum smart contract developers. Existing contracts must remain functional, and developer tooling should not need a complete overhaul.

This is often underestimated but is the most time-consuming part. Past EVM upgrades required extensive backward compatibility testing and tooling adaptation. The scale of changes in L1 zkEVM will be much larger, making tooling and compatibility work a significant challenge.

3. Why Is Now the Right Time to Understand This?

The release of Strawmap coincides with market doubts about ETH’s price performance. From this perspective, the most valuable aspect of this roadmap is redefining Ethereum as “infrastructure.”

For builders and developers, Strawmap provides directional certainty; for users, these technical upgrades will translate into perceptible improvements: transactions confirmed within seconds, seamless asset transfers between L1 and L2, privacy features built-in rather than add-ons.

Objectively, L1 zkEVM will not be a product ready for immediate deployment; full implementation may take until 2028–2029 or later.

But it at least redefines Ethereum’s value proposition. If L1 zkEVM succeeds, Ethereum will no longer just be a Layer 2 settlement layer but the “root of verifiable trust” for the entire Web3 ecosystem. Any on-chain state could ultimately be mathematically traced back to Ethereum’s ZK proof chain, which is a decisive long-term value capture for Ethereum.

It also influences the long-term positioning of Layer 2. When L1 itself has ZK capabilities, L2’s role shifts—from “security scaling solutions” to “dedicated execution environments.” Which L2s can find their place in this new landscape will be a key area of ecosystem evolution in the coming years.

Most importantly, I see this as an excellent window into Ethereum developer culture—capable of simultaneously advancing eight interdependent technical workstreams, each a multi-year engineering effort, while maintaining decentralized coordination. This is a unique strength of Ethereum as a protocol.

Understanding this helps more accurately assess Ethereum’s true position amid various competing narratives.

Overall, from the focus on rollups in 2020 to Strawmap in 2026, Ethereum’s narrative evolution reflects a clear trajectory: scaling cannot rely solely on Layer 2; L1 and L2 must evolve together.

Thus, the eight workstreams of L1 zkEVM are a technical reflection of this shift in understanding. They all aim toward a common goal: enabling Ethereum’s mainnet to achieve orders-of-magnitude performance improvements without sacrificing decentralization. This is not a rejection of the Layer 2 path but an enhancement and complement to it.

In the next three years, this “Ship of Theseus” will undergo seven forks and countless “planks” replacements. When it reaches its next station in 2029, we may see a truly “global settlement layer”—fast, secure, private, and as open as ever.

Let’s wait and see.