Ethereum’s Quest for Rollup-Centric Scalability
While this year’s alpha narrative has been about L2s, rollups and staking, Ethereum continues its quest for scalability. This is a visual tweet of Ethereum’s roadmap from Vitalik himself:
‘The Merge’ was the first step in Ethereum’s goal to achieve the Trifecta of security, scalability and decentralisation. Still, there is also a long way to go with the arrival of zkEVMs and L2 network volume courtesy of rollups. Rollups present many technical challenges, especially regarding blockspace and processing larger ‘batch transaction throughput’ from Layer2 rollup networks such as Arbitrum, Optimum and Polygon. The next stop on Ethereum’s roadmap is ‘The Surge’ and the introduction of proto-danksharding, which aims to increase block size through the introduction of ‘blobs’. Yes, friends, it's time for data ‘blobs’.
The Surge: EIP-4844
Having completed the Shapella upgrade, Vitalik Buterin recently confirmed that Ethereum’s next hard fork is rumoured to take place sometime around the start of 2024. EIP-4844 upgrade is set to introduce ‘proto-danksharding’ alongside the next Ethereum fork, which is tipped to boost the scalability of Layer 2 rollups by up to 10x while paving the way for full sharding to be implemented.
Researchers say EIP-4844 will dramatically improve the scalability of Layer 2 rollups by replacing ‘call data’ with data 'blobs’, which are less block space-intensive for the network to process. The goal is to work towards 100,000 transactions per second to increase throughput across the network. Buterin described minimising transaction data as “the primary bottleneck” for scaling rollups and the best hope for the network to achieve true scalability.
Rollups have emerged as Ethereum’s leading Layer 2 scaling solution and are being implemented by Arbitrum, Optimism, and Polygon. They work by bundling together transactions executed on a low-cost Layer 2 network, which are then submitted in batches for validation on Ethereum’s base layer to reduce transaction fees significantly.
Historical data will also be deleted from the network after 30 days once EIP-4844 takes effect. “The purpose of the Ethereum consensus protocol is not to guarantee storage of all historical data forever,” wrote Buterin. “Rather, the purpose is to provide a highly secure real-time bulletin board and leave room for other decentralised protocols to do longer-term storage.”
Build to sharding
Proto-danksharding gets its name from Dankrad Feist of the Ethereum Foundation. Feist designed danksharding, the current version of sharding slated to be introduced as part of Ethereum’s scaling roadmap. Proto-danksharding is the first of Ethereum’s two-part process to introduce full sharding. Proto-danksharding will create a different transaction type that can hold cheaper data in large fixed-size ‘blobs’, limiting how many ‘blobs’ can be included per block. These blobs are not accessible from the EVM (only commitments to the blobs are), and the blobs are stored by the consensus layer (beacon chain) instead of the execution layer.
Instead of providing more space for transactions, Ethereum sharding will provide more space for blobs. Ethereum protocol does not attempt to interpret data. Verifying a blob requires checking that it is available - it can be downloaded from its network. The data space in these blobs is expected to be used by layer-2 rollup protocols that support high-throughput transactions.
Proto-danksharding will implement most of the infrastructure for sharding before the network becomes fully sharded. This will include the transaction formats, verifications rules, consensus and execution logic, and gas price adjustments in the Danksharding specifications. The main innovation of danksharding will be the merged fee market: instead of there being a fixed number of shards that each have distinct blocks and distinct block proposers, in Danksharding, there is only one proposer that chooses all transactions and all data that go into that slot.
Danksharding is also tipped to improve Ethereum’s scalability once implemented in two to three years. Each validator will only have to download a small portion of the block, increasing block size and throughput by roughly 100 times for rollups compared to today.
No data storage, please
The removal of the need to store historical data is one of the key features of EIP-4844 that will increase rollups' scalability. By their nature, rollups generate a lot of data they need to post back to L1, and proto-danksharding provides them with a cheaper way to do this. This design is especially well-suited for rollups because they don’t need permanent storage but rather a strong guarantee that the data has been available on the Ethereum network for a specific time.
Buterin said that erasing historical data only poses risks to individual applications, not the Ethereum protocol itself. “It makes sense for applications to take on the burden of storing data relevant to themselves,” he said. “Block explorers, API providers, and other data services will likely store the full history.”
Buterin also praised Ethereum’s Layer 2 teams for their progress over the past 12 months, noting the launch of zkEVMs from Polygon and Matter Labs and the impressive growth of Arbitrum and Optimism. Buterin also had a shoutout for Polygon, the only zkEVM to receive his seal of approval for the level of work they have done this year.
Ethereum’s current roadmap is banking on the network’s burgeoning Layer2 ecosystems to handle scalability and fee mitigation until danksharding is implemented further down the roadmap. Full-scale sharding will split Ethereum’s computational load across an ecosystem of small chains working in parallel with Layer2 chains, which are expected to become the network’s shards in future. It will be interesting to see if Ethereum can handle increased transaction volume and size simultaneously and maintain its transaction speed with sharding.
CeAnn Simpson
