Even at a glance, the Ethereum core developer community has been moving at an unusually fast pace since 2025.
From the Fusaka upgrade and Glamsterdam to long-term planning around kEVM, post-quantum cryptography, and the gas limit, Ethereum has published multiple roadmap documents within just a few months, each looking three to five years ahead.
This cadence itself serves as a critical market signal.
A close read of the latest roadmaps reveals a clearer—and more ambitious—direction: Ethereum is turning itself into a verifiable computer, and L1 zkEVM is where that path leads.
1. Three Major Shifts in Ethereum’s Narrative
On February 26, Ethereum Foundation researcher Justin Drake said in a social media post that the Foundation had proposed a draft roadmap called Strawmap, outlining the direction of Ethereum L1 protocol upgrades over the next few years.
The roadmap sets out five core goals: a faster L1 with second-level finality, a zkEVM-powered “Gigagas” L1 capable of 10,000 TPS, high-throughput L2s based on data availability sampling (DAS), post-quantum cryptography, and native private transfers. It also envisions seven protocol forks by 2029, or roughly one every six months.
Over the past decade, Ethereum’s development has gone hand in hand with constant shifts in both narrative and technical direction.
The first phase (2015–2020) was the era of the programmable ledger.
This was Ethereum’s original narrative core: “Turing-complete smart contracts.” Its biggest advantage over Bitcoin at the time was simple—it could do more. DeFi, NFTs, and DAOs all emerged from this narrative. As more financial protocols moved on-chain, from lending and DEXs to stablecoins, Ethereum gradually became the main settlement layer of the crypto economy.
The second phase (2021–2023) was when the L2 narrative took over.
As gas fees on Ethereum mainnet surged and transaction costs became too high for ordinary users, Rollups moved to the center of the scaling narrative. Ethereum also began to reposition itself as a settlement layer—the security foundation for L2s.
Put simply, most execution was pushed to L2s through Rollups, while L1 focused on data availability and final settlement. During this period, both The Merge and EIP-4844 served that narrative, aiming to make Ethereum’s security cheaper and safer for L2s to use.
The third phase (2024–2025) focused on the narrative’s internal contradictions—and the reflection that followed.
But the rise of L2s also created an unexpected problem: Ethereum L1 itself started to matter less. Users increasingly spent their time on Arbitrum, Base, and Optimism, with little direct interaction with L1, and ETH’s price performance seemed to reflect that anxiety.
That led to a broader debate in the community: if L2s absorb all the users and activity, where does L1 capture value? But after Ethereum’s internal turbulence in 2025 and the wave of new roadmaps rolled out in 2026, that logic is now starting to change in a profound way.
A review of Ethereum’s core technical directions since 2025 shows the same themes appearing again and again: Verkle Trees, stateless clients, formal EVM verification, and native ZK support. All of them point to the same goal—making Ethereum L1 itself verifiable.
And this is not just about verifying L2 proofs on L1. The goal is to make every state transition on L1 provable and verifiable through zero-knowledge proofs.
That is the ambition behind L1 zkEVM. Unlike L2 zkEVMs, L1 zkEVM—also known as enshrined zkEVM—means integrating zero-knowledge proofs directly into Ethereum’s protocol architecture.
It is not a replica of L2 zkEVMs such as zkSync, Starknet, or Scroll. Instead, it turns Ethereum’s execution layer itself into a ZK-friendly system. If L2 zkEVM builds a ZK world on top of Ethereum, then L1 zkEVM turns Ethereum itself into that world.
If that goal is achieved, Ethereum’s narrative will evolve from an L2 settlement layer into the root of trust for verifiable computation.
That would be a qualitative leap, not just another incremental improvement.
2. What Is a True L1 zkEVM?
As a foundational premise: in the traditional model, validators must re-execute every transaction to verify a block. In a zkEVM model, by contrast, they only need to verify a ZK proof. That would allow Ethereum to raise its gas limit to 100 million or even higher without increasing the burden on nodes.(Further reading: “ZK Dawn: Is Ethereum’s Endgame Accelerating?”)
But turning Ethereum L1 into a zkEVM is not a matter of a single breakthrough. It requires parallel progress across eight workstreams, each of them a multi-year engineering effort.
Workstream 1: EVM Formalization
All ZK proofs depend on one prerequisite: the thing being proved must have a precise mathematical definition. Today, however, the EVM is defined in practice by client implementations such as Geth and Nethermind, not by a strict formal specification. In edge cases, different clients may behave differently. That makes it extremely difficult to build ZK circuits for the EVM, because you cannot prove a system whose definition is still ambiguous.
The goal of this workstream is to turn every EVM opcode and every state transition rule into a machine-verifiable formal specification. This is the foundation of the entire L1 zkEVM effort. Without it, everything else would be built on sand.
Workstream 2: Replacing Hash Functions with ZK-Friendly Alternatives
Ethereum still relies heavily on Keccak-256. But Keccak is not ZK-friendly: it is computationally expensive and significantly increases both proof generation time and cost.
The core task of this workstream is to gradually replace Ethereum’s internal use of Keccak with ZK-friendly hash functions such as Poseidon or the BLAKE family, especially in the state tree and Merkle proof paths. This is a system-wide change, because hash functions are embedded throughout the Ethereum protocol.
Workstream 3: Replacing the Merkle Patricia Tree with the Verkle Tree
This is one of the most closely watched changes in the 2025–2027 roadmap. Ethereum currently uses the Merkle Patricia Tree (MPT) to store global state. By replacing hash-based links with vector commitments, the Verkle Tree can shrink witness sizes by dozens of times.
For L1 zkEVM, that means far less data is needed to prove each block, and proof generation can become much faster. In other words, Verkle Trees are a key infrastructure prerequisite for making L1 zkEVM feasible.
Workstream 4: Stateless Clients
A stateless client is a node that can verify blocks without storing Ethereum’s full state database locally. Instead, it only needs the block itself and its accompanying state witnesses.
This workstream is tightly linked to Verkle Trees, because stateless clients are only practical if witness data is small enough. For L1 zkEVM, they matter for two reasons: they lower the hardware requirements for running a node, which helps decentralization, and they give ZK proofs a clear input boundary, so provers only need to process the data in the witness rather than the entire global state.
Workstream 5: Standardizing and Integrating ZK Proving Systems
L1 zkEVM needs a mature ZK proving system to generate proofs for block execution. But today’s ZK landscape is still highly fragmented, with no widely accepted best solution.
The goal of this workstream is to define a standardized proof interface at the protocol layer, so different proving systems can compete to plug in, rather than having a single one hard-coded into the protocol.
This keeps the design open while leaving room for proving systems to keep evolving. The Ethereum Foundation’s PSE (Privacy and Scaling Explorations) team has already done substantial early work in this area.
Workstream 6: Decoupling the Execution Layer from the Consensus Layer (Engine API Evolution)
Today, Ethereum’s execution layer (EL) and consensus layer (CL) communicate through the Engine API. In an L1 zkEVM architecture, every state transition in the execution layer would need a ZK proof, and generating that proof could take much longer than a single block interval.
The core challenge here is how to decouple execution from proof generation without breaking consensus: execution may complete quickly, while proofs are generated asynchronously and finalized later by validators. That would require a deep redesign of Ethereum’s finality model.
Workstream 7: Recursive Proofs and Proof Aggregation
Generating a ZK proof for a single block is expensive. But if proofs for multiple blocks can be recursively aggregated into a single proof, verification costs can be spread much more efficiently.
Progress in this workstream will directly determine how cheaply L1 zkEVM can operate.
Workstream 8: Developer Tooling and EVM Compatibility Guarantees
All of these deep technical changes must ultimately remain transparent to smart contract developers on Ethereum. Hundreds of thousands of existing contracts cannot break because zkEVM is introduced, and developers cannot be forced to rewrite their tooling stack.
This is one of the most underestimated workstreams, but it is often the most time-consuming. Every past EVM upgrade has required extensive backward-compatibility testing and tooling updates. The scope of change implied by L1 zkEVM is far greater than any previous upgrade, so the workload around tooling and compatibility will grow by an order of magnitude as well.
3. Why Is Now the Right Time to Understand This?
Strawmap arrived at a time when the market was still uneasy about ETH’s price performance. From that perspective, its biggest value is that it redefines Ethereum as infrastructure once again.
For builders, especially developers, Strawmap provides greater clarity on direction. For users, these upgrades should eventually translate into tangible improvements: transactions reaching finality within seconds, assets moving seamlessly between L1 and L2, and privacy becoming a built-in feature rather than an optional add-on.
Of course, L1 zkEVM is not a near-term product. Its full implementation may not arrive until 2028–2029, or even later.
At the very least, it redefines Ethereum’s value proposition. If L1 zkEVM succeeds, Ethereum will no longer be just a settlement layer for L2s. It will become the verifiable root of trust for the broader Web3 world, allowing the state of any chain to be traced back, mathematically, to Ethereum’s chain of ZK proofs. That would be decisive for Ethereum’s long-term value capture.
It also reshapes the long-term role of L2s. Once L1 itself has native ZK capabilities, L2s may shift from “secure scaling solutions” to specialized execution environments. Which L2s can find their place in that new landscape will be one of the most important ecosystem developments to watch in the years ahead.
Most importantly, this is also an excellent lens through which to observe Ethereum’s developer culture. Advancing eight interdependent technical workstreams at once—each a multi-year effort—while maintaining decentralized coordination is itself one of Ethereum’s unique strengths as a protocol.
Understanding this helps us assess Ethereum’s real position more accurately amid competing narratives.
Overall, from the “Rollup-centric” thesis of 2020 to Strawmap in 2026, Ethereum’s narrative has followed a clear trajectory: scaling cannot rely on L2 alone. L1 and L2 must evolve together.
These eight L1 zkEVM workstreams are the technical expression of that shift in thinking. Together, they point to a single goal: giving Ethereum mainnet order-of-magnitude performance gains without sacrificing decentralization. This represents a convergence rather than a divergence of the L1 and L2 roadmaps.
Over the next three years, this “Ship of Theseus” will go through seven forks and replace countless planks along the way. By the time it reaches its next stop in 2029, we may see a truly global settlement layer—fast, secure, private, and as open as ever.
It is worth watching closely.