Skip to content

[Security][tentative] Medium (correctness): P2P Message Size Can Prevent Large Block Sync #252

@evonide

Description

@evonide

Context

Summit peers use Commonware P2P channels for block propagation and resolver backfill. Lagging or checkpoint-joining nodes rely on single-message block and certificate responses to repair finalized data gaps, while max_message_size_bytes limits the largest payload those channels will send.

Claim

Summit sends full blocks and full (certificate, block) backfill responses as single Commonware P2P messages. It does not validate max_message_size_bytes against the largest valid block plus resolver and certificate overhead, so valid finalized data can be larger than the only backfill message format used to serve it.

A max_message_size_bytes configuration below the size of valid finalized block or (certificate, block) data can leave Summit's single-message backfill response larger than the transport cap. Lagging, restarting, or checkpoint-joining peers then request that finalized data through normal resolver backfill, but every single-message response exceeds the cap and the peers remain unable to repair the gap. A malicious proposer path would require separately proving that valid execution payloads in the target deployment can exceed the configured cap.

Flow

The path is reachable whenever finalized block repair or boundary-finalization backfill serves full responses as single P2P messages. It requires a valid block or (certificate, block) response exceeding the configured max_message_size_bytes, so adversarial proposer reachability depends on valid execution payloads being able to exceed the configured cap in the target deployment.

Impact

A lagging, restarting, or checkpoint-joining node can learn that a height is finalized but be unable to obtain the corresponding block or boundary finalization response if the encoded response is larger than the P2P message cap. The resolver retries, but every serve response fails the same size check, so archive gap repair and finalized-block dispatch can stall until manual intervention or an out-of-band block import.

Root Cause

Summit exposes a P2P message-size limit without validating it against the largest valid block/backfill response and without chunking resolver responses.

Code

Related Issues/PRs

Related issues cover adjacent P2P, RPC, resolver, and message-size limits that can interfere with large block sync or consensus progress.

Fix

  • Validate max_message_size_bytes against the maximum encoded Summit block plus resolver and certificate overhead.
  • Chunk large block and finalization responses, or provide an alternate bulk-sync path with explicit framing and limits.
  • Add a network regression test where a finalized block exceeds the configured single-message cap and the lagging node still repairs or fails with an actionable configuration error.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions