# FAQ on EIP-7251; Increasing the `MAX_EFFECTIVE_BALANCE`  *by [mike](https://twitter.com/mikeneuder), [francesco](https://twitter.com/fradamt), [dapplion](https://twitter.com/dapplion), & [mikhail](https://twitter.com/mkalinin2) – july 16, 2023* $\cdot$ *tl;dr; The continued growth of the validator set may cause instability in the existing Ethereum consensus layer due to p2p message load, beacon state size, and signature aggregation time. Additionally, the validator set inhibits progress towards Single-Slot Finality (SSF). Vitalik [discussed this](https://notes.ethereum.org/@vbuterin/single_slot_finality#What-are-the-issues-with-validator-economics) in October 2022 by pointing out that there exists a threshold for the size of the validator set past which BLS signature verification is no longer feasible on consumer-grade hardware. This begs the question of what to do if that threshold is surpassed while we aim to implement SSF. Vitalik encouraged the community to consider (i) voluntary validator balance consolidation, (ii) rotating the validator set so only a portion is active at a given time, and/or (iii) capping the validator set by changing the consensus layer economics. Since then, the validator set has grown from 445k to 669k, and post-Capella, the activation queue has [remained full](https://www.validatorqueue.com/) while the exit queue is nearly empty. The [non-finality event](https://ethresear.ch/t/cascading-network-effects-on-ethereums-finality/15871) in May was a major incident partially caused by the continual growth of the validator set. The [proposal](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801) to increase the `MAX_EFFECTIVE_BALANCE` (also [suggested](https://ethresear.ch/t/removing-unnecessary-stress-from-ethereums-p2p-network/15547) from the p2p network perspective by Aditya) takes a step towards item (i). We believe that limiting the growth of the validator set is critical to ensuring the decentralization and stability of the Ethereum consensus layer.* $\cdot$ ***Key takeaways*** `[I]` In the short & medium term, increasing the `MAX_EFFECTIVE_BALANCE` slows validator set growth without more drastic changes to validator economics (e.g., implementing a [validator set rotation](https://notes.ethereum.org/@vbuterin/single_slot_finality#Idea-1-super-committees) or [validator set capping](https://notes.ethereum.org/@vbuterin/single_slot_finality#Idea-2-validator-set-size-capping)). `[II]` In the long term, increasing the `MAX_EFFECTIVE_BALANCE` addresses technical debt and establishes a healthier network. A more managable validator set size enables SSF, opens up the potential to lower the 32 ETH minimum to become a validator, and places less load on beacon nodes and the p2p layer. $\cdot$ ***Purpose of this doc*** Present an FAQ on the `What?` and `Why?` of EIP-7251 and the accompanying post, ["Increase the `MAX_EFFECTIVE_BALANCE` – a modest proposal"](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801). $\cdot$ ***Thanks*** *Many thanks to [Danny](https://twitter.com/dannyryan), [Thomas](https://twitter.com/soispoke), [Terence](https://twitter.com/terencechain), [Anders](https://twitter.com/weboftrees), [Potuz](https://twitter.com/potuz1), [Sandra](https://au.linkedin.com/in/sandjohnson), [Roberto](https://twitter.com/robsaltini), [Justin](https://twitter.com/drakefjustin), and [Jon](https://twitter.com/jon_charb) for comments and discussions.* $\cdot$ ***Accompanying artifacts*** | **title** | **description** | | ---------- | ----------- | | [proposal](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801) | the initial ethresear.ch post | | [diff pr](https://github.com/michaelneuder/consensus-specs/pull/3/files) | a diff-view PR showing the draft of proposed the spec change | | [security considerations doc](https://notes.ethereum.org/@fradamt/meb-increase-security) | analysis of the security implications of this change | | [eip pr](https://github.com/ethereum/EIPs/pull/7251) | EIP-7251 open PR | ## FAQ ### What? *Questions around EIP-7251 concepts and mechanics.* 1. *What is the `MAX_EFFECTIVE_BALANCE`?* - The `MAX_EFFECTIVE_BALANCE` (abbr. `MaxEB`) is a consensus spec-defined [constant](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#gwei-values) that sets an upper bound on the `effective_balance` of a specific validator. 1. *What is `effective_balance`?* - The `effective_balance` of a [validator](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#validator) indicates how much stake the validator has from the point-of-view of the consensus mechanism. This balance is used by the protocol in many ways, for example, it determines (i) how often the validator is selected as a proposer, (ii) how much weight their attestations have, (iii) how much their slashing penalties are, etc. 3. *What is the partial withdrawals sweep?* - As of the [Capella hardfork](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md), withdrawals were enabled for validators. The partial withdrawals sweep [removes any validator balance over the current `MaxEB`](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#is_partially_withdrawable_validator) (32 ETH). Because this balance is above the `MaxEB`, it is not earning any rewards for the validators (it is not active), and thus is withdrawn (for free) to the specified address in the validator withdrawal credential. 5. *What is EIP-7251?* - EIP-7251 is the EIP accompanying the [proposal](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801) to increase the `MaxEB` from 32 ETH to 2048 ETH. 7. *Does EIP-7251 increase the minimum balance to become a validator?* - No. The minimum of 32 ETH to become a validator remains unchanged. This just increases the *maximum* active balance that a single validator can have. 9. *Why was the `MaxEB` set to 32 ETH in the first place?* - In the original sharding design, the attesting committee for each slot was split into subcommittees (referred to as `committee` in the [spec](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_committee)) that each needed to be majority honest. Capping the `MaxEB` at the relatively low value of 32 ETH allowed stronger guarantees about the safety of the subcommittees. Within the Danksharding design, the subcommittees are no longer levereged as previously expected; they are only used for attestation aggregation. Now we only need a single honest aggregator in each subcommittee, which makes the 32 ETH `MaxEB` unnecessary. 15. *What is the scope of EIP-7251?* - (1) increase the `MaxEB` and (2) allow for execution layer partial withdrawals. 11. *What are execution layer exits?* - Execution layer exits (proposed in [EIP-7002](https://ethereum-magicians.org/t/eip-7002-execution-layer-triggerable-exits/14195) and under active discussion for inclusion in an upcoming fork) allow validators to use their withdrawal credentials to trigger an exit from the execution layer (by creating a transaction that gets included in a block). EIP-7002 introduces a new precompile that can be called to initiate the exit. 13. *What are execution layer partial withdrawals?* - Execution layer partial withdrawals generalize execution layer exits to allow partial withdrawals (which are rate-limited in the same way as full exits) of any size (so long as the remaining balance is above 32 ETH) triggered from the withdrawal credential of a validator. EL partial withdrawals are critical to the UX of an increase to the `MaxEB` because they provide a way for validators to withdraw some but not all of their stake (given they have opted out of the partial withdrawal sweep). 17. *What are the security implications of increasing the `MaxEB`?* - We believe that the security of the protocol is not meaningfully impacted by increasing the `MaxEB`. Please see [security considerations doc](https://notes.ethereum.org/@fradamt/meb-increase-security) for more details. 18. *What are top-ups?* - Top-ups are deposits to already existing validators. In [`apply_deposit`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#deposits), the balance of a validator pubkey can be increased. These deposits skip the activation queue, but it doesn't currently matter because they can only increase the `effective_balance` of the validator to 32 ETH. If `MaxEB` is increased, these top-ups will be rate-limited along with all other deposits. This also allows existing validators to increase their `effective_balance` without exiting. 19. *What are the slashing risks associated with an increase in the `MaxEB`?* - A larger `effective_balance` results in a larger potential slashing for validators. For slashable attestations, the penalty still needs to be proportional to the validator `effective_balance` to maintain the security guarantees around `1/3-slashable` events. For proposer equivocations, however, the slashing penalty can be reduced to a fixed amount because the fork-choice weight of the competing forks doesn't depend on the equivocating proposer's `effective_balance`. We expect pools to continue splitting their ETH among separate validators to reduce slashing risk, but aim to allow them more flexibility in the amount of ETH they place in each validator. 21. *How does EIP-7251 impact large staking pools?* - Presently, large staking pools are forced to run many validators because they must divide their stake into 32 ETH chunks. With this proposal, large pools can consolidate their stake into a smaller set of validators that have more weight. Again this doesn't increase the proportion of the validator set by stake-weight that is controlled by large staking pools, it just reduces the number of validators they run. 22. *How does EIP-7251 impact solo-stakers?* - Solo-stakers benefit from more flexible staking amounts. For example, a 40 ETH validator would earn rewards on their extra 8 ETH instead of needing to deploy it elsewhere. Additionally, solo-stakers can benefit from auto-compounding of their ETH whereas previously that was only possible through participation in a large staking pool. 23. *Are large validators selected more frequently as proposers?* - Yes. The [proposer selection process](https://blog.rated.network/blog/solo-stakers) already uses `effective_balance` to weight the probability that a validator is selected as a proposer. This allows larger validators to continue being selected proportionally to their weight and thus doesn't reduce their rewards for participation (e.g., a 320 ETH validator is selected to propose 10x more frequentlythan a 32 ETH validator). 24. *How do very large validators make it through the activation queue?* - Activating validators who have more weight than the total amount of per-epoch churn are spread over multiple epochs. When processing a deposit, we calculate how many epochs will be needed to rate-limit the full amount. 25. *What is the envisioned UX for consolidating validators?* - We are still working through the design here. In the best case, we would have an in-protocol mechanism for validators to signal intent to consolidate without exiting and re-entering. In the worst case, validators would need to exit and re-enter in a new larger validator or by topping up an existing validator. The trade-off in this design space is complexity of the spec change (e.g., needing to track slashability of consolidated validator) vs. UX for validator consolidation. <!-- 23. How does EIP-7251 impact small/medium staking pools? - Small and medium size staking pools benefit from the auto-compounding nature of increasing the `MaxEB`. Smaller pools that do not earn enough to continually deploy new validators can use the fact that their stake auto-compounds to increase their capital efficiency. --> ### Why? *Questions around the motivation and necessity of EIP-7251.* 1. *What is the main reason for EIP-7251?* - To facilitate an efficient use of consensus-layer bandwidth. Under the current implementation, we are wasting beacon node resources by demanding that each staker sends extraneous consensus messages for every 32 ETH they wish to stake. Under the current roadmap, this no longer serves a purpose. 2. *What is the main benefit of EIP-7251 in the current situation?* - To slow the growth rate of the validator set. The validator set size is growing very quickly; if the activation queue remains fully utilized, we will have 1 million validators by late this year. Beacon nodes will continue to strain (e.g., ["Cascading Network Effects on Ethereum's Finality"](https://ethresear.ch/t/cascading-network-effects-on-ethereums-finality/15871/2)) under the networking, beacon state size, and signature verification burdens from such a large set. <img src="https://storage.googleapis.com/ethereum-hackmd/upload_518c049d3345fc13a69e9d8f8b2242cf.jpeg" width=70%> The figure above shows the validator set size growth if the activation queue remains full for the coming months. The red lines indicate when the churn allows an additional validator activation per-epoch (which is determined by the weak-subjectivity period calculations). We can expect to have more than a million validators within the next 5 months. The following plot shows the APY of the CL rewards as a function of the validator set size. <img src="https://storage.googleapis.com/ethereum-hackmd/upload_087811e5e125a88ed28673ec2b36bbb1.png" width=70%> We don't expect this reward schedule to decrease quickly enough to stop encouraging new stakers, especially with MEV (EL) rewards. 4. *What are some of the risks of not increasing the `MaxEB`?* - If we allow the validator set to continue growing uninhibited, we run the risk of overexerting the consensus-layer clients in terms of signature aggregation and state size. Additionally, processing each epoch transition is linear in the validator set size and we already see many missed slots around the epoch boundary as a result (figure from [Toni](https://twitter.com/nero_eth)). <img src="https://storage.googleapis.com/ethereum-hackmd/upload_35786f1dc8b149c9d6f56359a849f40e.jpeg" width=90%> The first and second slots in an epoch have a much higher probability of being reorged due to the latency introduced by the epoch processing. Additionally, the rate of reorgs, in general, has been increasing steadily ([source](https://twitter.com/jcksie/status/1668559049040748545)). <img src="https://storage.googleapis.com/ethereum-hackmd/upload_ca07d50e614ac5061dfd433a085e8f0a.png" width=90%> While there are many factors contributing to this, it is reasonable to assume that it is related to the increase in the validator set size. If client teams are forced to start adding further performance optimizations to handle larger validator set sizes, the risk of bugs and cascading failures increases. Further, if higher bandwidth and compute resources are necessitated (see [dapplion's initial analysis](https://hackmd.io/@dapplion/beacon_load_set_size)), solo-staking becomes more costly, which is a centralization pressure on an already [small set](https://blog.rated.network/blog/solo-stakers) of solo-stakers. 4. *Why would staking pools consolidate their validators?* - A validator set consolidation could eliminate the need to take more dramatic economic measures to limit the validator set size (e.g., reducing the economic rewards or using a rotating validator set). Consolidation is also a pro-social behavior that signals alignment with the Ethereum roadmap and the health of the overall network. Additionally, consolidation of validators could reduce the number of beacon nodes that staking pools need to maintain. This lowers operational/infrastructure costs (the actual impact may be marginal because they still will distribute the stake over many validators). 6. *Why do we need execution layer partial withdrawals as part of the EIP?* - Without EL partials, the UX of an increase to the `MaxEB` is quite poor. Because validators would opt out of the partial withdrawal sweep, they would no longer receive a regular withdrawal from the CL layer rewards. Without partial withdrawals, they would need to fully exit the validator to have access to any of the ETH they earned. This would be too poor of a UX to encourage any participation. EL partials make it so validators can withdraw a portion of their stake without needing to do a full exit. 7. *Does this change encourage centralization?* - No. In fact, compounding being more readily available to small hobbyists reduces the centralization vector of seeking large pooling for a higher APY. The centralized staking pools already benefit from compounding rewards because they can use the current partial withdrawal sweep to deploy new 32 ETH validators. The total amount of ETH controlled by the big staking pools will not change, just the number of validators they are required to run will be reduced (e.g., a pool running 1000, 32 ETH validators controls the same weight in the consensus layer as the same pool running 32, 1000 ETH validators). 9. *What parts of the roadmap depend on this proposal?* - Single-slot finality (SSF) introduces large changes to the consensus layer. For SSF, there is likely no viable forward without a validator set contraction. See Vitalik's ["Paths toward single-slot finality"](https://notes.ethereum.org/@vbuterin/single_slot_finality) for further discussion.