Buterin stated in a blog post that despite the network’s popularity and the presence of users, it is challenging to verify mainnet transactions. As a result of these obstacles, only some individuals can run their own nodes and must instead rely on trusted third parties, such as light clients. Although lightweight clients are necessary, the co-founder argues that it is difficult to determine whether a certain Ethereum validator adheres to established protocol requirements.
Buterin presents two ways to overcome layer-1 verification challenges on-chain while enhancing scalability to handle these issues.
Tackling On-Chain Verification Problems
In the first approach, he recommends limiting the mainnet and forcing activity to layer 2. This would necessitate decreasing the mainnet gas-per-block target from 15 million to 1 million, with layer-1 primarily testing layer-2 protocols.
There may be problems with this potential remedy, notwithstanding the possibility of its success. First, it would render many present L1-based products economically unfeasible, and user funds could become stagnant due to exorbitant costs. Migration on a large scale to a layer-2 project is feasible but would further complicate the process.
The co-founder emphasizes that, ideally, the Ethereum protocol should be simple to verify on several platforms, including laptops, smartphones, and browser extensions. Individually synchronizing the data on-chain for the first time or after a long period offline could take up to 54 seconds. This could be taxing on the device’s browser or cause quick battery depletion in 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 may be used to verify the execution of an Ethereum Virtual Machine (EVM) block.
Under this approach, additional SNARK code would be built to validate the consensus side of a block. In order to generate proofs in real-time, however, considerable hardware or architectural enhancements would be required.
If this option is used, a kind of zkEVM must be selected for verification. A single zkEVM, a closed multi-zkEVM, and an open multi-zkEVM are available.
Buterin believes that the open multi-zkEVM option is the best way, despite the fact that each alternative has pros and cons. Several clients would implement zkEVM differently, and each client would wait for compatible proof before acknowledging a block as valid.
Although ideal, there will be impediments. Clearly, Ethereum’s efficiency and parallelization would need to be vastly improved. Yet, he feels this option can be explored and feasible due to technical advances.
Enhancing Ethereum’s Scalability And Accessibility
Buterin’s ideas are a step in the right way to tackling the on-chain verification challenge. While the offered methods have flaws, they highlight the need for an Ethereum protocol that is more scalable and efficient.
This proposal was made when Polygon released its zkEVM mainnet beta at the beginning of this week with the intention of open-source the technology in order to inspire additional innovation.