Each unit ETH in the effective balance has the same likelihood of proposing and the same attestation weight as before.
Imagine a network with 2 real entities, one with 32 ETH and 1 validator, and another with 128 ETH in 4 validators. The entity with 32 ETH has 20% chance of selection, and 100% chance of proposing if selected, while the other entity has 80 and 100% chance for the same.
If the max EB was raised to 256 ETH, and the large entity consolidated its stake, the 32 ETH entity would have a 50% chance of selection, but only a 12.5% chance of proposing once selected, while the larger entity has 50% chance of selection, and 50% chance of proposing if selected.
Multiplying these out gives you 6.25% chance for the small entity and 25% chance for the large one. Since these don’t add up to 100% you have the “increased loop iterations” where you ping-pong between them more to decide who proposes, but with their odds of proposing normalized, the 32 ETH entity proposes 20% of the time, while the 128 ETH entity proposes 80% of the time.
The benefit of compounding rewards for solo stakers is pretty large, and their chance of proposing doesn’t fall due to a change in Max EB, only an increase of ETH being staked by others.
Reducing the operational overhead of managing many validators(benefits large-scale stakers)
Not entirely clear/convinced.
From the perspective of a firm that handles at-scale stake:
We keep each “environment” to 1,000 keys, 32,000 ETH, for blast radius reasons. How many validator keys that is does not impact the operational overhead even a little bit. I am happy to unpack that further if warranted, if there are questions as to the exact nature of operational overhead.
If I have validators with 2,048 ETH, how does that impact the slashing penalty in case of a massive f-up? I am asking - is there a disincentive for large stakers to consolidate stake into fewer validators?
If I have validators with 2,048 ETH, does this reduce the flexibility of LST protocols to assign stake? For example, “the large LST” currently is tooled to create exit requests 32 ETH at a time, taking from older stake and NOs with more stake first. 2,048 ETH makes it harder for them to be granular - but at the same time so far there have been 0 such requests generated, so maybe 2,048 is perfectly fine because it wouldn’t be a nickel-and-dime situation anyway. Maybe someone at that LST can chime in.
Followup thought: Maybe the incentive for large-scale staking outfits is a voluntary “we pledge to run very large validators (VLVs) so you don’t do a rotating validator set”
Definitely see the advantages of this. Would this also reduce bandwidth requirements for some nodes, as currently running more validators means subscribing to more attestation gossip topics? Bandwidth is already a limiting factor for many solo/home stakers and could be stressed further by EIP-4844, seems any reductions there would be helpful.
But I’m also looking to understand the downsides. Presumably when the beacon chain was being developed, the idea of supporting variable-sized validators must have been discussed at some point, and a flat 32 ETH was decided to be preferable. Why was that, and why wasn’t this design (with all its benefits) adopted in the first place? If there were technical or security concerns at the time, what were they, and what has changed (in this proposal or elsewhere in the protocol) to alleviate them?
Are there any places in the protocol where equal-sized validators are used as a simplifying mathematical assumption, and would have to be changed to balance-weighted?
Generally strongly in favour of this proposal. Has any thought been given to how this might impact products and services related to the staking community? Restaking services like EigenLayer may be particularly interested in analysing the consequences.
Very interesting proposal. From the perspective of the core protocol’s efficiency, I do see the benefits, but I can’t support it in its current form due to the problems it presents for UX.
As presented, this proposal forces compounding upon all stakers. It’s not opt-in, so skimming is no longer reliable income for stakers. I appreciate the simplicity of this change, but it clearly sacrifices one UX for another.
To make this a true upgrade for all users, partial withdrawals would need to be implemented as well. Of course, this presents the same CL spam issue that partial voluntary exits have always had.
To solve this, I suggest we change the order of operations here. First, let’s discuss and finalize EL-initiated exits for both full exits and arbitrary partial amounts. The gas cost would be an effective anti-spam filter for partial withdrawals, and then we can introduce this change without affecting users as much. It does means the current UX of free skimming at a (relatively) low validator balance would now incur a small gas cost, but I think that’s a much more reasonable trade-off to gain the advantages of this proposal. And to some extent, the CL skimming computation is incorrectly priced today anyway.
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.
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.
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.
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.
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.
We keep each “environment” to 1,000 keys, 32,000 ETH, for blast radius reasons. How many validator keys that is does not impact the operational overhead even a little bit. I am happy to unpack that further if warranted, if there are questions as to the exact nature of operational overhead.
this makes a lot of sense. i think some staking operators would like to reduce the key-pair management, but maybe it isn’t a huge benefit. (if the benefits for big stakers aren’t that high, then that is ok IMO. we care most about improving the health of the protocol and helping small stakers compete.)
If I have validators with 2,048 ETH, how does that impact the slashing penalty in case of a massive f-up? I am asking - is there a disincentive for large stakers to consolidate stake into fewer validators?
right, slashing penalties still are proportional to the weight of the validator. this is required because consider the case where a 2048 ETH validator double attests. that amount of stake on two competing forks needs to be slashable in order to have the same finality guarantees of today. we see the slashing risk as something validators will need to make a personal decision about.
If I have validators with 2,048 ETH, does this reduce the flexibility of LST protocols to assign stake? For example, “the large LST” currently is tooled to create exit requests 32 ETH at a time, taking from older stake and NOs with more stake first. 2,048 ETH makes it harder for them to be granular - but at the same time so far there have been 0 such requests generated, so maybe 2,048 is perfectly fine because it wouldn’t be a nickel-and-dime situation anyway. Maybe someone at that LST can chime in.
i am not as familiar with the LST implications you mention here!
Followup thought: Maybe the incentive for large-scale staking outfits is a voluntary “we pledge to run very large validators (VLVs) so you don’t do a rotating validator set”
absolutely! again, we are proposing something that is purely opt-in. but encouraging it from a roadmap alignment and network health perspective is useful because any stakers that do consolidate are helping and should be recognized for helping.
Definitely see the advantages of this. Would this also reduce bandwidth requirements for some nodes, as currently running more validators means subscribing to more attestation gossip topics? Bandwidth is already a limiting factor for many solo/home stakers and could be stressed further by EIP-4844, seems any reductions there would be helpful.
yes! less validators directly implies less attestations so a reduction in bandwidth requirements.
Why was that, and why wasn’t this design (with all its benefits) adopted in the first place? If there were technical or security concerns at the time, what were they, and what has changed (in this proposal or elsewhere in the protocol) to alleviate them?
the historical context is around the security of the subcommittees. in the original sharding design, the subcommittees needed to be majority honest. this is not the case for 4844 or danksharding, so now the subcommittees are just used to aggregate attestations (1 of N honesty assumption). we talk a bit more about this in this section of the security doc: Security Considerations and Spec Changes for a MAX_EFFECTIVE_BALANCE Increase - HackMD
Are there any places in the protocol where equal-sized validators are used as a simplifying mathematical assumption, and would have to be changed to balance-weighted?
only a few! check out the spec pr if you are curious: https://github.com/michaelneuder/consensus-specs/pull/3/files. the main changes are around the activation and exit queues, which were previously rate limited by number of validators, and now are rate limited by amount of ETH entering or exiting!
Generally strongly in favour of this proposal. Has any thought been given to how this might impact products and services related to the staking community? Restaking services like EigenLayer may be particularly interested in analysing the consequences.
staking services providers have seen this and we hope to continue discussing the UX implications for them! i am not sure if any restaking services people have considered it specifically! i will think more about this too
As presented, this proposal forces compounding upon all stakers. It’s not opt-in, so skimming is no longer reliable income for stakers. I appreciate the simplicity of this change, but it clearly sacrifices one UX for another.
sorry if this wasn’t clear, but the proposal ~is~ opt-in. that was a big design goal of the spec change. if the validator doesn’t change to the 0x02 withdrawal credential, then the 32 ETH skim is still the default behavior, exactly as it works today.
To solve this, I suggest we change the order of operations here. First, let’s discuss and finalize EL-initiated exits for both full exits and arbitrary partial amounts. The gas cost would be an effective anti-spam filter for partial withdrawals, and then we can introduce this change without affecting users as much. It does means the current UX of free skimming at a (relatively) low validator balance would now incur a small gas cost, but I think that’s a much more reasonable trade-off to gain the advantages of this proposal. And to some extent, the CL skimming computation is incorrectly priced today anyway.
i do love thinking about how we could combine the EL and CL rewards, but this paragraph seems predicated on the 32 ETH skimming not being present. i agree that in general, the tradeoff to consider is how much spec change we are OK with vs how the UX actually shakes out. i think this will be the main design decision if we move forward to the EIP stage with this proposal.
My main concern with the proposal as currently written is that it seems to degrade the UX for home stakers. Based on my reading of the code in your current proposal, if you’re a home staker with a single validator and you opt into being a compounding validator, you won’t experience a withdrawal until you’ve generated MAX_EFFECTIVE_BALANCE_MAXEB - MIN_ACTIVATION_BALANCE ETH, which (based on your 11 year calculation) would take ~66 years.
Speaking for myself, I don’t think I’d want to opt into this without some way to trigger a partial withdrawal before reaching that point. You have to pay taxes on your staking income after all
Off the top of my head, I can think of 2 ways to mitigate this:
Enable MAX_EFFECTIVE_BALANCE_MAXEB to be a configurable multiple of 32 up to 2048 by either adding a byte to every validator record or utilizing the WITHDRAWAL_PREFIX and reserving bytes 0x01…0x40 to indicate the multiple of 32.
Hey @mikeneuder thanks for the clarification! I have to admit that I only read your post, I didn’t click through to the spec change PR. The 0x02 credential is the first thing to pop up there
At first glance, a withdrawal credential change sounds like a great way to make this proposal opt-in while leaving the original functionality unchanged, but there are hidden costs.
Although this isn’t an objection, it’s worth noting that suggestions to add optional credential schemes are a philosophical departure from 0x01, which was necessary. While the conception of 0x00 makes sense historically, today it makes little sense to create 0x00 validators. Put another way, if Ethereum had been given to us by advanced aliens, we’d only have the 0x01 behavior. At least the Ethereum community, unlike Linux, has a view into the entire user space, so maybe one day 0x00 usage will disappear and can be removed safely. Until then, though, we’re stuck with it. Do we really want to further segment CL logic and incur that tech debt for an optional feature? Again, not an objection per se, but something to consider.
Regardless, I suspect that achieving this via EL-initiated partial withdrawals is better because users will want compounded returns anyway, even with occasional partial withdrawals.
Optimal workflow if MAX_EFFECTIVE_BALANCE is increased for all users after EL-initiated partial withdrawals are available:
combine separate validators (one-time process)
partially withdraw when bills are due
repeat step 2 as needed, compound otherwise
Optimal workflow if MAX_EFFECTIVE_BALANCE is increased for an optional 0x02 credential:
combine separate validators (one-time process)
exit entirely when bills are due
create an entirely new validator
go back to step 2 and 3 as needed, compound otherwise
Even if the user and CL costs end up similar under both scenarios, the first UX seems better for users and the network. The 0x02 path may only be worthwhile if validator set contraction is truly necessary in the short term. Otherwise, we have a better design on the horizon.
Absolutely the UX is a critical component here. The initial spec proposal was intentionally tiny to show how simple the diff could be, but it is probably worth having a little more substance there to make the UX better. We initially wrote it so that any power of 2 could be set as the ceiling for a validator, so you could choose 128 to be where the sweep kicks in. This type of question I hope we can hash out after a bit more back and forth with solo stakers and pools for what they would make use of if we implement it
thanks for the thorough response @Wander ! I agree that the first workflow sounds way better! Again we mainly made the initial proposal with the 0x02 credential to make the default behavior unchanged, but if we can get a rough consensus with everyone that we can just turn on compounding across the board with EL initiated partial withdrawals, then maybe that is the way to go! (it has the nice benefit of immediately making the withdrawal queue empty because now withdrawals have to be initiated and there is no more sweep until people hit 2048 ETH).
Noting that reducing state size also facilitates (or unlocks depending who you ask) another item from the roadmap. Single Secret Leader Election, with any possible construction would require a significant increase in state size (current Whisk proposal requires a ~2x increase)
@mikeneuder my mistake, I was under the impression that raising the effective balance would alter the real-world reward dynamics but in light of DrewF’s explanation I stand corrected. What - if any - impact on RANDAO bias-ability? Is the current system implicitly assuming that each randao_reveal is equally likely, and if so how would the higher “gravity” of large effective balances play out?
Excellent proposal, especially raising the node cap to 2048 (or even 3200, seems entirely reasonable to me). Currently on the Beacon Chain, the addition of new nodes requires an excessively long wait time. For instance, on June 18th, there were over 90,000 nodes in queue, and they needed to wait for 40-50 days, which is extremely disheartening for those new to joining ETH consensus.
In fact, from my personal interactions, I’ve come across many users who hold a significant amount of ETH. Considering the daily limit on nodes the consensus layer can accommodate, if one individual holds 2000 ETH, under this new proposal, they would only occupy 1 node instead of 62-63 nodes. This could potentially increase the efficiency of joining the node queue by 10x or even 20x, enabling more people to join staking at a faster rate. This also reduces people’s reliance on centralized exchanges for staking (simply bcuz there is no waiting time in cexs), which would make ETH network more robust.
@0xTodd The amount of eth is rate limited into and out of the active validator set for security reasons (security margin epoch-over-epoch degrades as eth enters/leaves). Not the number of validators.
In the event such a proposal goes into effect, the amount of ETH that can enter and leave per unit time would generally remain unchanged (unless the security margin was decided to be changed).
Hey @mikeneuder. This is a very thoughtful proposal.
You mentioned in your counter arguments the current ejection balance is 16 ETH.
Would you propose to maintain an ejection balance of 16 ETH with a MaxEB > 32 ETH?
Is there room in this proposal for a validator to set a custom ejection balance with the intent to limit their losses on a single validator?
One could imagine a scenario where a solo staker loses access to their validator key and encounters a permanent hardware failure, while still maintaining access to their withdrawal address.
