Why does Ethereum need to complete the ZK mainnet upgrade

Ethereum currently faces a narrative gap. The once-touted “world computer” and “financial settlement layer” are now in the past, and the new development focus appears blurry. Among many possibilities, zero-knowledge proofs (ZK) are gradually emerging as the most promising direction—this is also why the Ethereum community’s investment in ZK technology surpasses that of any other public chain in the crypto world.

Performance Dilemma and the Decentralization Tug-of-War

On the surface, Ethereum’s performance metrics are quite impressive. By repeatedly increasing the Gas limit, the mainnet’s theoretical peak has reached over 200 TPS. However, this approach has hidden costs—node operators need to equip more powerful servers.

This involves a deep contradiction: Ethereum adheres to decentralization principles and is reluctant to let node maintenance costs become too high (otherwise, only a few institutions could run nodes). In contrast, Solana’s cost for a single server is 5-10 times that of Ethereum, reflecting two fundamentally different technical paths.

Faced with this dilemma, simply continuing to raise the Gas limit has become a dead end. A new solution must be found—one that allows nodes to verify more transactions at lower hardware costs.

ZK Mainnet: From “Core Tool” to “Architectural Necessity”

Recently, Vitalik announced on Twitter that ZKEVM has entered the Alpha stage. The underlying logic is: ZK mainnetification is not optional but an inevitable path.

To illustrate intuitively: the work of nodes used to be like teachers grading exams one by one—each transaction needed to be verified individually, which was laborious and inefficient. After ZK integration, it’s like having an automatic grading machine—nodes only need to verify a concise ZK proof to confirm the validity of a batch of transactions.

What is the specific effect? A node that could verify 50 transactions before might now verify 1,000. The hardware and personnel remain unchanged, but efficiency multiplies.

It’s important to clarify a common misconception: ZK itself does not directly increase TPS; it builds the foundational infrastructure. True performance improvements still depend on raising the Gas limit, but under a ZK architecture, the hardware cost growth during this process is significantly reduced—that is the core value of ZK.

The successful upgrade of Fusaka, especially PeerDAS, indicates that Ethereum has prepared the technical reserves for ZK mainnetification. Once this transition is complete, surpassing 1,000 TPS will no longer be just a theoretical goal for Ethereum.

Opportunities for a Diversified ZK Ecosystem

Some worry: if the Ethereum official pushes ZK-EVM aggressively, will there still be room for independent ZK teams?

The answer is yes—there is still vast space.

First, from a technical complexity perspective, ZK and Fully Homomorphic Encryption (FHE) are considered the most challenging cryptographic engineering tasks. While the Ethereum Foundation has some experience, it is far from enough to handle all tasks independently. The open-source community’s core philosophy is collective effort; trial, error, and innovation from third-party ZK teams are crucial for the ecosystem.

Second, from a technical route perspective, ZK-EVM is divided into four types: Type 1 to Type 4. Teams like Polygon, Scroll, ZKsync, and Taiko are each focusing on one type, forming a de facto “division of labor and competition.” Ultimately, only one of these routes may become the standard recognized by Ethereum, but before consensus is reached, the value of diversified exploration is irreplaceable.

More importantly, the ZK-VM domain deserves attention. Unlike ZK-EVM, ZK-VM (such as Brevis’s solution) does not insist on EVM compatibility. Because it’s not constrained by EVM, its performance is often superior. Moreover, since there’s no “either-or” dilemma, ZK-VM teams enjoy longer-lasting vitality. Vitalik has specifically mentioned Brevis’s ZK-VM performance and expressed hope for its entry into the ZK-EVM space.

Rebalancing the L2 Ecosystem

Will Ethereum’s ZK mainnetification impact Layer 2?

Vitalik’s view is: ZK progress and L2 development should be evaluated separately. In the short term, there may indeed be some user migration—if L1 becomes cheap enough, the value-driven motivation for some L2 users might decline.

But from another perspective, L1 mainnet is like the foundation of a building, and L2 is like the skyscraper. The more solid the foundation, the more stable and scalable the entire structure. After L1 adopts ZK, transaction costs on L2 will also decrease, creating positive feedback for the entire ecosystem.

Furthermore, teams like Brevis, engaged in ZK work, have long gone beyond L2 scope. They are building ZK compute markets, providing ZK-based incentive distribution mechanisms for applications like Uniswap—these innovative, driven applications are not exclusive to L2 but represent the true “application layer ZK.”

Conclusion

Since the vision of ZK was proposed, Ethereum has been cultivating for five or six years. Now, with ZKEVM entering the Alpha stage, this leap relies on long-term official investment and continuous innovation from ecosystem partners like Brevis and Polygon.

When Ethereum ultimately achieves ZK mainnetification, it will be more than just a technical upgrade—it will be a complete narrative cycle—from the “world computer” to a “scalable financial settlement layer,” and finally to the “ultimate form combining decentralization and performance.” The next chapter of this story is worth looking forward to.