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

CN
10 hours ago

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

Looking across the entire network, Vitalik and the Ethereum Foundation have the most investment in ZK. ZK is somewhat like the youngest son 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 planning document 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.

Bottlenecks in Performance Improvement: Full Verification and GAS Limits

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

However, the problem is that increasing the GAS limit comes at a cost; excessively large blocks are a heavy burden for nodes.

Currently, Ethereum employs a verification model called “full verification by all”, meaning 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 also surge.

Considering that Ethereum's block interval is only 12 seconds, with time 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.

ZK-ified Ethereum: From "Full Verification by All" to "Single Verification by All"

If Ethereum L1 is fully ZK-ified, 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 first be generated.

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 (sending a transaction) on DingTalk, each leader (node) needed to verify one by one whether you had any vacation balance (full verification by all), and only after all approved would the process pass.

After ZK-ification, the system first verifies that you indeed have vacation time, then issues a proof (ZK) to all leaders, who only need to trust and quickly approve (single verification by all).

After ZK-ification, you still apply for leave (send a transaction), and the system finds you have remaining vacation, directly telling all leaders “this person has leave,” and the leaders fully trust that the system will not make mistakes (ZK), then the approval process is much faster (single verification by all).

This is the reason why Ethereum is pursuing ZK-ification.

Cryptographic Challenges and Cases

Of course, achieving all of this involves 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 currently one of the fastest solutions for generating ZK proofs under given conditions.

According to test data, under the current Ethereum block size of 45 M GAS, Brevis uses 64 RTX 5090 GPUs to complete 99.6% of block proofs within 12 seconds, 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 limit.

Why is the “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.

Summary: The Logical Path to Ethereum's ZK-ification

To accelerate L1 performance improvement, Ethereum must raise the GAS limit;

To safely raise the GAS limit, ZK-ification must be advanced;

And to elegantly achieve ZK-ification (proof generation within 10 seconds, hardware costs below $100,000), collaboration between the cryptographic community and the crypto ecosystem is required.

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.

Ebunker Official Website: https://www.ebunker.io

For more discussions, please join: https://t.me/ebunkerio

Ebunker Twitter: https://twitter.com/ebunker_eth

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink