gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-16 20:39:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add documentation for VC API /lighthouse/beacon/health (#6653)

Browse Source 
Changes the endpoint to get fallback health information from `/lighthouse/ui/fallback_health` to `/lighthouse/beacon/health`. This more accurately describes that the endpoint is related to the connected beacon nodes and also matched the `/lighthouse/beacon/update` endpoint being added in #6551.

Adds documentation for both fallback health and the endpoint to the Lighthouse book.
This commit is contained in:
Mac L
2025-04-30 12:07:07 +10:00
committed by GitHub
parent 34a6c3a930
commit 94ccd7608e
3 changed files with 75 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
book/src/advanced_redundancy.md
View File

@@ -39,9 +39,6 @@ There are a few interesting properties about the list of `--beacon-nodes`:
earlier in the list.
- *Synced is preferred*: the validator client prefers a synced beacon node over
one that is still syncing.
- *Failure is sticky*: if a beacon node fails, it will be flagged as offline
and won't be retried again for the rest of the slot (12 seconds). This helps prevent the impact
of time-outs and other lengthy errors.
> Note: When supplying multiple beacon nodes the `http://localhost:5052` address must be explicitly
> provided (if it is desired). It will only be used as default if no `--beacon-nodes` flag is
@@ -76,6 +73,22 @@ Prior to v3.2.0 fallback beacon nodes also required the `--subscribe-all-subnets
now broadcast subscriptions to all connected beacon nodes by default. This broadcast behaviour
can be disabled using the `--broadcast none` flag for `lighthouse vc`.
### Fallback Health
Since v6.0.0, the validator client will be more aggressive in switching to a fallback node. To do this,
it uses the concept of "Health". Every slot, the validator client checks each connected beacon node
to determine which node is the "Healthiest". In general, the validator client will prefer nodes
which are synced, have synced execution layers and which are not currently optimistically
syncing.
Sync distance is separated out into 4 tiers: "Synced", "Small", "Medium", "Large". Nodes are then
sorted into tiers based onto sync distance and execution layer status. You can use the
`--beacon-nodes-sync-tolerances` to change how many slots wide each tier is. In the case where
multiple nodes fall into the same tier, user order is used to tie-break.
To see health information for each connected node, you can use the
[`/lighthouse/beacon/health` API endpoint](./api_vc_endpoints.md#get-lighthousebeaconhealth).
### Broadcast modes
Since v4.6.0, the Lighthouse VC can be configured to broadcast messages to all configured beacon