Add max epoch churn limit (EIP-7514)

[dapplion]

This proposal limits beacon chain active index growth rate. Huge active validator set sizes make future roadmap upgrades more difficult. While this proposal does not address the root cause of growth, it "buys time" for proper solutions that may be delivered many months into the future.

Projected fork schedule

• D fork: EOY 2023
• E fork: mid 2024

Proposals such as MaxEB can land on the E fork at the latest. By then beacon chain size could have reached > 2M active indexes.

chart source https://app.noteable.io/f/d0a86d09-bb88-4e47-96e8-e3a6e6f29183/Churn-limit.ipynb

This change should be very easy to implement in consensus clients. Due to the exponential behaviour of the churn, there's an incentive to include this proposal in the first available fork.

This proposal is introduced with 12 as a starting value, which is higher than today's churn and which may cause a regression in the epoch churn when activated.

Epoch churn regression

The spec as is can handle an epoch churn decrease of > 1.

For exits, the highest exit epoch with the previous churn is the starting point for the new churn:

def initiate_validator_exit(state: BeaconState, index: ValidatorIndex) -> None:
   ...
   exit_queue_epoch = max(exit_epochs + [compute_activation_exit_epoch(get_current_epoch(state))])
   exit_queue_churn = len([v for v in state.validators if v.exit_epoch == exit_queue_epoch])
   # After the transition exit_queue_churn maybe >> than get_validator_churn_limit(state) without causing issues
   if exit_queue_churn >= get_validator_churn_limit(state):
       exit_queue_epoch += Epoch(1)

For activations less validators are sliced from the activation queue

def process_registry_updates(state: BeaconState) -> None:
    ...
    # Dequeued validators for activation up to churn limit
    for index in activation_queue[:get_validator_churn_limit(state)]:
        validator = state.validators[index]
        validator.activation_epoch = compute_activation_exit_epoch(get_current_epoch(state))

[djrtwo]

Changes look good/correct.

It's certainly a sensible bandaid, but it is that -- a bandaid.
I'd want to at least consider what other bandaids are available if the problem is indeed urgent.

This exacerbates the time preference on capital that is already staking which has fairness issues and also potential second order effects on markets around liquid staking tokens and other things

[dapplion]

It's certainly a sensible bandaid, but it is that -- a bandaid.
I'd want to at least consider what other bandaids are available if the problem is indeed urgent.

In terms of bandaids that could make it to Deneb this is the only one I'm aware of.

This exacerbates the time preference on capital that is already staking which has fairness issues and also potential second order effects on markets around liquid staking tokens and other things

Agreed, we have to consider the costs and benefits on this proposal.

My mental model here is that besides the costs of large active index sets, reaching a very high % of supply staked will have negative consequences long term and it will be hard to undo. If reaching 60-80% of supply staked can trigger problematic tipping points (i.e. stETH overtaking ETH), there's value in preventing those scenarios from happening at all at some fairness cost.

I'm not aware of the speed of research around changing the rewards curve, but it won't make it to Deneb

[dankrad]

On balance, I am now in favour of this "quick fix".

I agree that adapting the economics directly is too hard short term. But also, the only direct economic fix right now would be to lower issuance significantly, to the extent that solo staking would likely become completely unattractive and would be replaced by only liquid staking. Lowering the churn limit will "freeze" the current economics, which will at least preserve the solo stakers we currently have and that are the backbone of Ethereum for censorship resistance. (Either way, we need to find a better solution long term, but it's better to do so from a world where we still have solo stakers)

[mcdee]

If we assume the activation queue will continue to be full, then at the end of the year the churn limit will be 17. Are we comfortable with a) such a sharp reduction, and b) the fact that get_validator_churn_limit() will now need to take in to account the fork version to return the correct value?

[dapplion]

b) the fact that get_validator_churn_limit() will now need to take in to account the fork version to return the correct value?

There have been fork dependent constants since the Altair fork, so it is not a problem from a client implementation perspective.

[anderselowsson]

