Interpreting Vitalik's Blog Post: Exploring the Possibility of Integrating ZK-EVM Natively into Ethereum

Written by: TechFlow

Yesterday, Vitalik published a new blog post titled “What might an ‘enshrined ZK-EVM’ look like?”, systematically outlining the feasibility, methods, and expected outcomes of integrating a zero-knowledge proof-enabled Ethereum Virtual Machine (ZK-EVM) into Ethereum.

The future development of the EVM is often tied to various narratives or shifts in infrastructure-related directions, making it worthwhile for us to read and study this piece.

However, given the highly technical nature of the article, most Chinese-language media and community materials merely provide direct translations, often failing to clarify the context or core arguments behind the text.

Therefore, TechFlow has interpreted the article, aiming to reconstruct Vitalik’s thought process and viewpoints in a more accessible way, offering readers valuable insights.

The Word in the Title Hints: Enshrining ZK-EVM as Core

If you only read a literal translation, you may miss certain nuances or natural implications present in the original English context.

In the title of Vitalik’s article, there appears a relatively uncommon English word: "enshrined".

A quick check with GPT or an English dictionary reveals:

The word "enshrined" originally means “to treat something as sacred,” often used to describe elevating the status, importance, or value of something to a very high level—placing it in a revered or protected position.

In legal or religious texts, "enshrine" typically refers to formally and respectfully recording or preserving certain principles, rights, or beliefs.

In technology or software contexts, "enshrined" usually means formally and significantly integrating a particular technology, feature, or principle into a system, framework, or protocol. This implies that the technology or function is considered foundational, core, or essential—and thus formally and permanently incorporated into the system.

Thus, from the title alone, we can quickly grasp Vitalik’s intent:

Exploring the possibility of integrating a zero-knowledge (ZK) version of the Ethereum Virtual Machine (EVM) as a core or official component within the Ethereum protocol.

In other words, Ethereum might no longer treat ZK-EVM simply as an add-on component.

The Past of ZK-EVM: An External “Add-On” Component via L2, Not Native

For readers unfamiliar with Ethereum’s EVM and related Layer 2 (L2) solutions, Vitalik’s proposal to make ZK-EVM part of Ethereum’s mainnet raises another question:

Previously, what was the relationship between ZK-EVM and Ethereum? Wasn’t ZK-EVM already an “official” part of Ethereum?

Let’s go through a brief and fast-paced explanation:

• Ethereum Virtual Machine (EVM): The core of the Ethereum network responsible for executing smart contract code. All smart contracts on Ethereum are executed via the EVM.

• Zero-Knowledge Proofs (ZK): A cryptographic technique allowing one party (the prover) to prove to another (the verifier) that a statement is true without revealing any additional information beyond the truth of the statement. This technology enhances privacy and security in cryptocurrencies and blockchain systems.

• Purpose of ZK-EVM: Combines EVM functionality with the privacy-preserving properties of zero-knowledge proofs. It allows verification of transaction validity while keeping transaction data private—proving compliance with smart contracts and blockchain rules without disclosing transaction details.

• Relationship between ZK-EVM and Ethereum Mainnet: ZK-EVM acts as a solution that maintains compatibility with the EVM while introducing zero-knowledge proofs for enhanced privacy and scalability. Early implementations of ZK-EVM were primarily Layer 2 solutions—built atop Ethereum mainnet to offer additional privacy and scaling capabilities.

Thus, current ZK-EVMs mostly exist in the form of L2s rather than being natively designed into Ethereum L1. In simple terms, they are add-on components.

Well-known ZK-EVM solutions include Starknet, zkSync, Polygon Hermez, and Scroll.

With this background knowledge, understanding Vitalik’s blog becomes much easier.

Why Build a Native ZK-EVM Into Ethereum?

Following the above logic, you might ask: If L2-based ZK-EVM solutions are working well, why is Vitalik exploring integrating ZK-EVM directly into Ethereum’s core design?

Vitalik provides a concise answer:

1. Dependence on Large Codebases: Current Layer 2 solutions like Optimistic Rollups and ZK Rollups rely on EVM verification, meaning they must trust large codebases. Vulnerabilities in these could expose VMs to hacking risks.

2. Governance Issues: Even ZK-EVMs aiming for full equivalence with L1 EVM require governance mechanisms to replicate changes from L1 EVM into their own implementations—adding complexity and potential inconsistency.

3. Functional Redundancy: Layer 2 projects duplicate functions already present in the Ethereum protocol. Ethereum governance already handles upgrades and bug fixes. ZK-EVMs essentially perform the same work as validating L1 Ethereum blocks.

4. Future Development of Light Clients: As light clients grow stronger and soon use ZK-SNARKs to fully verify L1 EVM execution, Ethereum will effectively have a built-in ZK-EVM. This leads to the question: Why not also provide this native ZK-EVM capability for rollups?

By addressing these issues, Vitalik clarifies the motivation behind integrating ZK-EVM into Ethereum’s core—mainly to eliminate reliance on external codebases, simplify governance, reduce redundancy, and leverage existing network capabilities.

What Should a Built-In ZK-EVM Look Like?

So if Ethereum were to integrate a native ZK-EVM, what features and characteristics should it have? Vitalik outlines his vision:

1. Core Functionality: The primary role of ZK-EVM is to validate Ethereum blocks. It should accept a pre-state root, a block, and a post-state root as inputs and verify that the post-state root correctly results from executing the block.

2. Compatibility with Ethereum’s Multi-Client Philosophy: The ZK-EVM should avoid locking into a single proof system, instead allowing different clients to use different proof systems. This requires careful consideration of data availability and ensuring proofs remain independent of EVM and block data structures.

3. Auditability: If any execution is proven, underlying data must be available so users and developers can inspect it when problems arise.

4. Upgradability: If vulnerabilities are found in a specific ZK-EVM implementation, they should be fixable without requiring a hard fork.

5. Support for Almost-EVMs: The ZK-EVM should support innovations and extensions at the execution layer. If an L2 VM differs slightly from the standard EVM, it should still be able to use the native protocol-level ZK-EVM for common parts, relying only on its own code for differences.

Note: Some readers may be unfamiliar with "almost-EVMs." In fact, Vitalik has previously expressed similar views—that some ZK-EVM solutions don't need to strictly match the EVM exactly, but can be “slightly different” while remaining largely compatible.

Supporting almost-EVMs in Vitalik’s proposed ZK-EVM framework means greater flexibility to accommodate diverse needs and scenarios. This enables ZK-EVM to serve both fully standard-compliant applications and systems seeking minor modifications.

How Would a Built-In ZK-EVM Run Across Different Ethereum Clients?

Continuing through Vitalik’s reasoning, one might get confused here: Why suddenly discuss client implementations?

Looking back, Vitalik’s logic is clear:

“I want ZK-EVM to become a built-in component of Ethereum — Why do this? — What functionalities should it support?”

Hence, the next logical step is: How would this actually run across different clients?

Vitalik presents two models: running in an open multi-client system or a closed one.

• Open System: Aligns better with Ethereum’s decentralized and innovative spirit, enabling the community to develop and adopt new proof technologies as needed.

• Closed System: May be easier to manage and maintain, but could limit long-term adaptability and innovation potential.

Additionally, Vitalik emphasizes the importance of speed in ZK-EVMs. Faster proof generation makes integration into Ethereum’s main protocol more feasible, better meeting network performance demands and user experience expectations.

However, achieving this requires overcoming significant technical and engineering challenges. In this section, Vitalik identifies these hurdles and proposes possible solutions.

How Could ZK-EVM Be Implemented on Ethereum?

Vitalik also suggests possible implementation paths for ZK-EVM.

He proposes a new transaction type—the ZK-EVM Claim Transaction (ZKEVMClaimTransaction)—and how such transactions would be processed and verified within the Ethereum network.

