Skip to content

Add EIP: Add Max Epoch Churn Limit #7668

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
eth-bot merged 6 commits into from
Sep 13, 2023
Merged

Add EIP: Add Max Epoch Churn Limit #7668

Changes from 2 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
f9a6343
Add max epoch churn limit
dapplion Sep 7, 2023
d4cf4bb
Update text
dapplion Sep 7, 2023
de61e48
Review PR
dapplion Sep 9, 2023
db509ff
Update eip-7514.md
dapplion Sep 12, 2023
8fb05ac
Update eip-7514.md
dapplion Sep 12, 2023
8a2cedb
Update eip-7514.md
dapplion Sep 13, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions EIPS/eip-7668.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
---
eip: 7668
title: Add Max Epoch Churn Limit
description: Modify the churn limit function to upper bound it to a max value
author: dapplion (@dapplion), Tim Beiko (@timbeiko)
discussions-to: https://ethereum-magicians.org/t/eip-7668-add-max-epoch-churn-limit/15709
status: Draft
type: Standards Track
category: Core
created: 2023-09-07
---

## Abstract

Update the maximum validator growth rate from an exponential to a linear increase by capping the epoch churn limit.

## Motivation

This proposal aims to mitigate the negative externalities of very high level of total ETH supply staked before a proper solution is implemented. In other words, this proposal accepts the complexities of changing the rewards curve and is meant only to slow down growth.

With a full deposit queue, the share of ETH supply staked will reach 50% by May 2024, 75% by September 2024, and 100% by December 2024. While rewards decrease as the validator set size increases, at 100% of ETH supply staked, yearly consensus rewards alone (excluding MEV/transaction fees) for validators still represent ~1.6% of their stake. This can be sufficient to attract capital such that the equilibrium point of the validator set size is close to its maximum possible. Liquid staking tokens (LSTs) also contribute to this, given stakers can use them as they use unstaked ETH.

As the levels of ETH staked increase, more strain is put on the consensus layer. A larger number of validators leads to an increase in gossip messages, as well as a growing Beacon state size. Additionally, as the amount of stake grows, it's unclear how much marginal security benefits come from additional economic weight.

The Beacon Chain validator reward function was chosen before its launch in 2020. Much has changed since then, including the Beacon chain achieving unprecedented success. In light of this, it is worth discussing whether Beacon chain validator rewards should be adjusted to better match today's reality, potentially to discourage staking past a certain point.

This EIP does not attempt to do this, but to allow more time for the community to have these discussions. By limiting the epoch churn limit now, the time to reach critical milestones of total ETH supply staked are significantly delayed. This allows more time for research into more comprehensive solutions, and for community consensus around them to emerge.

## Specification

### Constants

| Name | Value |
| ---- | ----- |
| `MAX_PER_EPOCH_CHURN_LIMIT` | 12 |
Copy link
Copy Markdown
Contributor

@djrtwo djrtwo Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is the current value, but have you considered reducing it to a more modest number?
Why 12 and not, say, 8 or 6?

Copy link
Copy Markdown
Contributor

@djrtwo djrtwo Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there consideration in only applying this to activations and not exits?

Copy link
Copy Markdown
Contributor

@mkalinin mkalinin Sep 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there consideration in only applying this to activations and not exits?

At the first glance such imbalance doesn't affect security properties, but it might cause the need of additional analysis before the proposal can be accepted. Considering short time frames we might not want to impose any additional complexity to make this proposal pass through the governance process. Thus, capping both queues is preferable, IMHO

Copy link
Copy Markdown
Member Author

@dapplion dapplion Sep 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The lower the number the higher delta there will be in queue capacity at the fork epoch. A lower number increases the "unfairness" argument, but it increases the effectiveness of this EIP. I pick 12 without strong reasoning, just because it yields good results without resulting in a dramatic drop in churn.

Copy link
Copy Markdown
Contributor

@mkalinin mkalinin Sep 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the potential arguments in favour of 12 is that this is likely the limit when the Deneb fork happens on the mainnet assuming the same market conditions, so the decrease of the churn limit is unlikely to happen


### Execution layer

This requires no changes to the Execution Layer.

### Consensus layer

- Modify `get_validator_churn_limit` function adding an upper bound `MAX_PER_EPOCH_CHURN_LIMIT`

## Rationale

### `MAX_PER_EPOCH_CHURN_LIMIT` value

Depending on the specific constant selection the churn can _decrease_ at the activation fork epoch. The Beacon chain spec can handle this without issues. During 2023 Q4 (projected Dencun activation) the churn value will range 14-16. The table below compares the projected validator set assuming a continuous full deposit queue.

| `MAX_PER_EPOCH_CHURN_LIMIT` | max validator set (% of ETH supply) at 2024-07 |
| --------------------------- | ---------------------------- |
| 8 | 1.4M (37%)
| 12 | 1.5M (40%)
| 16 | 1.7M (45%)
| Inf (status quo) | 2.2M (59%)

Assuming that the earliest the next fork can happen is at the start of 2024 Q3, a value of 12 provides a significant reduction in projected size without causing a big drop in churn at a projected Dencun fork date.

## Backwards Compatibility

This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.

## Security Considerations

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).