From my perspective, a change to the issuance policy is the preferable solution, even in the short term. I am here focusing specifically on economic merits, while it obviously depends on technical aspects of updating the protocol as well. Generally, I hope we will improve the liquidity of staking going forward, not reduce it. We wish to make it as comfortable and easy as possible to stake. A modest reduction in issuance will temper the increase in staking more naturally. The main problems we may fear, such as spurring discouragement attacks or monopolistic pressure in the Ethereum transaction supply network (stakers collaborating at monopolistic choke points to bring down the deposit size) are not particularly affected by a one-time change to, for example, the base reward factor. They are instead affected by a change to the slope of the reward curve (e.g., a drastic fall in yield beyond some specific deposit size). There are also additional adjustments that will need to be made to the protocol if we make larger reductions in issuance, which we avoid in the short term by making a modest reduction. For example, if we implement more drastic changes to the issuance policy, we will first need to introduce a staking fee that kicks in at some issuance level, e.g., at 300 000 ETH annualized, and gradually increases as issuance falls. Its purpose is to preserve the economic relevance of, e.g., attestation duties when issuance yield falls, in light of proposer duties taking a larger piece of the pie due to MEV. Thus the purpose of the staking fee is not at first to generate overall negative issuance. Indeed negative issuance is not at this point something that we for certain will need to institute. It is instead to preserve the economic balance between validator duties, paying out substantial nominal rewards according to some invariance-preserved specification, while the real issuance yield is very low. Staking fees could perhaps also be targeted directly at proposers to further reduce variance, or rather, to move variance into the realm of failed block proposals. But this is a topic for another day.

The figure shows the validator yield at the current levels of realized extractable value (REV) across deposit size D and base reward factor F. The vertical lines suggest the range within which we would like to keep the deposit size (a complex discussion beyond the scope of this comment). The deposit size at The Merge was around 14 million ETH which can act as a “revealed preference” for the protocol at the lower end; that this is secure enough. The upper vertical line of around one million validators ($2^{25}$ ETH) has often been suggested by prominent figures in the Ethereum community. The purple curve is a hypothetical medium-run equilibrium, not accounting for the long-run effect of a shifting circulating supply (which can play out over decades). It is formed when using a supply curve (users’ willingness to supply stake) intersecting 25 million ETH at 2.5 % yield, with a yield elasticity of supply of approximately 2. Under that assumption, we may be able to keep the deposit size below $2^{25}$ ETH by reducing the base reward factor to 32 or 40. It is of course very much possible that the supply curve intersects 25 million ETH at a lower yield than 2.5 % (or has a higher yield elasticity) so we may still end up with an equilibrium above $2^{25}$. We have not yet reached an equilibrium at which our assumptions can be anchored, and will learn more about the yield elasticity of supply by studying how changes to the issuance policy alter the equilibrium going forward. But we will in any case push down the equilibrium significantly relative to the status quo even by a rather modest change to the base reward factor. Regardless of whether it is from 40 million ETH to 30 million ETH or from 70 million ETH to 55 million ETH, it is still a good first step.

The savings to the protocol of instituting a lower issuance quickly reach hundreds of thousands of ETH per year. For example, by bringing down rewards from the suggested equilibrium at F = 64 indicated by a circle to a hypothetical equilibrium of 2.5 % yield at 25 million ETH, we’d save around 764 000 ETH every year. This highlights the enormous amounts of ETH that the protocol would overspend on security under the current policy, with little to no benefit. It is the regular user transacting on-chain that will have to pay these unnecessary security fees, in the form of supply inflation of the ETH tokens they hold. This could ultimately stop the ETH asset from permeating and binding together the overall multi-layered Ethereum ecosystem. I will put up a draft of my paper on Ethereum reward curves in a while to hopefully bring some clarity on issuance policy. The associated models in Python are easy to adjust to any assumptions that individual researchers may wish to explore, e.g., regarding REV and supply. I will also suggest some reward curves that may be a little better than what is achieved by simply reducing the base reward factor, even in the short term. And then outline how we will shift focus from deposit size to deposit ratio. But we can discuss that later. In any case, if a reduction of F is something that is easier to come to an agreement on, then that would certainly be an improvement over the status quo in my opinion. While 32 is the memetic anti-bikeshedding value, even 40 or 48 gives improvements. Perhaps it is also easier to convince the community of a more modest reduction at first. Even if a reduction in rewards has been discussed by developers for several years, it may come as a surprise to some stakers, so there may take some time to readjust to this.

