GSR: Ethereum’s Roadmap Beyond Proof-of-Stake

Ethereum’s Roadmap

Exhibit 1: Ethereum’s Roadmap

The Merge

Exhibit 2: Active-Passive Redundancy vs. DVT Active-Active Redundancy

Single Secret Leader Elections (SSLE) are another upgrade in development. One issue with the current setup, where block proposers are assigned to each of the 32 slots and publicly revealed at the start of every epoch, is that it presents an attack surface for malicious actors to sequentially DDoS the publicly known block proposers in an attempt to freeze block production. Moreover, validators that propose a block following an empty slot can earn increased rewards by including attestations from two slots in their block, providing adverse incentives for a malicious validator to DDoS the proposer in the slot before them. In short, implementing an SSLE would mitigate these attack vectors and preserve the anonymity of each slot’s proposer until a block is proposed. Precise implementation details remain to be seen, but at a high level, the latest proposals use various validator shuffling mechanisms to preserve anonymity until the rightful proposer delivers a block[1].

Single-Slot Finality (SSF) is the most substantial upgrade outstanding in The Merge phase, and its implementation is likely years into the future. As implied in the name, SSF would decrease Ethereum’s finality time to a single slot from the 64 to 95 slots it takes to finalize today, but it requires a material revamping of Ethereum’s proof-of-stake underpinnings detailed in the first part of this series.

Exhibit 3: Gasper Parameterization Trilemma Illustrated

Source: Upgrading Ethereum, GSR. The ‘X’ bubble represents Ben Edgington’s estimate of where Ethereum falls on this trilemma.

Prior to implementing SSF, three primary challenges need to be addressed, including developing the precise consensus algorithm, optimizing the signature aggregation processes, and determining the best approach to validator participation and economics. Vitalik’s blog delves into these questions in considerable detail, so we’ll merely summarize the current stance while reiterating that no formal proposals have been made and the design space remains open.

While Ethereum plans to move closer towards a traditional BFT consensus algorithm, it will still employ a hybrid approach to consensus as it prefers to favor liveness over safety (i.e., the chain doesn’t halt block production if one-third of validators go offline). The Ethereum blockchain today is regularly finalized up to a given epoch, and the blocks following this epoch are optimistic until reaching finality about 15 minutes after being proposed. Conversely, under SSF, Ethereum would be finalized through the tip of the chain in normal times, but unlike traditional BFT consensus, Ethereum would not halt if it failed to reach its two-thirds consensus threshold, and it would continue to produce blocks optimistically. To accomplish this, instead of running the finality gadget and the fork-choice rule simultaneously, a particular slot would leverage either the finality gadget or the fork-choice rule depending on the consensus level achieved. If the two-thirds consensus threshold is reached, the finality gadget will finalize the proposed block before the next slot’s proposal, but if consensus falls short of the two-thirds threshold, the fork-choice rule will move the chain forward optimistically. While this doesn’t remediate all the complex interactions between the finality mechanism and the fork-choice rule previously covered, it’s expected to mitigate them materially.

SSF also presents new optimization challenges with signature aggregation, as it will meaningfully expand the number of attestations required per slot. Currently, only ~1/32 of ETH validators attest in each slot, but SSF will increase this meaningfully as every validator will ideally begin attesting in every slot. Moreover, since reaching finality requires validators to vote in two rounds of attestations, achieving finality in a single slot will require all participating validators to attest twice in each slot, increasing validator attestations ~64-fold[5]. Lastly, depending on how the validator set develops in the years ahead, a scenario could emerge where the total validator count exceeds the number of signatures that can be feasibly aggregated and processed in a slot. Resultantly, new criteria would need to be developed to select the eligible validator set, whether through super-committees, capping validators and/or their balances and rotating them, or some other mechanism entirely[6]. Depending on the approach used, corresponding adjustments to staking economics may necessarily follow.

Exhibit 4: Single-Slot Finality Illustrated

Source: Justin Drake, Delphi, GSR. Justin Drake noted that SSF is being designed to support ~1M validators.

