What is EIP-725: Increase max_effective_balance?
Dencun is right around the corner and there’s some exciting EIPs included in the upgrade which should rocket boost L2 uptake, Ethereum L1 scalability and validator experience.
https://www.ethereumcatherders.com/dencun/
However my eyes are already on potential Pectra EIPs and especially those which could impact validators and stakers. One of which is EIP-7251: Increase max_effective_balance.
Introduction to EIP-7215
This EIP would keep the minimum amount to run a validator at 32 ETH but would increase the max from the current ceiling of 32 ETH to a value of 2,048 ETH.
Why is this being proposed?
- CONSOLIDATION: There are currently over 978,000 active Ethereum validators, however this does not mean that there are almost 1m unique entities running validators.
Instead any entity who wants to contribute a large amount of ETH towards validation activities must currently spin up multiple validators because each is capped at a maximum of 32 ETH. This means some entities are running hundreds if not thousands of validators.
Twinstake, as an institutional staking provider has clients who stake millions of dollars worth of ether and therefore needs to run thousands of validators on behalf of clients.
Likewise services such as liquid staking providers are running thousands of validators which pool together the ETH from their many stakers.
There are c33,000 unique withdrawal credentials which would estimate that there’s less than 30,000 entities running validators — however this is certainly an upper bound since some entities may want to use distinct withdrawal credentials to reduce concentration risk or segregate funds for regulatory purposes.
The upgrade from EIP-7251 would allow these large node operators and entities to consolidate their ETH into fewer validators. This could reduce infrastructure complexity and would remove a faux-decentralisation view where it’s not the case that more nodes = more decentralisation.
2. COMPOUNDING: Solo stakers currently have to wait until they receive 32 ETH in rewards from their validator before they can spin up a new validator.
This upgrade would allow their ETH to be compounded into their existing validator and contribute to their rewards without first having to accumulate the minimum validator amount. This would also impact larger stakers, however since their rewards will compound to 32ETH quicker it’s less impactful for them in a time-to-new-validator perspective.
3. SUSTAINABLE GROWTH: There are currently over 900,000 validators, and growing. This increasing set size means it’s more cumbersome for nodes to communicate with each other and this is also a blocker for single slot finality (SSF) — the idea to enable a block to be fully validated within one slot rather than the current two epochs that it takes to finalise right now. This upgrade would hopefully lead to a reduction in the total number of validators and so reduce bandwidth use across the network for the various cross-validators communications which need to happen, and therefore pave the way for SSF work in the future.
How will this upgrade work under the hood?
To enable stakers to more easily consolidate across validators, it will be possible to create a consolidating transaction which will exit X validators (the sources) and move their stake into another validator (the target). This consolidating transaction must be signed by the source’s withdrawal credentials and the target’s signing key.
For the period of time (256 epochs) that the source validators are existing, they will not be earning rewards and can be slashed for any previous bad behaviour.
There will need to be changes to the activation and withdrawal queue to account for this max balance change. Since Dencun and EIP7514, it’s been possible for a fixed number of 8 validators to activate per epoch, and the number of validators that can exit is a dynamic value based on the total validator set size.
This equates to a value of 256ETH per epoch entering and currently 490ETH exiting (at 14 validators per epoch: https://www.validatorqueue.com/ ). However with EIP7251, a single validator could be entering/exiting anywhere from 32ETH to 2048ETH and as such the activation churn limit and exit churn limit need to change from a fixed validator number to a fixed ETH number.
The activation churn limit will therefore be changed to 438ETH and exit churn limit will continue to be dynamically set based on the validator set size.
However one additional element which comes into play is the activation_balance_to_consume and complementary exit_balance_to_consume — these are the remaining amounts from the churn limit for each epoch that can be activated or excited.
Walking through an example of the activation queue …
Imagine the activation queue has the following 4 validators:
Validator1 with a balance of 200 ETH
Validator2 with a balance of 100 ETH
Validator3 with a balance of 353 ETH
Validator4 with a balance of 32 ETH
Within epoch N, which has a churn limit of 438ETH, validator1 can be activated and since it’s activation_validator_balance is 200 ETH this leaves the activation_balance_to_consume at 238 ETH
Validator2 can also be activated since it has an activation_validator_balance of 100 ETH which is less than the remaining activation_balance_to_consume of 238 ETH. This brings the activation_balance_to_consume to 138 ETH.
Validator3’s activation_validator_balance of 353 ETH exceeds the activation_balance_to_consume of 138 ETH, this means that 138ETH of it’s balance is activated in epoch N and the remaining amount, 215 ETH is activated in epoch N+1.
Therefore a notable difference to the activation process right now is that a part of your total validator amount could activate in one epoch and then the rest could be in the next epoch.
It’s also worth noting that it will be possible to ‘top up’ an existing validator with amounts of 1ETH upwards, and this offers solo and smaller stakers the opportunity to slowly bump up their validator’s amount — significantly quickly than they can with the current 32 ETH minimum deposit.
Another new aspect of this EIP is the introduction of partial withdrawals which will allow a staker to be able to withdraw an amount from their validator which still keeps their balance above the minimum threshold of 32ETH e.g if the staker’s validator has a balance of 100 ETH then they can do a partial withdrawal of 68 ETH. This could mean that we start to see more activity regarding exits since currently a staker would need to exit a single validator worth 32 ETH even if they only needed access to a portion of that capital. Now they’d be able to have a validator with 64ETH and be able to withdrawal 5ETH, 10ETH or any amount which leaves at least the minimum. This brings more flexibility to stakers and could mean they’re comfortable having more ETH staked since they don’t have the minimum batch of 32ETH per withdrawal.
This partial withdrawal functionality is an extension of EIP7002: Execution layer triggerable exits in which the holder of the withdrawal credentials can exit a validator — whereas currently it is the holder of the singing keys ( https://eips.ethereum.org/EIPS/eip-7002 ). For institutional stakers, this gives them the direct ability to exit their validators, even if they’re being run by a third party. This EIP recognises the increasing number of stakers who are not running their own infrastructure but who are delegating this responsibility to a specialist infra provider — such as Twinstake, and ensures that stakers maintain control of when they enter and exit.
In line with this flexibility and access to staked ETH, this EIP also includes a custom sweep mechanism. Currently any amount above the 32 ETH threshold (from the consensus level rewards) for a validator is swept up and returned to the staker’s withdrawal credentials periodically. However with this EIP it will be possible for the staker to set a custom sweep amount and therefore have any amount above 32ETH and below this level returned to them each sweep.
What does this all mean from a slashing perspective?
When running a validator or staking towards a validator, the biggest risk to mitigate is the possibility of a slashing event, where you have some of your staked ETH taken by the protocol for behaviours which are against the fair running of the protocol e.g double signing a block.
Currently validators who are slashed loose an initial 1 ETH (or more specifically 1/32 * their validator_effective_balance). However in a post EIP7251 scenario where a validator’s effective balance could be up to 2,048 ETH, this could result in an initial slashing penalty of 64 ETH. As such, and to protect against compounded slashing risk for consolidated validators, the initial slashing penalty will be removed or modified to a fixed amount as part of this EIP. The final direction is still being discussed.
How will we know who’s opted in to use the EIP7251 functionality?
Validators who opt in to consolidate will set their withdrawal credentials to 0x02 and this will allow the max_effective_balance to be greater than the current 32 ETH. This extends the current withdrawal credential options from 0x00 for those ineligible for withdrawals and 0x01 for validators who are able to actively withdraw and means it will be easy to track the uptake of this new functionality.
https://pro.nansen.ai/eth2-withdrawals
When will this EIP be activated?
The simple answer is TBC.
It won’t necessarily be in the Prague Electra upgrade, plus due to the consolidating transactions requiring an exit and a balance increase, which must be processed in line with per-epoch limits on operations like this, merging the entire validator set could take up to 4 years! This is also looking to be an optional piece of functionality for validators and so whilst there’s benefits for validator operators and stakers, the speed at which they transition over to this new approach is uncertain.
So there’s no immediate activation nor result.
It is also worth noting that consolidations are optional, therefore whether node operators consolidate at first availability, later on or never is uncertain.
To dive further into this EIP I recommend watching this video: https://www.youtube.com/watch?v=3cVhNXDTjgg or reading the EIP: https://eips.ethereum.org/EIPS/eip-7251
Thanks to Marek Moraczyński for this feedback and inputs on this piece
Originally published at https://www.linkedin.com.
