Increase the MAX_EFFECTIVE_BALANCE – a modest proposal

Proof-of-Stake
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
54

Ethereum is a centralized product designed by Ethereum Foundation. Upgrades are prescribed by the Foundation and can include taking of funds (the DAO), change of Ether from an asset to a security (like this proposal) and other things that have a big impact on practical impact on the community.

Because this is a business, because Ethereum Foundation is liable to governments for its actions and marketing activities, and because the impact on owners of Ether is very large we should absolutely make protocol decisions with consideration of regulation.

I personally am one of 12 people presenting to the US Internal Revenue Service on their proposed crypto tax reporting rules. This is the largest regulation the US has made yet on crypto.

After we have decentralized Ethereum, i.e. making all upgrades actually optional with a different network ID for each upgrade… then we can make more decisions will less concern about regulation.

55

If this is true, then it means we have failed as a community to build the singular thing that we were trying to build in the first place, which was an open, permissionless, and uncontrolled financial system.

1 Like
56

Hello,

A small nit on the selection of sync committee validators, the current design takes into account increase of effective balance but with a very small difference between consolidated versus non-consolidated:

  • with k small validators, you can be up to k times in the same commitee sync with a lot of luck,
  • with 1 consolidated validator with k x 32 ETH, you have k times more chances to be picked once, but you don’t get the chance to be picked up to k times in the same sync committee.

There is likely a better mathematical way to express this, and difference is likely marginal so I doubt it matters in terms of security or rewards, maybe it could be documented/explicitly dismissed in the annotated/security considerations doc.

57

It is true. But I wouldn’t say we failed. We are just still scaffolding.

And these scaffolds make us vulnerable. So let’s get rid of the scaffolds.

1 Like
58

I published an in-depth explainer on EIP-7251 for those interested in learning more about the proposal to increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2048 ETH and implement in-protocol validator consolidation as a solution to the problem of contracting the Beacon Chain’s validator set: EIPs For Nerds #3: EIP-7251 (Increase MAX_EFFECTIVE_BALANCE).

The article explains how EIP-7251 modifies aspects of the consensus protocol like validator activation, deposits, withdrawals, and slashing penalties to enable validator consolidation while preserving the Beacon Chain’s existing security properties. It also addresses regarding increased slashing risk for large validators and (potential) regulatory issues arising from implementing EIP-7251’s auto-compounding rewards feature.

All comments/feedback are welcome.

3 Likes
59

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 32 ETH compounding annually with interest of ~3%, in 32 years you’d have ~82 ETH. If you don’t compound this annually, you end up with 64 ETH. Even if it takes a year to increment effective balance, these numbers are meaningful.

1 Like
60

I think 32 years is quite a distant time horizon. If we take a time period of 10 years, with yield at 3% and effective balance increment at 1 Ether, then with compounding you would have ~43.2 Ether Vs ~41.6 Ether without compounding. And this assumes that none of the rewards need to be withdrawn to pay taxes or operating costs; if 1/3 of returns were taken annually for these or similar purposes then the difference between compounding or not over 10 years is well under 0.5 Ether.

I get that compounding helps, but I’m not sure it’s any sort of immediate win for solo stakers when compared to those with a much larger amount of Ether to stake.

1 Like
61

I believe compounding should be every 7-8 days, same as the beacon withdrawal periods, not annually. Also taxes may be deferred with a custom withdrawal address that contractually removes the ability receive rewards until validators are exited…i.e. the exit option would be akin to choice of selling an asset or not, thereby deferring the taxes until sold…or if held until death completely eliminated with a step-up
in basis (US rules). Monetization over time could come in the form of Defi loans against the position as it grows in size. Could also highlight that the compounding effects increase substantially if staked through a levered validator like Rocketpool’s 8 ETH validators.

62

Hello.

Sorry in advance if this question doesn’t really have its place here.

I am a solo staker and I’ve never updated my credentials. I am afraid to do so because I think a partial withdrawal will be triggered and that I would lose the benefit of this EIP if it got implemented - ie that my 37 ETH become 32 ETH and thus I would not benefit from the stake increase calculation.

Am I right or would this proposal also theorically involve the ability to “add more stake to an existing validator” ? (ie add 5 ETH to my 32 ETH stake to increase it’s weight without exiting my current validator).

I am looking for a “what is the most likely to be implemented type of answer”. I don’t think I want to exit my validator (ever) and so exit+re-spining wouldn’t be an option for me.

Thank you so much.