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

7 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: EIP-7251: Implications of Increasing MaxEB for Validators.

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.

4 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

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

The proposal has the nice side effect of also increasing the average total value locked by the sync committee, making slashing approach for that more desirable in the future: EIP-7657: Sync committee slashings

8

Having these not in the CL ExecutionPayload makes local verification of EL block_hash complicated for the CL.

Generally, all of the new EIP-7685 “general purpose execution layer request” tend to share some of that, but the types 0 and 1 are at least somewhat mappable back to something of which the block hash can be computed by an optimistically syncing CL (while EL is undergoing maintenance, it cannot answer INVALID_BLOCK_HASH so the CL has to do it internally).

I’d advocate to try and replicate the three lists (deposit receipts / withdrawal requests / consolidation requests) into the EL block header as separate fields (instead of EIP-7685), and/or to create a EIP-6493 style StableContainer as their union, given their overlapping nature in common fields.

Currently the EIPs seem a bit… ad-hoc to me, which is alright for the initial devnet, but should be cleaned out later on.

Furthermore, all the extra BeaconState fields break trustminimized Merkle proof verifiers for decentralized staking pools such as RocketPool. It should be considered to combine this with EIP-7688: Forward compatible consensus data structures.

Have put it on the ACDE agenda as well: Execution Layer Meeting 187 · Issue #1029 · ethereum/pm · GitHub

9

Have the following scenarios been taken into account:

  1. initiating a validator exit with 32 ETH and then topping it up to 2048 ETH (would it allow me to go around the churn limits?)
  2. initiating a validator exit with 32 ETH and then consolidating other validators to the exiting validator (would it allow me to go around the churn limits?)

a separate question:

  • since on consolidation we are not really exiting the staked ETH, would it be possible to maintain a map of consolidated validators to their new indices for the period that would normally be driven by the churn limit without applying the actual churn limit delay? this would still allow us to slash the ETH (slash the target) while not delaying the consolidation of large operators
10

Should there a be a sequential index on these (across all blocks), to help distinguish between multiple copies of the same exit data?

Deposit requests and withdrawals have a unique index as well.

11

If the idea is for MAX_CONSOLIDATION_REQUESTS_PER_PAYLOAD to increase in the future, the Merkleization limit should be put to a theoretic limit (similar to how it is done for blobs). Otherwise, increasing the limit later breaks hash_tree_root.

12

Two questions regarding the EIP-7251:

  1. Custom Validator Ceilings:

    There are a lot of blog posts and resources mentioning validators being able to set custom validator ceilings, i.e., custom max EB, e.g., of 64 ETH, after which any excess amount would be automatically swept to the withdrawal credentials as currently done.

    In a breakout room discussion in April 2024 [Hack MD, Ethereum Breakout Room, Decision on Custom Ceilings], I read the feature of custom ceilings was removed from this EIP-7251 due to lack of demand. Is this correct?

    Thus, the incoming Pectra upgrade (EIP-7251) will not allow for custom validator ceilings to sweep from? If I ran a 0x02 validator and I wanted to sweep anything above 64 ETH, I could not and I would have to pay for a partial withdrawal transaction?

  2. Initial slashing penalty reduction with EIP-7251:

    Given that the initial slashing penalty currently scales linearly, a validator with an EB of 2048 ETH would get slashed 64 ETH, because initial_slashing_penalty = 1/32 * EB = 1/32 * 2048 ETH = 64 ETH.

    To make consolidation more popular, I found two resources regarding lowering this penalty:

    1. Initial slashing penalty set to a constant value of 1 ETH [Ethereum Notes, Mike Neuder, Slashing Penalty Analysis EIP-7251]
    2. Initial slashing penalty still scaling with EB, but a lot smaller than before, 1/128 * EB, i.e., 1/128 * 2048 ETH = 16 ETH [Mike Neuder, Coinbase Webinar, April 2024].

    Which one reflects the latest decision? Are there any other decisions around the other slashing penalties you can update us on?

Thank you. @mikeneuder @dapplion

1 Like