# EIP 7251 Explainer
A non-technical guide to understanding proposed changes under EIP 7251

In essence, EIP 7251 is a reaction to the rapid growth and success of Ethereum's validator network. It hopes to pave the way for Ethereum's continued scalability and functionality by addressing computational limits and streamlining validator operations.

The Ethereum network has circa 800k validators and, at current growth, will hit over one million by the end of 2023.

While this growth is positive, it is putting a strain on the network to perform.

Ethereum Researcher Aditya discussed the pressure on the P2P network in May 2023.

Shortly after Devops at Ethereum Foundation were running some tests in the new Holesky testnet (Holesky launched in September 2023 and will replace [Goerli](https://github.com/eth-clients/goerli) as a staking, infrastructure and protocol-developer testnet.), developers discovered that client software computational limits were being tested; at 2.1 million validators, the chain could not finalise because of the large number of validators overworking the peer-to-peer network.

At the current pace, Ethereum validators on the mainnet would hit 2.1m in just 11 months and potentially face a similar finality issue.

Keep track of the number of validators: https://beaconscan.com/statistics

> Test results: https://notes.ethereum.org/@parithosh/bigboi-beaconchain-test-2

Pari, DevOps:

“I expected the test to be a basic sanity check that we can do a 2.1M testnet, and we can commit to Holesky being under that value; the first failure kind of surprised me and triggered streams of thoughts as to where we could use this data. Seems like we inadvertently found some upper thresholds of the beacon chain”.

These tests showed that the Ethereum mainnet would face computational limits with this many active validators. The computational load on nodes could increase by 3x with the increased messaging volume on the networking layer. https://ethresear.ch/t/removing-unnecessary-stress-from-ethereums-p2p-network/15547

**Potential Solutions**

The issue has been discussed at the All Core Devs meeting, and Ethereum researchers have been discussing potential actions that can be implemented.

1. Dapplion proposed capping the churn limit at 12 validator entries and exits per epoch *Currently, the limit for active validators grows as the validator set grows; this would limit the growth - however, this would be a short-term fix, which other developers are against implementing.
2. Ethereum Researcher Dankrad said that, in his view, adjusting the reward curve for the validator was a more equitable way, to curb the growth of the validator set size than capping the churn limit.
3. EIP 7251 proposal created by Ethereum researchers is to allow one validator to hold up to 2048ETH; every ETH inside this would have the opportunity to earn rewards and propose blocks.

**EIP 7251**

To tackle the growing number of validators, EIP 7251 proposes a change to a field in the validator construct that does not affect other areas, such as validator economics.

The field in question is the MAX_EFFECTIVE_BALANCE (‘Max Effective Balance’).

- Effective balance: Represents the amount of ETH staked by each validator. It helps in:
- Deciding when a validator is ready to be activated.
- Computing penalties and rewards.
- Weighing validator attestations.
- Choosing a proposer.
- Assigning a validator to a committee, and more.

- It is capped at a maximum set by the MAX_EFFECTIVE_BALANCE (Currently 32 ETH).
- If a validator's balance goes beyond this cap, the withdrawal is activated for the extra balance.

The new proposal effectively has a MIN of 32 and a MAX of 2048 ETH. Allowing a consolidation of multiple validators into one.

- Create a ‘MIN EFFECTIVE BALANCE’ of 32 and a ‘MAX EFFECTIVE BALANCE’ of 2048
- Sixty-four validators can be consolidated into one.


**Why MAX_EFFECTIVE_BALANCE should be increased:**

1. **Future Upgrades:**
- The current validator set size prevents achieving "single-slot finality".
- Introducing enshrined Proposer-Builder Separation (ePBS) becomes risky with the current large validator set.
2. **Current Consensus Layer Challenges:**
- Large validator sets lead to delays and resource utilization problems.
- The network's p2p layer faces challenges due to the many attestations from different validators.
- There's a high withdrawal load every epoch due to validators exceeding the current MaxEB.
3. **From a Validator's Perspective:**
- **Solo-stakers:** They cannot compound their rewards as staking pools can. By raising the MaxEB, rewards can compound for validators of any size.
- **Large-scale stakers** currently manage thousands of validators, making it operationally intensive. Raising the cap might reduce their operational overhead.

**Examples**

A) If you were a large operator staking 256k ETH with 8000 Validators, this proposal would allow you to reduce to 125 validators.

B) If you are a solo staker with 40ETH, you can now use your entire balance (40) to receive rewards. Currently, solo stakers do not have access to compund like a bigger pool.

**Reasons Against Increasing the MaxEB:**

1. **Simplicity:** With its fixed constraints, the current system makes it easier to reason about different consensus aspects. Changing this could divert focus from other critical areas.
2. **Committee Considerations:**
- Given varying validator stakes, partitioning might lead to uneven influence in committees.
- A reduced validator set might increase the probability of a malicious actor dominating a committee.


**Slashing Risk Analysis**

The biggest concern raised during large staking pool feedback was the potential for significant slashing events.

Based on this, a new analysis and a new quadratic scale have been proposed:

- Adjust the Initial Penalty so it either doesn't increase as the validator's balance increases, or it increases but at a slower rate than before.
- The correlation penalty is modified to scale quadratically rather than linearly.

Conversely, we suggest leaving the attestation and inactivity leak penalties unchanged.


Full details here: https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509

Another EIP that has a strong desire by node operators to be introduced with **EIP 7251 is EIP-7002: Execution layer triggerable exits.**

Validators utilize two keys: an active BLS key for routine tasks and a withdrawal credential for managing staked ETH.

While the active key is frequently used, only it can initiate a validator's exit.

This design can cause issues when separate parties hold the two keys, as the staked ETH owner (withdrawal credential holder) needs help to start the withdrawal process independently.

This could lead to trust problems like the active key holder potentially withholding ETH. To address this, the new specification allows those with the 0x01 withdrawal credentials to trigger exits, providing trustless control over staked ETH for all users, including smart contracts.

Other key points

- It also is an ‘opt in’ proposal, so a solo staker / pool can continue to get automated rewards skimmed, as is the case at present.
- Consolidation is also a pro-social behaviour with the health of the overall Ethereum network. Additionally, consolidation of validators could reduce the number of beacon nodes that staking pools need to maintain. This could lower operational/infrastructure costs.
- We believe that the security of the protocol is not meaningfully impacted by increasing the `MaxEB`. Please see the [security considerations doc](https://notes.ethereum.org/@fradamt/meb-increase-security) for more details.
- Proposed custom withdrawal amounts i.e. a validator can exit 400 ETH of 2048 ETH without having to full exit.
- [Ethereum Researcher Aditya makes a very valid point that DVT can increase security of large validators](https://ethresear.ch/t/removing-unnecessary-stress-from-ethereums-p2p-network/15547#resilience-in-staking-infrastructure-8) that DVT can help security with MaxEB increasing.
"Currently, large stakers have their stake split into multiple validators running on independent machines (I hope!). By consolidating their stake into a single validator running on one machine, they would introduce a single point of failure in their staking infrastructure. An awesome solution to this problem is Distributed Validator Technology (DVT) 22, which introduces resilience by allowing a single validator to be run from a cluster of machines"

**Will this impact the decentralisation of the network?**

The current system currently inflates Ethereum decentralisation because many validators can be run by a single staker.

This proposal will give a more realistic overview while allowing:

1. Future upgrades are unblocked (e.g. [single slot finality](https://ethereum.org/fil/roadmap/single-slot-finality/))
2. improved performance of the *current consensus mechanism and p2p layer.*
3. Enhances operational efficiency for both small and large-scale validators.
4. It could potentially reduce the 32 ETH requirement in the future.

**Potential Timeline:**
EIP 7251 would be included in Electra. The consensus layer upgrade following Deneb.

**EIP 7251 Resources:**

First discussion around removing stress on P2P network
https://ethresear.ch/t/removing-unnecessary-stress-from-ethereums-p2p-network/15547

Testing 2.1 million Validators
https://notes.ethereum.org/@parithosh/bigboi-beaconchain-test-2

EIP 7251 Proposal

https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801

EIP 7251 FAQ
https://notes.ethereum.org/@mikeneuder/eip-7251-faq
Slashing Analyis
https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509

Lido Questions
https://docs.google.com/document/d/17R_OaZSqTG-zbDPdWy2sB280TBPIgMRA-zVEP-N4TQk/edit#heading=h.auj94rdsub84

[DRAFT] Increase the MAX_EFFECTIVE_BALANCE – a modest proposal
https://notes.ethereum.org/eFrRbZUkT3OoF2md08gSoA

Previous Discussions

https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219

https://notes.ethereum.org/@vbuterin/single_slot_finality#The-good-news-gains-from-enabling-voluntary-validator-balance-consolidation