Remove lighthouse/analysis endpoints (#8968)

Some of our custom `lighthouse/analysis` endpoints will require maintenance for the Gloas hard fork. We have decided instead to remove those endpoints. We don't utilize them internally and they have pretty limited utility and so we feel they are not worth maintaining.


  Remove `lighthouse/analysis/attestation_performance` and `lighthouse/analysis/block_packing_efficiency` endpoints.


Co-Authored-By: Mac L <mjladson@pm.me>
This commit is contained in:
Mac L
2026-03-18 04:24:58 +03:00
committed by GitHub
parent 17d183eb5b
commit a965bfdf77
9 changed files with 26 additions and 937 deletions

View File

@@ -512,126 +512,6 @@ As all testnets and Mainnet have been merged, both values will be the same after
}
```
## `/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_packing`
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/analysis/block_packing_efficiency?start_epoch=1&end_epoch=1" | jq
```
An excerpt of the response looks like:
```json
[
{
"slot": "33",
"block_hash": "0xb20970bb97c6c6de6b1e2b689d6381dd15b3d3518fbaee032229495f963bd5da",
"proposer_info": {
"validator_index": 855,
"graffiti": "poapZoJ7zWNfK7F3nWjEausWVBvKa6gA"
},
"available_attestations": 3805,
"included_attestations": 1143,
"prior_skip_slots": 1
},
{
..
}
]
```
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.
## `/lighthouse/logs`
This is a Server Side Event subscription endpoint. This allows a user to read