Author: Alec Chen
Source: Volt Capital
Source: @milesdeutscher
Foreword
Ethereum’s “The Merge” to the proof-of-stake network is scheduled to go live on mainnet by the end of September. Its goal is to unlock blockchain accessibility at scale. At its core, the merger transformed Ethereum from a Bitcoin-style proof-of-work consensus mechanism to a proof-of-stake system. Ethereum’s roadmap from implementing sharding to being Rollup-centric is a critical step in scaling the blockchain for the next billion users. Data availability and sharding in a modular architecture allow blockchains to scale throughput without sacrificing decentralization. This article will dive into the technical details of the merger (Ethereum’s new roadmap), and what the change means for users and developers.
Source: @ptrwtts
Originally, the plan for Ethereum 2.0 (the now-deprecated term) was to achieve scalability by dividing the mainnet into 64 shards, each with individual miners/validators. Then, based on congestion, utilization, and throughput, users will send transactions that are routed to specific shards. Due to the rise and adoption of rollups, and the complexity of implementing sharding, the scalability roadmap that initially centered on sharding has been abandoned in favor of data sharding. The Ethereum team now believes that Ethereum will scale to meet the needs of the world through rollups, and that the combined Ethereum plan is to be a strong settlement and data availability layer from which rollups derive their security.
Source: ETH2 Book
Contrary to popular belief, the purpose of the merger is not to reduce transaction costs, but to transform Ethereum into a powerful underlying infrastructure layer for rollups. The first core step towards this goal is the Beacon Chain. This transformed Ethereum from its previous proof-of-work system to a proof-of-stake system, where stakeholders had to submit collateral to produce blocks, and dishonest participants had their collateral slashed. Moving the consensus system to proof-of-stake introduces validating committees as a foundation, which in turn strengthens network consensus and paves the way for an efficient data availability layer within the protocol. The beacon chain guides and coordinates a network of stakeholders without processing or executing transactions like Ethereum does today. More specifically, what the merger does is merge the old Ethereum execution layer with the new consensus engine provided by the beacon chain, which will utilize the current algorithm of proof-of-work miners in exchange for a coordinated network of proof-of-stake validators. Switching the consensus algorithm also lays the groundwork for sharding: previously, in proof-of-work mining, there was no miner registry and miners could arbitrarily cease their duties and leave the network. Under proof-of-stake, the beacon chain now has a registry of all approved block producers and can coordinate and parallelize validator votes.
Source: ETH2 Book
Groups of validators, committees, are a key innovation offered by the beacon chain. The beacon chain randomly assigns committees to vote on blocks to form a consensus. The committee's combined vote is called "attestation", and by checking the committee's vote, the state of the beacon chain can be easily verified, minimizing block size and data growth compared to a single validator's verification. The certification committee also strengthens consensus, since in this model a relatively large number of validators are required to co-create the fork. In addition, the set of validators changes periodically, making it difficult for malicious validators to collude in time to carry out attacks.
Source: Flashbots
After the merger, Ethereum will implement a proposer-builder separation for the consensus layer. Vitalik believes that the endgame of all blockchains is to have centralized block production and decentralized block verification. Since the fragmented Ethereum block data is very dense, the centralization of block production is necessary due to the high requirements for data availability. At the same time, there must be a way to maintain a decentralized set of validators that validate blocks and perform data availability sampling.
The new builder role builds blocks of Ethereum execution payloads using user transactions and submits them with bids from proposers (a randomly selected subset of the validator set). Once the proposer accepts the payload, they sign the block and propagate it through the network. This structure eliminates the possibility of front-running transactions by validators since the payload sent to the proposer is stripped of the transaction content. In an efficient market, the introduction of a block space market would also incentivize builders to bid for the full value of extracted MEV, allowing a decentralized set of validators to receive the majority of MEV rewards. This setup prevents potentially unstable consensus among miners and mitigates harmful MEV compared to emulating Ethereum.
While the proposal-builder separation was originally designed to counteract MEV’s harmful externalities and centralization forces, the Ethereum core team realized that it could also serve the purpose of data sharding.
Danksharding is named after core contributor Dankrad Feist, and its main innovation is a merged fee market - instead of a fixed number of shards with different blocks and proposers, one proposer chooses all transactions and data. A proposer is a randomly selected committee of validators who subsequently perform data availability sampling on the blockchain data. This ensures a decentralized way to maintain data availability for light clients, since merged blocks are too large to be verified by a single point of verification. Since consensus nodes are also performing data availability sampling, this model unifies the settlement layer, consensus layer, and data availability layer.
Unified Settlement and Data Availability Layer Utilization of validity proofs unlocks an exciting feature for rollups: ZK rollups will now be able to make synchronous calls with the execution layer on Ethereum. This enhances new L2 primitives such as distributed liquidity and fractal scaling, laying the foundation for building innovative next-generation dapps on ZK rollups.
While danksharding bodes well for the future of Ethereum, it won't be fully available immediately after the merger. Proto-dank sharding (EIP-4844) is the original version of danksharding planned for release before it is fully implemented. The proposal creates a primitive called a carry blob transaction. As the name implies, a transaction with a blob is a transaction that carries a data payload called a blob. Blobs are the data standard for post-sharded Ethereum: they are bundled with KZG polynomial commitments and are more efficient than the calldata format due to decoupling from EVM execution. Currently, rollup uses calldata to send transaction data back to Ethereum, resulting in high gas costs. In the future of sharding, rollup will use blobs, saving users gas costs associated with EVM execution. The goal of Proto-danksharding is to provide developers with this forward-looking data format, while providing temporary relief from the expensive rollup of calldata by introducing a separate format and fee market for data to be sharded. Although proto-danksharding itself does not actually implement sharding, introducing standardized specifications for post-sharding data formats is the first step in building an efficient native data availability layer.
The Ethereum state and its storage is also a consideration. The ever-increasing state could potentially affect decentralization, since validators must be able to perform their tasks on consumer hardware. Proto-danksharding blobs are decoupled from the EVM execution layer and will be deleted after about a month. Additionally, EIP-4444 allows clients to delete and stop serving historical data on the peer-to-peer layer after about a year. Enforcing some type of mandatory history expiration at the protocol level is necessary anyway, since sharding will add about 40 TB of historical blob data per year. The blockchain state needs to be stored on RAM or SSD. However, historical storage, the data that Ethereum has reached consensus on, can be stored on cheap HDDs. Since historical storage operates on an honest minority (1/N) trust model, there is no need to store historical data on nodes performing real-time consensus. The Danksharding specification ensures that validators store and guarantee the availability of the data they reach consensus over a period of months. These pruned histories are then stored by third parties such as application-specific protocols, BitTorrent, portal networks, block explorers, individual amateurs, or indexing protocols.
Source: Consensys
Stateless Ethereum is another goal on the roadmap. Block producers who construct a block will utilize a witness, which is evidence consisting of relevant data required to execute the transactions contained in the block. Therefore, the client uses this witness to verify the state root produced by executing a block, and only needs to execute the part of the affected state, rather than the entire state. Two major hurdles to this design are witness scale and witness availability. The first problem can be solved by changing the state data structure in Ethereum from Merkle Patricia Tries to Verkle Tries, which is a more efficient data structure for the polynomial commitments used after the Ethereum merger. The second problem can be addressed by making block witnesses a protocol-level specification. Following Vitalik's conclusions in Endgame, relying on centralized block producers with specialized hardware while maintaining decentralized validation is a key design framework for scaling Ethereum.
Summary
Danksharding enhances rollup with security inherited from Ethereum. Upgrading the underlying infrastructure by tightly coupling data availability with the consensus and settlement layers allows rollups to leverage native data availability solutions, abandoning the security assumptions of validation and volition. This paves the way for architectures like enshrined rollups, which remove governance and smart contract risks by allowing the entire rollup to be deployed within the protocol. Rollup using SNARK for intra-protocol synchronous calls has become a promising design for future blockchain expansion. In-protocol rollup has many benefits: now the fixed gas cost per block faced by smart contract rollup is eliminated, when computation and consensus are decoupled, verifiers need to re-execute transactions to verify a block, and there is no State clients no longer need to download witnesses, as state differences are now guaranteed via the properties of validity proofs. These advantages include lower settlement latency, better synchronization, higher validator bandwidth (and thus higher EVM gas limit), and more secure cross-chain bridging. The Ethereum Foundation is currently working on implementing this design directly into Ethereum's roadmap, and plans to upgrade the EVM to a SNARK-compatible enshrined rollup.
The main goal of the Ethereum roadmap is to minimize trust assumptions and provide in-protocol scalability by implementing native solutions. Ethereum's base layer hosts an entire ecosystem of decentralized applications that promises to fundamentally change the way we think about identity, storage, search, reputation, and privacy in the digital age. Upgrading Ethereum to a base layer also elevates this application layer, benefiting users and developers by providing a highly secure, robust infrastructure to scale these use cases globally. Ethereum's vision is a digital future on a global scale. Its adherence to the principles of trusted neutrality, along with Ethereum’s network effects, decentralization, and security, firmly cements its role in the decentralized web of the future. The merger is the first step towards realizing this vision for Ethereum.