As Ethereum’s co-founder Vitalik Buterin recently explained, layer-2 scaling platforms cannot fully solve Ethereum’s scalability problem for decentralized finance (DeFi), non-fungible tokens (NFTs), and more. Although the network is widely utilized and there are multiple users, Buterin said that verifying mainnet transactions can be difficult. As a result, few people can run their nodes and rely instead on trusted third parties, such as light clients. The co-founder notes that lightweight clients are essential, but verifying whether a particular Ethereum validator complies with protocol rules is difficult.
Addressing on-chain verification problems
He proposes constraining the mainnet and forcing activity to layer-2 in the first option. This would necessitate lowering the mainnet gas-per-block target from 15 million to 1 million, with layer-1’s sole function being to verify layer-2 protocols. While this solution may work, it may have flaws. For starters, it would make many existing L1-based applications economically unviable, and user funds could become trapped due to exorbitant fees. A mass migration to a layer-2 project is possible, but it would complicate matters even further.
The protocol, according to the Ethereum (ETH) co-founder, should be simple to verify on a variety of devices, including laptops, phones, and browser extensions. However, syncing the data on-chain for the first time or after being offline for an extended period can take up to 54 seconds.
This could result in tasking on the device’s browser or rapid battery drain on portable devices. Buterin also suggests a Succinct Non-interactive Argument of Knowledge (SNARK)-verifying the mainnet with a zero-knowledge Ethereum Virtual Machine (zkEVM), which can be used to verify the Ethereum Virtual Machine (EVM) execution of an Ethereum block.
More SNARK code would be written in this approach to verify the consensus side of a block. However, generating proofs in real time would necessitate significant advancements in the form of specialized hardware or architectural changes. If this option is pursued, it will be necessary to select a type of zkEVM to be used for verification. There are three possibilities: a single zkEVM, a closed multi-zkEVM, and an open multi-zkEVM.
While each option has benefits and drawbacks, Buterin believes the open multi-zkEVM option is the best. Different clients would use different zkEVM implementations in this approach, with each client waiting for compatible proof before accepting a block as valid.
Improving scalability and accessibility in Ethereum
Buterin’s proposals are a step in the right direction for resolving the on-chain verification problem. While the proposed solutions have flaws, they spotlight the need for an Ethereum protocol that is more scalable and efficient. Polygon launched its zkEVM mainnet beta earlier this week, with techniques to open-source the technology to spur further development.