Ethereum, a smart contracting platform powering decentralized finance (DeFi), non-fungible token trading (NFT) and more, has a problem that cannot be solved by Layer 2 scaling platforms alone, its co-founder recently stated. Vitalik Buterin.
in a BlogButerin said that although the network is widely used and there are users, it is challenging to verify transactions from the main network. The challenges that arise from this mean that not many people are able to run their nodes and instead rely on trusted third parties, including thin clients. Although thin clients are essential, the co-founder notes that checking whether a particular Ethereum validator follows established protocol rules is challenging.
To address these issues, Buterin proposes two options to resolve on-chain layer 1 verification issues while improving scalability.
Address chain verification issues
In the first option, he suggests restricting the mainnet and forcing activity to layer 2. This would require reducing the mainnet’s gas per block target from 15 million to 1 million, with layer 1’s sole role being to verify protocols from layer 2.
While this solution might work, there can be glitches. First, it would make many existing L1-based applications financially unfeasible, and user funds could be stagnant due to overwhelmingly high fees. Bulk migration to a Tier 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. However, individual syncing of on-chain data for the first time, or after a long time offline, could take up to 54 seconds. This could be a task in the device browser or cause rapid battery drain for portable devices.
Another alternative option that Buterin proposes involves the Succinct Non-Interactive Knowledge Argument (SNARK): verifying the mainnet using a zero-knowledge Ethereum virtual machine (zkEVM), which can be used to verify the execution of the Ethereum virtual machine (EVM). of an Ethereum block.
(insert)https://www.youtube.com/watch?v=ta7h5O6NZ_Y(/insert)
In this approach, more SNARK code would be written to check the consensus side of a block. However, generating tests in real time would require significant improvements through specialized hardware or architectural improvements.
If this option is pursued, it would be necessary to choose a type of zkEVM to use for verification. There are three options: a single zkEVM, a closed multi-zkEVM and an open multi-zkEVM.
While each option has advantages and disadvantages, Buterin believes that the open multi-zkEVM option is the best path. This approach would imply that different clients have different zkEVM implementations, with each client waiting for a compatible proof before accepting a block as valid.
While ideal, it will not be without its challenges. What is clear is that it would require significant improvements in Ethereum’s efficiency and parallelization. However, he believes that this path can be explored and is practical due to technological advances.
Improving scalability and accessibility on Ethereum
Buterin’s proposals represent a step in the right direction to solve the verification chain problem. While the proposed solutions have weaknesses, they do highlight the need for a more scalable and efficient Ethereum protocol.
This proposal arose when Polygon thrown out its zkEVM mainnet beta earlier this week with plans to open source the technology to drive further development.
