Ethereum's narrative is being rewritten: When will the next revolution arrive once L1 zkEVM becomes the endgame?

Written by: imToken

From a purely perceptual perspective, since 2025, the Ethereum core developer community has been updating at an unusually high frequency.

From the Fusaka upgrade to Glamsterdam, and then to the long-term plan for the next three years focusing on issues such as kEVM, quantum-resistant cryptography, and gas limits, Ethereum has released a number of roadmap documents covering three to five years in just a few months.

This rhythm itself is a signal.

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

I. Three Shifts in the Center of Gravity of the Ethereum Narrative

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

The roadmap outlines five core objectives: faster L1 (second-level final confirmation), "Gigagas" L1 achieving 10,000 TPS through zkEVM, high-throughput L2 based on data availability sampling (DAS), quantum-resistant cryptography, and native privacy transfer functionality. The roadmap also plans for seven protocol forks by 2029, averaging about once every six months.

It can be said that over the past decade, the development of Ethereum has been accompanied by the continuous evolution of its narrative and technological roadmap.

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

This was the core of Ethereum's initial narrative: "Turing-complete smart contracts." At that time, Ethereum's biggest advantage was that it could do more than Bitcoin. For example, DeFi, NFTs, and DAOs were all products of this narrative. A large number of decentralized finance protocols began to run on the chain, from lending and DEXs to stablecoins. Ethereum gradually became the main clearing network for the crypto economy.

The second phase (2021–2023) is L2's narrative takeover.

As Ethereum mainnet gas fees soar, making transaction costs unaffordable for ordinary users, Rollups have become the primary means of scaling. Ethereum is also gradually repositioning itself as a settlement layer, aiming to provide a secure foundation for Level 2.

In simple terms, it involves migrating most of the computations from the execution layer to L2 and scaling them up through Rollup, while L1 is only responsible for data availability and final settlement. During this process, The Merge and EIP-4844 serve this narrative, aiming to make L2 use Ethereum's trust more cheaply and securely.

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

As we all know, the prosperity of L2 has brought an unexpected problem: Ethereum L1 itself has become less important. Users have started to operate more on Arbitrum, Base, and Optimism, and rarely directly interact with L1. The price performance of Ethereum (ETH) also confirms this anxiety.

This led to a debate within the community: if L2 takes all the users and activity, where does the value capture of L1 lie? This logic is undergoing a profound evolution until the internal turmoil within Ethereum in 2025, and the latest series of roadmaps rolled out in 2026.

In fact, reviewing the core technology directions since 2025, Verkle Tree, Stateless Client, EVM formal verification, and native ZK support have repeatedly emerged. These technology directions all point to the same thing: to make Ethereum L1 itself verifiable. It is important to note that this is not just about making L2 proofs verifiable on L1, but about making every step of the state transition in L1 compressible and verifiable through zero-knowledge proofs.

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

It is not a replica of L2 zkEVM (such as zkSync, Starknet, Scroll), but rather it transforms the Ethereum execution layer itself into a ZK-friendly system. So if L2 zkEVM is building a ZK world on top of Ethereum, then L1 zkEVM is turning Ethereum itself into that ZK world.

Once this goal is achieved, Ethereum's narrative will be upgraded from the L2 settlement layer to "root trust in verifiable computation".

This will be a qualitative change, not the quantitative change of the past few years.

II. What is a true L1 zkEVM?

To reiterate a point that has been raised many times before, in the traditional model, validators need to "re-execute" every transaction to verify a block, while in the zkEVM model, validators only need to verify one ZK Proof. This allows Ethereum to increase the Gas Limit to 100 million or even higher without increasing the burden on nodes (further reading : "The Dawn of the ZK Route: Is the Roadmap to Ethereum's End Accelerating? ").

However, transforming Ethereum L1 into zkEVM is not a matter of a single breakthrough, but requires simultaneous progress in eight directions, each of which is a multi-year project.

Workline 1: EVM Formalization

All ZK proofs presuppose that the object being proven has a precise mathematical definition. However, today's EVM's behavior is defined by client implementations (Geth, Nethermind, etc.) rather than by a strict formal specification. Different clients may behave inconsistently in boundary cases, which makes it extremely difficult to write ZK circuits for the EVM. After all, you can't write a proof for a vaguely defined system.

Therefore, the goal of this workline is to write every instruction and every 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 that follows is like building a tower on sand.

Workline 2: ZK-friendly hash function replacement

Ethereum currently uses Keccak-256 as its hash function. Keccak is extremely unfriendly to ZK circuits, has a huge computational overhead, and significantly increases the time and cost of proof generation.