In short, the remaining upgrades categorized in The Merge phase predominantly strive to improve Ethereum’s implementation of proof-of-stake and enable staked ETH withdrawals. DVT will help decentralize Ethereum’s validator network while improving validator performance and reducing several of the risks currently faced. And SSLE aims to preserve the anonymity of proposers until they deliver a block, mitigating one prominent avenue for abuse. Lastly, SSF will materially reduce the time it takes for Ethereum transactions to achieve finality, reducing finality times down to a single slot from the 64 to 95 slots it takes today.

The Surge

Rollups are a type of L2 scaling solution that bundle together multiple transactions, executing them in batches off of Ethereum mainnet before posting back to mainnet a smaller amount of data sufficient to reconstruct the L2’s state[7]. Since a rollup’s state can be reconstructed from data posted on Ethereum mainnet, rollups inherit many of Ethereum’s security guarantees. The two primary rollup categories are Optimistic Rollups (ORU) and Zero-Knowledge Rollups (ZKR). At a high level, ORUs and ZKRs both periodically publish state roots to mainnet, but the two solutions leverage different approaches to ensure that the batched set of transactions were executed correctly and that the published state is accurate. ORUs rely on economic incentives, and the posted state root is optimistically assumed to be valid, but any user can verify the state root’s accuracy and initiate a challenge if the state transition was done incorrectly to earn a reward at the expense of the operator that submitted the incorrect state change. Conversely, ZKRs rely solely on advanced cryptography, posting a state root alongside a validity proof that cryptographically verifies that the state transitioned correctly, typically without revealing any underlying transaction information.

Exhibit 5: Arbitrum Nitro’s Optimistic Rollup Flow Diagram

Source: Arbitrum, GSR. Note: The sequencer is the actor ordering transactions.

Ethereum’s transition to a rollup-centric roadmap simplified its path forward by deemphasizing scaling at the base layer and prioritizing data sharding over execution sharding. The updated roadmap aims to achieve network scalability by moving virtually all computation (i.e., execution) over to L2 while making it cheaper for data to be posted back to Ethereum mainnet. Simply put, computation is already very cheap on L2s, and the majority of L2 transaction fees today come from the cost of posting the computed data back to mainnet. Hence, improving mainnet’s ability to make data cheaply available will be the largest driver in decreasing L2 transaction costs. The updated roadmap retrenched the focus of Ethereum’s mainnet to consensus, settlement, and data availability, allowing L2 rollups to compete in the free market to provide execution.

Despite PDS making progress in the DS roadmap, the name is perhaps a misnomer given each validator is still required to download every data blob to verify that they are indeed available, and actual data sharding will not occur until the introduction of DS. The PDS proposal is simply a step in the direction of the future DS implementation, and expectations are for PDS to be fully compatible with DS while increasing the current throughput of rollups by an order of magnitude. Rollups will be required to adjust to this new transaction type, but the forward compatibility will ensure another adjustment is not required once DS is ready to be implemented. PDS will be implemented in the fork after Shanghai that’s expected next fall.

While the implementation details of DS are not set in stone, the general idea is simple to understand: DS distributes the job of checking data availability amongst validators. To do so, DS uses a process known as data availability sampling, where it encodes shard data using erasure coding, extending the dataset in a way that mathematically guarantees the availability of the full data set as long as some fixed threshold of samples is available[8]. DS splits up data into blobs or shards, and every validator will be required to attest to the availability of their assigned shards of data once per epoch, splitting the load amongst them. As long as the majority of validators honestly attest to their data being available, there will be a sufficient number of samples available, and the original data can be reconstructed. In the longer run, private random sampling is expected to allow an individual to guarantee data availability on their own without any validator trust assumptions, but this is challenging to implement and is not expected to be included initially.

Exhibit 6: Danksharding

Source: Vitalik Buterin, GSR.

In summary, The Surge focuses on scaling and improving Ethereum’s transaction throughput. However, many still misconstrue sharding as scaling Ethereum execution at the base layer, which is no longer the medium-term objective. The sharding roadmap prioritizes making data availability cheaper and leaning into the computational strengths of rollups to achieve scalability on L2. Finally, note that many have highlighted DS as the upgrade that could invert the scalability trilemma as a highly decentralized validator set will allow for data to be sharded into smaller pieces while statistically preserving data availability guarantees, improving scalability without sacrificing security.

The Scourge

