Overview This document defines the absolute minimum requirements for implementing a P2P networking layer that can successfully connect to and interoperate with all major Ethereum consensus clients (Prysm, Lighthouse, Teku, Lodestar, Grandine, Nimbus). These are not generic recommendations but exact specifications extracted from production client implementations, providing a bulletproof guide for new consensus client P2P development. 1. Request/Response (Req/Resp) Protocols Protocol Format Pattern: /eth2/beacon_chain/req/{method}/{version}/{encoding} Encoding: ssz_snappy (SSZ serialization + Snappy compression)
6/11/2025This 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/2023