Alternative to antiflood tokens: Rate-limiting nullifiers

[sanity]

• https://rate-limiting-nullifier.github.io/rln-docs/what_is_rln.html

ChatGPT summary:

Rate-Limiting Nullifier (RLN) is a cryptographic tool that helps prevent spam and Sybil attacks in anonymous and decentralized environments. RLN is useful for applications where users are anonymous, but there is a need to limit the number of actions they can take (e.g., voting, sending messages) to prevent abuse.

RLN consists of three main components: user registration, user interaction, and user removal (slashing). Here's how RLN works:

1. User Registration:

   • Users generate a secret key and derive an "identity commitment" from it using a hash function.
   • Users register with the application by providing their identity commitment and a form of stake (e.g., cryptocurrency).
   • The application stores the identity commitments in a Merkle tree, and each user receives an index representing their position in the tree.

2. User Interaction:

   • To interact with the application, users must generate a zero-knowledge proof showing that their identity commitment is part of the membership Merkle tree.
   • RLN enforces a rule that limits the number of interactions per user within a specific time frame (e.g., one message per second).
   • To comply with this rule, users use Shamir's Secret Sharing to split their secret key into parts and reveal a new part with each interaction.
   • If users exceed the allowed number of interactions, their entire secret key can be reconstructed.

3. User Removal (Slashing):

   • If a user violates the anti-spam rule, anyone who knows the user's secret key can remove (slash) the user from the membership tree.
   • In cases where users have provided an economic stake, the stake can be forfeited and awarded to the first user who correctly reports the spammer by providing the reconstructed secret key as proof.

Overall, RLN provides a way to limit the actions of anonymous users in a decentralized environment, helping to prevent spam and abuse while maintaining user privacy.

[ple1n]

Local time actually isn't available to a contract. It should remain useful, as we will probably make a contract for each forum post. It sets an upper limit one user can post to a thread, dictated by current contract state.

The contract has

• Set of approved users.
• Set of accepted epochs (epoch doesn't necessarily imply time)

That means, a contract state (including its dependency states) contains

• Merkle root hash of the set of approved users
• Accepted epochs
  • If the contract is simple, a number then, indicating the maximum value of epoch.
  • A set of unpredictable numbers
    • Use drand signatures, if the contract wants to increase allowance gradually
    • Use signatures of a particular publickey, if we want to manually control the parameter
• Messages

The contract verifies that

• The proof is valid
• The epoch is accepted.
• The internal_nullifier is unique in the contract (which uniquely corresponds to a (user, epoch, counter) in RLN v2)

In case of DoS

• The attacker can use up all messages for all epochs, until the moderator updates merkle root, for example
• If his identity is revealed, any other people will notice and avoid including it in future merkle trees of approval.
• His identity isn't necessarily revealed because it might not reach enough shares, which is bad.

---

As only nullifiers are revealed, it seems that we need a proof scheme for for any epoch, counter, there doesn't exist a commit(secretkey, epoch, counter) that is a member of a set of banned users, to solve that problem.