diff --git a/print.html b/print.html
index e3c121a..82c6d50 100644
--- a/print.html
+++ b/print.html
@@ -193,7 +193,7 @@
Well, let's discuss them.
-The first part of RLN is registration. There is nothing special in RLN registration; it's almost the same process as in other protocols/apps with anonymous environments: we need to create Merkle Tree, and every participant must submit the commitment and place it in the Merkle Tree, and after that to interact with the app every participant will create zkProof's, that he is a member of the tree (we use Incremental Merkle Tree, as it more GAS-effective).
+The first part of RLN is registration. There is nothing special in RLN registration; it's almost the same process as in other protocols/apps with anonymous environments: we need to create a Merkle Tree, and every participant must submit a commitment and place it in the Merkle Tree, and after that to interact with the app every participant will create a zkProof's, that they are a member of the tree (we use an Incremental Merkle Tree, as it more GAS efficient).
So, each member generates a secret key, denoted by a_0. Identity commitment q is the hash (Poseidon) of the secret key: q = Poseidon(a_0).
RLN wouldn't work if there were no punishment for spam; that's why to become a member, a user has to register and provide something at stake. So, whoever has our a_0 can "slash" us.
The slight difference is that we must enable a secret sharing scheme (to split the commitment into parts). We need to come up with a polynomial. For simplicity we use linear polynomial (e.g. f(x) = kx + b). Therefore, with two points, we can reconstruct the polynomial and recover the secret.
diff --git a/protocol_spec.html b/protocol_spec.html
index 6cdbd89..6ffe0af 100644
--- a/protocol_spec.html
+++ b/protocol_spec.html
@@ -145,7 +145,7 @@
Well, let's discuss them.
-The first part of RLN is registration. There is nothing special in RLN registration; it's almost the same process as in other protocols/apps with anonymous environments: we need to create Merkle Tree, and every participant must submit the commitment and place it in the Merkle Tree, and after that to interact with the app every participant will create zkProof's, that he is a member of the tree (we use Incremental Merkle Tree, as it more GAS-effective).
+The first part of RLN is registration. There is nothing special in RLN registration; it's almost the same process as in other protocols/apps with anonymous environments: we need to create a Merkle Tree, and every participant must submit a commitment and place it in the Merkle Tree, and after that to interact with the app every participant will create a zkProof's, that they are a member of the tree (we use an Incremental Merkle Tree, as it more GAS efficient).
So, each member generates a secret key, denoted by a_0. Identity commitment q is the hash (Poseidon) of the secret key: q = Poseidon(a_0).
RLN wouldn't work if there were no punishment for spam; that's why to become a member, a user has to register and provide something at stake. So, whoever has our a_0 can "slash" us.
The slight difference is that we must enable a secret sharing scheme (to split the commitment into parts). We need to come up with a polynomial. For simplicity we use linear polynomial (e.g. f(x) = kx + b). Therefore, with two points, we can reconstruct the polynomial and recover the secret.
diff --git a/searchindex.js b/searchindex.js
index 8d31363..71e91f5 100644
--- a/searchindex.js
+++ b/searchindex.js
@@ -1 +1 @@
-Object.assign(window.search, {"doc_urls":["rln.html#rln","overview.html#overview","what_is_rln.html#what-is-rate-limiting-nullifier","what_is_rln.html#how-it-works","what_is_rln.html#user-registration","what_is_rln.html#user-interaction","what_is_rln.html#user-removal-slashing","under_the_hood.html#under-the-hood","protocol_spec.html#technical-side-of-rln","protocol_spec.html#user-registration","protocol_spec.html#signalling","protocol_spec.html#slashing","protocol_spec.html#some-important-notes","protocol_spec.html#diagram","circuits.html#circuits","circuits.html#merkle-tree-circuit","uses.html#uses","uses.html#zk-chat","how_to_use.html#how-to-use","theory.html#theory","sss.html#shamirs-secret-sharing-scheme","appendix.html#appendix","terminology.html#terminology","references.html#references"],"index":{"documentStore":{"docInfo":{"0":{"body":35,"breadcrumbs":2,"title":1},"1":{"body":19,"breadcrumbs":2,"title":1},"10":{"body":64,"breadcrumbs":6,"title":1},"11":{"body":12,"breadcrumbs":6,"title":1},"12":{"body":159,"breadcrumbs":7,"title":2},"13":{"body":107,"breadcrumbs":6,"title":1},"14":{"body":26,"breadcrumbs":5,"title":1},"15":{"body":156,"breadcrumbs":7,"title":3},"16":{"body":0,"breadcrumbs":3,"title":1},"17":{"body":2,"breadcrumbs":4,"title":2},"18":{"body":14,"breadcrumbs":2,"title":1},"19":{"body":12,"breadcrumbs":2,"title":1},"2":{"body":83,"breadcrumbs":5,"title":3},"20":{"body":239,"breadcrumbs":8,"title":4},"21":{"body":9,"breadcrumbs":2,"title":1},"22":{"body":203,"breadcrumbs":3,"title":1},"23":{"body":26,"breadcrumbs":4,"title":1},"3":{"body":43,"breadcrumbs":3,"title":1},"4":{"body":65,"breadcrumbs":4,"title":2},"5":{"body":134,"breadcrumbs":4,"title":2},"6":{"body":63,"breadcrumbs":5,"title":3},"7":{"body":15,"breadcrumbs":5,"title":2},"8":{"body":37,"breadcrumbs":8,"title":3},"9":{"body":124,"breadcrumbs":7,"title":2}},"docs":{"0":{"body":"RLN (Rate-Limiting Nullifier) is a zk-gadget/protocol that enables spam prevention mechanism for anonymous environments. RLN is part of ( PSE ) Privacy & Scaling Explorations , a multidisciplinary team supported by the Ethereum Foundation. PSE explores new use cases for zero-knowledge proofs and other cryptographic primitives. alt text","breadcrumbs":"RLN » RLN","id":"0","title":"RLN"},"1":{"body":"This section is a starting point for understanding the concepts of RLN . Here we'll discuss: Basic explanation of the RLN protocol RLN protocol under the hood RLN uses","breadcrumbs":"Overview » Overview","id":"1","title":"Overview"},"10":{"body":"Now that the user is registered, he wants to interact with the system. Imagine that the system is an anonymous chat and the interaction is the sending of messages. So, to send a message user have to come up with share - the point (x, y) on her polynomial. We denote: x = Poseidon(message), and y = A(x). Thus, if the same epoch user sends more than one message, their polynomial and, therefore, their secret (a_0) can be recovered. Of course, we somehow must prove that our share = (x, y) is valid (that this is really a point on our polynomial = A(x)), as well as we must prove other things are valid too, that's why we use zkSNARK. An explanation of the zk-circuits can be found in the next topic.","breadcrumbs":"Overview » Under the hood » Protocol spec » Signalling","id":"10","title":"Signalling"},"11":{"body":"As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash him and take his stake.","breadcrumbs":"Overview » Under the hood » Protocol spec » Slashing","id":"11","title":"Slashing"},"12":{"body":"There are also nullifier and rln_identifier, which can be found in the RLN protocol/circuits. So, rln_identifier is just a random value that's unique per RLN app. It's used for additional cross-application security - to protect the user secrets from being compromised if they use the same credentials across different RLN apps. If rln_identifier is not present, the user uses the same credentials and sends a message in two different RLN apps using the same epoch, then their secret key can be revealed. Adding the rln_identifier field, we obscure the nullifier, so this kind of attack cannot happen. The only kind of attack that is possible is if we have an entity with a global view of all messages, and they try to brute-force different combinations of x and y shares for different nullifiers. Now, imagine there are a lot of users sending messages, and after each received message, we need to check if any member can be slashed. To do this, we can use all combinations of received shares and try to recover the polynomial, but this is a naive and non-optimal approach. Suppose we have a mechanism that will tell us about the connection between a person and their messages while not revealing their identity. In that case, we can solve this without brute-forcing all possibilities by using a public nullifier (nullifier = Poseidon(a_1, rln_identifier)), so if a user sends more than one message, it will be immediately visible to everyone. Also, in our example (and zk-chat implementation), we use linear polynomial, but SSS allows us to use various degree polynomials; therefore we can implement a protocol, where more than one signal (message) can be sent in per epoch. To learn more, check out the specification ; there are also circuits implemented for various degree polynomials too.","breadcrumbs":"Overview » Under the hood » Protocol spec » Some important notes","id":"12","title":"Some important notes"},"13":{"body":"flowchart TB subgraph Generate Secret Key random0(Random 32 bytes) --> a_0(Secret Key) random1(Random 32 bytes) --> a_0 end subgraph RLN subgraph Identity Commitment a_0 --> h0(Poseidon Hash) h0 --> q(Identity Commitment) end subgraph Calculate Internal Nullifier a_0 --> h1(Poseidon Hash) epoch(Epoch) --> h1 h1 --> a_1 rln_identifier(RLN Identifier) --> h2(Poseidon Hash) a_1 --> h2 h2 --> nullifier(RLN Internal Nullifier) end subgraph Merkle Tree q --> merkle_tree_inclusion_proof(Merkle Tree Inclusion Proof) merkle_tree_inclusion_proof --> root(ZKP of Merkle Tree Root) end subgraph Shamirs Secret Scheme a_0 --> plus(+) a_1 --> multiply(*) x(Hashed Messaage) --> multiply multiply --> plus plus --> share_y end nullifier --> proof(ZKP) root --> proof share_y --> proof end","breadcrumbs":"Overview » Under the hood » Protocol spec » Diagram","id":"13","title":"Diagram"},"14":{"body":"zkSNARK is used in the RLN core. Therefore, we need to represent the protocol in R1CS (as we use Groth16). Circom DSL was chosen for this. This section provides an explanation of RLN circuits. RLN circuits implement the logic described in previous topic .","breadcrumbs":"Overview » Under the hood » Circuits » Circuits","id":"14","title":"Circuits"},"15":{"body":"One of the key component of RLN is Incremental Merkle Tree . Let's look at the implementation . At the beginning of the file we denote that we use second version of Circom and include two helper zk-gadgets : pragma circom 2.0.0; include \"../node_modules/circomlib/circuits/poseidon.circom\";\ninclude \"../node_modules/circomlib/circuits/mux1.circom\"; Poseidon gadget is just the implementation of Poseidon hash function; mux1 gadget will be described later. Next, we can see two implemented gadgets: template PoseidonHashT3() { var nInputs = 2; signal input inputs[nInputs]; signal output out; component hasher = Poseidon(nInputs); for (var i = 0; i < nInputs; i ++) { hasher.inputs[i] <== inputs[i]; } out <== hasher.out;\n} template HashLeftRight() { signal input left; signal input right; signal output hash; component hasher = PoseidonHashT3(); left ==> hasher.inputs[0]; right ==> hasher.inputs[1]; hash <== hasher.out;\n} These are helper gadgets to make the code more clean. Poseidon gadget is implemented with the ability to take a different number of arguments. We use PoseidonHashT3() to initialize it like a function with two arguments. And HashLeftRight use PoseidonHashT3 in more \"readable\" way: it takes two inputs left and right and outputs the result of calculation. Next comes the core of Merkle Tree gadget: template MerkleTreeInclusionProof(n_levels) { signal input leaf; signal input path_index[n_levels]; signal input path_elements[n_levels][1]; signal output root; component hashers[n_levels]; component mux[n_levels]; signal levelHashes[n_levels + 1]; levelHashes[0] <== leaf; ... root <== levelHashes[n_levels];\n} Here we have three inputs: leaf, path_index and path_elements","breadcrumbs":"Overview » Under the hood » Circuits » Merkle Tree circuit","id":"15","title":"Merkle Tree circuit"},"16":{"body":"","breadcrumbs":"Overview » Uses » Uses","id":"16","title":"Uses"},"17":{"body":"https://github.com/njofce/zk-chat","breadcrumbs":"Overview » Uses » zk-chat","id":"17","title":"zk-chat"},"18":{"body":"This section provides information on how to use RLN in your project: JavaScript RLN (for rln-js ) Rust RLN (for zerokit-rln )","breadcrumbs":"How to use » How to use","id":"18","title":"How to use"},"19":{"body":"This section provides theoretical information that underpins RLN . Here we'll discuss: Shamir's Secret Sharing","breadcrumbs":"Theory » Theory","id":"19","title":"Theory"},"2":{"body":"This topic is a part of complete overview by Blagoj . RLN is a construct based on zero-knowledge proofs that enables spam prevention mechanism for decentralized, anonymous environments. In anonymous environments, the identity of the entities is unknown. The anonymity property opens up the possibility for spam attack and sybil attack vectors for certain applications, which could seriously degrade the user experience and the overall functioning of the application. For example, imagine a chat application, where users are anonymous. Now, everyone can write unlimited number of spam messages, while we don't have ability to kick this member, because the spammer is anonymous. RLN helps us identify and \"kick\" the spammer. Moreover RLN can be useful not only to prevent a spam attacks, but in general, to limit users (in anonymous environments) in the number of actions (f.e. to vote or to make a bid).","breadcrumbs":"Overview » What is RLN » What is Rate-Limiting Nullifier?","id":"2","title":"What is Rate-Limiting Nullifier?"},"20":{"body":"Shamirs Secret Sharing allows to split the secret to n parts and restore it upon presentation any m parts (m <= n) Sharmir's Secret Sharing wikipedia is a good reference to understand the concept. Reconstruction 1: https://github.com/akinovak/semaphore-lib/blob/5b9bb3210192c8e508eced7ef6579fd56e635ed0/src/rln.ts#L31 retrievePrivateKey(x1: bigint, x2:bigint, y1:bigint, y2:bigint): Buffer | ArrayBuffer { const slope = Fq.div(Fq.sub(y2, y1), Fq.sub(x2, x1)) const privateKey = Fq.sub(y1, Fq.mul(slope, x1)); return bigintConversion.bigintToBuf(Fq.normalize(privateKey)); } Reconstruction 2: https://github.com/akinovak/semaphore-lib/blob/rln_signature_changes/test/index.ts#L250 async function testRlnSlashingSimulation() { RLN.setHasher('poseidon'); const identity = RLN.genIdentity(); const privateKey = identity.keypair.privKey; const leafIndex = 3; const idCommitments: Array = []; for (let i=0; i hasher.inputs[0]; right ==> hasher.inputs[1]; hash <== hasher.out;\n} These are helper gadgets to make the code more clean. Poseidon gadget is implemented with the ability to take a different number of arguments. We use PoseidonHashT3() to initialize it like a function with two arguments. And HashLeftRight use PoseidonHashT3 in more \"readable\" way: it takes two inputs left and right and outputs the result of calculation. Next comes the core of Merkle Tree gadget: template MerkleTreeInclusionProof(n_levels) { signal input leaf; signal input path_index[n_levels]; signal input path_elements[n_levels][1]; signal output root; component hashers[n_levels]; component mux[n_levels]; signal levelHashes[n_levels + 1]; levelHashes[0] <== leaf; ... root <== levelHashes[n_levels];\n} Here we have three inputs: leaf, path_index and path_elements","breadcrumbs":"Overview » Under the hood » Circuits » Merkle Tree circuit","id":"15","title":"Merkle Tree circuit"},"16":{"body":"","breadcrumbs":"Overview » Uses » Uses","id":"16","title":"Uses"},"17":{"body":"https://github.com/njofce/zk-chat","breadcrumbs":"Overview » Uses » zk-chat","id":"17","title":"zk-chat"},"18":{"body":"This section provides information on how to use RLN in your project: JavaScript RLN (for rln-js ) Rust RLN (for zerokit-rln )","breadcrumbs":"How to use » How to use","id":"18","title":"How to use"},"19":{"body":"This section provides theoretical information that underpins RLN . Here we'll discuss: Shamir's Secret Sharing","breadcrumbs":"Theory » Theory","id":"19","title":"Theory"},"2":{"body":"This topic is a part of complete overview by Blagoj . RLN is a construct based on zero-knowledge proofs that enables spam prevention mechanism for decentralized, anonymous environments. In anonymous environments, the identity of the entities is unknown. The anonymity property opens up the possibility for spam attack and sybil attack vectors for certain applications, which could seriously degrade the user experience and the overall functioning of the application. For example, imagine a chat application, where users are anonymous. Now, everyone can write unlimited number of spam messages, while we don't have ability to kick this member, because the spammer is anonymous. RLN helps us identify and \"kick\" the spammer. Moreover RLN can be useful not only to prevent a spam attacks, but in general, to limit users (in anonymous environments) in the number of actions (f.e. to vote or to make a bid).","breadcrumbs":"Overview » What is RLN » What is Rate-Limiting Nullifier?","id":"2","title":"What is Rate-Limiting Nullifier?"},"20":{"body":"Shamirs Secret Sharing allows to split the secret to n parts and restore it upon presentation any m parts (m <= n) Sharmir's Secret Sharing wikipedia is a good reference to understand the concept. Reconstruction 1: https://github.com/akinovak/semaphore-lib/blob/5b9bb3210192c8e508eced7ef6579fd56e635ed0/src/rln.ts#L31 retrievePrivateKey(x1: bigint, x2:bigint, y1:bigint, y2:bigint): Buffer | ArrayBuffer { const slope = Fq.div(Fq.sub(y2, y1), Fq.sub(x2, x1)) const privateKey = Fq.sub(y1, Fq.mul(slope, x1)); return bigintConversion.bigintToBuf(Fq.normalize(privateKey)); } Reconstruction 2: https://github.com/akinovak/semaphore-lib/blob/rln_signature_changes/test/index.ts#L250 async function testRlnSlashingSimulation() { RLN.setHasher('poseidon'); const identity = RLN.genIdentity(); const privateKey = identity.keypair.privKey; const leafIndex = 3; const idCommitments: Array = []; for (let i=0; i hasher.inputs[0]; right ==> hasher.inputs[1]; hash <== hasher.out;\n} These are helper gadgets to make the code more clean. Poseidon gadget is implemented with the ability to take a different number of arguments. We use PoseidonHashT3() to initialize it like a function with two arguments. And HashLeftRight use PoseidonHashT3 in more \"readable\" way: it takes two inputs left and right and outputs the result of calculation. Next comes the core of Merkle Tree gadget: template MerkleTreeInclusionProof(n_levels) { signal input leaf; signal input path_index[n_levels]; signal input path_elements[n_levels][1]; signal output root; component hashers[n_levels]; component mux[n_levels]; signal levelHashes[n_levels + 1]; levelHashes[0] <== leaf; ... root <== levelHashes[n_levels];\n} Here we have three inputs: leaf, path_index and path_elements","breadcrumbs":"Overview » Under the hood » Circuits » Merkle Tree circuit","id":"15","title":"Merkle Tree circuit"},"16":{"body":"","breadcrumbs":"Overview » Uses » Uses","id":"16","title":"Uses"},"17":{"body":"https://github.com/njofce/zk-chat","breadcrumbs":"Overview » Uses » zk-chat","id":"17","title":"zk-chat"},"18":{"body":"This section provides information on how to use RLN in your project: JavaScript RLN (for rln-js ) Rust RLN (for zerokit-rln )","breadcrumbs":"How to use » How to use","id":"18","title":"How to use"},"19":{"body":"This section provides theoretical information that underpins RLN . Here we'll discuss: Shamir's Secret Sharing","breadcrumbs":"Theory » Theory","id":"19","title":"Theory"},"2":{"body":"This topic is a part of complete overview by Blagoj . RLN is a construct based on zero-knowledge proofs that enables spam prevention mechanism for decentralized, anonymous environments. In anonymous environments, the identity of the entities is unknown. The anonymity property opens up the possibility for spam attack and sybil attack vectors for certain applications, which could seriously degrade the user experience and the overall functioning of the application. For example, imagine a chat application, where users are anonymous. Now, everyone can write unlimited number of spam messages, while we don't have ability to kick this member, because the spammer is anonymous. RLN helps us identify and \"kick\" the spammer. Moreover RLN can be useful not only to prevent a spam attacks, but in general, to limit users (in anonymous environments) in the number of actions (f.e. to vote or to make a bid).","breadcrumbs":"Overview » What is RLN » What is Rate-Limiting Nullifier?","id":"2","title":"What is Rate-Limiting Nullifier?"},"20":{"body":"Shamirs Secret Sharing allows to split the secret to n parts and restore it upon presentation any m parts (m <= n) Sharmir's Secret Sharing wikipedia is a good reference to understand the concept. Reconstruction 1: https://github.com/akinovak/semaphore-lib/blob/5b9bb3210192c8e508eced7ef6579fd56e635ed0/src/rln.ts#L31 retrievePrivateKey(x1: bigint, x2:bigint, y1:bigint, y2:bigint): Buffer | ArrayBuffer { const slope = Fq.div(Fq.sub(y2, y1), Fq.sub(x2, x1)) const privateKey = Fq.sub(y1, Fq.mul(slope, x1)); return bigintConversion.bigintToBuf(Fq.normalize(privateKey)); } Reconstruction 2: https://github.com/akinovak/semaphore-lib/blob/rln_signature_changes/test/index.ts#L250 async function testRlnSlashingSimulation() { RLN.setHasher('poseidon'); const identity = RLN.genIdentity(); const privateKey = identity.keypair.privKey; const leafIndex = 3; const idCommitments: Array = []; for (let i=0; i hasher.inputs[0]; right ==> hasher.inputs[1]; hash <== hasher.out;\n} These are helper gadgets to make the code more clean. Poseidon gadget is implemented with the ability to take a different number of arguments. We use PoseidonHashT3() to initialize it like a function with two arguments. And HashLeftRight use PoseidonHashT3 in more \"readable\" way: it takes two inputs left and right and outputs the result of calculation. Next comes the core of Merkle Tree gadget: template MerkleTreeInclusionProof(n_levels) { signal input leaf; signal input path_index[n_levels]; signal input path_elements[n_levels][1]; signal output root; component hashers[n_levels]; component mux[n_levels]; signal levelHashes[n_levels + 1]; levelHashes[0] <== leaf; ... root <== levelHashes[n_levels];\n} Here we have three inputs: leaf, path_index and path_elements","breadcrumbs":"Overview » Under the hood » Circuits » Merkle Tree circuit","id":"15","title":"Merkle Tree circuit"},"16":{"body":"","breadcrumbs":"Overview » Uses » Uses","id":"16","title":"Uses"},"17":{"body":"https://github.com/njofce/zk-chat","breadcrumbs":"Overview » Uses » zk-chat","id":"17","title":"zk-chat"},"18":{"body":"This section provides information on how to use RLN in your project: JavaScript RLN (for rln-js ) Rust RLN (for zerokit-rln )","breadcrumbs":"How to use » How to use","id":"18","title":"How to use"},"19":{"body":"This section provides theoretical information that underpins RLN . Here we'll discuss: Shamir's Secret Sharing","breadcrumbs":"Theory » Theory","id":"19","title":"Theory"},"2":{"body":"This topic is a part of complete overview by Blagoj . RLN is a construct based on zero-knowledge proofs that enables spam prevention mechanism for decentralized, anonymous environments. In anonymous environments, the identity of the entities is unknown. The anonymity property opens up the possibility for spam attack and sybil attack vectors for certain applications, which could seriously degrade the user experience and the overall functioning of the application. For example, imagine a chat application, where users are anonymous. Now, everyone can write unlimited number of spam messages, while we don't have ability to kick this member, because the spammer is anonymous. RLN helps us identify and \"kick\" the spammer. Moreover RLN can be useful not only to prevent a spam attacks, but in general, to limit users (in anonymous environments) in the number of actions (f.e. to vote or to make a bid).","breadcrumbs":"Overview » What is RLN » What is Rate-Limiting Nullifier?","id":"2","title":"What is Rate-Limiting Nullifier?"},"20":{"body":"Shamirs Secret Sharing allows to split the secret to n parts and restore it upon presentation any m parts (m <= n) Sharmir's Secret Sharing wikipedia is a good reference to understand the concept. Reconstruction 1: https://github.com/akinovak/semaphore-lib/blob/5b9bb3210192c8e508eced7ef6579fd56e635ed0/src/rln.ts#L31 retrievePrivateKey(x1: bigint, x2:bigint, y1:bigint, y2:bigint): Buffer | ArrayBuffer { const slope = Fq.div(Fq.sub(y2, y1), Fq.sub(x2, x1)) const privateKey = Fq.sub(y1, Fq.mul(slope, x1)); return bigintConversion.bigintToBuf(Fq.normalize(privateKey)); } Reconstruction 2: https://github.com/akinovak/semaphore-lib/blob/rln_signature_changes/test/index.ts#L250 async function testRlnSlashingSimulation() { RLN.setHasher('poseidon'); const identity = RLN.genIdentity(); const privateKey = identity.keypair.privKey; const leafIndex = 3; const idCommitments: Array = []; for (let i=0; i