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`:
### 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/ :
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:
| 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
Sign in with Wallet
Connect another wallet