# Gnosis beacon chain performance

Consensus layer config differences to Ethereum

| Config value | Ethereum | Gnosis |
| -------- | -------- | -------- |
| `SLOTS_PER_EPOCH` | 32 | 16 |
| `SECONDS_PER_SLOT` | 12 | 5 |
| `EPOCHS_PER_SYNC_COMMITTEE_PERIOD` | 256 | 512 |
| `SECONDS_PER_ETH1_BLOCK` | 14 | 6 |
| `ETH1_FOLLOW_DISTANCE` | 2048 | 1024 |
| `BASE_REWARD_FACTOR` | 64 | 25 |
| `CHURN_LIMIT_QUOTIENT` | 65536 | 4096 |

Impact summary

- `SLOTS_PER_EPOCH`: Shorter epochs, faster finalization, more frequent epoch transitions so load
- `SECONDS_PER_SLOT`: Faster slots, the validator cycle runs faster, 5/3 seconds to propagate blocks, attestations, etc
- `EPOCHS_PER_SYNC_COMMITTEE_PERIOD`: "cancels out" with faster epoch. Same number of slots per sync committee period.
- `SECONDS_PER_ETH1_BLOCK`: Follow distance in time unit is smaller, faster time to process deposits
- `ETH1_FOLLOW_DISTANCE`: Smaller distance in block units, faster time to process deposits, more vulnerable to long re-orgs (only pre-merge)
- `BASE_REWARD_FACTOR`: Proportional factor to epoch rewards per validator. Gnosis epochs are 4.8 times faster, and mint 2.56 times less rewards. For same duties and network state Gnosis epoch rewards are 1.875 times higher per unit of time.
- `CHURN_LIMIT_QUOTIENT`: The churn to enter and exit the validator set is greater. For 100_000 validators, _100000 / 4096 = 24_ validators can activate and exit per epoch.

Churn out | Churn in
:-------------------------:|:-------------------------:
 | 
 | 

## Fast slot cycle

The beacon chain slot cycle has some "deadlines" which if exceeded rewards and the network may suffer.


## Fast slot cycle metrics to track

### Lighthouse

Full metrics list: https://github.com/sigp/lighthouse/blob/6d5a2b509fac7b6ffe693866f58ba49989f946d7/beacon_node/beacon_chain/src/metrics.rs#L452

- `beacon_block_observed_slot_start_delay_time`: Duration between the start of the block's slot and the time the block was observed.
- `beacon_block_imported_observed_delay_time`: Duration between the time the block was observed and the time when it was imported.
- `beacon_block_head_slot_start_delay_time`: Duration between the start of the block's slot and the time when it was set as head.
- `beacon_block_head_slot_start_delay_exceeded_total`: Triggered when the duration between the start of the block's slot and the current time will result in failed attestations.
- `validator_monitor_unaggregated_attestation_delay_seconds`: The delay between when the validator should send the attestation and when it was received.
- `validator_monitor_sync_committee_messages_delay_seconds`: The delay between when the validator should send the sync committee message and when it was received.

### Lodestar

Full metrics list: https://github.com/ChainSafe/lodestar/blob/1ceaa20ebef7a7adcf9709c323b128d4b4fbeba6/packages/beacon-node/src/metrics/metrics/lodestar.ts#L666

- `lodestar_gossip_block_elapsed_time_till_received`: Time elapsed between block slot time and the time block received via gossip
- `lodestar_gossip_block_elapsed_time_till_processed`: Time elapsed between block slot time and the time block processed
- `lodestar_gossip_block_elapsed_time_till_become_head`: Time elapsed between block slot time and the time block becomes head
- `validator_monitor_prev_epoch_attestations_min_delay_seconds`: The min delay between when the validator should send the attestation and when it was received
- `validator_monitor_prev_epoch_aggregates_min_delay_seconds`: The min delay between when the validator should send the aggregate and when it was received

### Nimbus

For full metrics text search `declareGauge` and `declareCounter` and `declareHistogram`.

- `validator_monitor_prev_epoch_attestations_min_delay_seconds`: The min delay between when the validator should send the attestation and when it was received.
- `validator_monitor_prev_epoch_aggregates_min_delay_seconds`: The min delay between when the validator should send the aggregate and when it was received.
- `validator_monitor_prev_epoch_sync_committee_messages_min_delay_seconds`: The min delay between when the validator should send the sync committee message and when it was received.
- `validator_monitor_prev_epoch_sync_contribution_min_delay_seconds`: The min delay between when the validator should send the sync contribution and when it was received.
- `beacon_attestation_delay`: Time(s) between slot start and attestation reception network wide via gossip
- `beacon_aggregate_delay`: Time(s) between slot start and aggregate reception network wide via gossip
- `beacon_block_delay`: Time(s) between slot start and beacon block reception

### Teku

For full metrics text search `SettableGauge` and `metricsSystem`

- `beacon_block_import_delay_summary`: Histogram recording delay in milliseconds at each stage of block import. With labels: arrival, pre-state_retrieved, processed, transaction_prepared, transaction_committed, completed. ([Source code](https://github.com/ConsenSys/teku/blob/da4be8e824e6d2bfa4cfd7c902254e0e10b6fba5/ethereum/statetransition/src/main/java/tech/pegasys/teku/statetransition/block/BlockImportMetrics.java#L55))
- `beacon_block_import_delay_counter`: Counter of blocks falling in different time frames in each import stages. ([Source code](https://github.com/ConsenSys/teku/blob/da4be8e824e6d2bfa4cfd7c902254e0e10b6fba5/ethereum/statetransition/src/main/java/tech/pegasys/teku/statetransition/block/BlockImportMetrics.java#L77))

_Validator metrics appear to not track submit delay_

### Prysm

For full metrics text search `promauto.`.

_Apparently none of the metrics above are supported._

## On chain analysis

**Participation distribution**

Distribution of validators in a certian window with percent of participation. Will answer the question:
- The drop in participation to < 100% is caused by a few validators going fully offline (~0% bucket) or by a more wide degradation of performance (~90%) bucket?

participation_head = []
participation_target = []
participation_source = []

for participation in participation_in_window:
   for (validator_index, flags) in participation:
      if flags.head:
        participation_head[validator_index]++
      if flags.target:
        participation_target[validator_index]++
      if flags.source:
        participation_source[validator_index]++
        
// Plot histogram of partici![](https://i.imgur.com/XGYN2D4.png)
pation_* arrays

_hypotesis chart_


First test


**Missed proposers offline**

Same as chart above but for a window around a missed proposal for that specific proposer. Answers the question:
- Guess if proposer was offline or not during a missed proposal.

**Attestation votes for non-cannonical votes**

Count votes for non-cannonical blocks:
- ??