mirror of
https://github.com/sigp/lighthouse.git
synced 2026-04-26 01:03:40 +00:00
Merge branch 'unstable' into validator-manager
This commit is contained in:
Paul Hauner
@@ -47,6 +47,7 @@
|
||||
* [Release Candidates](./advanced-release-candidates.md)
|
||||
* [MEV and Lighthouse](./builders.md)
|
||||
* [Merge Migration](./merge-migration.md)
|
||||
* [Late Block Re-orgs](./late-block-re-orgs.md)
|
||||
* [Contributing](./contributing.md)
|
||||
* [Development Environment](./setup.md)
|
||||
* [FAQs](./faq.md)
|
||||
|
||||
@@ -99,6 +99,55 @@ curl -X GET "http://localhost:5052/lighthouse/ui/health" -H "accept: applicatio
|
||||
}
|
||||
```
|
||||
|
||||
### `/lighthouse/ui/validator_count`
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/ui/validator_count" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"active_ongoing":479508,
|
||||
"active_exiting":0,
|
||||
"active_slashed":0,
|
||||
"pending_initialized":28,
|
||||
"pending_queued":0,
|
||||
"withdrawal_possible":933,
|
||||
"withdrawal_done":0,
|
||||
"exited_unslashed":0,
|
||||
"exited_slashed":3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### `/lighthouse/ui/validator_metrics`
|
||||
Re-exposes certain metrics from the validator monitor to the HTTP API.
|
||||
Will only return metrics for the validators currently being monitored and are present in the POST data.
|
||||
```bash
|
||||
curl -X POST "http://localhost:5052/lighthouse/ui/validator_metrics" -d '{"indices": [12345]}' -H "Content-Type: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"validators": {
|
||||
"12345": {
|
||||
"attestation_hits": 10,
|
||||
"attestation_misses": 0,
|
||||
"attestation_hit_percentage": 100,
|
||||
"attestation_head_hits": 10,
|
||||
"attestation_head_misses": 0,
|
||||
"attestation_head_hit_percentage": 100,
|
||||
"attestation_target_hits": 5,
|
||||
"attestation_target_misses": 5,
|
||||
"attestation_target_hit_percentage": 50
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### `/lighthouse/syncing`
|
||||
|
||||
```bash
|
||||
@@ -452,6 +501,102 @@ The endpoint will return immediately. See the beacon node logs for an indication
|
||||
Manually provide `SignedBeaconBlock`s to backfill the database. This is intended
|
||||
for use by Lighthouse developers during testing only.
|
||||
|
||||
### `/lighthouse/merge_readiness`
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/merge_readiness" | jq
|
||||
```
|
||||
|
||||
```
|
||||
{
|
||||
"data":{
|
||||
"type":"ready",
|
||||
"config":{
|
||||
"terminal_total_difficulty":"6400"
|
||||
},
|
||||
"current_difficulty":"4800"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### `/lighthouse/analysis/attestation_performance/{index}`
|
||||
|
||||
Fetch information about the attestation performance of a validator index or all validators for a
|
||||
range of consecutive epochs.
|
||||
|
||||
Two query parameters are required:
|
||||
|
||||
* `start_epoch` (inclusive): the first epoch to compute attestation performance for.
|
||||
* `end_epoch` (inclusive): the final epoch to compute attestation performance for.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/analysis/attestation_performance/1?start_epoch=1&end_epoch=1" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 1,
|
||||
"epochs": {
|
||||
"1": {
|
||||
"active": true,
|
||||
"head": true,
|
||||
"target": true,
|
||||
"source": true,
|
||||
"delay": 1
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Instead of specifying a validator index, you can specify the entire validator set by using `global`:
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/analysis/attestation_performance/global?start_epoch=1&end_epoch=1" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"index": 0,
|
||||
"epochs": {
|
||||
"1": {
|
||||
"active": true,
|
||||
"head": true,
|
||||
"target": true,
|
||||
"source": true,
|
||||
"delay": 1
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"index": 1,
|
||||
"epochs": {
|
||||
"1": {
|
||||
"active": true,
|
||||
"head": true,
|
||||
"target": true,
|
||||
"source": true,
|
||||
"delay": 1
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
..
|
||||
}
|
||||
]
|
||||
|
||||
```
|
||||
|
||||
Caveats:
|
||||
|
||||
* For maximum efficiency the start_epoch should satisfy `(start_epoch * slots_per_epoch) % slots_per_restore_point == 1`.
|
||||
This is because the state _prior_ to the `start_epoch` needs to be loaded from the database,
|
||||
and loading a state on a boundary is most efficient.
|
||||
|
||||
### `/lighthouse/analysis/block_rewards`
|
||||
|
||||
Fetch information about the block rewards paid to proposers for a range of consecutive blocks.
|
||||
@@ -464,7 +609,7 @@ Two query parameters are required:
|
||||
Example:
|
||||
|
||||
```bash
|
||||
curl "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=32" | jq
|
||||
curl -X GET "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=32" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
@@ -492,21 +637,43 @@ Caveats:
|
||||
[block_reward_src]:
|
||||
https://github.com/sigp/lighthouse/tree/unstable/common/eth2/src/lighthouse/block_rewards.rs
|
||||
|
||||
### `/lighthouse/analysis/block_packing`
|
||||
|
||||
### `/lighthouse/merge_readiness`
|
||||
Fetch information about the block packing efficiency of blocks for a range of consecutive
|
||||
epochs.
|
||||
|
||||
Two query parameters are required:
|
||||
|
||||
* `start_epoch` (inclusive): the epoch of the first block to compute packing efficiency for.
|
||||
* `end_epoch` (inclusive): the epoch of the last block to compute packing efficiency for.
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/merge_readiness"
|
||||
curl -X GET "http://localhost:5052/lighthouse/analysis/block_packing_efficiency?start_epoch=1&end_epoch=1" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"slot": "33",
|
||||
"block_hash": "0xb20970bb97c6c6de6b1e2b689d6381dd15b3d3518fbaee032229495f963bd5da",
|
||||
"proposer_info": {
|
||||
"validator_index": 855,
|
||||
"graffiti": "poapZoJ7zWNfK7F3nWjEausWVBvKa6gA"
|
||||
},
|
||||
"available_attestations": 3805,
|
||||
"included_attestations": 1143,
|
||||
"prior_skip_slots": 1
|
||||
},
|
||||
{
|
||||
..
|
||||
}
|
||||
]
|
||||
```
|
||||
{
|
||||
"data":{
|
||||
"type":"ready",
|
||||
"config":{
|
||||
"terminal_total_difficulty":"6400"
|
||||
},
|
||||
"current_difficulty":"4800"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Caveats:
|
||||
|
||||
* `start_epoch` must not be `0`.
|
||||
* For maximum efficiency the `start_epoch` should satisfy `(start_epoch * slots_per_epoch) % slots_per_restore_point == 1`.
|
||||
This is because the state _prior_ to the `start_epoch` needs to be loaded from the database, and
|
||||
loading a state on a boundary is most efficient.
|
||||
|
||||
|
||||
@@ -117,6 +117,31 @@ Returns information regarding the health of the host machine.
|
||||
}
|
||||
```
|
||||
|
||||
## `GET /lighthouse/ui/graffiti`
|
||||
|
||||
Returns the graffiti that will be used for the next block proposal of each validator.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/ui/graffiti` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"0x81283b7a20e1ca460ebd9bbd77005d557370cabb1f9a44f530c4c4c66230f675f8df8b4c2818851aa7d77a80ca5a4a5e": "mr f was here",
|
||||
"0xa3a32b0f8b4ddb83f1a0a853d81dd725dfe577d4f4c3db8ece52ce2b026eca84815c1a7e8e92a4de3d755733bf7e4a9b": "mr v was here",
|
||||
"0x872c61b4a7f8510ec809e5b023f5fdda2105d024c470ddbbeca4bc74e8280af0d178d749853e8f6a841083ac1b4db98f": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `GET /lighthouse/spec`
|
||||
|
||||
Returns the Ethereum proof-of-stake consensus specification loaded for this validator.
|
||||
|
||||
@@ -6,4 +6,4 @@ RESTful HTTP/JSON APIs.
|
||||
There are two APIs served by Lighthouse:
|
||||
|
||||
- [Beacon Node API](./api-bn.md)
|
||||
- [Validator Client API](./api-vc.md) (not yet released).
|
||||
- [Validator Client API](./api-vc.md)
|
||||
|
||||
@@ -200,19 +200,23 @@ for `INFO` and `WARN` messages indicating why the builder was not used.
|
||||
Examples of messages indicating fallback to a locally produced block are:
|
||||
|
||||
```
|
||||
INFO No payload provided by connected builder.
|
||||
INFO Builder did not return a payload
|
||||
```
|
||||
|
||||
```
|
||||
WARN Unable to retrieve a payload from a connected builder
|
||||
WARN Builder error when requesting payload
|
||||
```
|
||||
|
||||
```
|
||||
INFO The value offered by the connected builder does not meet the configured profit threshold.
|
||||
WARN Builder returned invalid payload
|
||||
```
|
||||
|
||||
```
|
||||
INFO Due to poor chain health the local execution engine will be used for payload construction.
|
||||
INFO Builder payload ignored
|
||||
```
|
||||
|
||||
```
|
||||
INFO Chain is unhealthy, using local payload
|
||||
```
|
||||
|
||||
In case of fallback you should see a log indicating that the locally produced payload was
|
||||
|
||||
@@ -19,13 +19,13 @@ validator client or the slasher**.
|
||||
| v2.0.0 | Oct 2021 | v5 | no |
|
||||
| v2.1.0 | Jan 2022 | v8 | no |
|
||||
| v2.2.0 | Apr 2022 | v8 | no |
|
||||
| v2.3.0 | May 2022 | v9 | yes (pre Bellatrix) |
|
||||
| v2.4.0 | Jul 2022 | v9 | yes (pre Bellatrix) |
|
||||
| v2.3.0 | May 2022 | v9 | yes from <= v3.3.0 |
|
||||
| v2.4.0 | Jul 2022 | v9 | yes from <= v3.3.0 |
|
||||
| v2.5.0 | Aug 2022 | v11 | yes |
|
||||
| v3.0.0 | Aug 2022 | v11 | yes |
|
||||
| v3.1.0 | Sep 2022 | v12 | yes |
|
||||
| v3.2.0 | Oct 2022 | v12 | yes |
|
||||
| v3.3.0 | TBD | v13 | yes |
|
||||
| v3.3.0 | Nov 2022 | v13 | yes |
|
||||
|
||||
> **Note**: All point releases (e.g. v2.3.1) are schema-compatible with the prior minor release
|
||||
> (e.g. v2.3.0).
|
||||
|
||||
60
book/src/late-block-re-orgs.md
Normal file
60
book/src/late-block-re-orgs.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Late Block Re-orgs
|
||||
|
||||
Since v3.4.0 Lighthouse will opportunistically re-org late blocks when proposing.
|
||||
|
||||
This feature is intended to disincentivise late blocks and improve network health. Proposing a
|
||||
re-orging block is also more profitable for the proposer because it increases the number of
|
||||
attestations and transactions that can be included.
|
||||
|
||||
## Command line flags
|
||||
|
||||
There are three flags which control the re-orging behaviour:
|
||||
|
||||
* `--disable-proposer-reorgs`: turn re-orging off (it's on by default).
|
||||
* `--proposer-reorg-threshold N`: attempt to orphan blocks with less than N% of the committee vote. If this parameter isn't set then N defaults to 20% when the feature is enabled.
|
||||
* `--proposer-reorg-epochs-since-finalization N`: only attempt to re-org late blocks when the number of epochs since finalization is less than or equal to N. The default is 2 epochs,
|
||||
meaning re-orgs will only be attempted when the chain is finalizing optimally.
|
||||
|
||||
All flags should be applied to `lighthouse bn`. The default configuration is recommended as it
|
||||
balances the chance of the re-org succeeding against the chance of failure due to attestations
|
||||
arriving late and making the re-org block non-viable.
|
||||
|
||||
## Safeguards
|
||||
|
||||
To prevent excessive re-orgs there are several safeguards in place that limit when a re-org
|
||||
will be attempted.
|
||||
|
||||
The full conditions are described in [the spec][] but the most important ones are:
|
||||
|
||||
* Only single-slot re-orgs: Lighthouse will build a block at N + 1 to re-org N by building on the
|
||||
parent N - 1. The result is a chain with exactly one skipped slot.
|
||||
* No epoch boundaries: to ensure that the selected proposer does not change, Lighthouse will
|
||||
not propose a re-orging block in the 0th slot of an epoch.
|
||||
|
||||
## Logs
|
||||
|
||||
You can track the reasons for re-orgs being attempted (or not) via Lighthouse's logs.
|
||||
|
||||
A pair of messages at `INFO` level will be logged if a re-org opportunity is detected:
|
||||
|
||||
> INFO Attempting re-org due to weak head threshold_weight: 45455983852725, head_weight: 0, parent: 0x09d953b69041f280758400c671130d174113bbf57c2d26553a77fb514cad4890, weak_head: 0xf64f8e5ed617dc18c1e759dab5d008369767c3678416dac2fe1d389562842b49
|
||||
|
||||
> INFO Proposing block to re-org current head head_to_reorg: 0xf64f…2b49, slot: 1105320
|
||||
|
||||
This should be followed shortly after by a `WARN` log indicating that a re-org occurred. This is
|
||||
expected and normal:
|
||||
|
||||
> WARN Beacon chain re-org reorg_distance: 1, new_slot: 1105320, new_head: 0x72791549e4ca792f91053bc7cf1e55c6fbe745f78ce7a16fc3acb6f09161becd, previous_slot: 1105319, previous_head: 0xf64f8e5ed617dc18c1e759dab5d008369767c3678416dac2fe1d389562842b49
|
||||
|
||||
In case a re-org is not viable (which should be most of the time), Lighthouse will just propose a
|
||||
block as normal and log the reason the re-org was not attempted at debug level:
|
||||
|
||||
> DEBG Not attempting re-org reason: head not late
|
||||
|
||||
If you are interested in digging into the timing of `forkchoiceUpdated` messages sent to the
|
||||
execution layer, there is also a debug log for the suppression of `forkchoiceUpdated` messages
|
||||
when Lighthouse thinks that a re-org is likely:
|
||||
|
||||
> DEBG Fork choice update overridden slot: 1105320, override: 0x09d953b69041f280758400c671130d174113bbf57c2d26553a77fb514cad4890, canonical_head: 0xf64f8e5ed617dc18c1e759dab5d008369767c3678416dac2fe1d389562842b49
|
||||
|
||||
[the spec]: https://github.com/ethereum/consensus-specs/pull/3034
|
||||
Reference in New Issue
Block a user