-
Notifications
You must be signed in to change notification settings - Fork 989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align seen_ttl
with attestation lifetime
#3627
Conversation
ethereum#3360 effectively extends the valid lifetime of an attestation/aggregate to 2 epochs - this means that an aggregate that was published at the beginning of a slot now is valid per the gossip rules up to 2 epochs later. Then net effect of the above change is that peers are allowed to republish old aggregates and attestations and libp2p will not stop the spread with the settings we recommend - instead the messages will have to be stopped with the "attestation cover rule" or similar, even though they have been observed already. Significant amounts of this kind of spam have been observed on the aggregate channel in particular leading to a 5x increase in aggregate traffic as some clients republish these old messages in spite of the "attestation cover rule" which should have stopped them - this simple change will provide an additional layer of protection against such bugs.
@@ -245,7 +245,7 @@ The following gossipsub [parameters](https://github.com/libp2p/specs/blob/master | |||
- `fanout_ttl` (ttl for fanout maps for topics we are not subscribed to but have published to, seconds): 60 | |||
- `mcache_len` (number of windows to retain full messages in cache for `IWANT` responses): 6 | |||
- `mcache_gossip` (number of windows to gossip about): 3 | |||
- `seen_ttl` (number of heartbeat intervals to retain message IDs): 550 | |||
- `seen_ttl` (expiry time for cache of seen message ids, seconds): SECONDS_PER_SLOT * SLOTS_PER_EPOCH * 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just set it at 1100 heartbeat intervals ? The previous value was estimated using the time for 1 epoch, so if we want to persist for 2 epochs, we can just double the current value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The gossipsub specification suggests this TTL should be expressed in time units, not heartbeats.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a good question though - we could reconsider more parameters here to align them with slot length - ie for a network like gnosis (which afair has 6s slots), they don't necessarily make a lot of sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, would be fine at setting it in terms of consensus params in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me seconds is more sensible to express this in anyway...
this allows us to drop these useless messages earlier in the pipeline ethereum/consensus-specs#3627
this allows us to drop these useless messages earlier in the pipeline ethereum/consensus-specs#3627
#3360 effectively extends the valid lifetime of an attestation/aggregate to 2 epochs - this means that an aggregate that was published at the beginning of a slot now is valid per the gossip rules up to 2 epochs later.
Then net effect of the above change is that peers are allowed to republish old aggregates and attestations and libp2p will not stop the spread with the settings we recommend - instead the messages will have to be stopped with the "attestation cover rule" or similar, even though they have been observed already.
Significant amounts of this kind of spam have been observed on the aggregate channel in particular leading to a 5x increase in aggregate traffic as some clients republish these old messages in spite of the "attestation cover rule" which should have stopped them - this simple change will provide an additional layer of protection against such bugs.