The core task of this workline is to gradually replace the Keccak used internally in Ethereum with ZK-friendly hash functions (such as Poseidon and Blake series), especially in the state tree and Merkle proof path. This is a change that affects the whole system because hash functions permeate every corner of the Ethereum protocol.

Workline 3: Replacing the Verkle Tree with the Merkle Patricia Tree

This is one of the most anticipated changes in the 2025–2027 roadmap. Ethereum currently uses Merkle Patricia Tree (MPT) to store global state. Verkle Tree replaces hash links with Vector Commitments, which can compress the witness volume by tens of times.

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

Workline 4: Stateless Clients

A stateless client refers to a node that, when verifying a block, does not need to store the complete Ethereum state database locally; it only needs the witness data attached to the block itself to complete the verification.

This workline is deeply tied to the Verkle Tree because stateless clients are only practically feasible if the witness is small enough. Therefore, the significance of stateless clients for L1 zkEVM is twofold: on the one hand, it significantly lowers the hardware threshold for running nodes, which helps decentralization; on the other hand, it provides clear input boundaries for ZK proofs, allowing provers to only process the data contained in the witness, rather than the entire world state.

Workline 5: Standardization and Integration of ZK Proof Systems

L1 zkEVM requires a mature ZK proof system to generate proofs for block execution, but the current technical landscape in the ZK field is highly fragmented, with no universally accepted optimal solution. The goal of this workline is to define a standardized proof interface at the Ethereum protocol layer, so that different proof systems can access each other through competition, rather than being assigned to a particular system.

This maintains the openness of the technology and leaves room for proving the continuous evolution of the system. The Ethereum Foundation's PSE (Privacy and Scaling Explorations) team has accumulated a great deal of preliminary experience in this direction.

Workline 6: Decoupling the Execution Layer and the Consensus Layer (Evolution of the Engine API)

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 the generation of a ZK proof, and the generation time of this proof may far exceed the block interval.

The core problem this workflow needs to solve is how to decouple execution and proof generation without compromising the consensus mechanism—execution can be completed quickly first, proof can be generated asynchronously with a delay, and then the verifier can complete the final confirmation at the appropriate time. This involves a deep transformation of the block finality model.

Workline 7: Recursive Proofs and Proof Aggregation

Generating a ZK proof for a single block is very costly, but if the proofs of multiple blocks can be recursively aggregated into a single proof, the verification cost can be significantly reduced. The progress of this workline will directly determine how low the cost of L1 zkEVM can be.

Workline 8: Developer Toolchain and EVM Compatibility Assurance

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

This workline is the most easily underestimated, but it is often the most time-consuming. Every EVM upgrade in history has required a lot of backward compatibility testing and toolchain adaptation work. The changes in L1 zkEVM are far greater than those of previous upgrades, and the workload of toolchain and compatibility will also be increased by orders of magnitude.

III. Why is now the right time to understand this matter?

The release of Strawmap comes at a time when the market is skeptical about the price performance of ETH. From this perspective, the most important value of this roadmap lies in redefining Ethereum as "infrastructure".

For Builders, represented by developers, Strawmap provides directional certainty; for users, these technological upgrades will ultimately translate into a tangible experience: transactions are finalized within seconds, assets flow seamlessly between L1 and L2, and privacy protection becomes a built-in feature rather than a plugin.

Objectively speaking, L1 zkEVM is not a product that will be launched in the near future. Its full implementation may not be until 2028-2029 or even later.

But at the very least, it redefines Ethereum's value proposition. If the L1 zkEVM succeeds, Ethereum will no longer be just an L2 settlement layer, but a verifiable root of trust for the entire Web3 world, allowing any on-chain state to ultimately be mathematically traceable back to Ethereum's ZK proof chain. This is crucial for Ethereum's long-term value capture.

Secondly, it also affects the long-term positioning of L2. After all, when L1 itself has ZK capabilities, the role of L2 will change—evolving from a "security expansion solution" to a "dedicated execution environment." Which L2s can find their place in this new landscape will be the most noteworthy ecological evolution to observe in the next few years.

Most importantly, I believe it is also an excellent window into the Ethereum developer culture—the ability to simultaneously advance eight interdependent technical worklines, each a multi-year project, while maintaining a decentralized coordination approach, is a unique capability of Ethereum as a protocol.

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

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

Therefore, the eight working lines of L1 zkEVM are the technical mapping of this cognitive shift. They all point to the same goal, which is to enable the Ethereum mainnet to achieve orders-of-magnitude performance improvements without sacrificing decentralization. This is not a negation of the L2 route, but rather a refinement and supplement to it.

Over the next three years, this "Ship of Theseus" will undergo seven forks and countless "planks" replacements. When it arrives at its next destination in 2029, we may see a truly meaningful "global settlement layer" —fast, secure, private, and as open as ever.

Let's wait and see.