skip to content

Paths Toward Reducing Validator Set Size Growth

Ethereum All Core Developers Execution Call #181 Writeup - Galaxy Research

Executive Summary

Ethereum is getting close to reaching an unsustainable number of active validators. Therefore, Ethereum protocol developers have decided to activate a cap to the validator churn limit in the forthcoming Cancun/Deneb upgrade. The cap will limit validator entries to a maximum of 8 new activations per epoch, that is 6.4 minutes. The cap will not impact the churn limit dictating validator exits, which will continue to dynamically increase as the size of the validator set grows. Creating a ceiling to the churn limit for validator entries is a short-term solution to the issue of validator set size growth. Developers are working towards various solutions to reduce the growth of the validator set long-term, and these solutions may have major ramifications on Ethereum’s monetary policy. This report dives into the dangers around a large validator size and the solutions proposed to mitigate this issue.

Introduction

As of September 14, 2023, there are 795,135 active validators on Ethereum. Since the activation of staked ETH withdrawals in the Shanghai/Capella upgrade on April 12, the number of active validators has increased 41%.

Ethereum, active validator, set size, total ETH staked, Galaxy Research, Christine Kim
Ethereum, active validator, set size, total ETH staked, Galaxy Research, Christine Kim

The growth of the active validator set is restricted by a dynamic churn rate that determines the maximum number of validators that can enter or exit Ethereum every epoch (every 6.4 minutes). As of September 14, 2023, the churn rate is 12. Assuming the maximum number of validators are activated on Ethereum per epoch, which has indeed been the case since Shanghai, the total number of active validators is expected to reach 1 million by mid-November and 2 million by June 2024 without developer intervention.

Ethereum’s rapidly growing validator set has sparked concerns among protocol developers for two main reasons.

  • First, a large validator set size creates strains on peer-to-peer networking and messaging that may cause node failures from high computational load and bandwidth requirements.

  • Second, a large validator set creates technical debt that may make future upgrades like single slot finality harder and riskier to achieve.

This report will dive into these concerns in more detail and the paths forward discussed by Ethereum developers to mitigating validator set size growth. Additionally, the report will analyze what impacts changes to Ethereum’s validator set may have on the network’s monetary policies and staking industry.

Reasons to Reduce Validator Set Size Growth

Unlike other proof-of-stake (PoS) blockchains, Ethereum does not support native stake delegation, meaning ETH holders can only stake by operating their own validator or relying on a third-party entity, such as a smart contract application, exchange, or custodian, to manage stake on their behalf. Further, validators are not equivalent to node operators. Thousands of validators can be operated on a single node. However, validator node operators are discouraged from doing this because of the compounding nature of slashing penalties. Large staking providers commonly operate hundreds of validators on a single node.

The following chart illustrates the amount of ETH penalized per validator by the percentage of validators also penalized in the same period:

Slashing Penalty Per Validator, % Faulty Validators, 36 Days post-event, Christine kim
Slashing Penalty Per Validator, % Faulty Validators, 36 Days post-event, Christine kim

Ethereum’s model for validators, which only allows users to stake in 32 ETH increments, is designed to encourage independent validator node operators and discourage stake centralization to staking pools. On Ethereum, there is an additional layer of trust and complexity that ETH holders must take on to stake through a service provider as there is no native stake delegation functionality. Additionally, service providers must take extra precautions to spread out user assets across multiple machines to reduce the risk of high correlation of staking penalties, thereby encouraging hardware and software client diversity among validator node operators.

Whilst encouraging decentralization and a diversity of different types of staking services (i.e., independent, fully trusted, and permissionless staking services), Ethereum’s model for validators is naturally inclined to rapidly grow the number of validators as the amount of ETH staked on the network rises. Instead of consolidating to a single validator node operator, the new ETH staked is bundled in 32 ETH increments and used to create new validators. Every active validator fulfills basic on-chain duties such as proposing blocks, voting on blocks, and monitoring for irregular and malicious behavior from other validators.

The networking layer of Ethereum is defined as the series of protocols through which nodes communicate and propagate messages about the state of the blockchain to other nodes. (To clarify, the networking layer is a peer-to-peer gossip protocol that is separate from the actual blockchain itself and is how nodes communicate). The higher the number of active validators, the more messages need to be propagated for the network to come to a consensus about its current state. One of the most common messages that are propagated by validator nodes on Ethereum are block attestations. Validators earn rewards for attesting to the validity of a block, that is voting on the correct “head” of the blockchain, and these rewards decline the longer it takes for a validator to propagate their attestations through the network.

