GSR: Ethereum’s Transition to Proof-of-Stake

A Brief Overview of Ethereum’s History

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.

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. In what follows, we 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.

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.

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

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 attestations2. 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 epoch3. 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, 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 stake4. Assuming an ETH price of $1,300 and using the ~14.9m ETH locked in the deposit contract currently, reversing a finalized block would cost the attacker(s) nearly $6.5b. 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 ~465k validators on the network today, about ~642k ETH would be issued annually, representing an average yield from issuance of ~4.3% across validators. However, the average yield from issuance would fall to just over 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.

The Merge Implementation Process

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.

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 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)5, 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 over the last 30 days, validators leveraging MEV-Boost are generating a nominal yield typically in the 6.5% to 7% 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.

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.

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

In the end, The Merge was a resounding success and brought many significant benefits. A successful Merge, however, was far from The Endgame, and much remains to be done. Indeed, Ethereum’s recently-revised roadmap is comprised of six sections that introduce critical concepts such as danksharding, statelessness, proposer-builder separation, and account abstraction, all of which are significant upgrades in enabling Ethereum mass adoption. We cover each of the six sections and their key components in considerable detail in part two of this report.

Footnotes:

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

2. A fork-choice rule is simply a protocol that determines one’s view of the head 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).

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

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

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

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.