Increase the MAX_EFFECTIVE_BALANCE – a modest proposal

Proof-of-Stake
31

hi @bkd – thanks for the response!

We totally agree that big stakers are running a variety of client nodes, in different data centers, diff cloud providers, etc. But the point we are making here is that they are logically controlled by the same entity so from the PoS mechanism perspective, they are a single unit.

More broadly, I’m not sure why we’re focusing on improving conditions for those who have > $50K to spin up a validator when I think we should really be spending time on how to enable validators to run with a smaller balance and thus further encourage solo and small scale stakers.

The benefits of the proposal for large validators are secondary to the overall benefits! The key takeaway is that the validator set is too large and growing incredibly quickly. In fact, as is, we have no hope of lowering the minimum of 32 ETH to become a validator, because of this validator set growth. If we have a consolidation, that is actually a viable path to considering lowering the minimum that wouldn’t be possible otherwise.

1 Like
32

At the top of the post:

Critically, we do not propose

  1. increasing the 32 ETH minimum required to become a validator
3 Likes
33

One open question here is how proposer slashings should be handled.

If the minimum slashing penalty is increased according to the current effective balance, then it would deter consolidation, as penalties for consolidated validators would be higher than for minimum stake (32 ETH) validators.

However, using a different mechanism will clash with the attestation slashing, which have to be proportional for security reasons.

Therefore I propose we change the proposer slashing to a penalty:

  1. Double proposer leads to a penalty, not a slashing. The amount is fixed and independent from the effective balance.
  2. Repeated penalties for the same proposer are allowed.
  3. Repeated penalties for the same slot are not allowed. (A bitfield is kept for the penalty period to record which slots have seen penalties)
  4. A double proposal penalty does not lead to a validator exit.
  5. There is no additional penalty according to the number of other validators being penalized/slashed.

Reducing the double proposer action from a slashing to a penalty is ok because no critical consensus properties depend on there being no double proposals.

5 Likes
34

How big would the penalty be?

How does the network react to double proposals? Does it reorg out both, or does it just coalesce on one or the other over the next handful of slots?

36

On the topic of ejection at 16 effective, and ACDC 112 discussion of having this track max balance.

While this could be friendly towards unaware operators, it also introduces some additional complexity to the protocol.

With EIP-7002, EL-initiated exits, do we need it? This is for operators that have lost their validator signing key but still have control over their withdrawal address.

They can initiate an exit from the withdrawal address and get their funds.

If they don’t have control over their withdrawal address, they won’t get funds anyway - and in that case, psychologically, it may feel better that it’ll take years for eth to land on that address, and that the amount will be relatively smaller.

37

EL-initiated partial withdrawals would be a strictly worse solution for all validators than the system we have today, due to it costing gas.

This proposal is only really of use to large staking operations. Is there any buy-in from such operations that they would want to utilize this proposal? Are the issues being addressed here the issue that large staking operations consider to be pain points? If not, then it seems unlikely that they will configure validators with much larger balances than the minimum required, as they bring attendant risks (e.g. cost of a validator being slashed) without significant upside (key management was mentioned, but managing a handful of keys or a few thousand keys has much the same process). And the danger of encouraging them by favoring configurations of larger validators would create a centralization vector.

2 Likes
38

Thanks for your comment Jim! I want to push back on a few things

This proposal is only really of use to large staking operations.

I think the solo-staking benefits are also meaningful! Auto-compounding, staking more than 32 ETH but less than 64 ETH, and EL-partials of any size are all things that people have expressed a lot of interest in.

Are the issues being addressed here the issue that large staking operations consider to be pain points?

Yes! The biggest concern we have heard is around slashing risk. This is why we are considering changing how proposer slashings work to no be proportional to the size of the validator (attester slashings ~MUST~ be proportional b/c they impact the fork-choice rule based on their weight).

And the danger of encouraging them by favoring configurations of larger validators would create a centralization vector.

For sure, this is something I am keen to avoid (incentivizing consolidation).

We have talked to a number of large staking providers and most are interested and want to see the full EIP and design and would do their own risk analysis. I think its naive to expect them all to fully consolidate, but I also think its safe to say that the cap of 32 ETH is quite low and there would be no meaningful increase in risk if they bumped their average validator size to say 128 ETH or something similar.

Two other points:

  1. There is an economic incentive to turn on auto-compounding because then the ETH above 32 is immediately earning rewards. Waiting for the withdrawals sweep to take place and then the deployment of a new validator through the activation queue is quite slow, so turning on auto-compounding would be an immediate boost in capital efficiency for small and large validators alike.
  2. I also see this as a near-term fix to minimize the continued bloat of the validator set. Even if the absolute size of the validator set doesn’t shrink, at least we may see a reduction in the rate at which it’s growing. This would help provide more time as we assess longer-term designs for the validator set (e.g., rotating validator set or changing the issuance curve to make it less profitable).

Let me know what you think :slight_smile:

39

For a solo staker? At time of writing it would take over a year for a validator’s effective balance to increase from 32 ETH to 33 ETH based on consensus rewards. And in many jurisdictions there are requirements to pay tax on staking rewards, so the time would be increased proportionately. Although auto-compounding is nice in theory, I don’t think that the numbers show this as something that would have a meaningful impact on solo staking rewards.

If you have a single validator with 2048 ETH then if there is an operational incident that causes the validator to be slashed you’re done. If you have 64 validators with 32 ETH each then you will likely have a fair amount of time (up to 31 slots) in which to save some of the validators. Given that slashing risk is the biggest concern, I’ don’t see why large staking services would consolidate their risk in this fashion.

As per above, the idea of “immediately” earning anything isn’t going to happen for smaller stakers with the way that Ethereum staking works, and for larger stakers their risk is lower by having multiple individual validators.

1 Like
40

At time of writing it would take over a year for a validator’s effective balance to increase from 32 ETH to 33 ETH based on consensus rewards.

We could easily consider making the increment 0.1 ETH for example! we haven’t bundled that with this change, but it could make sense to give better granularity!

And in many jurisdictions there are requirements to pay tax on staking rewards, so the time would be increased proportionately.

This among other reasons is why we initially want to leave the sweep alone! If they want the continuous dust swept for tax reasons, they don’t have to opt-in.

Given that slashing risk is the biggest concern, I’ don’t see why large staking services would consolidate their risk in this fashion.

We have talked to many who said they would! It is 100% a risk adjustment thing, but i think its safe to say that not everyone would choose a ceiling of 32 ETH for their validators if they had the flexibility.

for larger stakers their risk is lower by having multiple individual validators.

Its a risk-reward tradeoff though. Consider a larger validator who ascends that effective balance schedule faster (because larger stakers earn ETH faster), then they have more capital efficiency because they don’t have to do the withdrawal and activation queue. Some staking services may have different risk preferences and would take advantage of the higher capital efficiency.

It might make sense to think about doing some research specifically on the economics at play here for small and large validators. :thinking:

41

Right, but do you understand why the effective balance increment is currently 1 ETH, and why we have effective balance separate from balance?

Again, a full spec is required so that this can be looked at in the round rather than individual points. Because the answer to the question “would you like larger validators, fewer keys to manage, and reduced server costs?” is likely to be “yes” but that answer could well change if it resulted in a significantly higher cost if they were part to a slashing event.

At a glance, that would likely be an very minimal difference for anyone at scale (>1000 validators).

2 Likes
42

Decreasing increment by a factor of 10 (0.1 ETH) leads to rehashing every validator in the set roughly 10 times more frequently, which is 70 against 7 rehashing per epoch on average for 600,000. It doesn’t sound too bad complexity wise.

43

By itself, yes, but if this is introduced along with a higher maximum effective balance wouldn’t it cause additional rehashing as effective balances of all compounding validators would increment far more frequently?

Note that I haven’t looked at this specifically, I’m trying to point out that adjusting parameters in the protocol can have knock-on effects that need to be understood as part of the proposal.

1 Like
44

Seems like it would essentially be independent of the composition of the validator set (i.e., a 128 ETH-validator gets rehashed four times more frequently than a 32 ETH-validator)? There is also an opening for reducing the increment for larger validators, thus reducing the number of rehashes. In the most extreme version, you’d go with 0.4 for the 128 ETH-validator. This would make it neutral in terms of compounding rewards, but then larger validators may be more inclined to withdraw and start new validators to maximize their return (depending on fees). Or they may simply not opt for the larger validators, which is something we want them to. A compromise could be to log-scale the increment or something, if a fixed increment is deemed to favor large validators too much. However, as mentioned, it may be acceptable to favor large validators a little in this case, as long as the difference in expected return it is not too big, to nudge them into consolidating.

1 Like
45

This will likely be the case, not just for rewards, but liquidity in general. The main concern in this scenario is the queue time being inefficient, and opening up to more ops risk. Waiting 43 days (as of today) is not a great experaince, nor is having to spin down and up new nodes to juggle balances.

46

One interesting downside of this is that it will reduce the liquid ETH remaining for users who run validators. If Alice runs validators and puts in 100 ETH, she can run her maximum amount of validators (3) and will have 4 ETH to use on network activity. With this change, she can use all 100 ETH on her validator.

This becomes particularly dangerous in the case where staking becomes higher EV than any application (which could become possible with something like EigenLayer). This inactivity would be detrimental to the network.

47

Right so one point of this proposal is to avoid having to spin up new nodes just to maximize capital efficiency. So the increment can be tuned with that in mind. The current queue is a temporary anomaly and will eventually come down.

This is a separate issue which should (and very likely will) be addressed by lowering the staking yield. We want to make it as comfortable to stake as possible and not put up any artificial obstacles.

1 Like
48

Hello, I am writing here to argue AGAINST auto-compounding balances (as was raised at PM call 111, note there). And also possibly, as a side effect, against this proposal entirely.

Changing the fee to auto-compounding makes Ethereum appear as an interest-bearing security. We must end all consideration of this change.

A brief history of time

Some time in 2021 regulators in the United States, Europe and other regimes have basically come to accept Bitcoin and Ethereum as commodities/currency. This is a preferable to being considered a security. Hopefully this point does not require elaboration. Many other projects are considered as securities, from a now-famous comment by the U.S. Securities and Exchange Commission chair. Even other projects that are basically the same as Ethereum are considered securities, but Ethereum has been effectively exempted because “it’s been around for a while”, and “it’s running on its own.”

Then Ethereum released version 2.0 which makes Ether payments are given for participating in staking/validating.

Regulators have not said very much about this change. And they have not explicitly made a technical analysis of this mechanism. But generally the atmosphere is that “Ethereum is the same thing” and so there has not been a reevaluation.

Now Ethereum is preparing version 3.0 which changes Ether payouts to be auto-compounding. Yes, changing the way you pay out Ether is a MAJOR release version, every time. According to SemVer.

These are major changes

Every time we change payouts, fees, minting/burning, there is a possibility that regulators will reevaluate Ethereum and decide that it no longer qualifies as a commodity and that it instead is a security, or a money laundering platform or whatever else they want to classify it as.

Additionally, because Ethereum is a centralized application where you, the core devs, decide what is in the next version, and everybody else has to upgrade, the things you discuss (i.e. this meeting) are all part of the discoverable testimony that can be considered as part of regulators’ decisions. Eventually regulators will realize they can just compel you to ban Tornado Cash (U.S. Treasury) or require back doors in everything (EU Data Act), but that’s a blog post for a different day.

But back to compounding interest…

This major change

If a validator receives payment for validating, this is and appears to be payment-for-services. Normal people understand that. Regulators understand that.

If a validator receives a second payment for validating a second thing… same thing… that appears to be payment-for-services.

Let’s rewrite that with compounding.

The first time a validator receives payment for validating. Payment-for-services.

Then the second time the validator receives payment for validating… and ALSO extra payment for the money that they put into the system (i.e. the payout from the first services). What’s that? It’s interest. Normal people would call that interest. And regulators would call it that too.

Summary

In summary, a change to Ethereum staking payouts which introduces compounding payments is being considered. Normal people and regulators will see this as interest. Payout of interest might result in Ethereum being classified as a security by any of the myriad regulators on Earth. We must end any discussion of this.

Instead we must only consider validators as active, witting participants in the network security, whereas those people are performing effort to run validator nodes and Ethereum is paying them for their efforts in running a secure node. Running a secure node is difficult, trying new clients is difficult, and THIS is why payment is made to those participants. Payment is never based on, predicated on, or motivated by any investment in a common enterprise nor an incentive for moving money in (or not moving money out of) an account.

49

There isn’t any increase in risk probability, but having a 128 ETH validators in a large operation is increasing risk impact slightly less than 4x.

When an operator is slashed on attestations bc of a sloppy setup, software bug (non-malicious) etc, it usually happens to a small percentage of validators, is detected by a monitoring software and operator has time to turn off the offending setup. That has happened with Staked.Us (less than a hundred validators out of thousands slashed even when the detection takem hours), Rocklogic incident recently, etc.

The first equivocation in case of 128 ETH validator will have 4x impact immediately, and this impact now per 32 ETH validator is actually not very small - I think it’s around 1 ETH, combining together penalties, rewards unearned in exit queue and rewards unearned while in a deposit queue.

1 Like
51

Would be great to get more clarity here, what is a healthy balance point between the current queue mechanism and top off’s, since top off’s will open the door to queue skipping ? The path of least resistance will be taken, since “waiting” is a huge barrier to entry.

53

We shouldn’t make protocol decisions based on regulatory fears or fears in general. Regulation is a framework made up by nation states and has to be solved there (e.g. in DC) and is not a design input parameter to Ethereum.

1 Like