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

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

1 year ago

Ethereum successfully executed its Merge to proof-of-stake on September 15th. This report dives into Ethereum’s history, its proof-of-stake blockchain, and the implementation of The Merge.

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.

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

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

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 Maximal Extractable Value (MEV) by leveraging modified software such as Flashbot’s MEV-Boost, but this is notably outside of the 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 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.5% 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)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:, 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 (PBS), and MEV-Boost more thoroughly in part two of this series, 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:, 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.


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.

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

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.


Matt Kunke, Junior Strategist     |  Twitter, Telegram, LinkedIn
Brian Rudick, Senior Strategist  |  Telegram, LinkedIn
The authors would like to thank Justin Drake of the Ethereum Foundation for providing helpful comments, as well as Ben Edgington of ConsenSys for answering many questions on the Beacon Chain.


About GSR

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

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

Find out more at
Follow GSR on Twitter, Telegram, and LinkedIn for more content.

Required Disclosures

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

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

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

This article contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of CoinMarketCap, and CoinMarketCap is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. CoinMarketCap is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by CoinMarketCap of the site or any association with its operators. This article is intended to be used and must be used for informational purposes only. It is important to do your own research and analysis before making any material decisions related to any of the products or services described. This article is not intended as, and shall not be construed as, financial advice. The views and opinions expressed in this article are the author’s [company’s] own and do not necessarily reflect those of CoinMarketCap.
1 person liked this article