From 96d9abd09569acae0d1bb42763e54ae59ddf39d6 Mon Sep 17 00:00:00 2001 From: curryrasul Date: Sun, 2 Oct 2022 14:57:49 +0000 Subject: [PATCH] deploy: 7c54ae22d616ed22b89c10a7cf246de62a032719 --- 404.html | 2 +- appendix.html | 2 +- circuits.html | 12 +++---- how_to_use.html | 2 +- index.html | 5 +-- overview.html | 2 +- print.html | 52 ++++++++++++++++++++++-------- diagram.html => protocol_spec.html | 30 +++++++++++++---- references.html | 15 +++++++-- rln.html | 5 +-- searchindex.js | 2 +- searchindex.json | 2 +- sss.html | 4 +-- terminology.html | 2 +- theory.html | 2 +- under_the_hood.html | 8 ++--- uses.html | 6 ++-- what_is_rln.html | 10 +++--- 18 files changed, 108 insertions(+), 55 deletions(-) rename diagram.html => protocol_spec.html (72%) diff --git a/404.html b/404.html index 6261468..7c0b8a0 100644 --- a/404.html +++ b/404.html @@ -76,7 +76,7 @@ diff --git a/appendix.html b/appendix.html index 7383ad4..6740a5c 100644 --- a/appendix.html +++ b/appendix.html @@ -75,7 +75,7 @@ diff --git a/circuits.html b/circuits.html index c0594f6..b16b555 100644 --- a/circuits.html +++ b/circuits.html @@ -75,7 +75,7 @@ @@ -135,16 +135,16 @@

Circuits

-

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.

+

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.

diff --git a/how_to_use.html b/how_to_use.html index 19fb100..392f9a6 100644 --- a/how_to_use.html +++ b/how_to_use.html @@ -75,7 +75,7 @@ diff --git a/index.html b/index.html index 46154fa..fe07d7d 100644 --- a/index.html +++ b/index.html @@ -75,7 +75,7 @@ @@ -135,7 +135,8 @@

RLN

-

RLN (Rate-Limiting Nullifier) 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.

+

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

RLN team is working on the protocol (having the same name), implementations and different applications of it.

diff --git a/overview.html b/overview.html index bab5dde..ca5f989 100644 --- a/overview.html +++ b/overview.html @@ -75,7 +75,7 @@ diff --git a/print.html b/print.html index 5a08515..2ed1542 100644 --- a/print.html +++ b/print.html @@ -76,7 +76,7 @@ @@ -136,7 +136,8 @@

RLN

-

RLN (Rate-Limiting Nullifier) 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.

+

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

RLN team is working on the protocol (having the same name), implementations and different applications of it.

Overview

@@ -153,9 +154,9 @@

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).

+

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).

How it works

-

The RLN construct’s functionality consists of three parts, which when integrated together provide spam and sybil attack protection. These parts should be integrated by the upstream applications which require anonymity and spam protection. The applications can be centralized or decentralized. For decentralized applications, each user maintains a separate storage and compute resources for the application. The three parts are:

+

The RLN construct’s functionality consists of three parts, which when integrated together provide spam and sybil attack protection. These parts should be integrated by the upstream applications which require anonymity and spam protection. The applications can be centralized or decentralized. For decentralized applications, each user maintains a separate storage and compute resources for the application. The three parts are:

  • User registration
  • User interaction
    • @@ -163,7 +164,7 @@

User registration

Before registering to the application the user needs to generate a secret key and derive an identity commitment from the secret key using the Poseidon hash function identityCommitment = posseidonHash(secretKey).

-

The user registers to the application by providing a form of stake and their identity commitment, which is derived from the secret key. The application maintains a Merkle tree data structure (in the latest iteration of the RLN construct we use the Incremental Merkle Tree algorithm), which stores the identity commitments of the registered users. Upon successful registration the user’s identity commitment is stored in a leaf of the Merkle tree and an index is given to them, representing their position in the tree.

+

The user registers to the application by providing a form of stake and their identity commitment, which is derived from the secret key. The application maintains a Merkle tree data structure (in the latest iteration of the RLN construct we use the Incremental Merkle Tree algorithm), which stores the identity commitments of the registered users. Upon successful registration the user’s identity commitment is stored in a leaf of the Merkle tree and an index is given to them, representing their position in the tree.

User interaction

