---
# System prepended metadata

title: Suppress churn limit grow on Gnosis Chain

---

Visit [reference list](#Reference-list) for more detailed problem explanation and context.  

## Problem

The Gnosis chain `CHURN_LIMIT_QUOTIENT` parameter is currently considered too low. This has a significant impact on increasing the chain churn speed, and this effect is further exacerbated by the faster block time.

This situation results in reduced network security and renders a chain more susceptible to long-range attacks.

### Current Gnosis chain params:
According to the chain spec the [equation](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#get_validator_churn_limit) employed to determine the extent of validator churn during an epoch is as follows:

```python
VALIDATOR_CHURN_LIMIT = max(
        MIN_PER_EPOCH_CHURN_LIMIT,
        validators_number // CHURN_LIMIT_QUOTIENT
)
```
Giving the current Gnosis chain parameters
```json
CHURN_LIMIT_QUOTIENT: 4096(2**12)
MIN_PER_EPOCH_CHURN_LIMIT: 4
VALIDATOR_SET: ~140000
EPOCH_TIME: 80s
```

We can calulate that weak subjectivity checkpoint safe period is extremely short and insecure(`~0.2 days`)

To slow down the chain churn we can possibly change two parameters:

- `CHURN_LIMIT_QUOTIENT`
- `MIN_PER_EPOCH_CHURN_LIMIT`

## Options

Here is a table of weak subjectivity safe periods(rounded to days) for different `CHURN_LIMIT_QUOTIENT` values as a colums and a list of validator sets as a rows:


|         |  2**12 |  2**13 |  2**14 |  2**15 |  2**16 |  2**17 |  2**18 |
|---------|-------:|-------:|-------:|-------:|-------:|-------:|-------:|
| 65536   |    0.2 |    0.5 |    0.9 |    0.9 |    0.9 |    0.9 |    0.9 |
| 110000  |    0.2 |    0.5 |    0.9 |    1.4 |    1.4 |    1.4 |    1.4 |
| 131072  |    0.2 |    0.5 |    0.9 |    1.7 |    1.7 |    1.7 |    1.7 |
| 262144  |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    3.1 |    3.1 |
| 524288  |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    6.2 |    6.2 |
| 1048576 |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    6.2 |   12.3 |

As shown in a table `CHURN_LIMIT_QUOTIENT = 2**18` gives us the best safe period scale for validator set grow steps up to `1m`. 
Current number of validators in Gnosis chain is `~140k`, so with any  `CHURN_LIMIT_QUOTIENT > 2**14` we will get `~1.4d` of weak subjectivity safe period. If we consider this period is not safe enough we can also play around with `MIN_PER_EPOCH_CHURN_LIMIT` value.
Liveness bounded to `MIN_PER_EPOCH_CHURN_LIMIT` because Gnosis chain epoch time is `80s` (`~4.8` times lower than Ethereum).
Hence with the same `MIN_PER_EPOCH_CHURN_LIMIT` Gnosis chain churns `4.8` times faster than Ethereum. 

Here is the same table for `MIN_PER_EPOCH_CHURN_LIMIT = 2`:

|         |  2**12 |  2**13 |  2**14 |  2**15 |  2**16 |  2**17 |  2**18 |
|---------|-------:|-------:|-------:|-------:|-------:|-------:|-------:|
| 65536   |    0.2 |    0.5 |    0.9 |    1.7 |    1.7 |    1.7 |    1.7 |
| 110000  |    0.2 |    0.5 |    0.9 |    1.7 |    2.6 |    2.6 |    2.6 |
| 131072  |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    3.1 |    3.1 |
| 262144  |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    6.2 |    6.2 |
| 524288  |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    6.2 |   12.3 |
| 1048576 |    0.2 |    0.5 |    0.9 |    1.7 |    3.1 |    6.2 |   12.3 |


As shown in a table params such `MIN_PER_EPOCH_CHURN_LIMIT = 2` && `CHURN_LIMIT_QUOTIENT > 2**15` gives us maximum safe period of `~3.1` days for current gnosis validators set.

Possible effective `CHURN_LIMIT_QUOTIENT` values may be narrowed to:

- `2**16`
- `2**17`
- `2**18`

## Affected scope 

### Churn rate

To be sure that we don't overcomplicate enter and exit possibilities for validators, we can calculate `CHURN_RATE` for every set of parameters. 

`CHURN_RATE` is a mean time to allow one validator exit, e.g. if epoch time is `60s` and chain churn limit is `1` validator per epoch than  `CHURN_RATE = 60`.
Lower `CHURN_RATE` makes enter and exit queues grow less. 
It can be calculated with such equation:

```python
CHURN_RATE = EPOCH_TIME_SECONDS / VALIDATOR_CHURN_LIMIT
```
It will help to compare Gnosis chain and Ethereum on that quality.

e.g. for Ethereum it can be calculated with such params:
```
CHURN_RATE = 384 / max(4, 800000 // 2**16)
```
Current Ethereum `CHURN_RATE` is `~30`.

Here is the table of `CHURN_RATE`s for different `CHURN_LIMIT_QUOTIENT` values and `MIN_PER_EPOCH_CHURN_LIMIT = 2` for Gnosis chain:

|         | 2**16  | 2**17  | 2**18  |
|---------|-------|-------|-------|
| 65536   | 40.0  | 40.0  | 40.0  |
| 110000  | 40.0  | 40.0  | 40.0  |
| 131072  | 40.0  | 40.0  | 40.0  |
| 262144  | 20.0  | 40.0  | 40.0  |
| 524288  | 10.0  | 20.0  | 40.0  |
| 1048576 | 5.0   | 10.0  | 20.0  |

As we can see for current validator set Gnosis chain with `CHURN_LIMIT_QUOTIENT`s that we listed as candidates below, gives us `CHURN_RATE = 40` which is relatively close to current Ethereum exit rate and it will downscale with validators number grow.


For `CHURN_RATE` comparison here Ethereum `CHURN_RATE` with Gnosis validator set (`140k`) can be used as example:

```96 = 384 / max(4, 140000 // 2**16)```

So with current chain spec for the Gnosis validator set Ethereum `CHURN_RATE = 96`.

### Activations speed

Here we will look at the situation when dishonest party (with super large resources) enters the chain by standard deposit flow.

#### *Q1: How long it takes for dishonest party to get `>1/3` of the chain to prevent finalization?*

#### *Q2: How long it takes for dishonest party to get majority i.e. `>2/3` of the chain?*

To calculate how many epochs it will take to reach target fraction of validators set we can use such code: 
```python
def calculate_epochs_to_target_fraction(validators_set, churn_limit_quotient, min_per_epoch_churn_limit, target_fraction):
    
    dishonest_validators = 0
    epochs = 0
    
    current_validators = validators_set
    

    # add new validators untill activated group < target fraction
    # of whole validators set 
    while current_validators * target_fraction >= dishonest_validators:
        
        # calculate churn limit every epoch
        churn_limit = get_validator_churn_limit(
            current_validators,
            churn_limit_quotient,
            min_per_epoch_churn_limit
        )
        
        # add activated validators to the set
        current_validators += churn_limit
        
        # count new (dishonest) activated validators
        dishonest_validators += churn_limit
        epochs += 1

    return (epochs * GNOSIS_EPOCH_TIME) / DAY_IN_SECONDS
```

 Here the results for validators sets `140k`(current Gnosis) and `1m`:

![](https://hackmd.io/_uploads/Bk7tUh0Tn.png)


### UX consideration

#### *Q3: How different churn limit quotients affect activation queue?*

In order to calculate the potential validators queue in real-world scenarios, we can make the assumption that the Gnosis chain will experience the same level of demand for becoming a validator as Ethereum does currently.

Lets take public data from https://www.validatorqueue.com/ :
![](https://hackmd.io/_uploads/ByoGfrJRh.png)
NOTE: data from 31.08.2023

Than we have validator set of a size `~766k` with entry queue of `~54k` for our calculations. Note that wait period for Ethereum with such params is roughtly around `20.5 days`.

Having the following wait periods for Gnosis chain:
![](https://hackmd.io/_uploads/S1IchUkCn.png)
| Churn Limit Quotients | Wait Period (Days) |
|-----------------------|--------------------|
| 4096                  | 0.3                |
| 8192                  | 0.5                |
| 16384                 | 1.0                |
| 32768                 | 2.1                |
| 65536                 | 4.3                |
| 131072                | 9.0                |
| 262144                | 12.5               |


---


--- 
## Resume

#### `CHURN_LIMIT_QUOTIENT` candidates:

- `65536 (2**16)`
- `131072 (2**17)`
- `262144 (2**18)` with the best scale up to `1m` validators
 

#### `MIN_PER_EPOCH_CHURN_LIMIT`

- `2` is a safe ground and gives x2 scale in `safe period`


## Approaches
Possible approaches will be listed in **ascending complexity order** (from less to more complex).

#### A
Only change the `CHURN_LIMIT_QUOTIENT` to the best scaling value.
In our case its `2**18`.
As **Resume** section says:
> 262144 (2**18) with the best scale up to 1m validators

This change provide the longest weak subjectivity period we can get with current Gnosis chain spec and require least changes.
`CHURN_RATE` and activation speed will be more than acceptable as it will be `~2.5` times faster than on Ethereum with current validator sets.

#### B
Change `CHURN_LIMIT_QUOTIENT` and `MIN_PER_EPOCH_CHURN_LIMIT`.
```
CHURN_LIMIT_QUOTIENT: 2**18
MIN_PER_EPOCH_CHURN_LIMIT: 2
```
This approach require additional spec variable change but provides 2 times longer weak subjectivity period.
The `CHURN_RATE` will still close to Ethereum:
`40` for Gnosis chain vs `30` on Ethereum with current validators sets.

#### C

Changing the churn limit calculation logic.
Require way more changes and also sacrifice Ethereum compliance.
e.g. https://github.com/ethereum/consensus-specs/pull/3448

---

## Reference list

- https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
- https://www.youtube.com/watch?v=9avhMNJWnmw
- https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2
- https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187
- https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942/18