EJECTION_BALANCE review: improving UX, risk, and decentralisation

[darrenlangley]

The EJECTION_BALANCE parameter very roughly sets the lower bound for how much a validator can lose while participating in Ethereum Proof-of-Stake (PoS). The current value is 16 ETH so a validator that experienced an event, such as, a significant quadratic leak could lose 16+ ETH of their 32 ETH deposit.

This is a particularly harsh outcome for a validator:

• For Solo Stakers - this causes a tremendous amount of fear, increasing the barrier-to-entry
• For Centralised Staking Operators - this poses a massive risk to their business
• For Decentralised Staking Protocols - their operators are required to provide significant collateral to cover the risk

A higher EJECTION_BALANCE value would reduce the maximum loss to a validator, alleviating the problems above.

Reducing the maximum loss (even probabilistically), would certainly improve UX, risk, and contribute to decentralisation.

We are seeking feedback on whether this change is possible? If it is, what maximum value for the EJECTION_BALANCE is feasible? or desirable? and could be considered for a future hardfork (such as Capella).

[mcdee]

Also worth noting that an increase in EJECTION_BALANCE would reduce the time the chain has to wait if not finalizing due to inactive validators going through inactivity leak. This, of course, means that "briefly" inactive validators would more likely be ejected before they can remediate whatever issues they have, but if this comes in with Capella when withdrawals are available it mitigates the risk that such validators end up with their funds locked for a long period of time.

I would suggest that an increase in EJECTION_BALANCE would not decrease the financial exposure to stakers, due to the fact that slashing risk still exists, but it would have benefits for both individual stakers and the network as a whole.

For reference, here is the current state of effective balance of active validators on mainnet:

 f_effective_balance | count  
---------------------+--------
         29000000000 |     24
         30000000000 |     11
         31000000000 |     12
         32000000000 | 364641

[ralexstokes]

you say bug, i say feature :)

if the EJECTION_BALANCE is higher, then I have greater risk of leaving the active set through what may be accidental (and not adversarial) behavior where I am then placed into an exit queue that could be very long (effectively locking up my capital and forcing upon me an opportunity cost)

and while a higher EJECTION_BALANCE would shorten the "recovery" time during a chain-wide inactivity leak it means also that I, as an attacker, have to sustain an attack for a much shorter period of time before I can start to do something resembling a "hostile takeover"

this being said, it would be worth quantifying this period of time at various higher EJECTION_BALANCES and see if we can keep "reasonable" numbers at a higher limit.

@mcdee I'm assuming this table is the full active set, meaning the lowest effective balance is 29 ETH? I wonder what the leak situation looks like if the EJECTION_BALANCE is 20 ETH, rather than 16

[mcdee]

This is the inactivity leak curve, assuming balance starts at 32 ETH and final inactivity quotient value:

In terms of number of days to hit a given effective balance, it is:

31:  2.28 days
30:  5.16 days
29:  6.97 days
28:  8.46 days
27:  9.76 days
26: 10.94 days
25: 12.05 days
24: 13.10 days
23: 14.12 days
22: 15.11 days
21: 16.07 days
20: 17.03 days
19: 17.93 days
18: 18.92 days
17: 19.87 days
16: 20.82 days

[johnwongapi]

Previous discussion on higher EJECTION_BALANCE #2108

[Warfront1]

Someone please correct me if I am wrong on the following.

Assuming a 4% yearly yield on your staked 32 Ethereum it would take roughly 13 years to obtain 16 Ethereum. If I am understanding this correctly, as a staker you are currently betting that you won’t be caught up in a severe quadratic leak over the course of 13 years to just break even. Ironically, the only way I can think to mitigate such a risk is a multi-region and multi-cloud approach. As you extend your time horizon, the likelihood of a scenario emerging where one-third of the network is jeopardized, and an individual staker cannot intervene, appears increasingly plausible to me. I could make a list ad nauseam, but to mention a few high hitters: natural disasters, network outages, power outages, etc. While it would require exceptionally severe instances or combinations of the aforementioned events to happen, the likelihood is definitely not zero.

[dapplion]

Please note that a higher ejection balance only slightly attenuates the downside risk of balance loss to stakers in the case of a mass offline event.

See https://lighthouse-blog.sigmaprime.io/maxeb-inactivity-leak.html