As the name implies, PBS separates the roles and distinguishes between a block builder and a block proposer. The validator selected to propose the next block in the chain is known as the block proposer, and they outsource block construction (transaction selection and ordering) to a dedicated market of block builders. Under this model, specialized block builders search for MEV opportunities and/or receive them from trusted searchers. A block builder’s goal is to construct the most profitable block so they can submit the highest bid to the block proposer and have their block proposed to the network. Under this model, a proposer’s job becomes as simple as proposing the block provided by the builder that pays the highest bid. This eases the job of validators by selling the computationally difficult optimization problem to a more specialized entity and allows validators to fulfill their responsibilities with materially lower hardware specifications. Additionally, PBS should redistribute MEV profit to validators, as competition between builders to offer the highest bid to the proposer will erode builder margins and return most profit to the proposer[9]. Perhaps ironically, the PBS setup somewhat resembles the scale economies inherent in proof-of-work. Building a block that maximizes total profit is a difficult problem that’s best outsourced to specialized entities that benefit from economies of scale, but verifying the validity of this block remains very easy. This separation results in more centralized block building, but validation remains trustless and should be even more decentralized since block-building responsibilities are delegated elsewhere.

While the long-term plan is to enshrine PBS directly into Ethereum, PBS is only possible today on an opt-in basis by running third-party middleware from Flashbots known as MEV-Boost to enable outsourced block production. MEV-Boost separates proposers from builders, allowing proposers to generate incremental returns from MEV by outsourcing block production to a specialized builder. Moreover, MEV-Boost requires using a mutually-trusted relay to intermediate the transmission of block information between the proposer and the builder, ensuring that the proposer cannot steal MEV from the builder[10]. While relays have been generally performant, a non-performant relay could fail to deliver a block and cause a validator to miss their proposal, so this setup does embed trust. Lastly, MEV-Boost is commonly misconceived as censoring transactions on Ethereum, but this is not the case. MEV-Boost software allows proposers to outsource block production to specialized builders; it does not specify where blocks are outsourced, and validators can connect to any number of relays they choose to trust, including censoring and non-censoring relays (currently, OFAC-compliant and non-OFAC-compliant relays), selecting the block from whichever connected relay pays the highest bid.

Exhibit 7: Proposer-Builder Separation via MEV-Boost

Source: Flashbots, GSR.

Exhibit 8: MEV Per Block in ETH by Percentiles & Distribution Statistics

Source: Modeling the Profitability of the Rocket Pool Smoothing Pool, GSR. Note: MEV is proxied over 432,000 blocks from March 7, 2022 to May 14, 2022. Methodology details outlined further in the source.

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

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 deletion of history data is a concern primarily for Ethereum-based applications that require historical transaction data to show information about past user behavior. History storage is seen as a problem best handled outside of the Ethereum protocol moving forward, but clients will still be able to import this data from external sources. It’s expected that applications will have multiple different solutions to obtain history data outside of Ethereum, including from block explorers like Etherscan, indexing providers such as The Graph, or a more decentralized, Ethereum Foundation-supported protocol like the Portal Network.

In addition to history expiration, The Purge[14] includes state expiry, which prunes state that has not changed in some defined amount of time, like one year, into a distinct tree structure and removes it from the Ethereum protocol. State expiry is one of the furthest away upgrades in the Ethereum roadmap and only becomes feasible after the introduction of Verkle Trees. Notably, expired state assets could always be retrieved by displaying a proof as long as some other party maintains a copy of the chain’s history elsewhere. While state expiry is not as essential as it may initially seem after stateless clients are implemented, it will still decrease the strain of dust accounts and other inactive addresses on Ethereum’s state.

The Splurge

The Splurge is a catch-all bucket for miscellaneous upgrades that don’t fit neatly into any of the previous categories. Account abstraction, endgame EIP-1559, and Verifiable Delay Functions (VDFs) are some of the more prominent upgrades in this segment[15].

