iotaledger / iota / 24867676604

67%

Build Type

push

github

Committed by web-flow

Commit Message

fix(starfish): drop too-old ancestors when proposing a new block (#11303)

# Description of change

`Core::ancestors_to_propose` now skips ancestors whose round is strictly
below the linearizer's gc cutoff seen from the perspective of our
not-yet-proposed block. Such ancestors would be filtered out by the
linearizer anyway — referencing them only forces receiving validators to
chase the references through the header synchronizer. This is especially
important for fast commit syncer logic which reinitialize the dag state
with only a few recent blocks.

- **Filter** (`crates/starfish/core/src/core.rs`): inside
`ancestors_to_propose`, drop any candidate with `ancestor.round() <
min_ancestor_round(clock_round)` before the existing per-author dedup
logic. Own last proposed block header is still unconditionally chained
first.
- **`min_ancestor_round`**: `clock_round - gc_depth` if we are a leader
at `clock_round` (the linearizer at our own commit uses `gc_round =
clock_round - gc_depth`), otherwise `clock_round - (gc_depth - 1)` (the
earliest leader that can commit a non-leader block is at `clock_round +
1`, so its `gc_round` is one round higher).
- **Gate**: `consensus_fast_commit_sync`. When the flag is off the
method returns `GENESIS_ROUND = 0`, and the strict `<` filter never
fires — zero behavior change on networks without it (e.g. mainnet
today).
- **Edge cases**: `saturating_sub` naturally clamps small `clock_round`s
(`< depth`) to `0`; the filter self-disables there, so no special
quorum-round clamp is needed. Non-leader rounds that briefly have no
scheduled leader fall through to the `gc_depth - 1` branch which is only
ever stricter than what the eventual linearizer needs.

**Best-effort, not enforced.** This is a best-effort proposer-side
filter — receiving validators do not reject blocks that still reference
too-old ancestors. A proper validity check (rejecting blocks whose
ancestor rounds violate the same bound) will be added in a follow-up PR
wi... (continued)

Coverage Stats

63 of 63 new or added lines in 1 file covered. (100.0%)

534 existing lines in 20 files now uncovered.

176255 of 269890 relevant lines covered (65.31%)

433052.13 hits per line