Skip to content
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

RLN: preventing replay attacks over multiple shards #110

Open
jm-clius opened this issue Oct 24, 2024 · 1 comment
Open

RLN: preventing replay attacks over multiple shards #110

jm-clius opened this issue Oct 24, 2024 · 1 comment

Comments

@jm-clius
Copy link
Contributor

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:

  1. 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.
  2. 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.

@alrevuelta
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants