Ethereum's Narrative Shift: L1 zkEVM as the Next Evolution

From a purely experiential standpoint, the update frequency of the Ethereum core developer community has been unusually high since 2025.

From the Fusaka upgrade to Glamsterdam, and through long-term plans over the next three years centered on kEVM, post-quantum cryptography, Gas Limit, and other topics, Ethereum has released a series of roadmap documents covering three to five years within just a few months.

This rhythm itself is a signal.

If you carefully read the latest roadmap, a clearer and more ambitious direction is emerging: Ethereum is transforming itself into a verifiable computer, and the end of this path is L1 zkEVM.

On February 26, Ethereum Foundation researcher Justin Drake posted on social media that the Ethereum Foundation has proposed a roadmap draft called Strawmap, outlining the future upgrade direction of the Ethereum L1 protocol over the coming years.

The roadmap outlines five core goals: a faster L1 with second-level finality, a "Gigagas" L1 achieving 10,000 TPS via zkEVM, a high-throughput L2 based on Data Availability Sampling (DAS), quantum-resistant cryptography, and native privacy-preserving transfers; additionally, the roadmap plans seven protocol forks by 2029, averaging approximately one every six months.

Over the past decade, Ethereum's development has consistently been accompanied by evolving narratives and technological pathways.

Phase one (2015–2020) was the programmable ledger.

This was the original core narrative of Ethereum: “Turing-complete smart contracts.” At the time, Ethereum’s greatest advantage was its ability to do more than Bitcoin—DeFi, NFTs, and DAOs were all products of this narrative, as countless decentralized finance protocols began operating on-chain, from lending and DEXs to stablecoins, gradually establishing Ethereum as the primary settlement network for the crypto economy.

The second phase (2021–2023) was dominated by the L2 narrative.

As Ethereum mainnet gas fees have risen sharply, ordinary users find it difficult to afford transaction costs, making Rollups the primary solution for scaling. Ethereum is gradually repositioning itself as a settlement layer, aiming to provide a secure foundational base for L2s.

In simple terms, most execution-layer computations are moved to L2 via Rollups, while L1 handles only data availability and final settlement—both The Merge and EIP-4844 support this narrative, aiming to make L2s use Ethereum’s trust more cheaply and securely.

The third phase (2024–2025) focuses on narrative overcompetition and reflection.

It is well known that the boom in L2s has led to an unintended issue: Ethereum L1 itself has become less relevant, as users increasingly operate on Arbitrum, Base, and Optimism, rarely interacting directly with L1—a trend reflected in Ethereum ETH’s price performance, which has underscored this concern.

This has prompted the community to debate where L1s capture value if L2s absorb all users and activity. This logic is undergoing profound evolution through Ethereum’s internal upheavals until 2025 and the latest roadmap rollouts in 2026.

In fact, reviewing the core technical directions since 2025, Verkle Trees, Stateless Clients, EVM formal verification, and native ZK support repeatedly emerge—all pointing to the same goal: enabling Ethereum L1 itself to be verifiable. Importantly, this is not just about allowing L2 proofs to be verified on L1, but about making every state transition on L1 compressible and verifiable via zero-knowledge proofs.

This is precisely the ambition of L1 zkEVM. Unlike L2 zkEVMs, L1 zkEVM (embedded zkEVM) means integrating zero-knowledge proof technology directly into Ethereum’s consensus layer.

It is not a replica of L2 zkEVMs like zkSync, Starknet, or Scroll; instead, it transforms Ethereum’s execution layer itself into a ZK-friendly system. So if L2 zkEVMs build a ZK world on top of Ethereum, L1 zkEVM turns Ethereum itself into that ZK world.

Once this goal is achieved, Ethereum’s narrative will evolve from an L2 settlement layer to the “root of trust for verifiable computation.”

This will be a qualitative change, not just another quantitative shift like those we've seen over the past few years.

As always, under traditional models, validators must "re-execute" every transaction to verify a block, whereas in zkEVM mode, validators only need to verify a single ZK Proof—enabling Ethereum to increase the Gas Limit to 100 million or higher without increasing the burden on nodes (see further reading: The "Dawn of the ZK Path": Is Ethereum’s Ultimate Roadmap Accelerating Fully?).

However, transforming Ethereum L1 into a zkEVM is not a single-point breakthrough—it requires simultaneous progress across eight directions, each of which is a multi-year engineering endeavor.

Workstream One: EVM Formalization

The foundation of all ZK proofs is that the object being proven has a precise mathematical definition; however, today’s EVM is defined by client implementations (such as Geth and Nethermind), not by a strict formal specification, and different clients may behave inconsistently in edge cases, making it extremely difficult to write ZK circuits for the EVM—after all, you cannot write a proof for a system with an ambiguous definition.

Therefore, the goal of this line of work is to express every EVM instruction and every state transition rule in a machine-verifiable formal specification. This forms the foundation of the entire L1 zkEVM engineering effort. Without it, everything that follows is built on sand.

Workstream 2: Replacement with ZK-friendly hash functions

Ethereum currently uses Keccak-256 extensively as its hash function. Keccak is highly unfriendly to ZK circuits, requiring substantial computational overhead that significantly increases the time and cost of proof generation.

The core task of this line of work is to gradually replace Ethereum’s internal use of Keccak with ZK-friendly hash functions such as Poseidon and the Blake series, particularly in state trees and Merkle proof paths—a change that has far-reaching implications, as hash functions permeate every corner of the Ethereum protocol.