For each interaction that the user wants to make with the application, the user must generate a zero-knowledge proof which ensures the other participants (the verifiers) that they are a valid member of the application and their identity commitment is part of the membership Merkle tree.

The interactions are app specific, such as voting for voting application and message sending for chat applications. The verifier is usually a server for centralized applications, or the other users for decentralized applications.

@@ -174,17 +175,31 @@

Thus, users have to split their secret_key into n parts and for every interaction they have to reveal the new part of the secret_key. So, in addition to proving the membership in the Merkle Tree, users have to prove that the revealed part is truly the part of their secret_key.

If they make more interactions than allowed per epoch their secret key can be fully reconstructed.

User removal (slashing)

-

The final property of the RLN mechanism is that it allows for the users to be removed from the membership tree by anyone that knows their secret key. The membership tree contains the identity commitments of all registered users. User’s identity commitment is derived from their secret key, and the secret key of the user is only revealed in a spam event (except for the scenarios where the original users wants to remove themselves, which they can always do because they know their secret key). When an economic stake is present, the RLN mechanism can be implemented in a way that the spammer’s stake is sent to the first user that correctly reports the spammer by providing the reconstructed secret key of the spammer as a proof.

+

The final property of the RLN mechanism is that it allows for the users to be removed from the membership tree by anyone that knows their secret key. The membership tree contains the identity commitments of all registered users. User’s identity commitment is derived from their secret key, and the secret key of the user is only revealed in a spam event (except for the scenarios where the original users wants to remove themselves, which they can always do because they know their secret key). When an economic stake is present, the RLN mechanism can be implemented in a way that the spammer’s stake is sent to the first user that correctly reports the spammer by providing the reconstructed secret key of the spammer as a proof.

Under the hood

This section provides deep and technical RLN overview.

We'll discuss:

    +
  • Technical side of RLN (specification demo)
  • How circuits are implemented
    • -
  • RLN in general (diagram)
-

Circuits

-

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.

-

Diagram

+

Technical side of RLN

+

This topic is a less strict version of specifications. If you want more formal description, you can find specs in the references

+
+

As it's been said RLN consists of three parts:

+
    +
  • User registration
    • +
  • User interaction (signalling)
    • +
  • User removal (slashing) - additional part
    • +
+

Well, let's discuss them.

+

User registration

+

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 she is a member of the tree.

+

We'll use Incremental Merkle Tree, as it more GAS-effective.

+

The slight difference is that we must enable secret sharing scheme (to split the commitment into parts). Thus, generation of the commitment is different.

+

Each member randomly generate secret key, that is denoted by a_0. Identity commitment q is the hash (Poseidon) of the secret key: q = Poseidon(a_0).

+

RLN would have no sense if there was no punishment for spam, that's why to become a member a user have to provide a certain form of stake.

+

Diagram

flowchart TB
 
     subgraph Generate Secret Key
@@ -227,6 +242,8 @@
     end
+

Circuits

+

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.

Uses

zk-chat

https://github.com/njofce/zk-chat

@@ -243,7 +260,7 @@
  • Shamir's Secret Sharing
-

Shamirs Secret Sharing Scheme

+

Shamir's Secret Sharing Scheme

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

@@ -353,7 +370,7 @@

References

diff --git a/diagram.html b/protocol_spec.html similarity index 72% rename from diagram.html rename to protocol_spec.html index 0f89f04..157357b 100644 --- a/diagram.html +++ b/protocol_spec.html @@ -3,7 +3,7 @@ - Diagram - Rate-Limiting Nullifier + Protocol spec - Rate-Limiting Nullifier @@ -75,7 +75,7 @@ @@ -134,7 +134,23 @@
-

Diagram

+

Technical side of RLN

+

This topic is a less strict version of specifications. If you want more formal description, you can find specs in the references

+
+

As it's been said RLN consists of three parts:

+
    +
  • User registration
    • +
  • User interaction (signalling)
    • +
  • User removal (slashing) - additional part
    • +
+

Well, let's discuss them.

+

User registration

+

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 she is a member of the tree.

+

We'll use Incremental Merkle Tree, as it more GAS-effective.

+

The slight difference is that we must enable secret sharing scheme (to split the commitment into parts). Thus, generation of the commitment is different.

+

Each member randomly generate secret key, that is denoted by a_0. Identity commitment q is the hash (Poseidon) of the secret key: q = Poseidon(a_0).

+

RLN would have no sense if there was no punishment for spam, that's why to become a member a user have to provide a certain form of stake.

+

Diagram

flowchart TB
 
     subgraph Generate Secret Key
@@ -182,10 +198,10 @@
diff --git a/references.html b/references.html index d0ae864..81e99b3 100644 --- a/references.html +++ b/references.html @@ -75,7 +75,7 @@ @@ -137,7 +137,7 @@

References

diff --git a/rln.html b/rln.html index 46154fa..fe07d7d 100644 --- a/rln.html +++ b/rln.html @@ -75,7 +75,7 @@ @@ -135,7 +135,8 @@

RLN

-

RLN (Rate-Limiting Nullifier) 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.

+

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

RLN team is working on the protocol (having the same name), implementations and different applications of it.

diff --git a/searchindex.js b/searchindex.js index e58125a..a842b53 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","circuits.html#circuits","diagram.html#diagram","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":36,"breadcrumbs":2,"title":1},"1":{"body":19,"breadcrumbs":2,"title":1},"10":{"body":0,"breadcrumbs":3,"title":1},"11":{"body":2,"breadcrumbs":4,"title":2},"12":{"body":14,"breadcrumbs":2,"title":1},"13":{"body":12,"breadcrumbs":2,"title":1},"14":{"body":239,"breadcrumbs":8,"title":4},"15":{"body":9,"breadcrumbs":2,"title":1},"16":{"body":201,"breadcrumbs":3,"title":1},"17":{"body":18,"breadcrumbs":4,"title":1},"2":{"body":83,"breadcrumbs":5,"title":3},"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":13,"breadcrumbs":5,"title":2},"8":{"body":19,"breadcrumbs":5,"title":1},"9":{"body":107,"breadcrumbs":5,"title":1}},"docs":{"0":{"body":"RLN (Rate-Limiting Nullifier) 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 RLN team is working on the protocol (having the same name), implementations and different applications of it.","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":"","breadcrumbs":"Overview » Uses » Uses","id":"10","title":"Uses"},"11":{"body":"https://github.com/njofce/zk-chat","breadcrumbs":"Overview » Uses » zk-chat","id":"11","title":"zk-chat"},"12":{"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":"12","title":"How to use"},"13":{"body":"This section provides theoretical information that underpins RLN . Here we'll discuss: Shamir's Secret Sharing","breadcrumbs":"Theory » Theory","id":"13","title":"Theory"},"14":{"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 = []; for (let i=0; i = []; for (let i=0; i = []; for (let i=0; i
-
  1. RLN
  2. Overview
    1. What is RLN
    2. Under the hood
      1. Circuits
      2. Diagram
    4. Uses
  4. How to use
    1. JavaScript RLN
    2. Rust RLN
  6. Theory
    1. Shamir's Secret Sharing
  8. Appendix
    1. A - Terminology
    2. B - References
+
  1. RLN
  2. Overview
    1. What is RLN
    2. Under the hood
      1. Protocol spec
      2. Circuits
    4. Uses
  4. How to use
    1. JavaScript RLN
    2. Rust RLN
  6. Theory
    1. Shamir's Secret Sharing
  8. Appendix
    1. A - Terminology
    2. B - References
@@ -134,7 +134,7 @@
-

Shamirs Secret Sharing Scheme

+

Shamir's Secret Sharing Scheme

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

diff --git a/terminology.html b/terminology.html index 6d6785d..b1831d5 100644 --- a/terminology.html +++ b/terminology.html @@ -75,7 +75,7 @@ diff --git a/theory.html b/theory.html index 1083eab..a433a3e 100644 --- a/theory.html +++ b/theory.html @@ -75,7 +75,7 @@ diff --git a/under_the_hood.html b/under_the_hood.html index 476360f..aed0fc5 100644 --- a/under_the_hood.html +++ b/under_the_hood.html @@ -75,7 +75,7 @@ @@ -138,8 +138,8 @@

This section provides deep and technical RLN overview.

We'll discuss:

    +
  • Technical side of RLN (specification demo)
  • How circuits are implemented
    • -
  • RLN in general (diagram)
@@ -149,7 +149,7 @@ -
@@ -161,7 +161,7 @@ - diff --git a/uses.html b/uses.html index 1444b6f..e4d62c1 100644 --- a/uses.html +++ b/uses.html @@ -75,7 +75,7 @@ @@ -143,7 +143,7 @@