Interpreting Vitalik’s blog post: Exploring the possibility of having ZK-EVM built into Ethereum

Written by: Xiaobai Navigation Coderworld

Yesterday, Vitalik updated an article titled "What might an "enshrined ZK-EVM" look like?" in his blog, systematically expounding on the feasibility, methods and expected effects of integrating ZK-EVM into Ethereum.

The future development of EVM is often associated with multiple infrastructure-related narratives or directional changes, which are worth reading and studying.

However, considering that the article involves too many technical details, Chinese media andCommunityMost of the materials in the book are simple translations of the article, which makes it easy for people to lose track of the article's context and viewpoints.

Therefore, Xiaobai Navigation interpreted the article, trying to restore Vitalik's writing ideas and views in a more popular way, and provide a reference for readers.

The title implies: making ZK-EVM official

If you only read directly translated articles, you will hardly see some hints or natural expressions in the English context.

In the title of Vitalik's article, there appears a less common English word - "enshrined".

Simply look up the GPT or an English dictionary and you will see:

The word “Enshrined” originally means “to be consecrated” in English and is often used to describe raising something or someone to an extremely high level of status, importance, or value, such as placing it in a sacred or protected position.

In legal or religious texts, "enshrine" usually refers to the formal and respectful recording or preservation of certain principles, rights, or beliefs.

In the technology or software world, "enshrined" usually means that a technology, feature, or principle is formally and significantly integrated into a system, framework, or protocol.This usually means that the technology or functionality is considered fundamental, core, or critical, and is therefore formally and durably incorporated into the system.

Therefore, we can quickly understand Vitalik’s intention in this article directly from the title:

DiscussionZero knowledge proof(ZK) versionEthereum Virtual Machine(EVM) as a core or official part of the Ethereum protocol.

This means that Ethereum may not only view ZK-EVM as an add-on in the future.

The past of ZK-EVM:L2"Plug-in components" in the form of non-native

For those who are not familiar with Ethereum EVM and relatedL2For readers who are looking for solutions, Vitalik’s discussion of making ZK-EVM a formal part of the Ethereum mainnet easily brings to mind another question:

What was the relationship between ZK-EVM and Ethereum in the past? Wasn’t ZK-EVM an “official part” of Ethereum in the past?

Let's do a very light and quick science tutorial:

• Ethereum Virtual Machine(EVM):The core of the Ethereum network, responsible for executing smartcontractCode. All the intelligence running on EthereumcontractAll are executed through EVM.

• Zero knowledge proof(ZK): A cryptographic technique that allows one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any information other than the statement.cryptocurrencyandBlockchainIt is used in the field to enhance the privacy andSafetysex.

• What does ZK-EVM do?It combines the functionality of EVM and the privacy protection features of zero-knowledge proof. It allows the validity of transactions to be verified while keeping transaction data private. This means that it is possible to prove that the transaction complies with smart contracts andBlockchainRegular.

• The relationship between ZK-EVM and Ethereum mainnet：ZK-EVM can be used as a solution. While maintaining the compatibility of the Ethereum virtual machine, it introduces zero-knowledge proof so that the executed transactions can remain private.In the early days, ZK-EVM appeared more as a Layer 2 solution, that is, it was built on top of the Ethereum mainnet to provide additional privacy protection and scalability features for the mainnet.

Therefore, most of the current ZK-EVMs appear in the form of L2, rather than directly existing in the design of Ethereum L1.External components.

Everyone knows the more well-known ZK-EVM solutions, such as Starknet, zkSync, Polygon Hermez and Scroll.

With the above background knowledge, it becomes much easier to understand Vitalik’s blog.

Why build native ZK-EVM into Ethereum?

Following the above logic, you may ask: ZK-EVM's L2 solution is doing well, why did Vitalik try to discuss incorporating ZK-EVM directly into the core design of Ethereum?

Vitalik gave a very concise answer:

1. Dependencies on large code bases: Current Layer 2 solutions, such as Optimistic Rollups and ZK Rollups, rely on EVM verification. This means they must trust a large code base. If there are vulnerabilities in the code base, these virtual machines (VMs) may be at risk of being hacked.

2. Governance issues: Even ZK-EVMs that wish to maintain full equivalence with the L1 EVM would require some form of governance mechanism in order to replicate changes in the L1 EVM to their own EVM implementations. This adds complexity and potential risk of inconsistency.