The following is a chart depicting the reward scale for validator attestation by inclusion distance, that is the distance from a block proposal, which occurs by slot, or every 12 seconds.

Ethereum Validator, Attestation Reward Scale, christine kim
Ethereum Validator, Attestation Reward Scale, christine kim

Every attestation is created through a cryptographic signature scheme known as the Boneh–Lynn–Shacham (BLS) signature scheme. For every new validator that joins Ethereum, one additional BLS signature must be aggregated per epoch to progress the chain. The process of attestation aggregation, which is integral to the process of block creation and finalization, is becoming increasingly difficult as the number of validators and therefore, BLS signatures increases. In May 2023, Ethereum experienced large-scale network disruptions delaying transaction finalization due to issues with software client logic that were exacerbated by rapid growth in Ethereum’s validator set. Further, Ethereum developers have identified an increasing frequency of block reorgs and missed blocks in the first two slots of an epoch likely due to increasing latency in attestation aggregation.

As the size of Ethereum’s validator set grows, validator node operators will need to use more sophisticated hardware to support larger bandwidth and internet speeds. Therefore, an unbounded growth to the validator set size is a centralizing force that would reduce the number of independent node operators over time. To avoid node centralization, Ethereum protocol developers are working on solutions to limit validator set size growth and thereby reduce strains on networking requirements. Aside from concerns on Ethereum’s peer-to-peer layer, a large validator set size poses challenges to achieving a future upgrade known as single slot finality (SSF) on the development roadmap alongside other upgrades such as danksharding, statelessness, and enshrined proposer builder separation.

Single Slot Finality

Ethereum’s PoS consensus mechanism is a combination of two models, LMD GHOST and Casper FFG. The former favors chain liveness over chain finality, meaning it is designed to create consensus between many participants in a short period of time with weak guarantees on block and transaction finality. Casper FFG, which works in tandem with LMD GHOST, is a PoS model that favors chain security over liveness by guaranteeing the finality of blocks over time with high penalties for reverting transactions. In practice, validator node operators decide on the canonical state of Ethereum based on the fork choice rule defined by LMD GHOST. After two epochs or 12.8 minutes, votes from validators at each epoch checkpoint are aggregated to trigger chain finalization according to the rules of the Casper FFG consensus model.

Simplified Timeline, Ethereum Fork Choice Rule, Christine Kim
Simplified Timeline, Ethereum Fork Choice Rule, Christine Kim

The combination of the two models ensures that even if 1/3 of validators were to stop operating, the network would continue to add new blocks to the chain without fail and, eventually, once the number of validators reaching consensus about the state of the chain regains a 2/3 majority or higher, then automatically offer end-users finality guarantees backed by at least 1/3 of total ETH staked on the network. Combining both liveness and security is the primary strength of Ethereum’s PoS consensus mechanism. However, due to the complexity of overlaying Casper FFG atop LMD GHOST, there are drawbacks to this mechanism as well, which Vitalik Buterin noted in his post on paths forward for SSF. Some of these drawbacks include:

  • User experience: Ethereum and its 12.8 minutes for chain finalization is not ideal for users, especially exchanges, that could benefit from stronger chain finality guarantees in a shorter time frame.

  • Block reorgs: If short-range block reorgs are possible before chain finalization, this opens opportunities for sophisticated actors to identify opportunities for frontrunning, backrunning, and other types of maximal extractable value (MEV) by not just reordering transactions within a block but replacing blocks in their entirety. As far as Ethereum developers are aware, block reorganizations for MEV have never occurred on-chain since the Merge upgrade but this is a problematic possibility that Ethereum developers are seeking to mitigate through SSF.

  • Interaction bugs: There exists general protocol complexity and edge cases that can be exploited for profit at the expense of chain liveness between the interaction of LMD GHOST and Casper FFG that are difficult to address and patch without scrapping the dual model for consensus in its entirety.

SSF represents a potential path forward for addressing all the above drawbacks by revamping Ethereum’s consensus mechanism to rely on either model at any given point in time instead of both. If 2/3 of validators are online, then the model for consensus that favors chain security could be used to guarantee immediate chain finality. If less than 2/3 of validators are online, then the model for consensus that favors chain liveness could take over and oversee block production in the interim until more validators come online. The exact algorithm behind SSF to dictate the switch on and switch off behavior has yet to be fleshed out, though there are multiple proposals that have been shared by Ethereum researchers in recent months.

The following is an illustration of one proposal for SSF called RLMD-GHOST:

SSF Proposal, RLMD-GHOST, confirmation status, Galaxy Research, Christine Kim
SSF Proposal, RLMD-GHOST, confirmation status, Galaxy Research, Christine Kim

