rfc-index/vac/58/rln-v2.md

slug	title	name	status	editor	contributors
58	58/RLN-V2	Rate Limit Nullifier V2	raw	Rasul Ibragimov <curryrasul@gmail.com>	Lev Soukhanov <0xdeadfae@gmail.com>

Abstract

The protocol specified in this document is an improvement of 32/RLN-V1, being more general construct, that allows to set various limits for an epoch (it's 1 message per epoch in 32/RLN-V1) while remaining almost as simple as it predecessor. Moreover, it allows to set different rate-limits for different RLN app users based on some public data, e.g. stake or reputation.

Motivation

The main goal of this RFC is to generalize 32/RLN-V1 and expand its applications. There are two different subprotocols based on this protocol:

• RLN-Same - RLN with the same rate-limit for all users;
• RLN-Diff - RLN that allows to set different rate-limits for different users.

It is important to note that by using a large epoch limit value, users will be able to remain anonymous, because their internal_nullifiers will not be repeated until they exceed the limit.

Flow

As in 32/RLN-V1, the general flow can be described by three steps:

1. Registration
2. Signaling
3. Verification and slashing

The two sub-protocols have different flows, and hence are defined separately.

Important note

All terms and parameters used remain the same as in 32/RLN-V1, more details here

RLN-Same flow

Registration

The registration process in the RLN-Same subprotocol does not differ from 32/RLN-V1.

Signalling

Proof generation

For proof generation, the user needs to submit the following fields to the circuit:

{
    identity_secret: identity_secret_hash,
    path_elements: Merkle_proof.path_elements,
    identity_path_index: Merkle_proof.indices,
    x: signal_hash,
    message_id: message_id,
    external_nullifier: external_nullifier,
    message_limit: message_limit
}

Calculating output

The following fields are needed for proof output calculation:

{
    identity_secret_hash: bigint, 
    external_nullifier: bigint,
    message_id: bigint,
    x: bigint, 
}

The output [y, internal_nullifier] is calculated in the following way:

a_0 = identity_secret_hash
a_1 = poseidonHash([a0, external_nullifier, message_id])

y = a_0 + x * a_1

internal_nullifier = poseidonHash([a_1])

RLN-Diff flow

Registration

id_commitment in 32/RLN-V1 is equal to poseidonHash(identity_secret). The goal of RLN-Diff is to set different rate-limits for different users. It follows that id_commitment must somehow depend on the user_message_limit parameter, where 0 <= user_message_limit <= message_limit. There are few ways to do that:

1. Sending identity_secret_hash = poseidonHash(identity_secret, userMessageLimit) and zk proof that user_message_limit is valid (is in the right range). This approach requires zkSNARK verification, which is an expensive operation on the blockchain.
2. Sending the same identity_secret_hash as in 32/RLN-V1 (poseidonHash(identity_secret)) and a user_message_limit publicly to a server or smart-contract where rate_commitment = poseidonHash(identity_secret_hash, userMessageLimit) is calculated. The leaves in the membership Merkle tree would be the rate_commitments of the users. This approach requires additional hashing in the Circuit, but it eliminates the need for zk proof verification for the registration.

Both methods are correct, and the choice of the method is left to the implementer. It is recommended to use second method for the reasons already described. The following flow description will also be based on the second method.

Signalling

Proof generation

For proof generation, the user need to submit the following fields to the circuit:

{
    identity_secret: identity_secret_hash,
    path_elements: Merkle_proof.path_elements,
    identity_path_index: Merkle_proof.indices,
    x: signal_hash,
    message_id: message_id,
    external_nullifier: external_nullifier,
    user_message_limit: message_limit
}

Calculating output

The Output is calculated in the same way as the RLN-Same sub-protocol.

Verification and slashing

Verification and slashing in both subprotocols remain the same as in 32/RLN-V1. The only difference that may arise is the message_limit check in RLN-Same, since it is now a public input of the Circuit.

ZK Circuits specification

The design of the 32/RLN-V1 circuits is different from the circuits of this protocol. RLN-v2 requires additional algebraic constraints. The membership proof and Shamir's Secret Sharing constraints remain unchanged.

The ZK Circuit is implemented using a Groth-16 ZK-SNARK, using the circomlib library. Both schemes contain compile-time constants/system parameters:

• DEPTH - depth of membership Merkle tree
• LIMIT_BIT_SIZE - bit size of limit numbers, e.g. for the 16 - maximum limit number is 65535.

The main difference of the protocol is that instead of a new polynomial (a new value a_1) for a new epoch, a new polynomial is generated for each message. The user assigns an identifier to each message; the main requirement is that this identifier be in the range from 1 to limit. This is proven using range constraints.

RLN-Same circuit

Circuit parameters

Public Inputs

• x
• external_nullifier
• message_limit - limit per epoch

Private Inputs

• identity_secret_hash
• path_elements
• identity_path_index
• message_id

Outputs

• y
• root
• internal_nullifier

RLN-Diff circuit

In the RLN-Diff scheme, instead of the public parameter message_limit, a parameter is used that is set for each user during registration (user_message_limit); the message_id value is compared to it in the same way as it is compared to message_limit in the case of RLN-Same.

Circuit parameters

Public Inputs

• x
• external_nullifier

Private Inputs

• identity_secret_hash
• path_elements
• identity_path_index
• message_id
• user_message_limit

Outputs

• y
• root
• internal_nullifier

Appendix A: Security considerations

Although there are changes in the circuits, this spec inherits all the security considerations of 32/RLN-V1.

Copyright

Copyright and related rights waived via CC0.

References

• 1
• 2
• 3