Skip to content

Commit

Permalink
Add max epoch churn limit
Browse files Browse the repository at this point in the history
  • Loading branch information
dapplion committed Sep 7, 2023
1 parent 08405e7 commit f9a6343
Showing 1 changed file with 71 additions and 0 deletions.
71 changes: 71 additions & 0 deletions EIPS/eip-7668.md
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)
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

Limit Beacon chain growth from exponential to linear to mitigate the risks of very high levels of total ETH supply staked.

## Motivation

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 yields decrease as the validator set size increases, the APY at 100% ETH supply staked is 1.6% for consensus rewards only excluding MEV. This yield can be sufficient to attract capital such that the equilibrium point of the validator set size is close to its maximum possible.

Reaching very high levels of total ETH supply staked can have negative externalities. Liquid staking derivatives (LSDs) are likely to absorb most of the staking demand, jeopardizing the economic guarantees of the Beacon chain. If LSD tokens overtake the native token in liquidity, they permeate systemic risks into most Ethereum applications.

It's unclear if the Ethereum network security benefits from having so much stake. After some upper bound, attacks become so economically unfeasible that additional stake does not increase the network's safety. In that case, the network will be overpaying for security. Note that Beacon chain rewards are dictated by an opinionated function, chosen before its launch in 2020. Much has changed since then, including the Beacon chain achieving unprecedented success. Beacon chain rewards should be adjusted to match today's reality, and stop incentiving actors into increasing the risks listed above at no benefit to the network's security.

If one agrees that Beacon chain rewards should be adjusted down, it's important to forecast the social cost of doing so. The more ETH is staked, the more actors may depend on today's reward regime and oppose the change. Also, the network could reach some catastrophic tipping point before it can agree to a new rewards function.

This proposal accepts the complexities of changing the rewards curve and is meant only to slow down growth. It wants to mitigate the negative externalities of very high levels of total ETH supply staked before a proper solution is implemented.

## Specification

### Constants

| Name | Value |
| ---- | ----- |
| `MAX_PER_EPOCH_CHURN_LIMIT` | 12 |

### 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).

0 comments on commit f9a6343

Please sign in to comment.