I’d also like to make two suggestions concerning the yield elasticity of supply that are relevant to the preceding discussion in this thread:

• It is not infinite. There is a big difference between the assumption that stakers would be willing to supply stake at 2 % yield when the deposit size is 25 million ETH and when it is 95 million ETH. The reservation yield of the “marginal staker” will rise across deposit size. Still, it is of course good to prepare for any eventuality, but it is not the most likely scenario that the reservation yield is 2 % at 95 million ETH staked. Most researchers are aware that the yield offered by the protocol (demand) will fall naturally with an increase in D, but some may have missed that the reservation yield of stakers (supply) will also rise with an increase in D.

• Solo stakers pay their fixed costs upfront, and delegating stakers pay all costs on an ongoing basis, pushing down the yield elasticity of supply for solo stakers relative to delegating stakers. Solo stakers have taken a deliberate decision to stake and have acquired both the right technology and knowledge. Knowledge acquisition will for many be the largest fixed cost if it were to be quantified. Delegating stakers often pay no fixed cost upfront, perhaps an hour of research into various LSTs or CEXes. They will pay a fee to cover the validating agent's fixed and variable costs. We cannot say for certain that the validating agent will keep the same percentage of the yield as a fee if the yield goes down, they may wish to increase their take to properly amortize their own fixed costs. A reduction in staking yield could thus reduce the delegating staker's yield more than the yield of the solo staker, who already invested upfront and who is paying no fee. What strategy validating agents will take for extracting maximum total fees from delegating stakers if the yield falls is however not perfectly clear. There is also a possibility that they end up in a race to the bottom where they are unable to recoup upfront costs. The point is that the overall arrangement does give the delegating staker an opportunity to walk away from any fixed costs that they no longer wish to help amortize. This is particularly relevant when we consider risks associated with delegated staking. Delegating stakers will continuously "pay" risk-adjustment “costs” that solo stakers do not need to bear, such as risks associated with the principal—agent problem of delegating their ETH. The mechanisms designed to regulate this also have inherent risks, whether it is smart contracts, on-chain governance, or legislation. When the yield is 5 %, this may not be a problem, but the risks do not go down just because the yield falls. Rather the opposite perhaps. Now there is the issue that solo stakers will indeed face the consequences if they make a mistake. But the delegating staker pays this cost as well. This is something that cannot only be baked into the staking fee. It is also the general risk to their funds in the eventuality of a catastrophic mistake or misdeed by agents acting on their behalf. There are thus many aspects of fixed costs that push down the yield elasticity of supply of solo stakers relative to delegating stakers. In a scenario where the yield falls, those aspects will work to the protocol's benefit.

When it comes to variable costs of running a validator, solo stakers could perhaps have a higher cost, but I suppose not substantially so on many setups. There is also the issue of liquidity and the exogenous yield that LST holders may extract in DeFi. When it comes to liquidity that does not involve collateralization, things like variable validator balances and other possible enhancements to the solo staking experience will be important, even if they cannot bridge the gap fully. Concerning collateralization, restaking services such as EigenLayer are coming online, and modules may be particularly interested in the decentralization that solo stakers offers (if they can quantify it). After all, so are we. Note also the difference between yield that is endogenous to the consensus mechanism, such as yield from issuance and REV, and yield that is exogenous. If the endogenous yield is lower than the costs (including risks) inherent specifically to staking, we cannot assign LST holders some exogenous yield from activities within, e.g., DeFi and determine their decision to hold LSTs based on the total sum of both endogenous and exogenous yield. They would be better off receiving that DeFi yield via native ETH without also picking up the costs associated with staking. As an extreme example, if the endogenous yield is 0, the LST fees paid by holders will not be a percentage of the non-existent yield, but rather push their take of the endogenous yield negative. The same can be said about restaking yield on an out-of-protocol EigenLayer. If the yield falls enough, modules and users would be better off simply using non-staked ETH, thus pushing down staking deposits. The point is that the risk–benefit analysis must be done separately on endogenous yield, and only if this yield outweighs the associated costs will an agent stake their funds. The implication—that the endogenous yield must be over 0 to produce a stable equilibrium—will be useful to us when designing our issuance policy going forward.

