Ad
News
Vitalik Buterin proposes ‘enshrined zkEVM’ to address layer-2 challenges on Ethereum Vitalik Buterin proposes ‘enshrined zkEVM’ to address layer-2 challenges on Ethereum

Vitalik Buterin proposes ‘enshrined zkEVM’ to address layer-2 challenges on Ethereum

Buterin's new proposal addresses scalability by building a zero-knowledge Ethereum Virtual Machine directly into Ethereum itself.

Vitalik Buterin proposes ‘enshrined zkEVM’ to address layer-2 challenges on Ethereum

TechCrunch / CC BY 2.0 / Flickr. Remixed by CryptoSlate

Ethereum co-founder Vitalik Buterin introduced a new concept for the blockchain platform called an “enshrined Zero-Knowledge Ethereum Virtual Machine (ZK-EVM) in a Dec. 13 blog post.

The proposal’s main goal is to substantially improve the efficiency and security of Ethereum’s Layer-2 protocols, including optimistic and ZK rollups.

Addressing challenges in Layer-2 protocols

Buterin’s proposal arises from a need to streamline the current Layer-2 solutions on Ethereum. These protocols, vital for Ethereum’s scalability, depend heavily on EVM verification, which currently involves relying on a large, potentially vulnerable codebase.

Additionally, ZK-EVMs, designed to mimic the Layer-1 EVM, face the challenge of keeping up with changes in the main Ethereum protocol, leading to redundant efforts and increased risk of security flaws.

The solution proposed by Buterin involves embedding a ZK-EVM directly within the Ethereum network. This internal ZK-EVM would undertake the task of verifying Layer-1 Ethereum blocks, thereby offering a more efficient and secure approach.

As Ethereum advances, particularly with the development of light clients using ZK-SNARKs, the concept of a native ZK-EVM becomes increasingly practical and appealing.

Core aspects of the proposed ZK-EVM

Buterin envisions the ZK-EVM to focus mainly on verifying Ethereum blocks by processing inputs like a pre-state root, a block, and a post-state root.

This would ensure the integrity of the post-state root as a true outcome of block execution. The proposal also aligns with Ethereum’s multi-client philosophy, supporting the use of diverse proving systems and emphasizing the importance of data availability and auditability.

Implementing a ZK-EVM, as described by Buterin, presents several design challenges and trade-offs. Essential properties include:

  1. Compatibility and Adaptability: The system should be flexible enough to support various proving systems, reflecting Ethereum’s commitment to a multi-client environment.
  2. Ensuring Data Availability: Vital for enabling verification by different clients.
  3. Emphasizing Auditability and Upgradeability: Allowing for easy inspection and quick resolutions to any issues without requiring hard forks.
  4. Supporting Innovations in ‘Almost-EVMs’: Permitting Layer-2 solutions to extend and innovate upon standard EVM functionalities.

A crucial part of Buterin’s discussion revolves around choosing between an open multi-client system, where proofs are verified externally, and a closed system with predetermined proof systems. Buterin advocates for an available system for its flexibility and compatibility with Ethereum’s foundational principles despite its higher complexity.

Buterin emphasizes that speed is critical for ZK-EVM implementations. With technological advancements in parallelization and hardware acceleration, the goal is to reduce proof generation time, allowing for near-instantaneous processing.

Mentioned in this article