3. Functionality duplication: Layer 2 projects replicate functionality that already exists in the Ethereum protocol. Ethereum governance is already responsible for making upgrades and fixing vulnerabilities. ZK-EVM essentially performs the same work as validating L1 Ethereum blocks.

4. Future Light Client Development: As light clients become more powerful and soon be able to fully verify L1 EVM executions using ZK-SNARKs, the Ethereum network will effectively have a built-in ZK-EVM. This raises the question:Why not provide this native ZK-EVM for rollups as well?

By exploring these issues, Vitalik clarified the motivations for incorporating ZK-EVM into the core design of Ethereum — mainly to address the risks of relying on external code bases, simplify the governance process, reduce functional duplication, and leverage the capabilities of the Ethereum network itself.

What should a built-in ZK-EVM look like?

So if Ethereum wants to have a built-in ZK-EVM, what functions and features should it have? Vitalik further gave his thoughts:

1. Basic functions:The core function of ZK-EVM is to verify Ethereum blocks. This means that it should be able to accept a pre-state root, a block, and a post-state root as input, and verify that the post-state root is indeed the result after executing the block.

2. Comparison with Ethereum’s multi-client philosophycompatibility：ZK-EVM should avoid adopting a single proof system, but allow different clients to use different proof systems. This involves the requirement of data availability and the consideration that the proof should be independent of the EVM and block data structure.

3. Auditability: If any execution is proven, then the underlying data should be available so that users and developers can inspect it if problems arise.

4. Upgradability: If a vulnerability is found in a specific ZK-EVM scheme, it should be able to be fixed quickly without the need for a hard fork.

5. Supports almost the sameEVM(almost-EVMs): ZK-EVM should support innovation at the execution level and extensions to the EVM. If a given L2 VM is only slightly different from the EVM, it can still use native in-protocol ZK-EVM to handle the same parts as the EVM, and rely only on their own code to handle the different parts.

Note that thisalmost-EVMsSome readers may not know that Vitalik has mentioned a similar point of view before. He believes that some ZK-EVM solutions should not be strictly required to be exactly the same as EVM when implemented, but can become "somewhat close" to the original EVM.

In the ZK-EVM framework proposed by Vitalik, support for almost-EVMs means that ZK-EVM can be more flexible to adapt to a variety of different needs and scenarios. This allows ZK-EVM to serve not only applications that fully comply with the standard EVM specification, but also systems that require or wish to make minor adjustments.

How to run ZK-EVM on different Ethereum clients?

Following the same train of thought and reading Vitalik's original text, it is easy to get confused here: why is he suddenly talking about the client again?

Looking back at the above, you will find that Vitalik's logic is very clear:

“I want to make ZK-EVM a built-in component of Ethereum — Why do I want to do this? — What functions should this satisfy?”

So the next discussion point actually becomes:If we do this, how do we run it on different clients when we implement it?

Vitalik gave two directions, namely running in an open multi-client system or running in a closed multi-client system.

• Open System:More in line with Ethereum's decentralization and innovative spirit, allowingCommunityDevelop and adopt new proof technologies as needed.

• Closed System:May be easier to manage and maintain, but may limit the system's long-term adaptability and innovation potential.

In addition, Vitalik also talked about the importance of speed in ZK-EVM. If ZK-EVM can generate proofs quickly, it will be more suitable for integration into the Ethereum main protocol because it can better meet the performance requirements of the network and user experience expectations.

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

How is ZK-EVM implemented on Ethereum?

Vitalik also gave possible implementation methods of ZK-EVM.

He proposed a new transaction type - ZK-EVM Declaration Transaction (ZKEVMClaimTransaction), and how to process and verify these transactions in the Ethereum network.

Since this part is too technical, it is recommended that readers without basic knowledge can skip the technical details. Let's take a look at his design ideas and general ideas:

1. Introduced container type for passing ZK-EVM related declarations in the network.

2. At the consensus layer, a new rule is proposed that a block is accepted only when the client sees a valid proof for each statement.

3. Users can replace their execution clients in ZK-EVM proofs, but the execution clients are still used to generate proofs and build blocks, as well as nodes to store and index data.

4. Different ZK-EVM implementations may have different proof methods, but they can all verify and accept proofs from each other.