On the whole, it seems that a (slightly) reduced staking liquidity and a yield under the current trajectory, that may be reduced sometime in an uncertain future, will attract a larger proportion of new delegating stakers relative to new solo stakers (who must bear their fixed costs upfront). We may find that improved liquidity and a rather quick but modest tempering of our issuance policy better preserve the proportion of solo stakers, although the outcome is of course not obvious. More extensive studies and deeper elaborations on this topic would be interesting. In any case, one thing is more certain, and that is that a reduction in issuance will improve the monetary properties of ETH, while at the same time reducing load on the network.

[dapplion]

Hey @anderselowsson , without reducing the merit of your proposal it would be more suitable to move it to a different issue / PR. I would recommend you to post your analysis in an ethresear.ch post, and keep the scope of this PR contained to its original purpose.

I agree with you that revisiting the rewards curve is the long term sustainable fix, but it will be hard to gather enough consensus in time for dencun.

[dapplion]

• Referencing EIP for this PR Add EIP: Add Max Epoch Churn Limit EIPs#7668

[realbigsean]

I think we should consider the possibility that the activation queue empties. Not that it stays empty, just that the rate of new entrants is less than the churn limit (as it is now). The activation queue is half the size it was 3 months ago. So new entrants to the queue has been consistently less than the existing churn limit.

It's possible the rate of new entrants increases as the queue size decreases because there's less of a capital lockup penalty. But this hasn't shown to be the case of late as the queue wait times have also been cut in half over the last three months.

If the rate of new entrants remains where it is now this change has no impact on validator set size.

This change still might be worth doing if we're concerned about beacon state growth due to validator churn or in order for us to deal with deposit spikes with more lead time. But I think it shouldn't impact rate of exits at the very least.

[dapplion]

I think we should consider the possibility that the activation queue empties. Not that it stays empty, just that the rate of new entrants is less than the churn limit (as it is now). The activation queue is half the size it was 3 months ago. So new entrants to the queue has been consistently less than the existing churn limit.

Staking demand is influenced by market realities inside and outside Ethereum. Much can change in multiple months, either decreasing or increasing demand. I would prefer the problem to fix itself naturally, but at the same time it's not something I would leave to chance.

This change still might be worth doing if we're concerned about beacon state growth due to validator churn or in order for us to deal with deposit spikes with more lead time. But I think it shouldn't impact rate of exits at the very least.

I agree that it would be best to only apply to inbound, I'll look into it. The PR was meant to be minimal such that it can be included in deneb without much engineering effort.

[rocknet]

Staking demand is influenced by market realities inside and outside Ethereum. Much can change in multiple months, either decreasing or increasing demand. I would prefer the problem to fix itself naturally, but at the same time it's not something I would prefer to leave to chance.

This is where I am. If the entry queue empties and stays empty, limiting inbound means this isn’t even a change of status quo. If markets change, creating a large validator set, and we experience p2p congestion or other client issues (like we’ve seen in testing) before improvements can be made, or other mitigations like MAX EB can be implemented, it might be too late.

I agree ideally we could limit just entry rate, but I’d rather see this in Deneb even while applying to entry and exit, than either delay Deneb or have the cap wait for the next upgrade.

I’m not on a client team, just an engaged community member / consensus node operator. Didn’t see too much engagement here, so thought I’d voice my support.

[beetrootkid]

This seems a sensible if temporary / symptom-fixing change. I agree that the activation and exit churn limits should remain the same (as today). I do hope though that the time this change buys us is used to address the fundamental issues that are creating finalisation problems when the validator set gets too large 🙏

[dapplion]

• Closing for Add max epoch activation churn limit (EIP-7514) to Deneb #3499. Same feature but affects only activation churn.

please direct your comments and feedback to ⬆️ ⬆️