Ethereum’s Updated Roadmap: A Guide to The Merge and Beyond

Extended Release – Updated December 23, 2022 ¹

After years of research and development, Ethereum successfully executed its Merge to proof-of-stake on September 15th. This report dives into Ethereum’s implementation of proof-of-stake, the execution of The Merge, and a post-mortem analysis of the transition. It subsequently covers Ethereum’s recently-revised roadmap, previewing future upgrades such as Single-Slot Finality, Sharding, Statelessness, and Proposer-Builder Separation.

A Brief Overview of Ethereum

First conceived in 2013 by Vitalik Buterin and launched in mid-2015, Ethereum revolutionized blockchain technology and cryptocurrencies forever by creating a world settlement layer or decentralized state machine. No longer were blockchains home to a single, siloed application such as ÍBitcoin or Namecoin, or were developers confined by a limited set of transaction types. The Ethereum network could process general-purpose code, known as smart contracts, adding programmability and arbitrary computation without needing to modify the underlying blockchain. Moreover, common smart contract standards and open-source code enabled applications to interact and build on each other, creating a composable programming environment. And all of this was made possible while still adhering to the central tenets of crypto and blockchain, allowing anyone to permissionlessly interact with code that the network executes in a trustless fashion. 

Soon, hundreds of developers began building decentralized applications (dapps) on Ethereum, leveraging smart contracts for a wide range of use cases that now span DeFi, NFTs, DAOs, and more. And despite inspiring the creation of many well-funded, competing smart contract blockchains, Ethereum still commands the largest developer base supporting its industry-leading ecosystem of dapps. This has resulted in over $25b of value locked in the network, and the second highest market cap in crypto, behind that of only bitcoin at ~$150b. 

Like Bitcoin, Ethereum was launched using a proof-of-work consensus mechanism, allowing the decentralized network of unknown parties to agree on which transactions should go into a block and onto the blockchain. And by requiring block producers to expend something of value – in this case, significant computational and energy resources – Ethereum prevented bad actors from attempting to execute a double spend by reverting a block from the blockchain via a malicious chain reorganization or reorg. Moreover, the odds that any individual miner solves the mining puzzle and receives the block reward/miner tips were proportional to the amount of work, or hashrate, contributed, encouraging and rewarding greater participation in the consensus process and further securing the network. 

Ethereum, however, had long planned a transition to proof-of-stake, where block producers, known as validators under proof-of-stake rather than miners under proof-of-work, run full nodes, bond or stake the protocol’s native token, propose blocks when chosen to do so, and attest to the validity of a particular proposer’s block when not selected. Validators are chosen at random to produce a block in proportion to their stake. Importantly, by requiring and choosing block producers based on stake, attempting to revert a finalized block in proof-of-stake is asymmetrically expensive and even more costly than reorging a block under proof-of-work. Validators receive staking rewards for the work they perform but may be forced to pay a small penalty if they perform their duties poorly or may even be slashed and removed from the network if they behave maliciously. Such a construct provides the network with the ever-important functions of consensus and security. 

Ethereum’s transition to proof-of-stake, known as The Merge, was a long and arduous one with years of delays. In fact, Ethereum’s difficulty bomb, a feature intended to incentivize the transition to proof-of-stake by exponentially increasing the difficulty of mining ETH under proof-of-work, was pushed back six times since its first implementation in 2015. Despite this, developers transitioned several testnets to proof-of-stake and tested the transition on many other shadow forks before successfully executing The Merge on Ethereum mainnet on September 15th. Now, proof-of-stake validators have assumed the network’s block production and security responsibilities, replacing the historical role of proof-of-work miners. 

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. 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.  In what follows, we first introduce Ethereum’s implementation of proof-of-stake on the Beacon Chain, dive into the execution of The Merge, and provide a post-mortem on the resulting real-time change in the consensus mechanism. We subsequently cover what lies ahead for Ethereum, diving into each category of upgrades outlined in the roadmap and the key initiatives within each.  

The Beacon Chain

Launched in December 2020 as the first concrete step in Ethereum’s transition to proof-of-stake, the Beacon Chain, also known as the consensus layer, was a distinct proof-of-stake blockchain that historically ran in parallel to Ethereum’s proof-of-work mainnet prior to the two being merged together. While the Beacon Chain did not process transactions before The Merge, as execution was taking place on mainnet, validators on the Beacon Chain worked to reach consensus on state and agreed on the active validator set and their corresponding account balances. While this may have seemed superficial at the time, when mainnet transactions relied on proof-of-work consensus, it helped battle-harden the Beacon Chain’s implementation of proof-of-stake. Additionally, implementing the Beacon Chain as a distinct blockchain allowed developers to safely test The Merge without imposing additional risk on everyday Ethereum users. Hence, the Beacon Chain was launched as an independent blockchain to eventually swap out Ethereum’s existing consensus mechanism while generally retaining the rest of Ethereum’s history and other functionality.

