fix(fork-choice): bound a block's slot before the empty-slot loop runs

[tcoratger]

What

Closes #1171: block acceptance had a lower slot bound but no upper bound, so a single validly-signed block could force the state-transition's empty-slot loop to run unboundedly — a denial of service every transliterating client inherits.

The bug

The empty-slot loop advances state.slot one slot at a time up to block.slot, so its length is exactly block.slot − parent.slot. on_block ran no upper-bound check on block.slot before the transition. The proposer of a slot is slot % num_validators, so one key is the valid proposer for infinitely many slots and can sign a block at slot 2**63; the always-present genesis state is a reachable parent; and the post-state root is only checked after the loop. So one small message forces ~2**63 iterations.

The fix — two guards in on_block, before the transition

The consensus decision here matters: the loop length is block.slot − parent.slot, not block.slot − current_slot. A clock horizon alone bounds block.slot but not the loop — a block on the genesis parent at slot ≈ current_slot passes a clock check yet still runs ~current_slot iterations, a residual that grows with node uptime. So the fix uses both:

• Parent-gap cap (primary): reject block.slot − parent.slot > HISTORICAL_ROOTS_LIMIT (2^18). This bounds the actual loop variable directly and is clock-independent. It is lossless: process_block_header grows the historical_block_hashes list (capped at 2^18) by the gap, so any block with a larger gap is already doomed to overflow that list — but only after the loop runs. Capping the gap up front rejects exactly those already-doomed blocks, with no false rejections and no liveness cost, reusing the existing constant.
• Clock horizon (secondary): reject block.slot > current_slot + 1. Mirrors the attestation future-slot guard and keeps far-future blocks out of the store. The margin is a whole slot, not the attestation path's one interval, so an intended early block still imports.

Both work in Python integers (the near-2^64 wire slot never overflows), both run before signature verification so a far-future block is rejected cheaply, and both live only in on_block — the untrusted-input boundary. Block production advances slots through build_block/process_slots directly, so it is unaffected; the guard deliberately does not go in process_slots.

This matches consensus-specs, which also places the future-slot bound in on_block before the transition — but with a whole-slot margin rather than an exact current_slot >= block.slot assert, because this spec deliberately imports self-authenticating early blocks (see test_early_block_arrival.py).

Tests

Consensus vectors (fork behavior is vector-tested):

• test_block_future_horizon.py — a slot-2 block with the clock pinned at interval 0 is rejected with BLOCK_TOO_FAR_IN_FUTURE (full-message equality), the store untouched; plus a non-genesis-clock boundary (clock at slot 1: a slot-2 block imports, a slot-3 block is rejected).
• The existing early-arrival vectors still import unchanged (a slot-1 block at interval 0 is within the one-slot margin).

The parent-gap cap is verified by construction rather than by a vector: a block with a >2^18 slot gap cannot be built through the fixture (the builder runs the real transition, and the signing keys are slot-bounded) and would overflow the historical-roots list regardless. This is documented, not vectored.

just check is clean; the new and affected vectors fill deterministically.

Credit

Found via the Lean 4 formalization of this spec (NyxFoundation/formal-leanSpec): the empty-slot loop was proved to terminate for a given target, but nothing bounded the target itself — exactly the missing precondition.

Closes #1171

🤖 Generated with Claude Code