Written by: imToken
From a perceptual standpoint, 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’s 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.
This roadmap sets out five core objectives: 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 greatest 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, DEXs, to stablecoins, gradually making Ethereum the main clearing network in the crypto economy.
The second phase (2021–2023) was dominated by the narrative of Layer 2.
As Ethereum’s mainnet gas fees soared, ordinary users found transaction costs hard to bear, and rollups began to take center stage for scaling. Ethereum gradually repositioned itself as a settlement layer, aiming to provide 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, EIP-4844, and other developments served this narrative, aiming to make Ethereum cheaper and safer for Layer 2 to operate with trust.
The third phase (2024–2025) focuses on internal competition and reflection within the narrative.
It’s well known that 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 interact with L1. The price performance of ETH also reflects this anxiety.
This has led the community to debate: if L2 is dividing all users and activity, where is the value capture for L1? Until the internal turmoil of Ethereum in 2025 and the series of roadmaps unveiled in 2026, this logic is undergoing profound evolution.
In fact, reviewing the core technological directions since 2025, concepts like Verkle Trees, Stateless Clients, formal verification of EVM, and native ZK support keep recurring. These directions all point to the same goal: making Ethereum’s L1 inherently verifiable. It’s important to note that this isn’t just about enabling L2 proofs to be verified on L1, but about ensuring every state transition on L1 can be compressed and verified via zero-knowledge proofs.
This is precisely the ambition of L1 zkEVM. Unlike L2 zkEVM (such as zkSync, Starknet, Scroll), L1 zkEVM (the “shell zkEVM”) means integrating zero-knowledge proof technology directly into Ethereum’s consensus layer.
It’s not a replication of L2 zkEVM; instead, it transforms Ethereum’s execution layer itself into a ZK-friendly system. 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?
As always, in the traditional model, 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 increasing node burden (see “ZK Roadmap ‘Dawn’: Is Ethereum’s Finality Accelerating?” for extended reading).
However, transforming Ethereum’s L1 into zkEVM is not a single breakthrough; it requires simultaneous progress across eight different directions, each a multi-year engineering effort.
Workstream 1: Formalization of EVM (EVM Formalization)
The prerequisite for all ZK proofs is that the object being proved has a precise mathematical definition. Today’s EVM behavior is defined by client implementations (Geth, Nethermind, etc.), not by a formal, rigorous specification. Different clients may behave inconsistently in edge cases, making it extremely difficult to write ZK circuits for the EVM—after all, you can’t prove a fuzzy system.
Therefore, 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: ZK-Friendly Hash Function Replacement
Ethereum currently heavily relies on Keccak-256 as its hash function. Keccak is highly ZK-unfriendly, with significant computational overhead, greatly increasing proof generation time and cost.
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 impactful 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 dozens of times.
For L1 zkEVM, this means significantly reducing the data needed to prove each block, greatly speeding up proof generation, and making Verkle Trees a critical infrastructure for the feasibility of L1 zkEVM.
Workstream 4: Stateless Clients
Stateless clients refer to nodes that 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. For L1 zkEVM, this has dual significance: it lowers hardware requirements for nodes, aiding decentralization; and it provides clear input boundaries for ZK proofs, simplifying proof generation by focusing only on witness data rather than 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, enabling multiple proof systems to compete and integrate rather than relying on a single solution.
This maintains openness and allows continuous evolution of proof technology. 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 on the execution layer 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 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. If multiple proofs can be recursively aggregated into one proof, verification costs drop dramatically. Progress here will directly determine how low the operational costs of L1 zkEVM can be.
Workstream 8: Developer Toolchains and EVM Compatibility
All underlying technical modifications must remain transparent to Ethereum smart contract developers. Existing hundreds of thousands of contracts must not break due to zkEVM integration, and tooling must be compatible.
This is often underestimated but is the most time-consuming part. Past EVM upgrades required extensive backward compatibility testing and tooling adaptation. The scope of changes for 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 its redefinition of Ethereum as “infrastructure.”
For builders and developers, Strawmap provides directional certainty; for users, these technological upgrades will translate into perceptible experiences: 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 in the short term; full implementation may take until 2028–2029 or later.
But at least it redefines Ethereum’s value proposition. If successful, L1 zkEVM will elevate Ethereum from just an L2 settlement layer to 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 game-changer for Ethereum’s long-term value capture.
It also influences the long-term positioning of L2. When L1 itself gains 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 testament to Ethereum’s unique protocol strength.
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 mapping of this shift in understanding. They all aim toward a common goal: enabling Ethereum’s mainnet to achieve order-of-magnitude performance improvements without sacrificing decentralization. This is not a negation of the L2 path but a complement and enhancement.
In the next three years, this “Ship of Theseus” will undergo seven forks and countless “plank 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.
