ethereum
Increase gossipsub seen-ttl
The gossipsub IGNORE rule for attestations is:
attestation.data.slot + ATTESTATION_PROPAGATION_SLOT_RANGE >= current_slot >= attestation.data.slot
As ATTESTATION_PROPAGATION_SLOT_RANGE is 32, this allows for clients to propagate attestations up until the start of the 33rd slot after publishing.
Because we've set our duplicate cache to the start of the 32nd slot, I've noticed quite a few duplicates bouncing around the network. Increasing the cache time will prevent these extra duplicates being unnecessarily propagated.
Do you think attestations should be propagated at the 33rd slot? Or should the condition above be set to > rather than >=?
in nimbus, we stop propagating a bit earlier than 32 actually, to avoid the duplicate and to avoid being descored by lighthouse in particular - basically, there's a race where the attestation is valid when sending, then becomes invalid in-flight as time passes.
We do penalize peers that send attestations that are over this condition (32 slots). We could reduce it with a leniency period where we don't penalize peers in the reduced time to avoid penalizing non-updated nodes.
With this aside, I've seen duplicates being sent around in the 32nd slot, because they are valid. Essentially, someone sends an attestation around on slot 0, say, then after 32 slots, everyone's duplicate cache forgets about it, and for some reason it re-appears and everyone then re-propagates it (as it still passes these validation conditions) as they don't recognise it as a duplicate. Increasing the duplicate cache will prevent these duplicates flying around, but wont prevent us from downscoring peers that still send attestations outside the valid range (even though there is an in-flight race-condition).
We do penalize peers that send attestations that are over this condition (32 slots). We could reduce it with a leniency period where we don't penalize peers in the reduced time to avoid penalizing non-updated nodes.
For this, is it possible for lighthouse to not penalise peers propagating these attestations ? The spec does mention it as IGNORE rather than REJECT. Other than that I am fine with pushing up the seen-ttl to account for attestation validity time.
