zkEVM can solve verification problems in Ethereum

Ethereum, a smart contracting platform powering decentralized finance (DeFi), non-fungible tokens (NFTs) operations, and more, has a problem that cannot be solely solved by layer-2 scaling platforms, its co-founder Vitalik Buterin recently stated. 

In a blog, Buterin said though the network is widely used and there are users, it is a challenge to verify mainnet transactions. Challenges arising from this mean not many people can run their nodes and instead rely on trusted third parties, including light clients. Although lightweight clients are essential, the co-founder notes that verifying whether a particular Ethereum validator follows established protocol rules is challenging.

To address these problems, Buterin proposes two options to solve layer-1 verification problems on-chain while improving scalability.

Addressing on-chain verification problems 

In the first option, he suggests constraining the mainnet and forcing activity to layer-2. This would require reducing the mainnet gas-per-block target from 15 million to 1 million, with the only function of layer-1 being to verify layer-2 protocols.

While this solution could work, there can be flaws. First, it would render many existing L1-based applications economically unfeasible, and user funds could get stuck due to overwhelmingly high fees. Mass migration to a layer- 2 project is possible, but that would further complicate the process.

The co-founder notes that, ideally, the Ethereum protocol should be easy to verify on various devices, including laptops, phones, and browser extensions. Yet, individually syncing the data on-chain for the first time, or after a long time offline, could take up to 54 seconds. This could be tasking on the device’s browser or lead to rapid battery drain for portable devices.

Another alternative option Buterin proposes involves Succinct Non-interactive Argument of Knowledge (SNARK)-verifying the mainnet using a zero-knowledge Ethereum Virtual Machine (zkEVM), which can be used to verify the Ethereum Virtual Machine (EVM) execution of an Ethereum block. 

In this approach, more SNARK code would be written to verify the consensus side of a block. However, generating proofs in real-time would require significant improvements through specialized hardware or architectural improvements.

If this option is pursued, there would be a need to choose a type of zkEVM to use for verification. Three options exist: a single zkEVM, a closed multi-zkEVM, and an open multi-zkEVM. 

While each option has advantages and disadvantages, Buterin believes the open multi-zkEVM option is the best path. This approach would involve different clients having different zkEVM implementations, with each client waiting for compatible proof before accepting a block as valid.

While ideal, it won’t be without challenges. What’s evident is that it would require significant improvements in Ethereum’s efficiency and parallelization. However, he believes this path can be explored and is practical due to technological advancements.

Improving scalability and accessibility in Ethereum

Buterin’s proposals represent a step in the right direction for solving the verification problem on-chain. While the proposed solutions have weaknesses, they highlight the need for a more scalable and efficient Ethereum protocol. 

This proposal came when Polygon launched its zkEVM mainnet beta early this week with plans of open-sourcing the technology to spur more developments.

Follow Us on Google News