From 9e2de0f67efe16ed707a559bf76680c79c953bfa Mon Sep 17 00:00:00 2001 From: Mac L Date: Wed, 4 Dec 2024 20:56:37 +1100 Subject: [PATCH] Improve docs --- book/src/api-vc-endpoints.md | 7 +++++++ book/src/redundancy.md | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/book/src/api-vc-endpoints.md b/book/src/api-vc-endpoints.md index fd6db813012..255ddd9ccab 100644 --- a/book/src/api-vc-endpoints.md +++ b/book/src/api-vc-endpoints.md @@ -832,6 +832,13 @@ For more inormation about how to interpret the beacon node health, see [Fallback | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200, 400 | +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X GET http://localhost:5062/lighthouse/beacon/health \ + -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq + ``` + ### Example Response Body ```json diff --git a/book/src/redundancy.md b/book/src/redundancy.md index 7b886344fc5..3b488137231 100644 --- a/book/src/redundancy.md +++ b/book/src/redundancy.md @@ -77,7 +77,7 @@ can be disabled using the `--broadcast none` flag for `lighthouse vc`. 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 +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 optimisitically syncing.