This report details Ethereum’s recently-revised roadmap post PoS transition, covering The Merge, The Surge, The Scourge, The Verge, The Purge, and The Splurge outlined by Vitalik Buterin.
Ethereum’s Roadmap
While perhaps the most prominent upgrade in blockchain history, Ethereum’s transition to proof-of-stake was just one of many important technical upgrades designed to enhance Ethereum’s scalability, decentralization, and/or security. Recently, Vitalik Buterin released an updated diagram of Ethereum’s roadmap, breaking it into six categories: The Merge, The Surge, The Scourge, The Verge, The Purge, and The Splurge, illustrated in the exhibit below. Importantly, the exhibit reads from left to right, and developers are working on components of each category simultaneously. This series of upgrades was historically referred to as the Ethereum 2.0 roadmap until a rebranding earlier this year, yet the roadmap is still colloquially referred to as Ethereum 2.0 by many in the community. Part one of this report, which this post builds on and is recommended to be read first, covers the first portion of The Merge upgrade phase, namely the launch of the Beacon Chain and its technical underpinnings, as well as The Merge itself, where Ethereum mainnet transitioned its consensus mechanism from proof-of-work to proof-of-stake. In what follows, we dive into each category of upgrades outlined in Ethereum’s roadmap and cover key initiatives within each.
Exhibit 1: Ethereum’s Roadmap
Source: Vitalik Buterin as of November 2022. The graphic reads from left to right from a time perspective, but developments in each category are occurring simultaneously. Lastly, note that certain elements of Ethereum are not quantum-resistant (ECDSA, BLS Signatures, KZG Commitments), but the long-term roadmap will replace these vulnerable components with quantum-resistant replacements. This is a common long-term theme that we will not necessarily cover in each section for the sake of brevity.
The Merge
Though the most prominent portions of The Merge phase are behind us with the transition to proof-of-stake, there remain several important upgrades in this category ahead. Particularly topical are Beacon Chain withdrawals (EIP-4895), as all ETH staked into the Beacon Chain since its launch in late 2020 remains illiquid. Staked ETH withdrawals will be enabled in the Shanghai hard fork targeting March 2023. After withdrawals are enabled, validator account balances, which consist of their initial stake and consensus layer rewards accrued from attestations and block proposals, will become liquid. Conversely, rewards generated via transaction fees and MEV on the execution layer are already accessible today as they accrue outside the validator account balance.
The rollout of Distributed Validator Technology (DVT) is another important component of The Merge phase. DVT is a step toward decentralizing Ethereum’s validator network, and it’s expected to make validators more performant while decreasing risks as it essentially transitions Ethereum staking from “don’t be evil” to “can’t be evil”. As covered in the first part of this series, Ethereum validators are responsible for attesting to their view of the chain, including signing attestations and block proposals, among other items. Each validator instance has a validator key pair used to sign proposals and attestations, and the corresponding rewards generated depend on the correct and timely execution of these responsibilities. DVT can be viewed as a multi-signature scheme for consensus votes, sharding the validator key under a threshold signature scheme to achieve superior fault tolerance. For example, a three-of-four scheme can still deliver an accurate and timely attestation even when one signer fails to attest, mitigating the penalties from going offline and increasing the validator’s resilience more broadly. Additionally, given that no participant has the full validator key, the risk of slashing is mitigated relative to a traditional active-passive redundancy setup that could double sign if misconfigured. Already, large liquid staking providers like Lido and Stakewise, covered in detail in our applied Ethereum staking piece, have been early adopters testing DVT to improve their services. Lastly, DVT development is occurring outside of the Ethereum protocol, and companies like Obol Network are developing open-source middleware solutions for stakers to leverage on an opt-in basis.
Exhibit 2: Active-Passive Redundancy vs. DVT Active-Active Redundancy
Source: Obol Network, GSR. BN = Beacon Node. VC = Validator Client.
The left hand side illustrates a traditional active-passive redundancy setup. This setup loads one validator key into two validator clients on separate servers, one of which is online and actively signing attestations, while the other is an offline backup designed to toggle on if the primary server goes down. The validator risks being slashed if a misconfiguration results in both clients attesting simultaneously. Conversely, on the right hand side, DVT divides a single validator key amongst multiple operators in a three-of-four threshold scheme to come to consensus on what the validator should sign. No operator possesses the full signing key so slashing risk is mitigated. Additionally, it can still deliver an attestation even if one validator falls offline.
The left hand side illustrates a traditional active-passive redundancy setup. This setup loads one validator key into two validator clients on separate servers, one of which is online and actively signing attestations, while the other is an offline backup designed to toggle on if the primary server goes down. The validator risks being slashed if a misconfiguration results in both clients attesting simultaneously. Conversely, on the right hand side, DVT divides a single validator key amongst multiple operators in a three-of-four threshold scheme to come to consensus on what the validator should sign. No operator possesses the full signing key so slashing risk is mitigated. Additionally, it can still deliver an attestation even if one validator falls offline.
Single Secret Leader Elections (SSLE) are another upgrade in development. One issue with the current setup, where block proposers are assigned to each of the 32 slots and publicly revealed at the start of every epoch, is that it presents an attack surface for malicious actors to sequentially DDoS the publicly known block proposers in an attempt to freeze block production. Moreover, validators that propose a block following an empty slot can earn increased rewards by including attestations from two slots in their block, providing adverse incentives for a malicious validator to DDoS the proposer in the slot before them. In short, implementing an SSLE would mitigate these attack vectors and preserve the anonymity of each slot’s proposer until a block is proposed. Precise implementation details remain to be seen, but at a high level, the latest proposals use various validator shuffling mechanisms to preserve anonymity until the rightful proposer delivers a block[1].
Single-Slot Finality (SSF) is the most substantial upgrade outstanding in The Merge phase, and its implementation is likely years into the future. As implied in the name, SSF would decrease Ethereum’s finality time to a single slot from the 64 to 95 slots it takes to finalize today, but it requires a material revamping of Ethereum’s proof-of-stake underpinnings detailed in the first part of this series.
As a brief review, Ethereum currently employs a hybrid consensus protocol called Gasper that combines a practical Byzantine Fault Tolerant (pBFT)-inspired finality gadget known as Casper with the LMD Ghost fork-choice rule. This hybrid approach uses a fork-choice rule to advance the blockchain on a slot-by-slot basis, and the finality gadget finalizes these blocks about 15 minutes later through a system of checkpoint attestations of prior blocks. The hybrid consensus employed financially disincentivizes malicious actors from reorganizing finalized blocks, and while short-term forks can still occur, they are more infrequent than under proof-of-work Ethereum[2].
The initial parameterization of Ethereum’s Gasper consensus mechanism was a compromise between validator participation, time to finality, and node messaging requirements. Ethereum ideals aim to maximize validator participation while minimizing time to finality and node messaging requirements. However, given finality requires two-thirds of validator attestations, a mathematical relationship can be derived that illustrates a trilemma among these variables[3]. Ethereum favored decentralization in its design construction, requiring a relatively low 32 ETH staking minimum and modest node messaging requirements at the expense of finality extending to ~15 minutes[4].
Exhibit 3: Gasper Parameterization Trilemma Illustrated
Source: Upgrading Ethereum, GSR. The ‘X’ bubble represents Ben Edgington’s estimate of where Ethereum falls on this trilemma.
However, as outlined by Vitalik in his Path Towards Single-Slot Finality blog post, there have been two primary developments since Gasper’s initial parameterization. First, there are a few negatives resulting from the current construction. For example, the interaction between Casper and LMD Ghost is extremely complex, and several attack vectors have been and continue to be found that require complicated upgrades to fix. Additionally, Gasper’s ~15-minute finality results in a relatively poor user experience, and it cannot guarantee the prevention of short-term MEV reorgs, two drawbacks that traditional BFT consensus mechanisms like Tendermint mitigate by finalizing each block before producing the next. Second and more positively, improvements in BLS signature implementations now offer improved signature aggregation and validation capabilities, presenting a viable path toward processing hundreds of thousands of signatures in a single slot. Returning to the earlier trilemma, improvements in BLS signature aggregation should be able to transform a high load in messages-per-second terms into a medium load in data and CPU terms, creating the potential to achieve an improved compromise along this trilemma. As a result, SSF will be introduced to revamp the parameterization of Ethereum’s proof-of-stake implementation.
Prior to implementing SSF, three primary challenges need to be addressed, including developing the precise consensus algorithm, optimizing the signature aggregation processes, and determining the best approach to validator participation and economics. Vitalik’s blog delves into these questions in considerable detail, so we’ll merely summarize the current stance while reiterating that no formal proposals have been made and the design space remains open.
While Ethereum plans to move closer towards a traditional BFT consensus algorithm, it will still employ a hybrid approach to consensus as it prefers to favor liveness over safety (i.e., the chain doesn’t halt block production if one-third of validators go offline). The Ethereum blockchain today is regularly finalized up to a given epoch, and the blocks following this epoch are optimistic until reaching finality about 15 minutes after being proposed. Conversely, under SSF, Ethereum would be finalized through the tip of the chain in normal times, but unlike traditional BFT consensus, Ethereum would not halt if it failed to reach its two-thirds consensus threshold, and it would continue to produce blocks optimistically. To accomplish this, instead of running the finality gadget and the fork-choice rule simultaneously, a particular slot would leverage either the finality gadget or the fork-choice rule depending on the consensus level achieved. If the two-thirds consensus threshold is reached, the finality gadget will finalize the proposed block before the next slot’s proposal, but if consensus falls short of the two-thirds threshold, the fork-choice rule will move the chain forward optimistically. While this doesn’t remediate all the complex interactions between the finality mechanism and the fork-choice rule previously covered, it’s expected to mitigate them materially.
SSF also presents new optimization challenges with signature aggregation, as it will meaningfully expand the number of attestations required per slot. Currently, only ~1/32 of ETH validators attest in each slot, but SSF will increase this meaningfully as every validator will ideally begin attesting in every slot. Moreover, since reaching finality requires validators to vote in two rounds of attestations, achieving finality in a single slot will require all participating validators to attest twice in each slot, increasing validator attestations ~64-fold[5]. Lastly, depending on how the validator set develops in the years ahead, a scenario could emerge where the total validator count exceeds the number of signatures that can be feasibly aggregated and processed in a slot. Resultantly, new criteria would need to be developed to select the eligible validator set, whether through super-committees, capping validators and/or their balances and rotating them, or some other mechanism entirely[6]. Depending on the approach used, corresponding adjustments to staking economics may necessarily follow.
Exhibit 4: Single-Slot Finality Illustrated
Source: Justin Drake, Delphi, GSR. Justin Drake noted that SSF is being designed to support ~1M validators.
In short, the remaining upgrades categorized in The Merge phase predominantly strive to improve Ethereum’s implementation of proof-of-stake and enable staked ETH withdrawals. DVT will help decentralize Ethereum’s validator network while improving validator performance and reducing several of the risks currently faced. And SSLE aims to preserve the anonymity of proposers until they deliver a block, mitigating one prominent avenue for abuse. Lastly, SSF will materially reduce the time it takes for Ethereum transactions to achieve finality, reducing finality times down to a single slot from the 64 to 95 slots it takes today.
The Surge
Another major category of upgrades is The Surge, which refers to the set of upgrades commonly known as sharding that aims to scale Ethereum transaction throughput. In traditional database design, sharding is the process of partitioning a database horizontally to spread the load. And in earlier Ethereum roadmaps, it aimed to scale throughput on the base layer by splitting execution into 64 shard chains to support parallel computation, with each shard chain having its own validator set and state. However, as layer two (L2) scaling technologies developed, Vitalik Buterin proposed a rollup-centric scaling roadmap for Ethereum in October 2020 that materially altered Ethereum’s sharding plans. With rollups now a seminal component of the sharding roadmap, a brief introduction is in order.
Rollups are a type of L2 scaling solution that bundle together multiple transactions, executing them in batches off of Ethereum mainnet before posting back to mainnet a smaller amount of data sufficient to reconstruct the L2’s state[7]. Since a rollup’s state can be reconstructed from data posted on Ethereum mainnet, rollups inherit many of Ethereum’s security guarantees. The two primary rollup categories are Optimistic Rollups (ORU) and Zero-Knowledge Rollups (ZKR). At a high level, ORUs and ZKRs both periodically publish state roots to mainnet, but the two solutions leverage different approaches to ensure that the batched set of transactions were executed correctly and that the published state is accurate. ORUs rely on economic incentives, and the posted state root is optimistically assumed to be valid, but any user can verify the state root’s accuracy and initiate a challenge if the state transition was done incorrectly to earn a reward at the expense of the operator that submitted the incorrect state change. Conversely, ZKRs rely solely on advanced cryptography, posting a state root alongside a validity proof that cryptographically verifies that the state transitioned correctly, typically without revealing any underlying transaction information.
Rollups on mainnet today, however, do not inherit the full security guarantees of Ethereum and their continued progression towards decentralization and trust minimization formally sits in The Surge alongside sharding. For example, rollups today introduce many new trust and security assumptions beyond those of Ethereum, and existing rollups often rely on multisigs and have varying degrees of reliance on the fraud or validity proof schemes that more advanced implementations will be dependent on. Rollups further vary on contract upgradeability features, mechanisms available to force an exit, and paths to decentralization. As a result of the numerous distinctions between rollups today and their trustless future, Vitalik proposed a roadmap for rollups to remove their ‘training wheels’ and offered an early schema to categorize rollups along this roadmap.
Exhibit 5: Arbitrum Nitro’s Optimistic Rollup Flow Diagram
Source: Arbitrum, GSR. Note: The sequencer is the actor ordering transactions.
Ethereum’s transition to a rollup-centric roadmap simplified its path forward by deemphasizing scaling at the base layer and prioritizing data sharding over execution sharding. The updated roadmap aims to achieve network scalability by moving virtually all computation (i.e., execution) over to L2 while making it cheaper for data to be posted back to Ethereum mainnet. Simply put, computation is already very cheap on L2s, and the majority of L2 transaction fees today come from the cost of posting the computed data back to mainnet. Hence, improving mainnet’s ability to make data cheaply available will be the largest driver in decreasing L2 transaction costs. The updated roadmap retrenched the focus of Ethereum’s mainnet to consensus, settlement, and data availability, allowing L2 rollups to compete in the free market to provide execution.
Currently, rollups post their state roots back to Ethereum using calldata for storage. Calldata is the cheapest form of storage on Ethereum today, but it’s still expensive as the data goes through the Ethereum Virtual Machine (EVM) and is logged permanently in the blockchain’s history. While a full primer on rollups is beyond the scope of this piece, rollups do not need permanent data storage but instead only require that data is temporarily available for a short period of time. More precisely, they require data availability guarantees ensuring that data was made publicly available and not withheld or censored by a malicious actor. Hence, despite calldata being the cheapest data solution available today, it is not optimized for rollups or scalable enough for their data availability needs.
Ethereum’s current plan for sharding is known as Danksharding (DS). However, instituting full Danksharding is complex, leading the community to support an intermediate upgrade offering a subset of the DS features known as Proto-Danksharding (PDS; EIP-4844) to achieve meaningful scaling benefits more quickly. PDS introduces a new Ethereum transaction type called a Blob-carrying transaction which allows for data to be posted in ‘blobs.’ Blob-carrying transactions are like regular transactions, but they also include an extra data blob attached that allows the protocol to provide data availability guarantees without committing to store that data permanently. This new transaction type will materially increase the amount of data available for rollups to interpret since each blob, which is roughly 125 kB, is larger than an entire Ethereum block on average. Blobs are purely introduced for data availability purposes, and the EVM cannot access blob data, but it can prove its existence. The full blob content is propagated separately alongside a block as a sidecar. Blob transactions have their own independent, EIP-1559-style gas market, targeting eight blobs per block (~1 MB) up to a maximum of 16, with gas prices adjusting exponentially as the demand for blobs deviates from the target. This segregated fee market should yield efficiencies by separating the cost of data availability from the cost of execution, allowing the individual components to be priced independently based on their respective demand (i.e., an NFT mint on mainnet will not increase the price a rollup pays for data availability). Further, data blobs are expected to be pruned from nodes after a month or so, making them a great data solution for rollups without overburdening node operators with permanent bloat.
Despite PDS making progress in the DS roadmap, the name is perhaps a misnomer given each validator is still required to download every data blob to verify that they are indeed available, and actual data sharding will not occur until the introduction of DS. The PDS proposal is simply a step in the direction of the future DS implementation, and expectations are for PDS to be fully compatible with DS while increasing the current throughput of rollups by an order of magnitude. Rollups will be required to adjust to this new transaction type, but the forward compatibility will ensure another adjustment is not required once DS is ready to be implemented. PDS will be implemented in the fork after Shanghai that’s expected next fall.
While the implementation details of DS are not set in stone, the general idea is simple to understand: DS distributes the job of checking data availability amongst validators. To do so, DS uses a process known as data availability sampling, where it encodes shard data using erasure coding, extending the dataset in a way that mathematically guarantees the availability of the full data set as long as some fixed threshold of samples is available[8]. DS splits up data into blobs or shards, and every validator will be required to attest to the availability of their assigned shards of data once per epoch, splitting the load amongst them. As long as the majority of validators honestly attest to their data being available, there will be a sufficient number of samples available, and the original data can be reconstructed. In the longer run, private random sampling is expected to allow an individual to guarantee data availability on their own without any validator trust assumptions, but this is challenging to implement and is not expected to be included initially.
DS further plans to increase the number of target shards to 128, with a maximum of 256 shards per block, materially increasing the target blob storage per block from 1 MB to 16 MBs. While an increased block size isn’t an issue for nodes validating the network as they can verify the block efficiently with data availability sampling, it does represent a centralizing force for block builders that will need to compute the blob encoding and distribute the data. This increase in validator requirements would be detrimental to the diversity of the network, so an important upgrade from The Scourge, known as Proposer-Builder Separation (PBS), will need to be completed first. For those interested in a deeper understanding of the long-term DS roadmap, The Hitchhiker's Guide to Ethereum offers thorough coverage.
Exhibit 6: Danksharding
Source: Vitalik Buterin, GSR.
In summary, The Surge focuses on scaling and improving Ethereum’s transaction throughput. However, many still misconstrue sharding as scaling Ethereum execution at the base layer, which is no longer the medium-term objective. The sharding roadmap prioritizes making data availability cheaper and leaning into the computational strengths of rollups to achieve scalability on L2. Finally, note that many have highlighted DS as the upgrade that could invert the scalability trilemma as a highly decentralized validator set will allow for data to be sharded into smaller pieces while statistically preserving data availability guarantees, improving scalability without sacrificing security.
The Scourge
The Scourge is the set of upgrades focused on mitigating the centralizing effect of MEV while preserving credibly neutral (i.e., transparently objective and fair) transaction inclusion. Proposer-Builder Separation (PBS) is the most prominent upgrade in The Scourge, with roadmaps to DS and statelessness both requiring PBS as a prerequisite.
Before expanding on PBS, a brief introduction to block building and MEV is needed, with our previous report on MEV providing an overview and historical context for interested readers. In short, MEV or Maximal Extractible Value is a measure of profit that a miner or validator can extract from block production beyond the block reward and gas fees by including, excluding, and changing the order of transactions in a block. It’s commonly measured as the incremental gains achieved by deviating from a naive block-building approach that orders transactions based on priority fees. While validators are in a prime position to identify and capitalize on MEV, as they control which transactions are included and in what order, the majority of MEV is extracted by independent third parties called searchers that use sophisticated trading strategies to capture it. In practice, searchers identify and execute MEV extraction via bots that comb through the mempool and utilize various strategies such as DEX arbitrage, liquidations, and frontrunning / backrunning sandwich trades. However, the specialization necessary to compete for MEV extraction is an inherently centralizing force that is fundamentally incongruent with Ethereum’s ideals of making it as easy as possible to participate in network consensus.
As the name implies, PBS separates the roles and distinguishes between a block builder and a block proposer. The validator selected to propose the next block in the chain is known as the block proposer, and they outsource block construction (transaction selection and ordering) to a dedicated market of block builders. Under this model, specialized block builders search for MEV opportunities and/or receive them from trusted searchers. A block builder’s goal is to construct the most profitable block so they can submit the highest bid to the block proposer and have their block proposed to the network. Under this model, a proposer’s job becomes as simple as proposing the block provided by the builder that pays the highest bid. This eases the job of validators by selling the computationally difficult optimization problem to a more specialized entity and allows validators to fulfill their responsibilities with materially lower hardware specifications. Additionally, PBS should redistribute MEV profit to validators, as competition between builders to offer the highest bid to the proposer will erode builder margins and return most profit to the proposer[9]. Perhaps ironically, the PBS setup somewhat resembles the scale economies inherent in proof-of-work. Building a block that maximizes total profit is a difficult problem that’s best outsourced to specialized entities that benefit from economies of scale, but verifying the validity of this block remains very easy. This separation results in more centralized block building, but validation remains trustless and should be even more decentralized since block-building responsibilities are delegated elsewhere.
While the long-term plan is to enshrine PBS directly into Ethereum, PBS is only possible today on an opt-in basis by running third-party middleware from Flashbots known as MEV-Boost to enable outsourced block production. MEV-Boost separates proposers from builders, allowing proposers to generate incremental returns from MEV by outsourcing block production to a specialized builder. Moreover, MEV-Boost requires using a mutually-trusted relay to intermediate the transmission of block information between the proposer and the builder, ensuring that the proposer cannot steal MEV from the builder[10]. While relays have been generally performant, a non-performant relay could fail to deliver a block and cause a validator to miss their proposal, so this setup does embed trust. Lastly, MEV-Boost is commonly misconceived as censoring transactions on Ethereum, but this is not the case. MEV-Boost software allows proposers to outsource block production to specialized builders; it does not specify where blocks are outsourced, and validators can connect to any number of relays they choose to trust, including censoring and non-censoring relays (currently, OFAC-compliant and non-OFAC-compliant relays), selecting the block from whichever connected relay pays the highest bid.
Exhibit 7: Proposer-Builder Separation via MEV-Boost
Source: Flashbots, GSR.
As covered in part one of this report, censorship concerns have been a key area of focus since The Merge, as censoring relays quickly commanded a dominant market share. Fortunately, censorship resistance is a specifically categorized priority on the roadmap. In late November, Flashbots released a new MEV-Boost feature that allows validators to fall back and propose a locally-built block if outsourced builders fail to meet prespecified minimum bid criteria. This feature enables proposers to outsource block production and collect MEV if rewards are sufficiently high while preserving censorship resistance and proposing locally-built blocks when rewards are low. Additionally, given the incredibly high variance in MEV rewards per block, analysis suggests that a validator can locally build ~50% of blocks while only forgoing very modest MEV rewards (less than 0.01 ETH per block on average). While a helpful solution on the way to enshrined PBS, it’s short-term in nature as non-specialized validators may be unable to build blocks locally once upgrades designed with builder specialization in mind like DS are implemented.
Exhibit 8: MEV Per Block in ETH by Percentiles & Distribution Statistics
Source: Modeling the Profitability of the Rocket Pool Smoothing Pool, GSR. Note: MEV is proxied over 432,000 blocks from March 7, 2022 to May 14, 2022. Methodology details outlined further in the source.
One notable feature of enshrined PBS is that trusted relays will no longer be necessary as the Ethereum protocol will assume their place as the broker between proposers and builders. Once implemented, builders will send bids directly to proposers, and these bids will be binding even if they subsequently fail to deliver a valid block. While the specification details of in-protocol PBS still need to be determined, a two-slot approach that uses a commit-reveal scheme has gained the most traction. At a high level, builders send their bids and a block header to the proposer, a winning bid/header is then selected by the proposer, and a committee of attestors vouches for it before the builder reveals the block body. Additionally, multiple censorship-resistant designs are being discussed for enshrined PBS, such as whole block auctions with inclusion lists and partial block auctions. The idea behind the former is that a proposer would publish a censorship-resistance list (crList) to display their view of censored transactions in the mempool, and builders would be required to include the proposer’s listed transactions unless they deliver a full block. Since proposing a full block is expensive under EIP-1559, and costs grow exponentially when full blocks are proposed sequentially, censoring transactions on a crList quickly becomes prohibitively expensive[11]. Alternatively, partial block auctions function more similarly to MEV-Geth before The Merge, where both the proposer and the builder can include transactions in a given block[12].
There are a number of other focus areas within The Scourge after enshrining PBS. Finding ways to more equitably distribute MEV to mitigate its centralizing effects is one example. One proposal to do so is committee-driven MEV smoothing, which aims to make the distribution of MEV to validators as uniform as possible. Another proposal aims to burn MEV, accruing the value of MEV to all ETH holders instead of only ETH stakers, more akin to EIP-1559’s burn. The last major plan on the long-term roadmap is the distributed builder track. While many planned upgrades in Ethereum’s roadmap have accepted builder specialization in order to minimize the requirements on validators, it would still be beneficial to decentralize block building over the long run for numerous reasons[13]. The distributed builder track is far down the Ethereum roadmap, but at a high level, it aims to decrease the required specs to construct data blobs, provide strong pre-confirmation assurances that a transaction will be included in the next block, and minimize toxic MEV like sandwich attacks. However, it remains an open question if these latter two components will be implemented outside of Ethereum or enshrined in the protocol.
In summary, MEV is a centralizing force with harmful implications that The Scourge aims to mitigate. Extra-protocol implementations of PBS have largely isolated centralization concerns to block builders, but more guardrails are still necessary to preserve credibly neutral transaction inclusion. The short to mid-term focus is on developing censorship resistance mechanisms to protect credible neutrality, enshrining PBS, and determining the optimal way to redistribute MEV. Mitigating toxic forms of MEV and addressing builder centralization will be tackled later down the line.
The Verge
The Verge is a series of upgrades that aims to introduce statelessness, a feature that removes the requirement for validating nodes to maintain a copy of Ethereum’s state to validate transactions. Ethereum’s state is an extensive database encompassing all externally-owned accounts and their balances, smart contract deployments, and associated storage. In addition to its considerable size, Ethereum’s state is continuously growing as new users join the network and new contracts are deployed. Presently, all of the data in Ethereum’s state is hashed together and compressed into a Merkle-Patricia Tree. And in the current design, Ethereum nodes must store the state to validate blocks and ensure that the network transitions between states correctly. This growing storage requirement increases the hardware specifications to run a full node over time, which could have a centralizing effect on the validator set.
The permanence of state also causes an arguably incongruent construct where a user pays a one-time gas fee to send a transaction in exchange for an ongoing cost to the network via permanent node storage requirements. The Verge aims to alleviate the burden of state on the network by replacing the current Merkle-Patricia state tree with a Verkle Tree, a newer data structure invented in 2018. A vital property of both tree structures is that anyone can make a proof known as a ‘witness’ that some piece of information is an element of the tree, and anyone can easily verify this proof against the publicly available state root. However, Verkle proofs are much more efficient in proof size compared to Merkle proofs. Unlike a Merkle-Patricia Tree, which requires more hashes as the tree widens with more children, Verkle Trees use vector commitments that allow the tree width to expand without expanding the witness size. For a review of Merkle Trees, see How Bitcoin Works.
The transition to Verkle Trees will allow stateless clients to proliferate as smaller proof sizes make it feasible to directly include proofs into blocks. Instead of validators maintaining a local copy of Ethereum’s state, block builders will provide a Verkle proof giving the portions of the state impacted in a particular block, as well as the proof ensuring the accuracy of these pieces, allowing validators to verify blocks without maintaining Ethereum’s state. Stateless clients will enable fresh nodes to immediately validate blocks without ever syncing the state as they would simply request the required block information and proof from a peer. Ethereum aims for ‘weak statelessness,’ meaning validators can verify blocks without maintaining a copy of Ethereum’s state, but block builders will still need the state to construct a block. The assumptions underpinning ‘weak statelessness’ do not pose material concerns as block builders will be more specialized under PBS and will be able to manage any state growth.
On the longer-term path to Ethereum’s endgame, The Verge will leverage a more powerful proof technology in zk-SNARKs (SNARKs) to improve proof efficiency and simplify block verification even further. Additionally, SNARKs will be able to prove increasingly complex statements as specialized SNARK hardware is developed. Quantum-resistant zk-STARKs are expected to be the endgame, but proof generation times are viewed as a limiting factor today.
In short, The Verge aims to simplify block verification by leveraging more efficient proof techniques. The upgrades in The Verge will decrease the hardware requirements for validator nodes by introducing stateless clients that can verify blocks without downloading a local copy of Ethereum’s state, which requires an increasingly large amount of solid-state storage to maintain. Enabling nodes to validate the network primarily with RAM will improve Ethereum’s decentralization properties.
The Purge
The Purge refers to a series of upgrades aiming to simplify the protocol by reducing historical data storage and technical debt. Most prominently, it aims to introduce history expiration (EIP-4444), an upgrade requiring nodes to stop serving historical blocks on the peer-to-peer network that are more than one year old. Removing history data from Ethereum significantly reduces the hard disk requirements for node operators and allows for client simplification by removing the need for code that processes different versions of historical blocks. If desired, nodes can maintain these historical blocks locally, but once implemented, keeping this data is no longer required, and nodes can opt to prune it. Once a node is fully synced to the head of the chain, validators do not require historical data to verify incremental blocks. Hence, historical data is only used at the protocol level when an explicit request is made via JSON-RPC or when a peer attempts to sync the chain. After EIP-4444, new nodes will leverage a different syncing mechanism, like checkpoint sync, which will sync the chain from the most recently finalized checkpoint block instead of the genesis block.
The deletion of history data is a concern primarily for Ethereum-based applications that require historical transaction data to show information about past user behavior. History storage is seen as a problem best handled outside of the Ethereum protocol moving forward, but clients will still be able to import this data from external sources. It’s expected that applications will have multiple different solutions to obtain history data outside of Ethereum, including from block explorers like Etherscan, indexing providers such as The Graph, or a more decentralized, Ethereum Foundation-supported protocol like the Portal Network.
In addition to history expiration, The Purge[14] includes state expiry, which prunes state that has not changed in some defined amount of time, like one year, into a distinct tree structure and removes it from the Ethereum protocol. State expiry is one of the furthest away upgrades in the Ethereum roadmap and only becomes feasible after the introduction of Verkle Trees. Notably, expired state assets could always be retrieved by displaying a proof as long as some other party maintains a copy of the chain’s history elsewhere. While state expiry is not as essential as it may initially seem after stateless clients are implemented, it will still decrease the strain of dust accounts and other inactive addresses on Ethereum’s state.
The Splurge
The Splurge is a catch-all bucket for miscellaneous upgrades that don’t fit neatly into any of the previous categories. Account abstraction, endgame EIP-1559, and Verifiable Delay Functions (VDFs) are some of the more prominent upgrades in this segment[15].
Account abstraction is a particularly crucial upgrade, with EIP-4337 receiving the most traction. This proposal lets users employ smart contract wallets as their primary Ethereum account instead of an externally-owned account (EOA), and it does so by leveraging a higher-layer account abstraction approach that avoids any Ethereum protocol changes. Specifically, EIP-4337 creates a separate mempool consisting of a higher-order transaction-like object called a UserOperation. A special set of users known as bundlers would aggregate UserOperations into a transaction that would directly communicate with a particular smart contract, and that transaction would then be included in a block on mainnet.
Account abstraction brings about many benefits. First, it improves the user experience by atomically batching operations into a single transaction that would otherwise require multiple different mainnet transactions to execute. Further, it provides user flexibility to deviate from the ECDSA digital signature algorithm to employ arbitrary verification logic, such as a quantum-resistant signature scheme. It also simplifies the use of multisigs and social recovery wallets. Lastly, it introduces a form of gas abstraction where gas fees can be paid in ERC-20 tokens, and applications can subsidize the gas fees of their users. In the longer-term future, an additional EIP enabling the conversion of EOAs into smart contract wallets may be introduced. A mandatory conversion proposal may follow that would simplify the protocol by making all accounts smart contract wallets.
Exhibit 9: Account Abstraction - EIP-4337
Source: Vitalik Buterin, GSR.
Endgame EIP-1559 is an extension of the idea previously covered in The Surge that gas market efficiency can be improved by more granularly bifurcating the cost of the distinct resources that Ethereum transactions consume based on the supply and demand dynamics for each underlying resource. Currently, gas is a multidimensional resource based on numerous individual resources like EVM execution, transaction calldata, witness data, and others. Endgame EIP-1559 tackles the issues arising from the large divergence between the average and worst-case load for each of these individual resources. As noted in Vitalik’s multidimensional EIP-1559 proposal, transaction data plus calldata consumes only ~3% of an average block, but given EIP-1559’s elastic block sizes, a worst-case block would contain ~67x more data than an average block[16]. Endgame EIP-1559 aims to mitigate the magnitude of this potential divergence by pricing distinct resources independently, making it much more expensive for calldata or any individual resource to comprise such a substantial portion of a block.
Lastly, before introducing VDFs, understanding the importance of randomness in a proof-of-stake blockchain is required. Ethereum requires randomness to fairly assign block proposals and other committee assignments to validators. Randomness is provided today via the RANDAO value maintained in the beacon state. The RANDAO value accumulates randomness as each block proposer contributes a verifiably random contribution to it, namely, the BLS signature generated from their validator private key. The proposer’s signature can be verified against their public key, verifying the randomness of the proposer’s contribution to the RANDAO. However, since the RANDAO isn’t updated when a block proposal is skipped and future validator assignments are dependent on the RANDAO value at the end of each epoch, validators in the last slot of an epoch can bias the calculation at the cost of skipping their block proposal and foregoing associated rewards. For example, the proposer in the last slot of an epoch can determine future validator roles under both scenarios when they propose and when they skip their proposal, selecting whichever decision is more favorable to them on an aggregate basis[17]. While this abuse has a slim chance of profitability, Ethereum still plans to introduce unbiasable randomness via VDFs in its long-term roadmap.
VDFs employ specialized hardware to solve a series of sequential computations that are non-parallelizable, each taking a certain amount of time to compute, known as the delay, and once computed, they can be easily verified without specialized hardware. This may spark some parallels to proof-of-work, but unlike the probabilistic nature of proof-of-work, VDFs verifiably show that a known amount of time was spent computing a result. At a high level, the idea underpinning VDFs is that if you can build specialized hardware capable of computing a particular calculation within some close threshold of the theoretical peak efficiency, you can then assess the minimum amount of time it would take anyone to solve it[18]. Combining RANDAO contributions with VDFs would force a proposer to decide between proposing a block or skipping their proposal before they can computationally verify the impact on RANDAO, removing the potential for bias. Beyond this, VDFs provide Ethereum with a purer source of randomness that may be necessary to develop particular applications in the future. The Ethereum Foundation is expecting VDF ASIC samples to arrive in January 2023.
Conclusion
While Ethereum's transition from proof-of-work to proof-of-stake was a crowning achievement, Ethereum's work is far from finished, with Vitalik himself estimating the network is still only 55% complete after the upgrade. Despite this, Ethereum is equipped with a thoughtful and well-defined roadmap, and its developers are hard at work perfecting the various upgrades to bring about their many benefits. Single-Slot Finality will materially enhance Ethereum's implementation of proof-of-stake, improving user experience with decreased finality times. Through Danksharding, with its data blobs and data availability sampling, The Surge will make data availability cheaper and distribute the job of checking data availability amongst nodes, providing material scalability benefits on L2. The Scourge will add Proposer-Builder Separation to mitigate the centralizing impact of MEV and redistribute MEV income while ensuring credibly neutral transaction inclusion. The Verge will achieve statelessness by implementing Verkle Trees and SNARKs later on, allowing stateless clients to easily verify blocks without maintaining a local copy of Ethereum's state. The Purge will introduce history expiration and state expiry, archiving history data, pruning untouched state, and generally simplifying the protocol. And The Splurge will introduce account abstraction, increasing wallet choice/functionality and improving user experience, alongside more efficient gas markets and unbiasable randomness. In the end, Ethereum is expected to process ~100,000 transactions per second with vast improvements in its already leading security and decentralization, enabling mass adoption and achieving Ethereum's initial goal of creating a trustless and permissionless world settlement layer for a diverse suite of dapps and beyond.
Footnotes:
2. Technically forks can still occur in the long run since Ethereum achieves economic finality instead of absolute finality, but reverting a finalized block would cost billions of dollars via slashing, hence the term economic finality. See economic finality in part one of this series for a further explanation. See here for reorg analysis across consensus mechanisms.
3. V ≤ F*M/2. V is the cap on the number of validators, F is the time to finality in seconds, and M is the messaging requirements per second placed on full nodes. The equation states that the number of validators must be less than or equal to the product of time to finality and messaging requirements divided by two. This formula applies to monolithic blockchains where every node is responsible for processing every transaction. As Ben Edgington notes, this equation is not as straightforward as it may seem, as there’s a relationship between V and M. For example, if the 32 ETH validator requirement was decreased to incentivize higher V, M would likely increase as a larger populous becomes able to participate, so more attestations would be expected.
4. Ethereum’s hybrid consensus approach is notably distinct from many BFT consensus mechanisms, like Tendermint, that offer near-instantaneous finality with a relatively small number of validators. For context, Ethereum has ~475,000 validators today, and while 32 ETH may not seem like a modestly sized investment, initial proposals required 1,500 ETH minimums to stake and would’ve required capping the total number of active validators at ~900.
5. It’s expected that slots may need to be lengthened to 16 seconds or so to implement SSF, with each validator attesting once in each of the two 8-second sub-slots within a slot. Hence, the number of slots to finality will decrease 32-fold, but the actual time to finality will decrease by a lesser amount if slots times increase in length by ~33%. See exhibit 4 for an illustration of the two-vote process (justification and finality).
6. One mitigant to this cap is that SSF would allow the 32 ETH effective balance cap placed on validators to be removed or meaningfully increased. Large stakers could then elect to consolidate their stake amongst fewer validator instances, which is one partial mitigant to the increased number of attestations required per slot under SSF. This increase would have other positive egalitarian effects on the economics of staking as well. Assuming withdrawals are enabled and effective balances are capped at 32 ETH, then large validators are able to compound their stake while small validators cannot. Further, assume that staking earns 7% per year, ETH is staked for ten years, and validators rebalance annually if they’ve generated the 32 ETH necessary to launch a new validator instance. Comparing the hypothetical performance of a large staker that starts with 100 validators to an individual that starts with one validator, the large validator outperforms by ~25% over the period, or ~1.5% per year.
7. ORU post compressed L2 transaction data alongside an L2 state root to L1, allowing anyone to check and verify accurate state transitions. Conversely, instead of posting L2 transaction data to L1, ZKRs typically post state differences (i.e., the net change from all the transactions), as well as a validity proof to verify that the state transitioned correctly. This statement isn't universally true for ZKRs, however, as some ZKRs like Scroll are being built to post compressed transaction data instead of state differences.
8. It also requires KZG Polynomial Commitments to prove that the original data was encoded correctly. KZG is beyond the scope of this report and is covered thoroughly here. The last step of The Surge phase is a transition away from KZG to a different commitment scheme that is quantum resistant and does not require a trusted setup. In our opinion, the latter of which is primarily an upgrade of elegance, and it isn’t a practical concern. KZG’s trusted setup has a 1 of n trust assumption, meaning that it only requires a single good actor in the total set of participants involved in the ceremony to preserve the integrity of the setup. You can be that person in Ethereum, learn how to participate here! Vitalik covers trusted setups more thoroughly here.
9. Developing a market to attract multiple builders is particularly important as MEV may be harvested and monetized primarily by builders if they are not competing to win proposals. Builder centralization also poses risks to credibly neutral transaction inclusion, which Ethereum plans to address with crLists. Flashbots’ SUAVE white paper elegantly describes many of the concerns with builder centralization. In summary, the existence of scale economies stemming from exclusive order flow (i.e., payment for flow) and cross-chain MEV suggests that builder diversity is not guaranteed and it’s something that must be actively protected.
10. MEV-Boost is a whole block auction, and unlike MEV-Geth in PoW Ethereum, the proposing validator cannot append additional transactions to the end of the outsourced block currently. This is one of the key censorship concerns with MEV-Boost. In PoW Ethereum, only a few mining pools controlled block construction, so pools and searchers could form trusted relationships directly, and if a mining pool stole a searcher's MEV, the searcher would just end the relationship. After The Merge, however, a much broader set of ~450k validators control transaction ordering, so mutually trusted relays need to be introduced since builders cannot form trusted relationships with so many proposers. Currently, the builder sends a full block to the trusted relay, but the proposer only receives a header and must commit (sign) the header before the full block is revealed, so under this model additional transactions cannot be appended.
11. Proposing a full block increases the base fee by 12.5%, so fees would increase by ~18x [1.12525-1] if full blocks were proposed for five minutes straight (25 blocks).
12. See footnote 10.
13. See footnote 9.
14. In addition to history and state expiry, The Purge features numerous smaller technical EVM upgrades that we omitted. For coverage of the EVM simplification track, LOG reforms, and serialization harmonization, see here.
15. The Splurge also features numerous technical EVM upgrades that we omitted. See here for coverage of the EVM improvement track.
16. EIP-1559 elastic block sizes target 15m gas with a hard cap at 30m gas. Noting the 3% average and factoring in the 2x multiple on a 30m gas block, a worst-case block contains ~67x more data than an average block.
17. Note the amount of bias that can be introduced into RANDAO scales when an attacker controls multiple validators with sequential block proposals at the end of an epoch. In fact, if an attacker has ‘k’ sequential proposals to close an epoch, they can decide amongst 2k distinct RANDAO values. Detailed dives into the math and abuse potential can be found here and here. The summary is that the potential for profitable abuse is very limited in this instance.
18. Unlike proof-of-work mining, VDFs only require one sufficiently powerful application-specific integrated circuit (ASIC) to service the entire Ethereum network. We’ve covered ASICs in prior reports on Bitcoin mining infrastructure, and the ASIC development process is notably long and expensive. The VDF Alliance was formed in early 2019, in partnership with the Ethereum Foundation and others, to build an ASIC optimized for computing a VDF.
Authors:
The authors would like to thank Justin Drake, Ben Edgington, Toghrul Maharramov, and Collin Myers for answering questions and providing many helpful comments.
Sources:
Ethereum.org, All Core Devs Update, ETH Roadmap FAQ - Tim Beiko, Validator FAQ, Endgame - Vitalik Buterin & Bankless, Endgame - Vitalik Buterin, The Ethereum Merge - Tim Beiko & Epicenter, The Hitchhiker’s Guide to Ethereum - Delphi Digital, Upgrading Ethereum - Ben Edgington, Ethereum 2.0 Knowledge Base, Combining Ghost & Casper, Parameterizing Casper - Vitalik Buterin, Ethereum Annotated Roadmap - Domothy, EIP-4895 - Beacon Chain Withdrawals, Ethereum Reorgs After The Merge - Paradigm, What is Distributed Validator Technology - Obol Network, Whisk: A Practical Shuffle-based SSLE, Simplified SSLE, Path Towards Single-Slot Finality - Vitalik Buterin, A Rollup-centric Ethereum Roadmap - Vitalik Buterin, An Incomplete Guide To Rollups - Vitalik Buterin, The Complete Guide to Rollups - Delphi, Proposed Milestones For Rollups Taking Off Training Wheels - Vitalik Buterin, L2Beat, Danksharding - Dankrad Feist, Dive Into Danksharding - Ethereum Foundation & Bankless, Proto-Danksharding - Protolambda, EIP-4844 - Proto-Danksharding, EIP4844.com, Data Availability Sampling - Paradigm, Addressing Common Rollup Misconceptions - Polynya, Rollups + Data Shards - Polynya, Trusted Setups - Vitalik Buterin, Updates on Proposer-Builder Separation - Barnabe Monnot, Two-slot Proposer-Builder Seperation, Credible Neutrality - Vitalik Buterin, crList Proposal, The Future of MEV is Suave, Committee-driven MEV Smoothing, Burning MEV, A Theory of Ethereum State Size Management - Vitalik Buterin, Verkle Tree Integration - Vitalik Buterin, Verkle Trees - Vitalik Buterin, An Intro to zkSNARKs - Vitalik Buterin, EIP-4444 - History Expiration, EIP-4337 - Account Abstraction, EIP-1559 - Fee Market Change, Multidimensional EIP-1559 - Vitalik Buterin, Introduction to VDFs, VDF Alliance, Account Abstraction Roadmap - Vitalik Buterin, Modeling the Profitability of the Rocket Pool Smoothing Pool - Ken Smith
About GSR
GSR has nine years of deep crypto market expertise as a market maker, ecosystem partner, asset manager, and active, multi-stage investor. GSR sources and provides spot and non-linear liquidity in digital assets for token issuers, institutional investors, miners, and leading cryptocurrency exchanges. GSR employs over 300 people around the globe, and its trading technology is connected to 60 trading venues, including the world’s leading DEXs.
We have a culture of approaching complex problems with tenacity and imagination. We build long-term relationships by offering exceptional service, expertise and trading capabilities tailored to the specific needs of our clients.
Find out more at www.gsr.io.
Required Disclosures
This material is provided by GSR (the “Firm”) solely for informational purposes, is intended only for sophisticated, institutional investors and does not constitute an offer or commitment, a solicitation of an offer or commitment, or any advice or recommendation, to enter into or conclude any transaction (whether on the terms shown or otherwise), or to provide investment services in any state or country where such an offer or solicitation or provision would be illegal. The Firm is not and does not act as an advisor or fiduciary in providing this material.
This material is not a research report, and not subject to any of the independence and disclosure standards applicable to research reports prepared pursuant to FINRA or CFTC research rules. This material is not independent of the Firm’s proprietary interests, which may conflict with the interests of any counterparty of the Firm. The Firm trades instruments discussed in this material for its own account, may trade contrary to the views expressed in this material, and may have positions in other related instruments.
Information contained herein is based on sources considered to be reliable, but is not guaranteed to be accurate or complete. Any opinions or estimates expressed herein reflect a judgment made by the author(s) as of the date of publication, and are subject to change without notice. Trading and investing in digital assets involves significant risks including price volatility and illiquidity and may not be suitable for all investors. The Firm is not liable whatsoever for any direct or consequential loss arising from the use of this material. Copyright of this material belongs to GSR. Neither this material nor any copy thereof may be taken, reproduced or redistributed, directly or indirectly, without prior written permission of GSR.
This article contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of CoinMarketCap, and CoinMarketCap is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. CoinMarketCap is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by CoinMarketCap of the site or any association with its operators.
This article is intended to be used and must be used for informational purposes only. It is important to do your own research and analysis before making any material decisions related to any of the products or services described. This article is not intended as, and shall not be construed as, financial advice.
The views and opinions expressed in this article are the author’s [company’s] own and do not necessarily reflect those of CoinMarketCap.
