# Seeking for proper EIP-7514 value for Gnosis chain

The Ethereum Improvement Proposal [EIP-7514](https://eips.ethereum.org/EIPS/eip-7514) introduces a significant specification parameter: `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT`. This parameter plays a crucial role in shaping the activation cue, directly impacting the activation churn. It's important to note that this parameter specifically affects the activation cue and does not fall under the considerations of weak subjectivity.

## Understanding Activation Churn

The activation churn equation is a fundamental aspect of [EIP-7514](https://eips.ethereum.org/EIPS/eip-7514). The churn limit for validator activation in the current epoch is determined by the following function:

def get_validator_activation_churn_limit(state: BeaconState) -> uint64:
    """
    Return the validator activation churn limit for the current epoch.
    """
    return min(MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT, get_validator_churn_limit(state))

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=Ovfz8d6uOWly&line=3&uniqifier=1)

## The Validator Set and Growth Projection
[EIP-7514](https://eips.ethereum.org/EIPS/eip-7514) is expected to become active during the Dancun upgrade, tentatively scheduled for the `EOY 2023`. To determine an optimal value for `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT`, we analyze the expected size of the validator set around the time of the hardfork.

Based on growth rate projections since the Shapella hard fork on Gnosis chain, it is estimated that the validator set will reach approximately `163000` validators by mid-December 2023. The current mean growth rate stands at approximately `165 validators per day`:

PRE_SHAPELLA_SET = 140611
PRE_SHAPELLA_DATE = datetime(2023, 7, 31)

CURRENT_SET = 149349
CURRENT_SET_DATE = datetime(2023, 9, 22)

DANCUN_DATE = datetime(2023, 12, 15)

set_growth = CURRENT_SET - PRE_SHAPELLA_SET
days_between = (CURRENT_SET_DATE - PRE_SHAPELLA_DATE).days

growth_rate_per_day = set_growth / days_between

future_set = CURRENT_SET + growth_rate_per_day * (DANCUN_DATE - CURRENT_SET_DATE).days # ~163198

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=W1ZXH7bSzs3D&line=18&uniqifier=1)

## Analyzing Activation Speed

### Possible queue grow (Ethereum demand)

To comprehend how `EIP-7514` might affect the entry queue on the Gnosis chain, we take Ethereum entry demand model and consider two scenarios: the worst Ethereum queue on June 10, 2023, and the current Ethereum status as of end of September, 2023. These scenarios allow us to calculate wait periods for different `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT` values, assuming that the demand on the Gnosis chain aligns with that of Ethereum AT MOST.

# June 10, 2023
WORST_CASE_VALIDATOR_SET: 608224
WORST_CASE_QUEUE: 96508

# September, 2023
CURRENT_CASE_VALIDATOR_SET: 822593
CURRENT_CASE_QUEUE: 20292

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=UbzcQ34p206j&line=1&uniqifier=1)

### Gnosis entry demand

This following plot provides insights into the historical demand to enter the network, represented by the average activations per epoch, for each month since December 2022 ("The Merge" on Gnosis).
Plot shows (`monthly_activations / monthly_epochs`) for every month respectively.


[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=alfcSaqFdMje&line=4&uniqifier=1)

The highest value so far is `0.35` activations per epoch (~1 activation per 3 epochs) in July 2023.

We can also calculate the time it would take to process daily entries for each listed `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT`. For the current (September 2023) daily entries (`165/day`), the table below showcases the results:

**Columns**:
- **Necessary Epochs** column shows how many epochs it will take to process current daily entries
- **Percentage of 24h** column shows how many % of day time it will take to process daily entries
- **Total Time** is self describing

| MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT | Necessary Epochs | Percentage of 24h | Total Time (hours) |
|-------------------------------------|------------------|--------------------|---------------------|
| 2 | 83 | 7.7 | 1.8 |
| 3 | 55 | 5.1 | 1.2 |
| 4 | 42 | 3.9 | 0.9 |
| 5 | 33 | 3.1 | 0.7 |
| 6 | 28 | 2.6 | 0.6 |

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=NW0kmATT25nt&line=3&uniqifier=1)

We see that even with the tightest `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT: 2` it takes only `7.7%` of day time to proccess all daily entries (with current demand).

The maximum daily capacities(`MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT * epochs_number_24h`) looks as follows (assuming 1 GNO == 100$):
| MAX_PER_EPOCH_CHURN_LIMIT | Daily Capacity | Max Daily GNO | Max Daily USD |
|---------------------------|----------------|---------------|---------------|
| 2 | 2160 | 2160 | 216000$ |
| 3 | 3240 | 3240 | 324000$ |
| 4 | 4320 | 4320 | 432000$ |
| 5 | 5400 | 5400 | 540000$ |
| 6 | 6480 | 6480 | 648000$ |

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=MIE4xj3a9L1b&line=15&uniqifier=1)

As chain capacity with `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT: 2` is way more higher than current and maximal historical demand it would be a safe ground to pick the lowest value as it provides highest security benefits and better serves the purpose described in EIP.

### How fast chain will churn at max

The churn percantage also might be helpful to analyze how different limits suppress chain churn while validator set grows:

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=Iu6OD6YEQFf6&line=26&uniqifier=1)

The plot indicates that tightening the entry rate, denoted by `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT: 2`, could have a significant impact if the validator set grows substantially. However, this effect is deemed acceptable.

## Optimizing Churn Speed for Increased Security
A lower value for `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT` can significantly contribute to a slower chain churning speed. This deliberate slowing of the churn process inherently increases the security of the chain. Moreover, we can calculate the time it would take to churn the validator set to reach target fractions (`>1/3` and `>2/3` of the chain) for different `MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT` values.

- `>1/3` fraction considered important threshold because it devaluates the Gasper consensus security assumption, i.e. chain become `>1/3` slashable and dishonest party could prevent chain finalization
- `>2/3` threshold reflects a situation akin to a "51% attack," where a dishonest party gains control over a majority

[try in google colab](https://colab.research.google.com/drive/1lxVPHb4bPfm3qd0LC152Q5P6phuDNQqB?authuser=1#scrollTo=QO-sZK8LBOGZ&line=5&uniqifier=1)

---
# Recap

MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT: 2

**Important Consideration**:

- **Resilience to Demand Surges**: The conservative value of 2 equips the chain to handle unexpected spikes in demand, more than 10 times higher from current.

- **Optimal Balance with UX**: While 2 is the lowest viable value, it's essential to note that choosing such a low churn limit strikes a delicate balance. It optimizes chain security and churn reduction without dramatically impacting UX.

- **Aggressive yet Cautious Choice**: This choice reflects an aggressive approach in freezing chain economy grow to provide time for better solutions, with an acknowledgment that possible growth tightening is viewed as acceptable.