This document contains ideas for achieving Xatu consensus layer mimicry, which is a thin client that can stay connected to the beacon p2p network with minimal resources with the goal of monitoring and exporting data on the network for later analysis. Goals 1. Exports beacon p2p events for analysis :::warning Severity: Required ::: Notes
2/14/2024Ethereum Prometheus alerts Nearly all of our Ethereum network alerts are based on a % of the nodes we run for a network hitting a condition. We generally don't alert on individual instances having issues through our Ethereum channels. Alerting on a % of nodes seeing a condition generally leads to a higher signal-to-noise ratio (i.e. when there is an actual issue), but some of these can still be pretty annoying so might need individual tweaking. Finalized Epoch Stalled on % of nodes we run on a network Description: Only alerts if more than 35% of our nodes on a network have had a stalled finalized epoch for more than 20mins. Alert config:
4/6/2023Links Testnet Homepage Instances Running Prysm Lighthouse Lodestar Teku Nimbus
2/7/2023This document covers the high level ideas behind setting up a Beacon chain Checkpoint Sync endpoint. It does not go over the low level details like which exact commands to run. Instructions on how to expose an endpoint to the internet (i.e. https, dns) are out of scope for this guide. Check out this document for an idea on how end-users will use your endpoint. Overview Checkpoint syncing is the process where a fresh beacon node jumps to a finalized checkpoint that is relatively close to the head of the chain. Fetching the state/blocks for that finalized checkpoint from another beacon node, node operators are able to spin up a beacon node and start performing validating duties within a matter of minutes. Each client has implemented this process slightly differently. For more details on the routes required by each client check out this doc. Checkpointz
9/2/2022