In addition, Vitalik discusses the “almoXiaobai Navigationst-EVMs” (a system nearly equivalent to the Ethereum Virtual Machine), which is a desired goal for ZK-EVM functionality.

These systems have additional features built in, which might include new precompiled contracts, opcodes, contract writing options (such as the choice of writing in the standard EVM or an entirely different virtual machine, such as Arbitrum Stylus), or even multiple parallel EVMs with support for synchronous cross-communication.

Meanwhile, Vitalik Buterin discussed how stateful validators can be supported within ZK-EVM and why this is beneficial:

Why support state validators?

• Data efficiency: State validators can improve data compression efficiency. A completely stateless system requires all data to be available at every transaction, which may lead to data duplication and waste. State validators can store previous state information, reducing the amount of data that must be transmitted and processed.

• Reduced data redundancy: If a piece of data has already been provided by a previous block or transaction, there is no need to provide it again in a subsequent proof because it is already “known”.

• System performance: Stateful systems allow for more efficient computation and verification because they can leverage known information rather than starting from scratch each time.

As for how to support it, the original text involves too many technical details, which is difficult to interpret in depth here. We just need to understand:

“Supporting state validators” means introducing a mechanism in ZK-EVM.This allows the system to remember and utilize previous states, rather than being completely stateless on every operation. This can improve the overall performance of the system, reduce the required data transfer, and allow for more efficient computation.This is an extension to the ZK-EVM design to improve its feasibility and efficiency in real-world applications.

With ZK-EVM built in, what about other L2s that do similar things?

At the end of the article, Vitalik slightly jumped out of the serious technical discussion and turned to think about another question, that is, if ZK-EVM becomes a built-in function of Ethereum L1, how will the roles of other L2s that do ZK change?

In Vitalik's vision, if this is really done, L2 may have to play a more "auxiliary" role in the future, playing a supplementary role in the following aspects:

1. Quick pre-confirmation:Single-slot finality may slow down Layer 1 processing, while Layer 2 projects can provide fast pre-confirmation services that are powered by Layer 2 itself.SafetyMechanism support, latency is much lower than one time slot. These services will continue to be the exclusive responsibility of Layer 2.

2. Minimum Extractable Value (MEV) Mitigation Strategy:This may include encrypted memory pools, reputation-based sorter selection, and other features that Layer 1 is reluctant to implement. Layer 2 can implement these strategies to reduce the impact of MEV on user transactions.

3. rightEVMExtensions: Layer 2 projects can introduce significant extensions to the EVM that provide significant value to their users. This includes supporting versions of "almost-EVMs", or completely different approaches, such as the WASM-enabled Arbitrum Stylus and the SNARK-friendly Cairo language.

4. Convenience for users and developers: Layer 2 teams do a lot of work by attracting users and projects to their ecosystem and making them feel welcome; they get paid by capturing MEV and congestion fees within the network. This model will continue even if ZK-EVM is integrated into the Ethereum protocol.

Please note that these are just Vitalik’s personal ideas and have not yet been formally put into practice.

But judging from this blog, Vitalik has clearly considered the original intention, method, function and additional impact of Ethereum's own ZK-EVM, and it is obviously not a spur-of-the-moment idea.

From EVM to EVM with better performance, and then to EVM with ZK considerations, Vitalik, as the designer of Ethereum, has made his work more perfect in a progressive way;

Of course, in this process he has never rejected the idea of other L2 solutions, but he also seems to have never given up on making Ethereum better in a native way.

As to whether the native idea of ZK-EVM will actually be passed, we will have to wait until the ideas in these blogs become specific proposals to find out.

However, what is certain is that when technological innovation is coming, the entire ecosystem will also be in turmoil.

The article comes from the Internet:Interpreting Vitalik’s blog post: Exploring the possibility of having ZK-EVM built into Ethereum

Related recommendations: T2T2 product analysis, how to create a Token flywheel through decentralized copy trading?

T2T2 allows ordinary users to not only copy orders, but also receive additional arbitrage subsidies and share the inflation benefits of the entire system. On November 7, the T2T2 decentralized copy order product officially started internal testing, and a group of top traders have begun to settle in, including institutional traders,BinanceThe top of the contract win rate list, telegram bot team, etc. From the current traders...