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

Author: Ebunker

Among the many ideas for scaling Ethereum, ZK is the most complex and critical direction.

Looking across the network, Vitalik and the Ethereum Foundation have the most investment in ZK. ZK is somewhat like the youngest child in the Ethereum family, receiving the most attention, but with the most uncertain future.

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

So, why does Ethereum urgently need ZK-VM?

The answer is simple: for performance improvement, without sacrificing security.

Performance Bottleneck: Full Verification and GAS Limit

Previously, we mentioned that the most immediate way to improve Ethereum's performance is to raise the GAS limit, which means making blocks larger.

But the problem is that raising the GAS limit comes at a cost; overly large blocks are a heavy burden for nodes.

Currently, Ethereum employs a verification model called "full verification by all", where all nodes must fully verify each block. This mechanism, while simple and secure, is highly redundant.

If the GAS limit is significantly increased, the computational load on each node will surge accordingly.

Considering that Ethereum's block interval is only 12 seconds, and time must be reserved for block propagation and MEV sorting, the actual time available for validators to verify is about 4-8 seconds, leaving almost no room to handle larger loads.

Ethereum After ZK: From "Full Verification by All" to "Single Verification by All"

If Ethereum L1 is fully ZK-enabled, the verification model will change from "full verification by all" to "single verification by all." In this model, once a block is assembled, a ZK proof will be generated first.

The characteristic of ZK is that generating the proof is slow, but verification is extremely fast. Therefore, nodes only need to verify once whether the proof is correct, without having to re-execute all transactions within the block.

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

A vivid analogy is: in the past, when you submitted a leave request process on DingTalk (sending a transaction), each leader (node) needed to verify one by one whether you still had vacation days left (full verification by all), and only after all approved could the process go through.

After ZK implementation, the system first verifies that you indeed have vacation days, then issues a proof to all leaders (ZK), at which point the leaders only need to trust and quickly approve (single verification by all).

After ZK implementation, you still apply for leave (send a transaction), the system finds you have remaining vacation days, directly tells all leaders "this person has leave," and the leaders fully trust that the system won't make mistakes (ZK), then the approval process is much faster (single verification by all).

This is why Ethereum needs to implement ZK.

Cryptographic Challenges and Cases

Of course, achieving all this requires a massive engineering effort, and the cryptographic difficulty is very high, so Ethereum must collaborate 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 one of the fastest solutions for generating ZK proofs under given conditions.

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

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

While higher-end GPUs (like H 200 or B 200) can generate proofs faster, that would significantly raise the entry barrier. Brevis's current design fits perfectly within this limitation.

Why is "10-second coverage" also crucial? Because MEV blocks are typically generated within 1-3 seconds, and the 10 seconds of proof time perfectly fills the 12-second block interval.

Conclusion: The Logical Path to Ethereum's ZK Implementation

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

To safely raise the GAS limit, it must advance ZK implementation;

And to elegantly achieve ZK implementation (generating proofs within 10 seconds and hardware costs below $100,000), it requires joint efforts from the cryptographic community and the crypto ecosystem.

ZK is the most complex yet most certain direction in Ethereum's scaling roadmap.

It not only concerns performance but also represents Ethereum's ultimate solution in seeking a balance between security and decentralization.