Lev Soukhanov <ahref="mailto:0xdeadfae@gmail.com">0xdeadfae@gmail.com</a>
</li>
</ul><h1id="abstract">
Abstract
<aclass="anchor"href="#abstract">#</a>
</h1>
<p>The protocol specified in this document is an improvement of <ahref="/spec/32">32/RLN-V1</a>, being more general construct, that allows to set various limits for an epoch (it’s 1 message per epoch in <ahref="/spec/32">32/RLN-V1</a>) 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.</p>
<h1id="motivation">
Motivation
<aclass="anchor"href="#motivation">#</a>
</h1>
<p>The main goal of this RFC is to generalize <ahref="/spec/32">32/RLN-V1</a> and expand its applications.
There are two different subprotocols based on this protocol:</p>
<ul>
<li>RLN-Same - RLN with the same rate-limit for all users;</li>
<li>RLN-Diff - RLN that allows to set different rate-limits for different users.</li>
</ul>
<p>It is important to note that by using a large epoch limit value, users will be able to remain anonymous, because their <code>internal_nullifiers</code> will not be repeated until they exceed the limit.</p>
<h1id="flow">
Flow
<aclass="anchor"href="#flow">#</a>
</h1>
<p>As in <ahref="/spec/32">32/RLN-V1</a>, the general flow can be described by three steps:</p>
<ol>
<li>Registration</li>
<li>Signaling</li>
<li>Verification and slashing</li>
</ol>
<p>The two sub-protocols have different flows, and hence are defined separately.</p>
<h2id="important-note">
Important note
<aclass="anchor"href="#important-note">#</a>
</h2>
<p>All terms and parameters used remain the same as in <ahref="/spec/32">32/RLN-V1</a>, more details <ahref="/spec/32/#technical-overview">here</a></p>
<h2id="rln-same-flow">
RLN-Same flow
<aclass="anchor"href="#rln-same-flow">#</a>
</h2>
<h3id="registration">
Registration
<aclass="anchor"href="#registration">#</a>
</h3>
<p>The registration process in the RLN-Same subprotocol does not differ from <ahref="/spec/32">32/RLN-V1</a>.</p>
<h3id="signalling">
Signalling
<aclass="anchor"href="#signalling">#</a>
</h3>
<h4id="proof-generation">
Proof generation
<aclass="anchor"href="#proof-generation">#</a>
</h4>
<p>For proof generation, the user needs to submit the following fields to the circuit:</p>
<pretabindex="0"><code>{
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
}
</code></pre><h4id="calculating-output">
Calculating output
<aclass="anchor"href="#calculating-output">#</a>
</h4>
<p>The following fields are needed for proof output calculation:</p>
<pretabindex="0"><code>{
identity_secret_hash: bigint,
external_nullifier: bigint,
message_id: bigint,
x: bigint,
}
</code></pre><p>The output <code>[y, internal_nullifier]</code> is calculated in the following way:</p>
<p><strong>id_commitment</strong> in <ahref="/spec/32">32/RLN-V1</a> is equal to <code>poseidonHash(identity_secret)</code>.
The goal of RLN-Diff is to set different rate-limits for different users.
It follows that <strong>id_commitment</strong> must somehow depend on the <code>user_message_limit</code> parameter, where 0 <= <code>user_message_limit</code><= <code>message_limit</code>.
There are few ways to do that:</p>
<ol>
<li>Sending <code>identity_secret_hash</code> = <code>poseidonHash(identity_secret, userMessageLimit)</code> and zk proof that <code>user_message_limit</code> is valid (is in the right range).
This approach requires zkSNARK verification, which is an expensive operation on the blockchain.</li>
<li>Sending the same <code>identity_secret_hash</code> as in <ahref="/spec/32">32/RLN-V1</a> (<code>poseidonHash(identity_secret)</code>) and a user_message_limit publicly to a server or smart-contract where <code>rate_commitment</code> = <code>poseidonHash(identity_secret_hash, userMessageLimit)</code> 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.</li>
</ol>
<p>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.</p>
<h3id="signalling-1">
Signalling
<aclass="anchor"href="#signalling-1">#</a>
</h3>
<h4id="proof-generation-1">
Proof generation
<aclass="anchor"href="#proof-generation-1">#</a>
</h4>
<p>For proof generation, the user need to submit the following fields to the circuit:</p>
<p>The design of the <ahref="/spec/32">32/RLN-V1</a> 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.</p>
<p>The ZK Circuit is implemented using a <ahref="https://eprint.iacr.org/2016/260.pdf">Groth-16 ZK-SNARK</a>,
using the <ahref="https://docs.circom.io/">circomlib</a> library.
Both schemes contain compile-time constants/system parameters:</p>
<ul>
<li>DEPTH - depth of membership Merkle tree</li>
<li>LIMIT_BIT_SIZE - bit size of <code>limit</code> numbers, e.g. for the 16 - maximum <code>limit</code> number is 65535.</li>
</ul>
<p>The main difference of the protocol is that instead of a new polynomial (a new value <code>a_1</code>) 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 <code>limit</code>.
This is proven using range constraints.</p>
<h3id="rln-same-circuit">
RLN-Same circuit
<aclass="anchor"href="#rln-same-circuit">#</a>
</h3>
<h4id="circuit-parameters">
Circuit parameters
<aclass="anchor"href="#circuit-parameters">#</a>
</h4>
<p><strong>Public Inputs</strong></p>
<ul>
<li><code>x</code></li>
<li><code>external_nullifier</code></li>
<li><code>message_limit</code> - limit per epoch</li>
</ul>
<p><strong>Private Inputs</strong></p>
<ul>
<li><code>identity_secret_hash</code></li>
<li><code>path_elements</code></li>
<li><code>identity_path_index</code></li>
<li><code>message_id</code></li>
</ul>
<p><strong>Outputs</strong></p>
<ul>
<li><code>y</code></li>
<li><code>root</code></li>
<li><code>internal_nullifier</code></li>
</ul>
<h3id="rln-diff-circuit">
RLN-Diff circuit
<aclass="anchor"href="#rln-diff-circuit">#</a>
</h3>
<p>In the RLN-Diff scheme, instead of the public parameter <code>message_limit</code>, a parameter is used that is set for each user during registration (<code>user_message_limit</code>); the <code>message_id</code> value is compared to it in the same way as it is compared to <code>message_limit</code> in the case of RLN-Same.</p>