Workstream Three: Replace Merkle Patricia Tree with Verkle Tree

This is one of the most anticipated changes in the 2025–2027 roadmap. Ethereum currently uses the Merkle Patricia Tree (MPT) to store global state; Verkle Trees replace hash chains with vector commitments, reducing witness size by tens of times.

For L1 zkEVM, this means a significant reduction in the amount of data required to prove each block, a substantial increase in proof generation speed, and underscores that the introduction of Verkle Trees is a critical infrastructure prerequisite for the feasibility of L1 zkEVM.

Workstream Four: Stateless Clients

A stateless client is a node that can verify blocks without locally storing the full Ethereum state database; it only needs the witness data included with the block to complete verification.

This workstream is deeply tied to the Verkle Tree, as stateless clients are only practically feasible when witnesses are sufficiently small. Thus, the significance of stateless clients for L1 zkEVM is twofold: on one hand, it significantly lowers the hardware requirements for running nodes, promoting decentralization; on the other hand, it provides a clear input boundary for ZK proofs, allowing provers to process only the data included in the witness rather than the entire world state.

Workstream Five: Standardization and Integration of ZK Proof Systems

L1 zkEVM requires a mature ZK proof system to generate proofs for block execution, but the current technological landscape in the ZK field is highly fragmented, with no universally accepted optimal solution. This initiative aims to define a standardized proof interface at the Ethereum protocol layer, enabling different proof systems to integrate through competition rather than favoring a single provider.

This maintains the openness of the technology while leaving room for the ongoing evolution of the system, with the Ethereum Foundation’s PSE (Privacy and Scaling Explorations) team having made significant prior contributions in this direction.

Workstream Six: Decoupling the Execution Layer and Consensus Layer (Engine API Evolution)

Currently, Ethereum's Execution Layer (EL) and Consensus Layer (CL) communicate via the Engine API. Under the L1 zkEVM architecture, each state transition in the Execution Layer requires generating a ZK proof, and the time required to generate this proof may far exceed the block production interval.

The core issue this workstream needs to address is how to decouple execution from proof generation without compromising the consensus mechanism—execution can be completed quickly, while proofs can be generated asynchronously and later finalized by verifiers at the appropriate time. This requires a fundamental redesign of the block finality model.

Work Line 7: Recursive Proofs and Proof Aggregation

Generating a ZK proof for a single block is expensive, but if proofs from multiple blocks can be recursively aggregated into a single proof, the verification cost will be significantly amortized. Progress on this line of work will directly determine how low the operational cost of an L1 zkEVM can be.

Work Line 8: Developer Toolchain and EVM Compatibility Assurance

All underlying technical upgrades must remain transparent to smart contract developers on Ethereum; existing hundreds of thousands of contracts must not become invalid due to the introduction of zkEVM, and developers' toolchains must not be forced to be rewritten.

This line of work is the most underestimated, yet often the most time-consuming—every historical EVM upgrade required extensive backward compatibility testing and toolchain adaptations; the changes to L1 zkEVM are far greater than any previous upgrade, and the workload for toolchains and compatibility will increase by an order of magnitude.

The release of Strawmap coincides with market skepticism regarding ETH's price performance; from this perspective, the most important value of this roadmap lies in redefining Ethereum as "infrastructure."

For builders, Strawmap provides clarity of direction; for users, these technological upgrades will ultimately translate into tangible experiences: transactions finalized within seconds, assets flowing seamlessly between L1 and L2, and privacy protection built in as a core feature rather than an add-on.

Of course, objectively speaking, a Layer 1 zkEVM will not be a product that arrives anytime soon; its full implementation may not occur until 2028–2029 or even later.

But at the very least, it redefines Ethereum’s value proposition: if L1 zkEVM succeeds, Ethereum will no longer be merely a settlement layer for L2s, but the verifiable root of trust for the entire Web3 ecosystem, enabling the state of any chain to be mathematically traced back to Ethereum’s ZK proof chain—a decisive advantage for Ethereum’s long-term value capture.

Second, it also impacts the long-term positioning of L2s, as when L1s themselves possess ZK capabilities, the role of L2s will shift—from being a "security-focused scaling solution" to becoming a "dedicated execution environment." Which L2s can find their place in this new paradigm will be one of the most compelling ecosystem developments to watch in the coming years.

Most importantly, the author believes it also serves as an excellent window into Ethereum’s developer culture—the ability to simultaneously advance eight interdependent technical workstreams, each a multi-year engineering endeavor, while maintaining a decentralized coordination model, is itself a unique capability of Ethereum as a protocol.

Understanding this helps more accurately assess Ethereum's true position among various competing narratives.

Overall, from the 2020 "Rollup-centric" narrative to the 2026 Strawmap, Ethereum's evolving story reflects a clear trajectory: scaling cannot rely solely on L2s—L1 and L2 must evolve together.

Thus, the eight workstreams of L1 zkEVM are the technical manifestation of this paradigm shift, collectively aiming to achieve an order-of-magnitude performance improvement for Ethereum mainnet without compromising decentralization—not as a rejection of the L2 path, but as its refinement and complement.

Over the next three years, this "Ship of Theseus" will undergo seven forks and replace countless "planks"; by 2029, when it reaches its next port, we may witness a truly global settlement layer—fast, secure, private, and as open as ever.

Let’s wait and see together.