EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

EIPs
1

Discussion thread for Add EIP: Increase the MAX_EFFECTIVE_BALANCE by michaelneuder · Pull Request #7251 · ethereum/EIPs · GitHub

Abstract

Increases the constant MAX_EFFECTIVE_BALANCE, while keeping the minimum staking balance 32 ETH. This permits large node operators to consolidate into fewer validators while also allowing solo-stakers to earn compounding rewards and stake in more flexible increments.

Motivation

As of October 3, 2023, there are currently over 830,000 validators participating in the consensus layer. The size of this set continues to grow due, in part, to the MAX_EFFECTIVE_BALANCE, which limits the stake of a single validator to 32 ETH. This leads to large amounts of “redundant validators”, which are controlled by a single entity, possibly running on the same beacon node, but with distinct BLS signing keys. The limit on the MAX_EFFECTIVE_BALANCE is technical debt from the original sharding design, in which subcommittees (not the attesting committee but the committee calculated in is_aggregator) needed to be majority honest. As a result, keeping the weights of subcommittee members approximately equal reduced the risk of a single large validator containing too much influence. Under the current design, these subcommittees are only used for attestation aggregation, and thus only have a 1/N honesty assumption.

With the security model of the protocol no longer dependent on a low value for MAX_EFFECTIVE_BALANCE, we propose raising this value while keeping the minimum validator threshold of 32 ETH. This increase aims to reduce the validator set size, thereby reducing the number of P2P messages over the network, the number of BLS signatures that need to be aggregated each epoch, and the BeaconState memory footprint. This change adds value for both small and large validators. Large validators can consolidate to run fewer validators and thus fewer beacon nodes. Small validators now benefit from compounding rewards and the ability to stake in more flexible increments (e.g., the ability to stake 40 ETH instead of needing to accumulate 64 ETH to run two validators today).

Related work – eip7251 related work · GitHub

6 Likes
2

I published an in-depth explainer on EIP-7251 for those interested in learning more about the proposal to increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2048 ETH and implement in-protocol validator consolidation as a solution to the problem of contracting the Beacon Chain’s validator set: EIPs For Nerds #3: EIP-7251 (Increase MAX_EFFECTIVE_BALANCE).

The article explains how EIP-7251 modifies aspects of the consensus protocol like validator activation, deposits, withdrawals, and slashing penalties to enable validator consolidation while preserving the Beacon Chain’s existing security properties. It also addresses regarding increased slashing risk for large validators and (potential) regulatory issues arising from implementing EIP-7251’s auto-compounding rewards feature. All comments/feedback are welcome.

3 Likes
3

Is it not necessary to also modify the ejection balance? If a validator consolidates their stake, they would lose substantially more from e.g. inactivity leak or lost keys before being ejected than retaining discrete, 32 ETH validators. Perhaps it should be proportional to the stake. Or am I missing something?

See also prior discussions

4

Dear authors of the proposal, given the latest news regarding including the EIP proposed into Pectra, I have several questions about the actual implementation.

  • How the sweep threshold will be set?
    • Would it be a validator private key or WC to initiate this value?
    • Would this value be changeable during validator operation?
    • Can this value be reduced? (effectively acting as a trigger for the partial withdrawal)
  • The point about the cancelation of the initial slashing does not seem to be researched. When should one expect clarifications?
  • How will validators consolidation be performed?

Any information available is appreciated!

1 Like
5

I believe this blog post answers my question

6

Hi @dgusakov. I updated the EIPs For Nerds: EIP-7251 article with information about the validator consolidation process. I consulted this article from @mikeneuder and team, so you can check that for answers to some of the other questions you asked.

The slashing penalty analysis has useful information on the cancelation of the initial slashing penalty. I haven’t seen anything concrete on the decision to remove the initial slashing penalty, but it’s part of the EIP-7251 feature set, so we should have more information about it soon enough. (I should update the EIP-7251 article once the info is available, too.)

1 Like