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
- Genesis exposes only a message-size knob, not a block-size relationship, and validates unrelated fields: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/genesis.rs#L35, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/genesis.rs#L135.
- Node startup casts
genesis.max_message_size_bytes to u32 and passes it to authenticated::discovery::Config::{recommended,local}: https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L371, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L373, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L383, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L551, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L561.
- Syncer backfill serves a raw encoded block for
Request::Block and raw encoded (finalization, block) / (notarization, block) responses for finalized and notarized requests: https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L840, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L846, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L858, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L870.
- Missing finalized blocks are repaired by fetching block/finalized items through that resolver path: https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L627, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L1195, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L1524, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L1534.
- Summit's block codec size is the SSZ block size plus a four-byte length prefix, with no configured max encoded block size: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/block.rs#L245, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/block.rs#L251, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/block.rs#L261.
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.
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_byteslimits 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 validatemax_message_size_bytesagainst 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_bytesconfiguration 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 configuredmax_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
genesis.max_message_size_bytestou32and passes it toauthenticated::discovery::Config::{recommended,local}: https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L371, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L373, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L383, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L551, https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/args.rs#L561.Request::Blockand raw encoded(finalization, block)/(notarization, block)responses for finalized and notarized requests: https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L840, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L846, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L858, https://github.com/SeismicSystems/summit/blob/ed2c5c8/syncer/src/actor.rs#L870.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
max_message_size_bytesagainst the maximum encoded Summit block plus resolver and certificate overhead.