Context
The syncer resolver serves historical block and archive data to authenticated peers so nodes can backfill or repair missing state. Inbound resolver requests cross from the P2P resolver engine into Summit's syncer actor, where archive reads and response encoding are performed for the requesting peer.
Claim
Commonware's resolver stores inbound serve operations in an unbounded futures pool and expects Summit's producer to limit or drop requests. Summit's resolver producer forwards every request into the syncer mailbox and waits for a response, so many small valid resolver requests can create unbounded pending serve futures and repeated storage/encoding work.
A malicious accepted P2P peer can send many small valid resolver requests, causing the local resolver to create an unbounded serve future for each request while Summit forwards every one into syncer-backed archive reads and response encoding.
Flow
The path is reachable on the resolver P2P channel for peers accepted by the authenticated-discovery tracker, such as primary or secondary keys currently tracked by the network oracle. It should not be read as reachable by an arbitrary key that can complete cryptographic authentication but is not acceptable to the tracker. It requires request volume above the syncer's ability to serve archive reads and encoded responses.
Impact
An accepted P2P peer can flood small resolver requests faster than the syncer can serve disk/archive reads and encoded responses. Memory grows in the resolver task while syncer time is spent serving adversarial historical queries instead of normal backfill and repair.
Root Cause
The Commonware resolver leaves serve concurrency unbounded and Summit's producer does not add an in-flight cap, peer quota, or request-class limiter before awaiting syncer work.
Code
Related Issues/PRs
Related issues cover other public RPC, P2P, and resolver paths where unbounded or shared resources can delay consensus work.
Fix
- Add a bounded in-flight request limit in Summit's producer.
- Drop or rate-limit resolver requests by peer and request class.
- Add metrics for pending serve futures and syncer produce queue depth.
Context
The syncer resolver serves historical block and archive data to authenticated peers so nodes can backfill or repair missing state. Inbound resolver requests cross from the P2P resolver engine into Summit's syncer actor, where archive reads and response encoding are performed for the requesting peer.
Claim
Commonware's resolver stores inbound serve operations in an unbounded futures pool and expects Summit's producer to limit or drop requests. Summit's resolver producer forwards every request into the syncer mailbox and waits for a response, so many small valid resolver requests can create unbounded pending serve futures and repeated storage/encoding work.
A malicious accepted P2P peer can send many small valid resolver requests, causing the local resolver to create an unbounded serve future for each request while Summit forwards every one into syncer-backed archive reads and response encoding.
Flow
The path is reachable on the resolver P2P channel for peers accepted by the authenticated-discovery tracker, such as primary or secondary keys currently tracked by the network oracle. It should not be read as reachable by an arbitrary key that can complete cryptographic authentication but is not acceptable to the tracker. It requires request volume above the syncer's ability to serve archive reads and encoded responses.
Impact
An accepted P2P peer can flood small resolver requests faster than the syncer can serve disk/archive reads and encoded responses. Memory grows in the resolver task while syncer time is spent serving adversarial historical queries instead of normal backfill and repair.
Root Cause
The Commonware resolver leaves serve concurrency unbounded and Summit's producer does not add an in-flight cap, peer quota, or request-class limiter before awaiting syncer work.
Code
max_repair: https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L776.Related Issues/PRs
Related issues cover other public RPC, P2P, and resolver paths where unbounded or shared resources can delay consensus work.
Fix