Remove /lighthouse/analysis/block_rewards APIs (#8935)

Mark pointed out that these APIs will require updates for Gloas, so I figured we may as well get rid of them. As far as I know, blockprint was the only use case and it is now defunct. The consensus block value is included in getBlock API responses, so there's no reason for VCs to use the `POST` API, and there is now a standard API for the rewards of canonical blocks. The SSE event was non-standard, and likely only used by blockprint as well.


Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
This commit is contained in:
Michael Sproul
2026-03-09 11:35:52 +11:00
committed by GitHub
parent efe43f7699
commit 537c2ba8b3
11 changed files with 4 additions and 541 deletions

View File

@@ -590,60 +590,6 @@ Caveats:
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.
Two query parameters are required:
- `start_slot` (inclusive): the slot of the first block to compute rewards for.
- `end_slot` (inclusive): the slot of the last block to compute rewards for.
Example:
```bash
curl -X GET "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=1" | jq
```
The first few lines of the response would look like:
```json
[
{
"total": 637260,
"block_root": "0x4a089c5e390bb98e66b27358f157df825128ea953cee9d191229c0bcf423a4f6",
"meta": {
"slot": "1",
"parent_slot": "0",
"proposer_index": 93,
"graffiti": "EF #vm-eth2-raw-iron-101"
},
"attestation_rewards": {
"total": 637260,
"prev_epoch_total": 0,
"curr_epoch_total": 637260,
"per_attestation_rewards": [
{
"50102": 780,
}
]
}
}
]
```
Caveats:
- Presently only attestation and sync committee rewards are computed.
- The output format is verbose and subject to change. Please see [`BlockReward`][block_reward_src]
in the source.
- For maximum efficiency the `start_slot` should satisfy `start_slot % slots_per_restore_point == 1`.
This is because the state *prior* to the `start_slot` needs to be loaded from the database, and
loading a state on a boundary is most efficient.
[block_reward_src]:
https://github.com/sigp/lighthouse/tree/unstable/common/eth2/src/lighthouse/block_rewards.rs
## `/lighthouse/analysis/block_packing`
Fetch information about the block packing efficiency of blocks for a range of consecutive