Skip to content

Add configurable server-side limit to enforce maximum --sync-fetch-span in peer sync requests #1717

Closed as not planned
@bhazzard

Description

@bhazzard

Originally requested here: #1691

As a relay node operator or Spring node admin, I want the ability to configure a maximum allowed --sync-fetch-span value on the server, so that I can prevent peers from requesting unreasonably large block spans and reduce the risk of memory pressure or abuse on my node.


Background

Currently, --sync-fetch-span is a client-side setting that determines how many blocks a syncing node can request at a time. However, the server has no mechanism to enforce a maximum span. This means a client could specify an excessively large fetch span (e.g., 100,000,000), causing it to receive more blocks than it can process quickly, leading to unbounded memory usage. While the burden primarily impacts the requesting node, relay node operators may want to protect their infrastructure from high-throughput demands or misuse by clients using extreme settings.

Introducing a server-side limit provides a simple safeguard. It doesn't prevent syncing altogether—it just ensures that each peer-to-peer request is bounded and fair.


Acceptance Criteria

  • Add a new server-side configuration option:
    --max-sync-fetch-span (default: no limit / same as current behavior).

  • When responding to a sync request, if the client’s requested sync-fetch-span exceeds this limit:

    • Truncate the response to the maximum allowed span.
    • Log a warning with peer info and the clamped value for observability.
  • Ensure clamped spans still result in valid behavior and don’t cause sync errors or protocol issues.

  • Document the new flag in CLI help and release notes.


Non-Goals

  • No changes to the default behavior of clients using --sync-fetch-span.
  • No enforcement of memory usage or throughput caps beyond span clamping.
  • No changes to how blocks are fetched from other nodes (e.g., round-robin behavior).

Notes

  • While the requesting node bears most of the performance cost for large spans, server-side limits can prevent abuse or uneven load in peer-to-peer networks.
  • This change is forward-compatible and can be rolled out without coordination across nodes.
  • Consider adding metrics or logging for visibility into average fetch span requested and enforced.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    Done

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions