You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since messages containing RLN proofs are not tied to a specific shard (and therefore validated against published shard), it will be possible to replay the same message + proof on multiple shards.
This may have the following impact:
Validators monitoring only one of the shards on which the (same) message is relayed can potentially be DoSed if an attacker copies enough valid messages from other shards. These messages will appear as non-duplicates to such validators and they will relay them to their peers. This is somewhat mitigated by the fact that each message can only be copied once to every shard, would have had to originate in the past 20 seconds to be valid and would still be deduplicated by validators monitoring more than one shard on which the message occurs.
Validators monitoring more than one of the shards on which the message is relayed will deduplicate (i.e. drop) the second copy of the message it sees, even if this was on the original intended shard. This can be exploited as a way to censor messages on a specific shard by "frontrunning" them at validators
Possible solution
Tie a message + proof to a specific shard by encoding the shard in some way into the RLN signal. Each validator will then confirm that the relayed shard matches the encoded shard as an additional validating step.
The text was updated successfully, but these errors were encountered:
Thanks!. Adding another possible solution. Since the mapping contenttopic<->shard is deterministic based on consistent hashing and every message contains a contenttopic, then gossipsub validator could validate if the message is being replayed. In this case won't need to modify the RLN signal.
This is a spin-off issue from #109.
Since messages containing RLN proofs are not tied to a specific shard (and therefore validated against published shard), it will be possible to replay the same message + proof on multiple shards.
This may have the following impact:
Possible solution
Tie a message + proof to a specific shard by encoding the shard in some way into the RLN signal. Each validator will then confirm that the relayed shard matches the encoded shard as an additional validating step.
The text was updated successfully, but these errors were encountered: