# Public eth2 launch health metrics [toc] ## Pre-genesis Prior to genesis, we want to ensure all clients agree on genesis info and that the p2p network looks strong * genesis root/state/time and fork_digest in agreement * nodes of each type successfully peer through discovery and maintain healthy peer counts leading up to genesis ## Post-genesis Monitor logs, block explorers, and local http endpoints looking for the following events * Genesis epoch * Block published in early slot (No user block proposed at GENESIS_SLOT) * GOOD: First block seen at slot 1 or 2 * CONCERNING: First block seen between slots 3 and 8. Signals potential bad connectivity or low validator liveness * BAD: First block not seen before slot 8 (25% of epoch passed). Signals network might be fragmented * End of epoch (No change in finality possible): * GOOD: vote participation >= 90% * CONCERNING: 66.6% <= vote participation < 90% * BAD: vote participation < 66.6% * Epoch 1 * Monitor logs looking for very regular blocks and attestations * End of epoch (No change in finality possible): * GOOD: vote participation >= 90% * CONCERNING: 66.6% <= vote participation < 90% * BAD: vote participation < 66.6% * Epoch 2 * Monitor logs looking for very regular blocks and attestations * End of epoch: * GOOD: Epoch 2 justifies * CONCERNING: Epoch 1 justifies but _not_ epoch 2. Implies good connectivity/participation at epoch 1 but not 2 * BAD: No justifications at end of epoch 2. Tracking participation in previous epochs would have already signalled that this as likely * Epoch 3 * Monitor logs looking for very regular blocks and attestations * End of epoch: * GOOD: Epoch 3 justifies, epoch 2 finalizes * CONCERNING: Some combination of justifications that does not lead to finality * BAD: No justifications since genesis ## Relevant http endpoints Listed the most relevant API endpoints for initial health monitoring. Usage: `curl http://localhost:PORT/ENDPOINT` where `PORT` is the configured http port for your client and `ENDPOINT` is one of the endpoints below _Note_: `jq` is a wonderful tool for parsing json return values from these http requests. Just pipe your call to `curl` into `jq`. Give it a shot! * Lighthouse (default http port: 5052) * `/network/peer_count` * `/consensus/global_votes?epoch=EPOCH` * `/beacon/head` * `/beacon/state?slot=SLOT` piped into the following: * `jq '.beacon_state.finalized_checkpoint'` * `jq '.beacon_state.current_justified_checkpoint'` * Teku (default http port: 5051) * `/network/peer_count` * `/beacon/chainhead` * `/beacon/state?slot=SLOT` piped into the following: * `jq '.finalized_checkpoint'` * `jq '.current_justified_checkpoint'` * Prysm (default http port: 3500) * `/eth/v1alpha1/node/peers | jq '.peers | length'` * `/eth/v1alpha1/beacon/chainhead` * Lodestar * `/eth/v1/node/peers | jq '.data | length'` * `/eth/v1/beacon/states/head/finality_checkpoints`
Last changed by  
 
Danny Ryan
3129

Read more

Eth2 Phase 0 Pre-Launch Bounty Program

⚠️The bug bounty program is no longer "pre-launch" and instead has a permanent home and stable set of rules. Check it out here!⚠️ We are excited to kick off the Eth2 Phase 0 Pre-Launch Bounty Program. This program is designed to incentivize you to find and report bugs in the core Eth2 Phase 0 specs prior to mainnet launch 🐛. The Ethereum Foundation will run this program from now until just prior to the Phase 0 mainnet launch. After Phase 0 is in production, we will transition Phase 0 bounties to the standard Ethereum Bounty Program. Note: As of 2020/5/6 all rewards have been doubled for a maximum reward of $20k for critical bugs :) Note: As of 2020/6/22, the Solidity eth2 deposit contract and formal verification have been added to the scope of the bounty program

10/15/2021
Sign-in with Ethereum RFP

Introduction The Ethereum Foundation (EF) and True Names LTD (ENS) would like to announce a Request for Proposals (RFP) for the creation of a Sign-In with Ethereum specification, a package using Oauth for easy implementation by web2 services, and a Javascript library for the user-facing part of sign-in. [toc] Scope Survey current practices: Examine existing uses of Sign-In with Ethereum, look at the code, and talk to the developers. Determine what developers are doing and why, how it could be improved, and what best practices have already emerged. Specification: Write a specification for how Sign-In with Ethereum should work, both with and without Oauth. Include best practices and recommended graphics. The specification should be simple and generally follow existing practices. Avoid feature bloat, particularly the inclusion of lesser-used projects who see getting into the specification as a means of gaining adoption. The core specification should be decentralized, open, non-proprietary, and have long-term viability. It should have no dependence on a centralized server except for the servers already being run by the application that the user is signing in to. The basic specification should include: Ethereum accounts used for authentication, ENS names for usernames (via reverse resolution), and data from the ENS name's text records for additional profile information (e.g. avatar, social media handles, etc).

7/12/2021
Phase 0 for Humans [v0.10.0]

Warning: This a work in progress document with many broken links, some unfinished sections, and commands for including code segments. The entirety of the document is subject to change without warning. Introduction This document is an aid to the specification of the state transition function and accompanying data structures for Phase 0 - The Beacon Chain -- the core system level chain at the heart of Ethereum 2.0. The primary Phase 0 specification is particularly terse, only defining much of the functionality via python code and comments. This document aims to provide a more verbose version of the specification, primarily aimed at helping onboard new contributors to Ethereum 2.0. Table of contents [toc]

7/1/2021
ethdo audit

8/27/2020
Read more from Danny Ryan
Published on HackMD