Nodes operating on Ethereum run open-source Ethereum software implementations known as clients. Prior to The Merge, nodes needed to run an execution layer (EL) client implementation, such as Geth or Erigon, while nodes on the Beacon Chain were required to run a different consensus layer (CL) client implementation, such as Prysm or Lighthouse. Additionally, since validator account balances on the Beacon Chain were credited by depositing 32 ETH into a smart contract on mainnet that temporarily functioned as a one-way bridge, Beacon Chain nodes were also required to watch the staking deposit contract on an EL client to be aware of any new validator instances or changes to validator account balances.

Ethereum’s Proof-of-Stake Detailed

Validators on Ethereum have several roles, including attesting to their view of the chain, proposing new blocks, and participating in sync committees that support light client functionality. Validators are frequently chosen to vote on their view of the chain head block, where the chain head block is the most recent block in that validator’s view of the canonical chain. Each vote is known as an attestation, and the attestation process relies heavily on time in the Beacon Chain, which is divided into periods lasting 6.4 minutes, known as epochs, that are further partitioned into 32 distinct slots, each lasting 12 seconds. Each slot has one designated block proposer that the protocol randomly selects to propose a block in that particular slot. Hence, new blocks come every 12 seconds unless a selected proposer fails to deliver a block leading to an empty slot, in which case the next block would be expected to arrive 24 seconds after the previous block. Every validator is placed on one beacon committee per epoch, and each beacon committee is randomly assigned to a particular slot and required to attest to their view of the chain head block during their assigned slot. Beacon committees are equally spread amongst the 32 slots in an epoch, resulting in ~1/32 of the total validator set attesting to the validity of each slot/block (assuming a block is proposed in each slot)². By dividing validators into beacon committees, the network cuts down on messaging requirements, allowing for individual attestations to be aggregated in parallel and gossiped at the committee level. In fact, each slot has multiple beacon committees, all attesting to the same information in that particular slot, so the number of aggregated attestations per slot will align with the number of committees per slot in an idealized example.³ Each beacon committee makes a single attestation per epoch before being disbanded and the process restarting anew in the next epoch. In addition, a small set of validators are also chosen at random to join sync committees (which are different from the aforementioned beacon committees), which pay additional rewards to validators and help light clients sync up and determine the head of the chain. Participating in a sync committee is particularly lucrative as such validators receive a reward for each slot, and the selection lasts for 256 epochs, or 8,192 slots before a new committee is selected.

Exhibit 1: Epochs, Slots, and Beacon Committees Illustrated

Source: Upgrading Ethereum, GSR. This graphic is generalized to show ‘N’ committees per slot. The number of committees per slot depends on the number of validators participating in consensus and this varied more earlier in the Beacon Chain’s history. Currently, there are 64 committees per slot. 

The Beacon Chain employs a proof-of-stake consensus protocol named Gasper, which the Ethereum team designed internally. Gasper combines the Casper FFG finality mechanism, a practical Byzantine Fault Tolerant (pBFT)-inspired finality gadget for the realization of proof-of-stake, with the LMD GHOST fork-choice rule, which at a high level selects the chain by choosing the branch with the most attestations.⁴ By doing so, Gasper combines the low overhead benefits that allow for a high number of participants to support decentralization seen in longest chain systems with the finality benefits of a pBFT-inspired system. In short, Gasper favors liveness over safety, continuing to produce blocks even if finality thresholds aren’t reached, which may result in a fork, but it always keeps the chain moving forward (liveness). Alternative approaches favoring safety like Tendermint will not allow for forks (safety), but they cease block production and halt when finality thresholds are not met. 

Gasper uses a system of checkpoint attestations of prior blocks, which requires a supermajority of attestation votes and increases the cost of reorganizing the blockchain prior to such checkpoints. Every epoch has one checkpoint, and that checkpoint is a hash identifying the latest block at the start of that epoch.⁵ Validators attest to their view of two checkpoints every epoch and also run the LMD GHOST fork-choice rule to attest to their view of the chain head block. The two checkpoint blocks are known as a source and a target, where the source is the earlier of the two checkpoint blocks. Generally speaking, the target checkpoint is the validator’s view of the block at the start of the current epoch, while the source checkpoint is their view of the most recent ‘justified’ checkpoint. Simply put, the most recent ‘justified’ checkpoint is the most recent checkpoint that received more than two-thirds of the stake weight voting for its inclusion in the canonical chain; typically, this will refer to the previous epoch’s checkpoint. If more than two-thirds of the total validator stake vote to link two adjacent checkpoint blocks, then there is a supermajority link between these checkpoints, and they both achieve an increased level of security. The target checkpoint becomes ‘justified,’ and the source checkpoint, which is already justified from a prior supermajority link, becomes ‘finalized.’ A checkpoint typically receives the necessary votes to become finalized after two epochs (i.e., finalization takes two rounds of voting), and once a checkpoint is finalized, all previous slots become finalized. Reversing a finalized block would require malicious action by two-thirds of the total validator stake, and resultantly, the protocol guarantees they would be slashed at least one-third of the total network stake.⁶ Assuming an ETH price of $1,300 and using the ~15.7m ETH locked in the deposit contract currently, reversing a finalized block would cost the attacker(s) more than $6.8b. This is referred to as economic finality – while a finalized Beacon Chain block can be reversed at a later date, unlike a protocol that achieves absolute finality such as Tendermint, it is impossible to do so without having a prohibitively large amount of stake slashed.