Caption: Simplified illustration of RLMD-GHOST

Source: Francesco D'Amato, Luca Zanolini

Based on the vision for SSF, there is a high likelihood that the use of Casper FFG to provide immediate chain finality under assumptions of high validator participation will mean that the network can only support a limited number of validators. An unbounded growth in the number of validator attestations that may need to be aggregated per epoch would delay chain finality. Under SSF, a delay to chain finality would mean a delay to transaction execution given the assumption of more than 2/3 of validators being online. To avoid potential delays to transaction execution based on the size of the validator set, there are several proposals to limit validator growth which would complement paths toward achieving a more efficient and simpler model for PoS consensus on Ethereum through SSF.

Ways to Reduces Validator Set Size Growth

Since June 2023, Ethereum protocol developers have been assessing different ways to reduce validator set size growth that could be implemented in the next 6 to 12 months on Ethereum. They include:

  1. Adding an upper epoch churn limit bound: Proposed by a pseudonymous developer for the Lodestar (CL) client team by the name of “Dapplion,” this solution suggests capping the churn limit such that the maximum number of validator entries and exits per epoch is fixed. At present, the churn limit is 12 and increases as the active validator set size grows. The proposal would limit the growth of the validator set size by a certain number per epoch.

    Projected Churn, Limit Bound, Christine Kim
    Projected Churn, Limit Bound, Christine Kim

    Capping the churn limit would effectively curb the growth of the validator set size as the following illustration shows.

    Projected Validator Set, Growth, Maximum Churn Limit, Christine Kim
    Projected Validator Set, Growth, Maximum Churn Limit, Christine Kim
  2. Adjust reward curve of validators downwards: Dapplion’s proposal may discourage new stakers from joining Ethereum, especially if the activation queue grows larger because of bounds placed on the churn limit. It may also discourage existing stakers, who have already passed through the activation queue, from unstaking and thereby concentrate rewards to staking incumbents, rather than new entrants. Therefore, the proposal is likely to trigger second order effects on staking markets and the value of liquid staking tokens on Ethereum. To avoid favoring staking incumbents, another short-term solution to limit the growth of the validator set size is to simply adjust Ethereum’s security spend—i.e., unilaterally reduce the issuance rewards of validators to disincentive new validators.

  3. Increase validator maximum effective balance: With enough fees and MEV per block, it is unclear whether reducing validator rewards would have a material impact on appetite from ETH holders to stake their ETH and curb the growth of the validator set size. Further, it is unclear how much the reward schedule should be adjusted for temporary relief of the problem without doing more research and consultation with Ethereum stakeholders, especially staking providers. Arising from these uncertainties is another proposal by Ethereum Foundation Researcher Mike Neuder to increase the maximum effective balance of validators. This would allow validators to accrue higher rewards by increasing their staked ETH balance beyond 32 ETH up to 2048 ETH. To be clear, the proposal does not propose a change to the minimum balance of ETH required to become a validator on Ethereum, that is 32 ETH, only a change to the maximum effective balance of validators.

The following is an illustration of the maximum amount of ETH a validator can earn per year with an effective balance of 32 ETH:

Annual ETH Earned, One Validator, Total Active Validators, chart, Christine kim
Annual ETH Earned, One Validator, Total Active Validators, chart, Christine kim

Under Neuder’s proposal, validator rewards would scale as a function of the total amount of staked ETH as opposed to the total number of active validators.

There are several benefits to increasing the maximum effective balance of a validator aside from addressing the issue of validator set size growth. The first is that it would remove the infrastructure complexity of many large staking providers as they would not have to activate multiple validators in 32 ETH increments to earn more rewards. Further, the auto-compounding feature of this proposal may improve the appeal of solo-staking by empowering independent validators to benefit from compounded earnings without staking through a larger service provider. The main concern with this proposal is its complexity, as it would require paths for existing validators to switch to auto-compounding rewards, variations to stake based weighting for validator votes, and new considerations for slashing risks undertaken by consolidated validators.

The first two solutions presented above are not designed to address all concerns with validator set size growth but merely act as a quick mitigation to reduce the growth of the problem until more robust proposals can be drawn up. Neuder’s proposal is a relatively more complex and involved solution that is being worked on by Ethereum developers for potential activation in a hard fork upgrade following Cancun/Deneb. While Neuder’s proposal would permanently remove the 32 ETH cap on a validator’s effective balance, it is not the only solution for addressing validator set size growth, especially over the long-term.

