Debounce UnknownBlockHashFromAttestation events

[dapplion]

Issue Addressed

debounce duplicated UnknownBlockHashFromAttestation for the same root peer tuple. A peer may forward us thousands of attestations, each triggering an individual event. Only one event is useful, the rest generating log noise and wasted cycles

PR

•  delete spammy log #5672

Noticed the issue first but there's another log that gets spammy if the peer is disconnecting here

lighthouse/beacon_node/network/src/sync/manager.rs

Line 694 in ee974db

debug!(self.log, "Ignoring unknown block request"; "block_root" => %block_root, "reason" => reason);

I think this fix is more complete as it also reduces CPU cycles downstream, as for every event it wants to find a lookup and insert the peer to it

Proposed Changes

Debounce UnknownBlockHashFromAttestation events

• Q: Should we revert  delete spammy log #5672 now that the log is not spammy?

[realbigsean]

Q: Should we revert #5672 now that the log is not spammy?

Yes! down for that

[AgeManning]

Looks good to me.

The reason we are using the (peer_id, root) tuple is because we want distinct peers to send us the same root to add them to current lookups right?

[dapplion]

The reason we are using the (peer_id, root) tuple is because we want distinct peers to send us the same root to add them to current lookups right?

Yes, if a second peer claims to know about a root of an existing lookup it will be added to the pool of "peers that claim to know the block". If the initial request of the lookup fails, that second peer may be used as retry. It's also important for scoring. If the block ends up being invalid we want to penalize everyone that claims to have imported it

[realbigsean]

@mergify queue

[mergify]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at a1271bc