Given the technical depth of this section, readers without a strong foundation may skip ahead. Here’s the essence of his design:

1. Introduce a container type to transmit ZK-EVM-related claims across the network.

2. In the consensus layer, introduce a new rule: a block is accepted only after clients verify each claim’s validity.

3. Users can replace their execution clients within the ZK-EVM proof system, though execution clients still generate proofs, build blocks, and store/index data on nodes.

4. Different ZK-EVM implementations may use different proving methods, yet all should be able to mutually verify and accept each other’s proofs.

Moreover, Vitalik discusses supporting “almost-EVMs”—a desired goal for ZK-EVM functionality.

These systems may include extra features such as new precompiles, opcodes, contract-writing options (e.g., choosing between standard EVM or entirely different VMs like Arbitrum Stylus), or even multiple parallel EVMs supporting synchronous cross-communication.

Vitalik also explores how ZK-EVM could support stateful verifiers and why this would be beneficial:

Why support stateful verifiers?

• Data Efficiency: Stateful verifiers improve data compression. A fully stateless system requires all data to be available with every transaction, leading to duplication and waste. Stateful verifiers store prior state, reducing transmitted and processed data volume.

• Reduced Redundancy: If data has already been provided in a previous block or transaction, it doesn’t need to be retransmitted since it’s already “known.”

• System Performance: Stateful systems allow more efficient computation and validation by leveraging known information instead of starting from scratch each time.

As for implementation, the original text contains too many technical details to deeply unpack here. The key takeaway is:

"Supporting stateful verifiers" means introducing a mechanism in ZK-EVM that allows the system to remember and reuse previous states instead of operating in a completely stateless manner each time. This improves overall performance, reduces data transmission needs, and enables more efficient computation. It represents an extension of ZK-EVM design aimed at enhancing real-world feasibility and efficiency.

If ZK-EVM Is Built In, What Happens to Other L2s Doing Similar Things?

At the end of the article, Vitalik steps slightly away from strict technical discussion to consider another question: If ZK-EVM becomes a built-in L1 feature, how will the roles of existing ZK-based L2s change?

In Vitalik’s vision, if this path is taken, L2s would likely take on more of a “supporting” role, contributing in the following areas:

1. Fast Pre-Confirmation: Single-slot finality on Layer 1 might slow down processing speed. L2 projects can continue providing fast pre-confirmation services secured by their own mechanisms, with latencies far below a single slot. This remains a unique responsibility of L2s.

2. Minimizing Extractable Value (MEV): Strategies such as encrypted mempools, reputation-based sequencer selection, and other features Layer 1 may hesitate to implement. L2s can adopt these to mitigate MEV impact on user transactions.

3. Extensions to EVM: L2 projects can introduce major enhancements to EVM, delivering significant value to users—such as supporting “almost-EVM” variants or entirely different approaches like WASM-supporting Arbitrum Stylus or SNARK-friendly Cairo.

4. User and Developer Experience: L2 teams invest heavily in attracting users and projects to their ecosystems and making them feel welcome—earning revenue through captured MEV and congestion fees. This model will persist even if ZK-EVM is integrated into the Ethereum protocol.

Note: These are currently just Vitalik’s personal thoughts and have not been formally implemented.

Nevertheless, this blog post shows that Vitalik has clearly thought through the motivations, methods, functionalities, and broader implications of building ZK-EVM natively into Ethereum—it’s clearly not a spur-of-the-moment idea.

From EVM, to improved EVM, to ZK-integrated EVM, Vitalik—as Ethereum’s designer—is progressively refining his creation in a step-by-step manner.

Of course, he has never rejected ideas from other L2 solutions, yet he also seems committed to improving Ethereum through native evolution.

Whether this native ZK-EVM concept will eventually be adopted remains to be seen—only when these ideas evolve into concrete proposals will we know for sure.

But one thing is certain: when technological innovation arrives, the entire ecosystem will undoubtedly undergo dramatic transformation.