Skip to content

feat: extend /eth/v1/node/peers with peer scoring and disconnect reasons#606

Draft
barnabasbusa wants to merge 3 commits into
ethereum:masterfrom
barnabasbusa:bbusa/peer-scoring-spec
Draft

feat: extend /eth/v1/node/peers with peer scoring and disconnect reasons#606
barnabasbusa wants to merge 3 commits into
ethereum:masterfrom
barnabasbusa:bbusa/peer-scoring-spec

Conversation

@barnabasbusa
Copy link
Copy Markdown
Member

No description provided.

Introduces a new debug endpoint that returns the consensus client's
current per-peer scoring snapshot. Each entry includes the client-
native blended score, the per-subsystem score components the client
chooses to expose, the most recent score-affecting action (if any),
and the most recent disconnect (if any).

The schema is intentionally permissive about what each client
surfaces, because the visibility eth2 clients have into their own
scoring varies widely:

- `components` is a flexible map; `gossipsub` is optional because
  some clients (notably Nimbus) have no application-layer access to
  the underlying libp2p scores.
- `last_action` and `last_disconnect` are both optional - gossipsub-
  driven disconnects in particular often bypass the client's reason-
  capture path.
- `score_range` is required so consumers can normalize across
  clients whose native score ranges differ wildly: [-100, +100] for
  Lighthouse / Lodestar / Grandine, [-10, +20] for Teku, [0, 1000]
  for Nimbus, [-100, +1] for Prysm.

`PeerScoreReason` and `PeerDisconnectReason` are controlled
vocabularies that group the common cross-client causes; the original
client-side string is preserved in `native_reason` so consumers can
distinguish e.g. multiple `rpc_*` flavors that map to the same
controlled code.

Prior art motivating this proposal:
- Lighthouse `GET /lighthouse/peers`
- Lodestar `GET /eth/v1/lodestar/lodestar_peer_score_stats`
- Teku `GET /teku/v1/nodes/peer_scores`
- Prysm internal `ScoreInfo` proto + the WIP REST endpoint
  on `OffchainLabs/prysm:peer-scores-ui`
Matches the existing flat snake_case URL convention used by
/eth/v1/node/peer_count and the file name peer_scores.yaml. Prior
revision used /eth/v1/debug/node/peers/scores which mixed
subdirectory-style with the rest of the API.
Drop the separate /eth/v1/debug/node/peer_scores endpoint and the
PeerScore/PeerScoreRange/PeerScoreComponents/PeerScoreAction/
PeerDisconnectAction object hierarchy in favour of four optional
fields on the existing Peer schema: agent_version, score,
disconnect_reason, downscore_reasons.

Trim PeerScoreReason from 51 to 15 controlled values and
PeerDisconnectReason from 20 to 8, keeping the cross-client realistic
union rather than the full taxonomy. Implementations that compute
finer-grained internal tags are expected to map them onto the closest
listed value.

Strictly additive change to /eth/v1/node/peers and /eth/v1/node/peers/
{peer_id}: all new fields are optional so existing consumers are
unaffected.
@barnabasbusa barnabasbusa changed the title Bbusa/peer scoring spec feat: extend /eth/v1/node/peers with peer scoring and disconnect reasons May 15, 2026
@barnabasbusa barnabasbusa marked this pull request as draft May 15, 2026 07:44
barnabasbusa added a commit to barnabasbusa/lighthouse that referenced this pull request May 15, 2026
… state

Per the proposed beacon-API spec
(ethereum/beacon-APIs#606), `disconnect_reason`
MUST only be populated when the peer's `state` is `disconnected` or
`disconnecting`. Wrap the existing `last_disconnect()` lookup in both
the single-peer and list handlers so the field is omitted (None) for
connected/connecting peers.
barnabasbusa added a commit to barnabasbusa/lodestar that referenced this pull request May 15, 2026
… state

Per the proposed beacon-API spec
(ethereum/beacon-APIs#606), `disconnect_reason`
MUST only be populated when the peer's `state` is `disconnected` or
`disconnecting`. Compute the node-peer view first and only attach a
mapped `disconnectReason` when the resolved state matches.
barnabasbusa added a commit to barnabasbusa/teku that referenced this pull request May 15, 2026
…ing state

Per the proposed beacon-API spec
(ethereum/beacon-APIs#606), `disconnect_reason`
MUST only be populated when the peer's `state` is `disconnected` or
`disconnecting`. Teku exposes only `connected`/`disconnected` via
`Eth2Peer#isConnected()`, so suppress the field for connected peers.
barnabasbusa added a commit to barnabasbusa/prysm that referenced this pull request May 15, 2026
Per the proposed beacon-API spec
(ethereum/beacon-APIs#606), `disconnect_reason`
MUST only be populated when the peer's `state` is `disconnected` or
`disconnecting`. Only look up the last goodbye when the (lowercased)
peer state matches one of those values.
barnabasbusa added a commit to barnabasbusa/nimbus-eth2 that referenced this pull request May 15, 2026
Per the proposed beacon-API spec
(ethereum/beacon-APIs#606), `disconnect_reason`
MUST only be populated when the peer's `state` is `disconnected` or
`disconnecting`. Gate the `peer.lastDisconnectReason` lookup in both
the list and single-peer handlers on `peer.connectionState` so the
field is omitted (Opt.none) for connected/connecting peers.
barnabasbusa added a commit to barnabasbusa/grandine that referenced this pull request May 15, 2026
Per the proposed beacon-API spec
(ethereum/beacon-APIs#606), `disconnect_reason`
MUST only be populated when the peer's `state` is `disconnected` or
`disconnecting`. Only map `last_disconnect()` when the resolved
`PeerState` matches one of those variants.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant