diff --git a/print.html b/print.html index b3f1a11..f32faed 100644 --- a/print.html +++ b/print.html @@ -207,7 +207,7 @@ 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.

Slashing

-

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.

+

As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash them and take their stake.

Some important notes

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.

diff --git a/protocol_spec.html b/protocol_spec.html index 6ffe0af..276302d 100644 --- a/protocol_spec.html +++ b/protocol_spec.html @@ -159,7 +159,7 @@ 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.

Slashing

-

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.

+

As it's been said, if a user sends more than one message, everyone else will be able to recover his secret, slash them and take their stake.

Some important notes

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.

diff --git a/searchindex.js b/searchindex.js index b662134..e2295d5 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":74,"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":69,"breadcrumbs":4,"title":2},"5":{"body":136,"breadcrumbs":4,"title":2},"6":{"body":64,"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 zero-knowledge gadget that enables spam prevention for decentralized, anonymous environments. The anonymity property opens up the possibility for spam 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 an unlimited number of spam messages, but we don't have the 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 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 zero-knowledge gadget that enables spam prevention for decentralized, anonymous environments. The anonymity property opens up the possibility for spam 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 an unlimited number of spam messages, but we don't have the 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 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 zero-knowledge gadget that enables spam prevention for decentralized, anonymous environments. The anonymity property opens up the possibility for spam 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 an unlimited number of spam messages, but we don't have the 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 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 zero-knowledge gadget that enables spam prevention for decentralized, anonymous environments. The anonymity property opens up the possibility for spam 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 an unlimited number of spam messages, but we don't have the 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 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