rfc
rfc copied to clipboard
vacp2p
17/WAKU2-RLNRELAY: Spamming through multiple registrations
Problem
In RLN using Semaphore and SSS, the number of signals per registered user per epoch is limited and guaranteed to be one (otherwise the user gets slashed) however, the system is still subject to spamming since each user can register multiple times and use her cumulative quotas for signaling and spamming the system (without being caught). For example, the spammer can create N accounts and then signals N times per epoch while none of her accounts is slashed (and her deposit remains intact). The deposit required for accounts may disincentivize multiple registrations but does not eliminate the spamming problem entirely.
cc @barryWhiteHat @oskarth
This is correct. What we do is enforce a cost/limit on account creation this can be
- solve captcha
- burn some eth / crypto
- make a ZKP about social connections
This is correct. What we do is enforce a cost/limit on account creation this can be
- solve captcha
- burn some eth / crypto
- make a ZKP about social connections
Thanks, @barryWhiteHat! liked the ZKP of social connections, has it been implemented? got curious to read more about it, it sounds like anonymous credentials or group/ring-based signatures Also, is there any comparison of these methods available, e.g., their effectiveness, hardness, computational complexity, etc? For instance, solving captcha seems like the least costly preventative method (and maybe the weakest), and burning eth the most costly one (and perhaps the strongest)
Burning seems to fit quite well with the overall design, could this easily be incorporated into the existing registration contract? That way it comes as a "whole package" with stronger spam guarantees.
The other two might work, but seems less elegant to me as they are either complex or require out of band operations.
I.e. you deposit 100 units, 50 is burned and 50 goes towards the private key that is slashable. Something like that perhaps? "Half now, half later". This proportion can be tunable I suppose, but for simplicity it seems reasonable. A bit like car losing half its value when you start using it...
@oskarth totally agree that burning is a good fit and will do the job with minimum complexity!
We are not going to cover it any time soon but we'll consider this for later. Unassigned myself for now, will get back to it later.