Account abstraction brings about many benefits. First, it improves the user experience by atomically batching operations into a single transaction that would otherwise require multiple different mainnet transactions to execute. Further, it provides user flexibility to deviate from the ECDSA digital signature algorithm to employ arbitrary verification logic, such as a quantum-resistant signature scheme. It also simplifies the use of multisigs and social recovery wallets. Lastly, it introduces a form of gas abstraction where gas fees can be paid in ERC-20 tokens, and applications can subsidize the gas fees of their users. In the longer-term future, an additional EIP enabling the conversion of EOAs into smart contract wallets may be introduced. A mandatory conversion proposal may follow that would simplify the protocol by making all accounts smart contract wallets.

Exhibit 9: Account Abstraction - EIP-4337

Source: Vitalik Buterin, GSR.

VDFs employ specialized hardware to solve a series of sequential computations that are non-parallelizable, each taking a certain amount of time to compute, known as the delay, and once computed, they can be easily verified without specialized hardware. This may spark some parallels to proof-of-work, but unlike the probabilistic nature of proof-of-work, VDFs verifiably show that a known amount of time was spent computing a result. At a high level, the idea underpinning VDFs is that if you can build specialized hardware capable of computing a particular calculation within some close threshold of the theoretical peak efficiency, you can then assess the minimum amount of time it would take anyone to solve it[18]. Combining RANDAO contributions with VDFs would force a proposer to decide between proposing a block or skipping their proposal before they can computationally verify the impact on RANDAO, removing the potential for bias. Beyond this, VDFs provide Ethereum with a purer source of randomness that may be necessary to develop particular applications in the future. The Ethereum Foundation is expecting VDF ASIC samples to arrive in January 2023.

Conclusion

While Ethereum's transition from proof-of-work to proof-of-stake was a crowning achievement, Ethereum's work is far from finished, with Vitalik himself estimating the network is still only 55% complete after the upgrade. Despite this, Ethereum is equipped with a thoughtful and well-defined roadmap, and its developers are hard at work perfecting the various upgrades to bring about their many benefits. Single-Slot Finality will materially enhance Ethereum's implementation of proof-of-stake, improving user experience with decreased finality times. Through Danksharding, with its data blobs and data availability sampling, The Surge will make data availability cheaper and distribute the job of checking data availability amongst nodes, providing material scalability benefits on L2. The Scourge will add Proposer-Builder Separation to mitigate the centralizing impact of MEV and redistribute MEV income while ensuring credibly neutral transaction inclusion. The Verge will achieve statelessness by implementing Verkle Trees and SNARKs later on, allowing stateless clients to easily verify blocks without maintaining a local copy of Ethereum's state. The Purge will introduce history expiration and state expiry, archiving history data, pruning untouched state, and generally simplifying the protocol. And The Splurge will introduce account abstraction, increasing wallet choice/functionality and improving user experience, alongside more efficient gas markets and unbiasable randomness. In the end, Ethereum is expected to process ~100,000 transactions per second with vast improvements in its already leading security and decentralization, enabling mass adoption and achieving Ethereum's initial goal of creating a trustless and permissionless world settlement layer for a diverse suite of dapps and beyond.

3. V ≤ F*M/2. V is the cap on the number of validators, F is the time to finality in seconds, and M is the messaging requirements per second placed on full nodes. The equation states that the number of validators must be less than or equal to the product of time to finality and messaging requirements divided by two. This formula applies to monolithic blockchains where every node is responsible for processing every transaction. As Ben Edgington notes, this equation is not as straightforward as it may seem, as there’s a relationship between V and M. For example, if the 32 ETH validator requirement was decreased to incentivize higher V, M would likely increase as a larger populous becomes able to participate, so more attestations would be expected.

4. Ethereum’s hybrid consensus approach is notably distinct from many BFT consensus mechanisms, like Tendermint, that offer near-instantaneous finality with a relatively small number of validators. For context, Ethereum has ~475,000 validators today, and while 32 ETH may not seem like a modestly sized investment, initial proposals required 1,500 ETH minimums to stake and would’ve required capping the total number of active validators at ~900.

5. It’s expected that slots may need to be lengthened to 16 seconds or so to implement SSF, with each validator attesting once in each of the two 8-second sub-slots within a slot. Hence, the number of slots to finality will decrease 32-fold, but the actual time to finality will decrease by a lesser amount if slots times increase in length by ~33%. See exhibit 4 for an illustration of the two-vote process (justification and finality).