Exhibit 2: Gasper Checkpoint Blocks & Finality Illustrated

Source: Upgrading Ethereum, GSR. Note that the checkpoint block illustrated in the graphic represents the source checkpoint. The target checkpoint is unlabeled, and it would live in the forkful section of the illustration as it’s not finalized.

Gasper’s inclusion of an explicit finality mechanism helps deter reorg attempts by illuminating the cost to reorg a finalized block, which is notably distinct from existing proof-of-work chains that rely on probabilistic finality where an attacker’s ability and cost to reorganize the chain is probabilistic in nature. Additionally, proof-of-stake has an asymmetric cost advantage that should disincentivize chain reorgs even more so than proof-of-work. The cost to a miner of attempting a chain reorganization and failing under proof-of-work is the electricity cost of their hashrate and the opportunity cost of coins that could have been mined on the canonical chain. The proof-of-stake reorganization equivalent requires a malicious validator to front as much as two-thirds of the total Ethereum stake, understanding that they will be slashed at least one-third of the total network stake after reorganizing a finalized block. Ethereum researcher Vlad Zamfir notably analogized that it’s the equivalent of a miner’s entire ASIC farm burning down as soon as it participated in a reorganization. 

The Beacon Chain has additional mechanisms in place, such as the inactivity leak, to ensure finality is reached eventually, even if it’s temporarily disrupted. Whether the impediment is from validators being offline due to a client issue or a fork caused by a consensus disagreement, the inactivity leak is designed to penalize validators that impede finality by failing to attest to the chain, and it will eventually allow for the chain(s) to finalize as the impeding party accrues quadratically growing penalties until a supermajority is reclaimed. As such, slashing and penalties are the features that underpin Ethereum’s strong economic finality guarantees.

Rewards and penalties are aggregated across slots and paid to validators every epoch. Rewards issued for validating the chain are dynamic and depend on the total amount of ETH staked in the network. Specifically, the total ETH issued to validators in aggregate is proportional to the square root of the number of validators. This mechanism incentivizes validators with larger issuance rewards when there are fewer validators participating in consensus, and it decreases the incentive as the validator set grows and attracting additional validators becomes less essential. As an example, with the ~488k validators on the network today, about ~657k ETH would be issued annually, representing an average yield from issuance of ~4.2% across validators. However, the average yield from issuance would fall to just below 3.0% if the validator count was to double. Note that these numbers simply show the total issuance over the total stake or the average yield paid across all validators, but individual validators will achieve different yields based on their performance, as well as other uncontrollable factors.

Exhibit 3: Annual ETH Issuance by Validator Participation

Source: GSR, Upgrading Ethereum. The graphic denotes new ETH issued to validators. Historically, this only accounted for ~10% of total ETH issuance before The Merge when mining rewards were considered. The illustration assumes the Beacon Chain is running optimally, validators are performing their duties perfectly, and all validators have a 32 ETH effective balance. Actual issuance will be lower than illustrated as validators do not behave optimally in practice, but data since the launch of the Beacon Chain indicates that live validator performance is only a few percentage points below optimal. 

A substantial portion of validator rewards are derived from attestations, as every validator will make one attestation during each epoch. Rewards from attestations also depend on the validator’s timeliness in attesting and their correctness relative to the block proposer’s view of the chain. Attesting too slowly or incorrectly will result in rewards turning into penalties. In addition, the rewards realized by individual validators will further vary as incremental rewards accrue to the randomly selected block proposers and sync committee participants. Additionally, the rewards scale with a validator’s effective balance and with the total participation rate of other validators in the set. In short, this essentially means that validators with a balance below 32 ETH due to penalties for going offline or being slashed for malicious behavior will have their rewards scaled downward versus validators with a 32 ETH balance. Conversely, a validator’s effective balance is capped at 32 ETH, so one’s proportional share of rewards does not continue to grow beyond this level as their balance grows, making it suboptimal to hold a balance much higher than 32 ETH. Lastly, rewards between validators could further diverge as validators elect to participate in MEV by leveraging modified software such as Flashbot’s MEV-Boost, but this is notably outside of the Beacon Chain protocol for now. 

