# Beacon block received timing metrics ### Lighthouse Full metrics list: https://github.com/sigp/lighthouse/blob/6d5a2b509fac7b6ffe693866f58ba49989f946d7/beacon_node/beacon_chain/src/metrics.rs#L452 To enable metrics prefixed `validator_monitor` refer to these docs: https://lighthouse-book.sigmaprime.io/validator-monitoring.html#how-to-enable-monitoring Validator monitoring is per-validator so if sentry nodes don't have a connected VC, you'll need to explicitly list a set of validator pubkeys with `--validator-monitor-pubkeys`. Otherwise `--validator-monitor-auto` will detect validators in a local VC. - `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. _note: network ingress is threaded per client, metrics should reflect reality unless peer send a high burst of messages_ ### 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 _note: Lodestar network ingress is single threaded, metrics may be distorted for underprovisioned hosts_ ### 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 _note: from offline chats seems Nimbus does not thread network ingress per peer so metrics may appear distorted under heavy load_ ### 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)) - `attestation_publication_delay` Counter of attestations published in different time intervals after their due time - `block_publication_delay` Counter of blocks published in different time intervals after their due time _Validator metrics appear to not track submit delay_ ### Prysm For full metrics text search `promauto.`. _Apparently none of the metrics above are supported._
Last changed by  
 
dapplion
145

Read more

Increase `CHURN_LIMIT_QUOTIENT`

Rationale Current CHURN_LIMIT_QUOTIENT in Gnosis is low such that the network's validator set can change significantly in short periods of time posing unnecessary risks to the network. The original value was chosen without a great deal of care to facilitate staker onboarding UX. Even that argument will no longer apply with eip6110 (in-protocol deposits). CHURN_LIMIT_QUOTIENT dictates the validator_churn_limit which is constant through an epoch variable only to active validator count. def get_validator_churn_limit(state: BeaconState) -> uint64: """ Return the validator churn limit for the current epoch. """ active_validator_indices = get_active_validator_indices(state, get_current_epoch(state))

4/19/2023
GC withdrawal contract

Background From Spec Gnosis Chain withdrawals #1 During block processing, state transition must call WITHDRAWAL_CONTRACT function function withdrawals(uint64[] amounts, address[] addresses) If transaction reverts, the block is invalid. So if a specific state (i.e. not enough funds) causes a revert in all cases, the network halts Deposit flow Bridge GNO from mainnet to Gnosis Chain

2/14/2023
How to run Hive with Lodestar

Get repo and build it (requires Go lang) git clone https://github.com/ethereum/hive go build . Checkout branch depending on current progress. For capella Mario's working on eth2-withdrawals-interop. Check with Mario Vega on current branch if working on new forks. master should reflect configurations that are somewhat stable. To run a test do: ./hive --client go-ethereum,lodestar-bn,lodestar-vc --sim eth2/withdrawals --sim.limit "/test-capella-fork" --sim.loglevel 5 client: flag sets which combo to run. For the example above, if you don't provide EL, CL and VC the test breaks: client go-ethereum,lodestar-bn,lodestar-vc. To test an interaction between Lodestar and Teku, do: client go-ethereum,lodestar-bn,lodestar-vc,teku-bn,teku-vc.

1/23/2023
Blobs booby-trap :bomb:

Given the conditions: To ensure an upper-bounded disk size, consensus clients must only store blobs within the MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS time range Blobs from finalized blocks are considered available If the latest finalized checkpoint is before MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS, there exist a range of blocks which cannot be checked for is_data_available. More context on ethereum/consensus-specs/pull/3141 Range sync When performing a range sync the client cannot know the latest finalized checkpoint until it syncs to the head. There are two possible scenarios:

1/23/2023
Read more from dapplion
Published on HackMD