6. One mitigant to this cap is that SSF would allow the 32 ETH effective balance cap placed on validators to be removed or meaningfully increased. Large stakers could then elect to consolidate their stake amongst fewer validator instances, which is one partial mitigant to the increased number of attestations required per slot under SSF. This increase would have other positive egalitarian effects on the economics of staking as well. Assuming withdrawals are enabled and effective balances are capped at 32 ETH, then large validators are able to compound their stake while small validators cannot. Further, assume that staking earns 7% per year, ETH is staked for ten years, and validators rebalance annually if they’ve generated the 32 ETH necessary to launch a new validator instance. Comparing the hypothetical performance of a large staker that starts with 100 validators to an individual that starts with one validator, the large validator outperforms by ~25% over the period, or ~1.5% per year.

7. ORU post compressed L2 transaction data alongside an L2 state root to L1, allowing anyone to check and verify accurate state transitions. Conversely, instead of posting L2 transaction data to L1, ZKRs typically post state differences (i.e., the net change from all the transactions), as well as a validity proof to verify that the state transitioned correctly. This statement isn't universally true for ZKRs, however, as some ZKRs like Scroll are being built to post compressed transaction data instead of state differences.

10. MEV-Boost is a whole block auction, and unlike MEV-Geth in PoW Ethereum, the proposing validator cannot append additional transactions to the end of the outsourced block currently. This is one of the key censorship concerns with MEV-Boost. In PoW Ethereum, only a few mining pools controlled block construction, so pools and searchers could form trusted relationships directly, and if a mining pool stole a searcher's MEV, the searcher would just end the relationship. After The Merge, however, a much broader set of ~450k validators control transaction ordering, so mutually trusted relays need to be introduced since builders cannot form trusted relationships with so many proposers. Currently, the builder sends a full block to the trusted relay, but the proposer only receives a header and must commit (sign) the header before the full block is revealed, so under this model additional transactions cannot be appended.

11. Proposing a full block increases the base fee by 12.5%, so fees would increase by ~18x [1.12525-1] if full blocks were proposed for five minutes straight (25 blocks).

12. See footnote 10.

13. See footnote 9.

16. EIP-1559 elastic block sizes target 15m gas with a hard cap at 30m gas. Noting the 3% average and factoring in the 2x multiple on a 30m gas block, a worst-case block contains ~67x more data than an average block.

Authors:

Sources:

About GSR

GSR has nine years of deep crypto market expertise as a market maker, ecosystem partner, asset manager, and active, multi-stage investor. GSR sources and provides spot and non-linear liquidity in digital assets for token issuers, institutional investors, miners, and leading cryptocurrency exchanges. GSR employs over 300 people around the globe, and its trading technology is connected to 60 trading venues, including the world’s leading DEXs.

We have a culture of approaching complex problems with tenacity and imagination. We build long-term relationships by offering exceptional service, expertise and trading capabilities tailored to the specific needs of our clients.

Required Disclosures

This material is provided by GSR (the “Firm”) solely for informational purposes, is intended only for sophisticated, institutional investors and does not constitute an offer or commitment, a solicitation of an offer or commitment, or any advice or recommendation, to enter into or conclude any transaction (whether on the terms shown or otherwise), or to provide investment services in any state or country where such an offer or solicitation or provision would be illegal.  The Firm is not and does not act as an advisor or fiduciary in providing this material.

This material is not a research report, and not subject to any of the independence and disclosure standards applicable to research reports prepared pursuant to FINRA or CFTC research rules. This material is not independent of the Firm’s proprietary interests, which may conflict with the interests of any counterparty of the Firm. The Firm trades instruments discussed in this material for its own account, may trade contrary to the views expressed in this material, and may have positions in other related instruments.

Information contained herein is based on sources considered to be reliable, but is not guaranteed to be accurate or complete. Any opinions or estimates expressed herein reflect a judgment made by the author(s) as of the date of publication, and are subject to change without notice. Trading and investing in digital assets involves significant risks including price volatility and illiquidity and may not be suitable for all investors. The Firm is not liable whatsoever for any direct or consequential loss arising from the use of this material. Copyright of this material belongs to GSR. Neither this material nor any copy thereof may be taken, reproduced or redistributed, directly or indirectly, without prior written permission of GSR.