While this section aimed to provide an overview of Ethereum’s implementation of proof-of-stake, we acknowledge that the full depth and nuance of the Beacon Chain deserves coverage beyond the scope of this report. For readers interested in a deeper understanding of the Beacon Chain, we found Ben Edgington’s Upgrading Ethereum to be the most detailed resource. For those interested in a more applied overview to Ethereum staking, check out our recent report A Guide to Ethereum Staking. 

The Merge Implementation Process

Arguably the most important upgrade in Ethereum’s seven-year history, The Merge formally deprecated Ethereum’s proof-of-work consensus mechanism in favor of proof-of-stake. The Merge was actually a sequence of two upgrades, a CL client upgrade known as Bellatrix and an EL client upgrade known as Paris, which encompassed the improvement proposals of EIP-3675 and EIP-4399. Bellatrix occurred on September 6th, and it gave the Beacon Chain logic to be aware that The Merge was coming, while Paris was the actual Merge itself, where the consensus mechanism was switched in real-time. 

Building the Beacon Chain specification and battle-testing the client implementations was no small feat, and Ethereum developers ran through numerous tests aiming to simulate The Merge in a controlled environment. Around 20 shadow forks, which are simply copies of the state of a network used for testing purposes, were executed across mainnet and the Goerli testnet, allowing developers to trial The Merge through a large suite of live network conditions. Shadow forks work by coordinating a small number of nodes to fork off the canonical chain by pulling the Merge implementation timeline ahead of the live network. These shadow forks provided a more realistic testing environment than simulating The Merge on newly launched testnets like Kiln that didn’t have a long history of transactions, and they were an important step before merging existing public testnets. Developers then merged the Ropsten, Sepolia, and Goerli testnets in June, July, and August, respectively. While many bugs were identified, these tests were widely viewed as successful, and Goerli’s Merge was the final test that precipitated developers to set the triggering mechanism scheduling mainnet’s Merge.

The Merge was triggered when the chain reached a pre-specified terminal total difficulty (TTD) level, which is a measure of the total cumulative mining power used to build the proof-of-work chain since genesis. Once a proof-of-work block was added to the chain that crossed the preset TTD threshold, no additional proof-of-work blocks were produced from this point on. While prior mainnet upgrades were triggered at a predetermined block number, The Merge used TTD to protect against attacks where a bad actor would direct hashrate to a forked chain, pulling forward the block number, which would force a chain reorg similar to a 51% attack. 

Upon the network hitting the pre-specified TTD level of 58750000000000000000000 on September 15, Ethereum EL clients toggled off mining and ceased their gossip-based communication about blocks, with similar responsibilities being assumed by CL clients. As a result, Ethereum mining ceased, and proof-of-stake validators began leveraging Gasper to achieve consensus on mainnet. The two distinct blockchains that were historically running in parallel merged into the Beacon Chain, and new blocks were proposed to extend the Beacon Chain as usual, but they now included transaction data that was historically included in proof-of-work blocks. All told, The Merge resulted in Ethereum mainnet and the Beacon Chain merging together under a new consensus mechanism while maintaining the network’s full transaction history under proof-of-work.

Exhibit 4: Ethereum Block Architecture Pre & Post Merge

Source: Danny Ryan, Tim Beiko. Annotations by GSR. The Merge required a CL client upgrade (Bellatrix) and an EL client upgrade (Paris; EIP-3675 & EIP-4399) which happened ~9 days apart, yet the graphic illustrates it as a single upgrade for simplicity. We would recommend this post to those interested in a very precise series of events. 

Perhaps the biggest challenge with The Merge was that Ethereum could not be easily shut down or paused to implement the upgrade, as it exists not on a centralized server but simultaneously on thousands of computers (nodes) that run one of the open-source Ethereum software clients. This challenge is perhaps best illustrated by an analogy where Ethereum can be viewed as a spaceship (multiple functional layers – consensus, execution, settlement, data availability) with the Beacon Chain being a newly built engine (consensus), and after substantial testing, The Merge swapped out the spaceship’s engine mid-flight. This approach allowed for live testing while permitting everyday Ethereum users and their assets to remain segregated until developers executed The Merge. 

