Why Ethereum Needs ZK-VM: The Ultimate Path to Scalability

Among the many approaches to Ethereum scaling, ZK is the most complex and also the most crucial direction.

Across the entire network, Vitalik and the Ethereum Foundation have placed the biggest bets on ZK. ZK is somewhat like the youngest child in the Ethereum family—receiving the most attention and effort, but with the most uncertain future.

A few days ago, the Ethereum Foundation released the Kohaku roadmap, which is a plan for the basic components of a privacy wallet. The roadmap once again emphasizes that many core functions will still rely on the implementation of ZK-EVM or ZK-VM.

So, why does Ethereum need ZK-VM so urgently?

The answer is simple: for performance improvement, but not at the expense of security.

The Bottleneck of Performance Improvement: Universal Verification and GAS Limit

As we mentioned before, the most immediate way to improve Ethereum’s performance is to increase the GAS limit, which means making the blocks larger.

But the problem is, increasing the GAS limit comes at a cost; oversized blocks are a heavy burden for nodes.

Currently, Ethereum uses a “universal verification” model, meaning every node must fully verify every block. While this mechanism is simple and secure, it is highly redundant.

If the GAS limit is significantly increased, the computational load for each node will skyrocket accordingly.

Considering Ethereum’s block interval is only 12 seconds, and some of that time must be reserved for block propagation and MEV sorting, validators actually have only about 4–8 seconds to verify, leaving almost no room to handle a larger load.

Ethereum after ZK: From “Universal Verification” to “Universal Single Verification”

If Ethereum L1 is fully ZK-ified, the verification model will shift from “universal verification” to “universal single verification.” In this model, once a block is assembled, a ZK proof is generated first.

The characteristic of ZK is that proof generation is slow, but verification is extremely fast. Therefore, nodes only need to verify once whether the proof is correct, without repeatedly executing all transactions in the block.

This means that Ethereum can greatly increase the GAS limit without significantly increasing the burden on nodes.

A vivid analogy: in the past, when you submitted a leave request on DingTalk (send a transaction), every manager (node) had to check one by one whether you still had leave balance (universal verification), and the process would only pass after everyone approved.

After ZK-ification, the system first verifies that you do have leave, then issues a proof (ZK) to all managers at once. At this point, managers only need to trust and quickly approve (universal single verification).

After ZK-ification, you still submit a leave request (send a transaction), the system finds you have remaining leave, directly tells all managers “this person has leave,” and the managers fully trust the system won’t make mistakes (ZK), so approval is much faster (universal single verification).

This is why Ethereum wants to implement ZK-ification.

Cryptographic Challenges and Case Studies

Of course, the engineering workload to achieve all this is enormous, and the cryptographic difficulty is also very high, so Ethereum must cooperate with professional teams.

The Brevis protocol mentioned by Ethereum Foundation researcher Justin is one of the leading cases in this field.

Brevis focuses on ZK-VM, and its latest Pico Prism technology is currently one of the fastest solutions for generating ZK proofs under given conditions.

According to test data, with the current Ethereum block size of 45M GAS, Brevis uses 64 RTX 5090 GPUs and can complete 99.6% of block proofs within 12 seconds, with 96.8% of blocks having proof generation completed within 10 seconds.

To maintain decentralization, Ethereum requires the cost of ZK proof devices to not exceed $100,000.

Although higher-end GPUs (such as H200 or B200) can generate proofs even faster, that would greatly raise the entry barrier. Brevis’s current design fits right within this limit.

Why is “10-second coverage” also crucial? Because MEV blocks are usually generated within 1–3 seconds, and adding 10 seconds of proof time just fills the 12-second block interval.

Summary: The Logic of Ethereum’s ZK-ification Path

If Ethereum wants to accelerate L1 performance improvement, it must increase the GAS limit;

To safely increase the GAS limit, ZK-ification must be promoted;

And to elegantly achieve ZK-ification (proof generation within 10 seconds, hardware cost below $100,000), it requires the joint efforts of the cryptography community and the crypto ecosystem.

ZK is the most complex but also the most deterministic direction in Ethereum’s scaling roadmap.

It’s not just about performance; it’s also the ultimate solution for Ethereum to seek a balance between security and decentralization.