[Security][tentative] Medium (correctness): Proposer Can Build Too-Far-Future Timestamp From Parent

[evonide]

Context

The application proposer chooses timestamps for newly built Summit blocks, and peer validators independently enforce timestamp rules before voting. The normal invariant is that an honest proposer should only emit blocks that satisfy the same monotonicity and future-window checks used by verifiers.

Summit must balance two timestamp constraints: each child must be later than its parent, and it must not be too far ahead of the verifier's local clock. The finding concerns the proposer-side path where preserving parent-child monotonicity can produce a timestamp that still violates the verifier future allowance.

Claim

The proposer enforces parent-child timestamp monotonicity without enforcing the verifier's future-timestamp bound. When local time is not greater than the parent timestamp, it emits parent.timestamp() + 1 even if that value is still outside the configured future allowance that honest verifiers apply.

After clock skew or an accepted parent near the future-timestamp limit, an honest proposer can select parent.timestamp() + 1 to preserve monotonicity without waiting for peers' future-window predicate; peers then reject the otherwise well-formed child as too far in the future, causing missed proposal or notarization progress.

Flow

This requires local wall clock to be at or behind the parent timestamp, such as after clock skew or after accepting a parent near the future-timestamp limit. The proposer then chooses parent.timestamp() + 1 without waiting.

Impact

After clock skew or a previously accepted future-timestamp parent, an honest proposer can create a block that is monotonic relative to the parent but still too far ahead for peers. Honest validators may reject or fail to notarize the block, causing missed slots or temporary consensus stalls until clocks catch up.

Root Cause

Proposal timestamp selection enforces monotonicity relative to the parent but does not enforce the same future-window predicate used by verifiers.

Code

• Proposal timestamp selection bumps to parent_block.timestamp() + 1 when local time is behind the parent: https://github.com/SeismicSystems/summit/blob/ed2c5c8/application/src/actor.rs#L480, https://github.com/SeismicSystems/summit/blob/ed2c5c8/application/src/actor.rs#L482.
• Verification rejects non-increasing timestamps: https://github.com/SeismicSystems/summit/blob/ed2c5c8/application/src/actor.rs#L630.
• Verification also rejects timestamps above now_millis + allowed_timestamp_future_ms: https://github.com/SeismicSystems/summit/blob/ed2c5c8/application/src/actor.rs#L638.
• The future-timestamp allowance is bounded as a protocol parameter: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/protocol_params.rs#L9-L10.

Related Issues/PRs

Related issues cover related proposal and verification progress hazards caused by stale fork state, old-epoch handling, or boundary-state timing.

• [Security][tentative] Medium (attackable): Finalizer Leaves Losing-Fork Height Waiters Pending #245
• [Security][tentative] Medium (unknown): Losing-Fork Descendants Remain Live for Aux Data #249
• [Security][tentative] Medium (correctness): Old Epoch Schemes Are Unregistered Too Early #251

Fix

• Before proposing, wait until parent.timestamp() + 1 is within the allowed future window, or derive proposal eligibility from the same clock-skew rule verifiers use.
• Add tests for parent timestamps ahead of proposer and verifier clocks.
• Separately keep enforcing that execution payload timestamps match the consensus header timestamp.