Another notable challenge associated with The Merge was the sheer number of pairwise combinations between consensus and execution layer clients. Unlike Bitcoin, which has a single reference implementation in Bitcoin Core, post-Merge Ethereum nodes must run an execution client and a consensus client paired together, with the implementations selected at the discretion of the node operator. Further, Ethereum has multiple distinct client teams independently developing and implementing the EL and CL protocol specifications. Ignoring client implementations with less than one percent of the user base at the time of The Merge, there were four EL client implementations and four CL client implementations, according to clientdiversity.org. This created 16 distinct pairs of EL and CL client implementations that all needed to interoperate seamlessly. While client diversity certainly made The Merge more challenging, it enhanced Ethereum’s decentralization and security by reducing various risks that arise when a network’s stake is concentrated in a single client implementation. Additionally, the Beacon Chain explicitly incentivizes client diversity by incorporating a correlation penalty that escalates the punishment when a slashing event occurs that impacts a large portion of the network’s stake. The inactivity leak further punishes correlated failures that impede finality. Hence, running a majority client increases one’s correlation with other validators, increasing the potential cost of a client bug that results in a large set of validators going offline or being slashed. 

The Merge was designed to be minimally disruptive to most participants of the Ethereum network; however, there were a few important changes for users to be aware of. Importantly and as discussed above, the upgrade required full nodes to run an EL client and a CL client. In contrast, transactions and blocks could previously be received, validated, and propagated with a single EL client. After The Merge, both EL and CL clients maintained unique peer-to-peer networks. The CL client gossips blocks, attestations, and slashings while the EL client continues to gossip transactions, handle execution, and maintain state. The two clients leverage the Engine API to communicate with each other, forming a full post-Merge Ethereum node in tandem. Additionally, Ethereum applications were not materially affected by The Merge, but certain changes like a marginally decreased block time and the removal of proof-of-work-related opcodes like difficulty may have impacted a subset of smart contracts.

The Merge was intended to produce several significant benefits, with perhaps the largest benefit being a ~99.9% reduction in the network’s aggregate energy consumption. Another byproduct of The Merge was the substantial reduction in the amount of new ETH issued. Before The Merge, about 15,100 new ETH were issued daily, equating to ~4.6% of Ethereum’s supply on an annualized basis, with ~13,500 of this going to miners and the remaining ~1,600 going to validators. After The Merge, however, no more ETH was issued to miners, and gross issuance fell by ~90%, with gross annualized issuance representing only ~0.55% of supply. Moreover, net issuance may be deflationary at times, as gas fees burned under EIP-1559 may more than offset the lower gross issuance. In fact, it only takes an average base fee of ~15 gwei to fully offset gross ETH issuance. Further, priority fees, which are equivalent to miner tips and are the unburned portion of gas fees, now accrue to validators, and these fees increased staking yields in the range of ~50%. Additionally, validators can now participate in MEV, generating incremental returns beyond the protocol-level yield. Lastly, it’s important to note that Beacon Chain validators are still unable to withdraw their stake today, and they will not be able to withdraw until the Shanghai upgrade is complete in an estimated six to twelve months. As a result, all new ETH issuance is currently illiquid as it accrues to validator accounts, where it cannot be withdrawn or transferred until after the next upgrade. And even then, there are validator exit limits in place to prevent a simultaneous run to the exits after staked ETH becomes liquid. 

The Merge Post-Mortem

Ethereum breached its terminal total difficulty level at block #15537393 on September 15th at approximately 2:43 am EST, triggering The Merge and the transition to proof-of-stake consensus for all future blocks. The execution of The Merge was as smooth as any test before it, and Ethereum seamlessly finalized its first checkpoint before 3:00 am EST. As mentioned previously, the Beacon Chain requires attestations from two-thirds of the stake to finalize, so any client bugs or node misconfigurations that resulted in more than one-third of the validator set going offline would have impeded finality. Comparing the last pre-Merge epoch (146874) to the first complete post-Merge epoch (146876), the voting participation of validators only decreased from 99.7% to 96.0%, and participation quickly moved back above 99.0% as offline validators worked through their issues. The result was an overwhelming success in what’s arguably the most important upgrade in crypto history. 

The completion of The Merge brought about many positive benefits to Ethereum. It replaced proof-of-work miners with energy-efficient proof-of-stake validators and reduced Ethereum’s electricity usage by an estimated ~99.9%. Block times decreased from ~13.3 seconds on average to a constant 12 seconds (assuming no empty slots)⁷, and the network now offers stronger finality guarantees underpinned by slashing and other validator penalties. From an economic perspective, the gross ETH issuance fell by ~90% as the block rewards paid to miners under the old security model ceased. On a net basis since The Merge, issuance has decreased by more than 100% as burned gas fees have more than offset gross issuance, turning ETH deflationary. And finally, staking yields have risen meaningfully as transaction priority fees now accrue to validators, and validators have new opportunities to capture MEV returns as well. Looking at validator performance since The Merge, validators leveraging MEV-Boost are generating a nominal yield typically in the 5% to 6% range, and the yield has been even higher on a real basis factoring in ETH burn dynamics.

Exhibit 5: Annualized Net Token Issuance Since The Merge

Source: Ultrasound.money, GSR. Note: Ethereum’s supply growth is variable, and this graphic shows an annualized extrapolation of the supply growth based on the realized changes in ETH supply between The Merge and November 11th. Bitcoin and pre-Merge ETH inflation are shown for comparative purposes. 

While The Merge provides many positive benefits, one purported drawback is increased transaction censorship, with some validators excluding certain valid transactions from their blocks even when their block is not full. 

Censorship concerns on Ethereum gained prominence following the U.S. Treasury’s recent sanctions of Tornado Cash. As background, on August 8th, the U.S. Treasury’s Office of Foreign Assets Control (OFAC) sanctioned crypto mixer Tornado Cash, which adds privacy and anonymity to transactions by mixing them together to obfuscate their origin and destination. With the sanctions, OFAC added Tornado Cash-related addresses to its Specially Designated Nationals And Blocked Persons List (SDN List) on which OFAC publishes the names of sanctioned terrorists, authoritarian regimes, and international criminals. Unless exempted or authorized by OFAC, all U.S. persons and businesses are prohibited from doing business with its blacklisted constituents, which now includes Tornado Cash.

The legal responsibilities of U.S. validators as a result of the sanctions remain unclear, and validator responses to the sanctions vary by legal interpretation. Generally speaking, conservative U.S. validators may exclude transactions that interact with Tornado Cash smart contracts. While this form of transaction censorship has gained prominence post-Merge, it does not uniquely apply to proof-of-stake Ethereum. Prior to The Merge, mining pools largely controlled the block-building process, and Ethermine, the largest mining pool, began censoring Tornado Cash transactions due to the sanctions as well. While the block-building process is very different pre- and post-Merge, a key distinction as it pertains to the sanctions is the difference in geographic distribution between pool operators and validators. Prominent validators like Coinbase, Kraken, and Lido Finance are U.S.-based or could arguably be subject to the sanctions, while most mining pools previously operated outside of the U.S. 

Additionally, the more complex block-building workflow that many validators employ under proof-of-stake complicates matters further. We will cover MEV, Proposer-Builder Separation, and MEV-Boost more thoroughly in The Scourge section, but in short, many validators run third-party middleware from Flashbots known as MEV-Boost that outsources block production to a distinct builder to generate incremental returns from MEV. Additionally, MEV-Boost requires the use of a mutually-trusted relay to intermediate block information between the validator and the builder, ensuring that the validator cannot steal MEV from the builder. As a result of this more complex block-building workflow, validators, relays, and builders may all be distinct entities, with each of their requirements under the sanctions up to legal interpretation. Lastly, at the time of the Merge, there were only a small number of relays and builders, and for numerous reasons like Flashbots’ builders operating without a fee and sending blocks to their own relay, Flashbots’ relay quickly captured the majority of market share. Moreover, Flashbots believes it’s legally required to exclude Tornado Cash transactions, so the majority of post-Merge Ethereum blocks have been OFAC compliant.

Exhibit 6: Trailing Seven-Day Block Breakdown by OFAC Compliance 

Source: mevwatch.info, GSR. Data as of Nov 11th, 2022. 

While the state of Ethereum censorship may sound perilous, it is important to define what this type of censorship really means. Per Justin Drake, the above examples are known as weak censorship, which is more akin to a delay than a freeze. While weak censorship is sub-optimal and developers plan on improving this, it notably does not prevent a sanctioned transaction from being included in a block, but rather increases the average time it takes for inclusion. For example, if 95% of blocks are proposed via Flashbots’ censoring relay and 5% of blocks are not censored, then it will take a censored transaction ~20x as long to be included in a block on average, or about four minutes instead of 12 seconds. Therefore, as long as some validators uphold Ethereum’s ethos of censorship resistance, weak censorship only increases the time it takes to get a censored transaction included in a block⁸. Additionally, the ecosystem is working on building more non-censoring relays, like BloXroute [Max-Profit], Relayooor, and Manifold that will hopefully carve out market share in the month’s ahead. 

Ethereum’s Roadmap: What Lies Ahead

While Ethereum’s transition to proof-of-stake was a resounding success and brought many significant benefits, it was just one of many important technical upgrades on the path to Ethereum’s Endgame. The remainder of this report turns to the future and evaluates Ethereum’s recently updated roadmap, including 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. In what follows, we dive into each category of upgrades and the prominent initiatives within each.

Exhibit 7: 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 Second Half of 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 previously covered, 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 8: 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. 

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⁹. 

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 that we previously covered.

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¹⁰.

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¹¹. 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 ¹².

Exhibit 9: 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¹³. 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¹⁴. Depending on the approach used, corresponding adjustments to staking economics may necessarily follow.

Exhibit 10: 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¹⁵. 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 11: 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 call data 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¹⁶. 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, 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 12: 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¹⁷. 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¹⁸. 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 13: Proposer-Builder Separation via MEV-Boost

Source: Flashbots, GSR. 

As covered in our post-mortem of The Merge, censorship concerns quickly became a key area of focus after the upgrade as censoring relays captured the majority of block production. 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 14: 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¹⁹. 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²⁰.

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²¹. 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²² 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²³.

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 15: 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²⁴. 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²⁵. 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²⁶. 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:

1. For those that read our previous coverage in September 2022, this piece incorporates Vitalik’s newly revised roadmap that was unveiled in November 2022. This report includes nearly 15 pages of new additions with the most prominent being: a post mortem evaluation of the transition to proof-of-stake; more detail on the second half of the Merge phase, covering Distributed Validator Technology, Single Secret Leader Elections, and Single-Slot Finality; an introduction to Rollups in The Surge to better frame the context of the Danksharding roadmap; the newly added Scourge roadmap with more nuanced coverage of the post-Merge MEV environment, Credible Neutrality, and the long-term roadmap for Proposer-Builder Separation; lastly, it offers new coverage of the Endgame fee market and Verifiable Delay Functions in The Splurge. Conversely, the least changed sections are the Overview, The Beacon Chain, Ethereum’s Proof-of-Stake Detailed, The Merge Implementation Process, The Verge, and The Purge. 
2. Notably, validators are attesting to their view of the chain head block for LMD GHOST during their slot, which is generally but not necessarily the block proposed in their slot. In practice, blocks are proposed at the very beginning of each slot, so the block proposed in a given slot will generally be the chain head block that validators are attesting to in that slot, resulting in 1/32 of the validator set attesting to each block. However, if a block proposer does not deliver a block in their assigned slot, the validators in that slot would attest to their view of the chain head block, which would likely be the same chain head that validators in the previous slot attested to. Hence, it’s not necessarily always 1/32 of the validator set attesting to each block (there also will be offline validators that miss attestations in practice). In aggregate, validators are delivering one attestation per epoch, but that attestation includes three items: 1) a vote on the source checkpoint, 2) a vote on the target checkpoint, and 3) a vote for the chain head block. Notably, the chain head vote uniquely determines the source and target vote, so strictly speaking, voting on all three is redundant and unnecessary, but it simplifies processing. 
3. There are 64 committees per slot, which results in about ~240 validators per committee based on the size of the validator set currently. The exact number of validators per committee shown here is an estimate, but it should give an idea of the size of the validator set. 32 slots per epoch, 64 committees per slot, 240 validators per committee, 32*64*240 = 491,520 validators each attesting once per epoch. 
4. A fork-choice rule is simply a protocol that determines one’s view of the head (tip) of the chain based on the available information. Bitcoin and proof-of-work Ethereum use(d) a rule that selects the longest chain, or more precisely, the chain with the most cumulative chainwork. Gasper, however, follows the chain containing the justified checkpoint that has the greatest block height without ever reverting a finalized block. From here, it essentially counts the accumulated votes from validators for blocks and their descendent blocks (the economically heaviest chain). For an interactive explanation, see here from 1:33 to 4:00. 
5. An epoch’s checkpoint is generally going to be the first block in an epoch. However, a checkpoint is a hash identifying the latest block at the start of that epoch, and the block identified by a checkpoint’s hash isn’t always included in this new epoch because an empty slot can occur at the beginning of an epoch, so “the latest block” would reference the last block in the prior epoch. Checkpoints are known as epoch boundary blocks in other literature, which may help with intuition. Checkpoints are identified by their block root (hash) and an epoch number. A block can theoretically serve as the checkpoint for multiple epochs if the slots throughout remain empty. 
6. Since checkpoint finalization requires a two-thirds supermajority, the finalization of two competing checkpoints would require attestations from at least four-thirds of the total stake weight, guaranteeing at least one-third of the total stake attested to two different checkpoints for the same epoch. In a normal scenario where the honest validators’ views of the canonical chain are not divergent or split, the attacker would also need to procure two-thirds of Ethereum’s total stake to execute this attack in the first place. Imagine an attacker has two-thirds of the total network stake, and honest validators possess the other one-third. Assuming honest validators all attest to the same checkpoint, the attacker could finalize this checkpoint by attesting with half of their stake or one-third of the total network stake equivalently. The attacker could then unilaterally finalize a competing checkpoint by attesting to it with the entirety of their two-thirds stake, but as guaranteed by the first sentence of this footnote, this would result in them having one-third of the total network stake slashed as this would require them to maliciously reuse one-third of the total network stake that they already used to attest to the first checkpoint. Despite this attack requiring two-thirds of the stake to conduct, only half of the stake was required to attest to competing checkpoints, and this is the only provably malicious act that the protocol can detect, so the one-third is all that can be slashed. It could easily be argued that this attack should warrant the malicious actor being slashed the full two-thirds, but this is not detectable in protocol and would require social slashing through a user-activated soft fork. It may be possible to revert a finalized block with less than two-thirds stake in the event that honest validators are partitioned on their view of the canonical chain, but regardless, any attacker is always guaranteed to be slashed one-third of the total network stake under all circumstances which seems to be a sufficiently large distinctive. 
7. Average block times are greater than 12 seconds due to the occasional empty slot. Notably though, block times will be a constant 12 seconds if a block is proposed in each slot. Unlike proof-of-work, where block times are probabilistic in nature based on how quickly a miner solves the mining puzzle, all Beacon Chain slots are exactly 12 seconds apart, and block times will only deviate from 12 seconds if a proposer fails to propose a block in their assigned slot. This deviation would naturally only come in multiples of 12 seconds. 
8. Strong censorship is a more severe, malicious attack on the network. Strong censorship would be executed via attestations instead of proposals, and it would be a type of 51% attack. A strong censoring validator would stop recognizing the validity of blocks from the non-censoring minority, preventing sanctioned transactions from ever being included in a block. This would be an attack on the fork choice rule as opposed to an individual validator’s decision about the contents of their own block proposal. Importantly, this is not the type of censorship occurring today, and if it was, the Ethereum community has social mechanisms like a user-activated soft fork (UASF) and social slashing to defend itself. There would be a censored version of Ethereum and an uncensored Ethereum as a result. 
9. Two of the more recently discussed SSLE proposals here and here.
10. Technically forks can still occur in the long run since Ethereum only achieves economic finality instead of absolute finality, but reverting a finalized block would cost billions of dollars via slashing. See here for reorg analysis across consensus mechanisms. 
11. 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. 
12. 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 ~488,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. 
13. 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 10 for an illustration of the two-vote process (justification and finality). 
14. 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. 
15. 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.
16. 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. 
17. 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 and/or other mechanisms. 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.
18. 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. 
19. Proposing a full block increases the base fee by 12.5% under EIP-1559, so fees would increase by ~18x [1.12525-1] if full blocks were proposed for five minutes straight (25 blocks).
20. See footnote 18. 
21. See footnote 17. 
22. 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. 
23. The Splurge also features numerous technical EVM upgrades that we omitted. See here for coverage of the EVM improvement track. 
24. EIP-1559 elastic block sizes target 15m gas with a hard cap at 30m gas per block. Noting the 3% average and factoring in the 2x multiple on a 30m gas block, a worst-case block contains ~67x [2*(1/.03)] more data than an average block. 
25. 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. 
26. 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: 

