Why Ethereum Urgently Needs to Go ZK

The most common question lately is: How should we interpret Ethereum’s current narrative?

In 2017, Ethereum’s story was all about ICOs and the world computer concept. By 2021, the focus shifted to DeFi and its role as a financial settlement layer. Heading into 2025, however, there doesn’t seem to be a new narrative that matches the scale of those earlier cycles.

Some would argue that the ETF and Staking ETF are partial narratives, but these developments aren’t under the direct control of Ethereum’s developer community. If there’s another contender, it’s ZK.

Ethereum is, without question, the public blockchain making the largest commitment to ZK technology in the crypto world.

Just a few days ago, Vitalik excitedly announced on Twitter that ZKEVM has entered its Alpha phase.

Why is Ethereum so devoted to ZK?

Ethereum’s current TPS is already quite high, with theoretical peaks now above 200 TPS—mainly due to repeated increases in the gas limit.

But raising the gas limit comes at a cost, and there’s a ceiling. The higher the limit, the more expensive the servers required for nodes to operate.

At the same time, Ethereum aims to preserve its hallmark decentralization, so it can’t push node hardware requirements too high (for context, a Solana server is about 5–10 times more expensive than an Ethereum server).

This makes full ZK integration at the mainnet level essential. It’s not just about launching a few ZK Layer 2s—this is comprehensive ZK integration for Layer 1 itself.

What does ZK bring to the table?

Ethereum nodes will be able to simply verify ZK proofs, rather than laboriously checking each transaction one by one.

Think of it like grading exams: nodes are the teachers, and transactions are the students’ test papers.

Manual grading is slow, but with answer sheets (ZK integration), a machine can instantly tally each student’s score. The teacher’s workload drops dramatically.

Now, someone who could grade 50 papers can handle 1,000—the same person, but with exponentially greater efficiency.

This is why Ethereum needs ZK at the mainnet level before it can safely raise the gas limit even further.

ZK integration isn’t what directly boosts TPS—it’s the prerequisite. Performance gains still rely on increasing the gas limit, but with ZK, nodes won’t need to pay much more for server hardware, making the upgrade far less costly.

After the recent Fusaka upgrade—especially PeerDAS—performance has been strong, putting Ethereum another step closer to mainnet ZK integration. That’s what has Vitalik so enthusiastic.

Imagine a mainnet with TPS over 1,000—that would be a compelling new narrative for Ethereum.

Some have asked: If Ethereum itself implements ZK-EVM for the mainnet, do other ZK teams still matter?

The answer is yes—they absolutely do.

Why?

First, ZK engineering is among the most complex projects in the entire industry, on par with FHE. It demands a deep pool of cryptography talent.

While the Ethereum Foundation has some resources, the open-source ethos is all about collective effort. Ethereum depends on many third-party ZK teams for experimentation and innovation, and rewards them with substantial support.

Second, there are four types of ZK-EVM, from type 1 to type 4. Teams like Polygon, Scroll, ZKsync, and Taiko have each taken on different types—almost like dividing up the workload.

There’s also ZK-VM, such as Brevis.

In fact, ZK-VM’s position is even more secure than ZK-EVM’s.

Why? Because among the four major ZK-EVM types, one will likely be chosen as the most cost-effective solution and become part of Ethereum’s official mainnet ZK-EVM, potentially sidelining the other three.

But ZK-VM isn’t EVM-compatible, so it will always be part of Ethereum’s broader ecosystem.

And because VMs aren’t limited by EVM constraints, their performance can be much higher. Ethereum’s ZK-EVM poses no threat—in fact, the Ethereum community actively encourages such innovation.

For example, Vitalik has publicly praised Brevis’s ZK-VM performance and looks forward to its entry into the ZK-EVM space.

What about Layer 2? There may be some impact, but it’s limited.

Vitalik has said that it’s best to keep ZK and Layer 2 separate when discussing Polygon.

With ZK at Layer 1, some users will likely migrate back from ZK Layer 2, since a cheaper Layer 1 reduces the incentive to use Layer 2.

But consider this: Layer 1 is the foundation, Layer 2 is the skyscraper. The stronger the foundation, the better. So if Layer 1 is ZK-integrated, Layer 2 will also see lower costs and benefit accordingly.

In that same post, Vitalik specifically mentioned Brevis’s ZK-VM work, noting that much of their ZK research isn’t limited to Layer 2—“ZK research and Layer 2 research should remain separate.”

For example, they run a ZK compute marketplace, help Uniswap hooks implement ZK-based reward distribution, and drive application-focused innovation.

In short, Ethereum has been live for 10 years, and the call for ZK integration dates back five or six years. After years of dedication, ZK integration has finally reached the Alpha stage—a milestone made possible by the ongoing efforts of Ethereum and numerous third-party ZK teams, including Brevis and Polygon.

Disclaimer:

1. This article is republished from [Medium] and copyright belongs to the original author [Ebunker]. If you have concerns about this republication, please contact the Gate Learn team for prompt resolution according to standard procedures.
2. Disclaimer: The views and opinions expressed in this article are those of the author and do not constitute investment advice.
3. Other language versions of this article are translated by the Gate Learn team. Unless Gate is mentioned, do not copy, distribute, or plagiarize translated content.