iotaledger / iota / 30678166217

70%

Build Type

push

github

Committed by web-flow

Commit Message

feat(starfish): prefer commit-sync peers that have the requested range (#12486)

# Description of change

The commit syncer draws its fetch candidates from the whole committee,
with no signal about which peers actually hold the range. A peer asked
for a range it does not have answers with an empty success, which costs
a full request and one slot in the sequential per-round pass. On a
network where only part of the committee is caught up, the wasted round
trips scale with committee size over the number of caught-up peers.

`CommitVoteMonitor` already tracks the highest commit index voted by
each authority, and `commit_syncer::Inner` already holds it — only the
aggregate `quorum_commit_index()` was being read. This uses the
per-authority value to ask peers that voted for the end of the range
first, keeping the existing shuffled order within each group.

Peers without an observed vote are ordered behind. The signal is
one-sided: entries only advance when this node observes a block from
that author, and serving additionally needs the certifying headers in
the peer's storage. One consequence to be aware of: each fetch round is
truncated to `MAX_NUM_TARGETS` (24) **after** this ordering, so on a
committee with more than 24 observed voters every round consists of
voters, and a peer whose headers do not reach us is not asked until they
do. Accepted because rounds retry forever over up to 24 peers that
provably solidified the range, and any header from such a peer carrying
a recent commit vote promotes it immediately; committees of 25 or fewer
are unaffected.

Gated by the node-local
`enable_commit_sync_peer_selection_by_commit_votes`, default on. It only
reorders candidates, so it cannot diverge consensus; with the flag off
the selection is exactly what it is today.

`test_fast_sync_voting_blocks_served_to_peer` asserts that B fetches
from A specifically, which depends on the peer order, so it sets the
flag off — the property it covers (voting headers are ser... (continued)

Coverage Stats

77 of 85 new or added lines in 4 files covered. (90.59%)

813 existing lines in 32 files now uncovered.

166143 of 240172 relevant lines covered (69.18%)

476736.64 hits per line