Matt Kunke, Junior Strategist     |  Twitter, Telegram, LinkedIn 

Brian Rudick, Senior Strategist  |  Telegram, LinkedIn 

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’s PoS Consensus Explained, Bellatrix & Paris – Etherworld, Client Diversity – Dankrad Feist, EIP-3675 – Upgrade to Proof-of-Stake, EIP-4399 – Supplant Difficulty Opcode 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, Ultra Sound Money, The Case for Social Slashing – Eric Wall, Rated.network, MEVWatch, Relay Overview, Is The Block Building Market Doomed to Monopoly – SajZ, Ethereum Uncensored – Justin Drake & Bankless

This material is a product of the GSR Sales and Trading Department. It is not a product of a Research Department, not a research report, and not subject to all 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 your interests. The Firm trades instruments discussed in this material for its own account. The author may have consulted with the Firm’s traders and other personnel, who may have already traded based on the views expressed in this material, may trade contrary to the views expressed in this material, and may have positions in other instruments discussed herein. This material is intended only for institutional investors. Solely for purposes of the CFTC’s rules and to the extent this material discusses derivatives, this material is a solicitation for entering into a derivatives transaction and should not be considered to be a derivatives research report. 

This material is provided solely for informational purposes, is intended for your use only and does not constitute an offer or commitment, a solicitation of an offer or comment (except as noted for CFTC purposes), or any advice or recommendation, to enter into or conclude any transaction (whether on the indicative 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.

Information is based on sources considered to be reliable, but not guaranteed to be accurate or complete. Any opinions or estimates expressed herein reflect a judgment made 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. GSR will not be liable whatsoever for any direct or consequential loss arising from the use of this Information. Copyright of this Information belongs to GSR. Neither this Information nor any copy thereof may be taken or rented or redistributed, directly or indirectly, without prior written permission of GSR. Not a solicitation to U.S. Entities or individuals for securities in any form. If you are such an entity, you must close this page.