Increase the MAX_EFFECTIVE_BALANCE – a modest proposal

hi TheCookieLab! thanks for your response :slight_smile:

This would significantly decrease “real” decentralization by effectively raising the 32 ETH solo staking floor to whatever the new EB value would be. Sure while one can still spin up a validator with 32 ETH, its influence would be one of a second-class citizen when compared to one with “maxed out” EB.

i don’t understand this point. how does it become a “second-class citizen”? a 32 ETH validator still earns rewards proportional the size of the validator. the 32 ETH validator is still selected just as often for proposing duty.

  1. The SSF numbers you provided as rationale are straw-man numbers (quite literally - the linked Horn proposal calls them “A Strawman Proposal” and notes significant improvements are possible with multi-threaded implementation).

agree! there can be improvements, but regardless, i think the consensus is that doing SSF with a validator set of approx. 1 million participants is not possible with current aggregation schemes. especially if we want solo-stakers to meaningfully participate in the network.

  1. You refer to the current 600K validator set as “artificially high” but the Ethereum upgrade road-map extensively uses 1-million validators as a scaling target. How can we currently be at “artificially high” levels despite being well under the original scaling + decentralization target?

it’s artificially high because many of those 600k validators are “redundant”. they are running on the same beacon node and controlled by the same operator; the 60k coinbase validators are logically just one actor in the PoS mechanism. the only difference is they have unique key-pairs. Solo stakers: The backbone of Ethereum — Rated blog is a great blog from the rated.network folks showing the actual amount of solo-stakers is a pretty small fraction of that 600k.

  1. You point to the May 11th & 12th, 2023 non-finalization as evidence of undue stress on the P2P layer however the root cause of said event was due to unnecessary re-processing of stale data. The fact that there were clients that were unaffected (namely Lighthouse) shows that the problem was an implementation bug rather than being protocol level.

it was certainly an implementation bug, but that doesn’t mean that there isn’t unnecessary strain on the p2p layer! i linked Removing Unnecessary Stress from Ethereum's P2P Network a few times, but it makes the case for the p2p impact.

  1. The two pros listed under “validator perspective” are questionable. Sure, solo-stakers can now compound additional rewards, but at the trade-off of (potentially drastic) lower odds of proposals, sync committee selections, etc. This would be a huge net loss for the marginal 32 ETH solo staker. As for large-scale stakers, there is already tooling to manage hundreds/thousands of validators so any gain would be a difference in degree rather than kind, and even the degree diminishes by the day as tooling matures.

this is the part that there must be confusion on! the validators have the same probability of being selected as proposer and sync committee members. the total amount of stake in the system is not changing and the validators are still selected with a probability proportional to their fraction of the total stake. as far as the large validators go, we have talked to many that would like to reduce their operational overhead, and they see this as useful proposal! additionally, it is opt-in so if the big stakers don’t want to make a change, then they can continue as they are without any issues.