A few ideas that have been raised for limiting the validator set to a specific number over the next 2+ years include:

  1. Super-Committees: Instead of the entirety of the validator set size participating in earning rewards each epoch, a subset is randomly selected, and their votes aggregated. There are questions around how big this active set should be to maximize security but also attestation aggregation efficiency. Additionally, super committees would require some amount of code complexity to maintain a growing validator set size but frequently choose some subset. Wealthy validators may also game this system by favoring more validators to increase their chances of being selected for a committee.

  2. Economic capping of total deposits: Another alternative is economic capping, which would penalize all active validators if the validator set size grows beyond a certain number. A specific validator set size would be maintained through a dynamically adjusting reward curve that flips negative once a threshold of validators is reached. The rewards and penalties would impact all new and existing validators equally. While this approach would avoid the complexities and attack vectors of managing a queue of validators into super committees, it also increases the potential for a discouragement attack, where a wealthy validator temporarily sustains a high penalty to drive out other validators to establish dominance and earn more MEV.

  3. Floating minimum balance: The final alternative being considered for a long-term solution is to implement a floating minimum balance where the lowest-valance validator is kicked out if the validator count exceeds a certain number. This would ensure a dynamically adjusting validator minimum balance that adjusts as the demand for staking increases. This proposal would, of course, favor staking pools and quickly cut out independent stakers that don’t have sufficient balances. Consequently, that outcome could expedite plans to introduce some type of native stake delegation to Ethereum to avoid reliance on third-party, out of protocol entities.

Outlook

On Thursday, September 14, during ACDE #170, Ethereum protocol developers agreed to move forward with Dapplion’s proposal as a short-term solution to the growing validator set size and create an upper bound to the validator churn limit of 8 validator entries per epoch. This proposal has since been formalized into an EIP, EIP 7514, and will be activated alongside 8 other EIPs in the Cancun/Deneb upgrade. The Cancun/Deneb upgrade is tentatively slated for activation on Ethereum mainnet some time in Q4 2023 or Q1 2024.

The Holesky test network for Ethereum which is designed to support 1.4 million validators, is scheduled for launch on Friday, September 15. During the development of Holesky, developers had initially aimed to launch the testnet with 2.1mn validators, which was three times the number of validators on Ethereum mainnet at the time. However, during simulations for Holesky, developers ran into networking issues causing validators to submit late attestations and block proposals, which is why developers ended up launching the testnet with 1.4mn validators, instead of 2.1mn. As the largest Ethereum testnet, Holesky is designed to be an invaluable resource for developers and validator node operators to experiment with code changes and various proposals impacting a network of Ethereum’s size or larger.

As of September 14, Holesky is 76% larger than Ethereum in terms of the size of its validator set. Based on current projections, under the assumption that the churn limit is consistently maxed out, Ethereum will reach 1.4mn validators by May 2024.

Projected Churn Limit Bound, Growth of Validator Set, Max Churn, Limit of 8, Christine kim
Projected Churn Limit Bound, Growth of Validator Set, Max Churn, Limit of 8, Christine kim

In practice, the Ethereum validator queue is dropping dramatically, having reached a high of 95,000 entering validators in June 2023 and dropping to below 40,000 as of September 2023. Assuming no new validators enter this queue, the growth of the validator set may naturally start to slow by early October.

number, ethereum validators, entry que, christine kim
number, ethereum validators, entry que, christine kim

The long-term solutions that have been proposed face challenges and concerns of encouraging stake centralization to professional staking entities as opposed to individuals. However, one of the main challenges around deciding on a long-term solution to validator economics that discourages the growth of the active validator set beyond a certain threshold whilst also encouraging decentralization is governance. Changing the economics of Ethereum is a highly contentious and political issue that Ethereum protocol developers are not keen on engaging. More so than the technical merit around these long-term solutions, Ethereum protocol developers will be relying on social consensus from the broader Ethereum community to move forward with one proposal over others in the months and years ahead.

Conclusion

Ethereum protocol developers are actively discussing solutions to the problem of the network’s growing validator set size. Projected to reach 1.4mn by the end of May 2024, the number of active validators on Ethereum has been steadily increasing since the Shanghai/Capella upgrade. The urgency of this issue has encouraged developers to implement a short-term solution, that is limiting the validator entry churn to 8, in the forthcoming Cancun/Deneb upgrade. However, developers will likely have to prioritize a long-term solution to this issue in upgrades following Cancun/Deneb. The two main reasons for slowing the growth of the validator set size are reducing unnecessary bloat on the peer-to-peer layer from high volumes of messages from validators and improving the ease of implementation for future roadmap upgrades such as SSF.