# RLN spec (canonical Poseidon + IncrementalQuinTree) **Note: For the spec of the old RLN construct implementation please refer to [this link](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?both). ## Membership Each member has a secret key that is denoted by `a_0`. And identity commitment `q` is the hash of the secret key ``` q = h(a_0) ``` To become a member one must: * Provide a certain form of stake * Place themselves in a empty leaf of the membership identity tree (IncrementalQuinTree). ## Signalling Members are cryptoeconomically bounded to send only one signal in an epoch. Proof system enforces members to reveal their secret key `a_0` when they go beyond that limit. ### Membership For a valid signal identity commitment `q` must be exists in identity tree. Membership is proven by providing a membership proof (`witness`). The fields from the membership proof required for the verification are: `path_elements` and `identity_path_index`. ### Linear Equation & SSS Secret key `a_0` which is first coefficient of a linear polynomial. Each member _knows_ a linear polynomial for any `epoch` which is derived from secret key `a_0` and the `epoch`. So, each `epoch` there is a polynomial with different `a_1` equation but with same `a_0`. ``` A(x) = (a_0, a_1) a_1 = h(a_0, epoch) ``` Each member has a secret line equation for an epoch ``` y = a_0 + x a_1 ``` Along with a signal members should publicly provide a `(x, y)` share such that satisfies the line equation. With more that one share anyone can derive `a_0`, the secret id key. Hash of a signal will be evaluation point `x`. So that a member who sends more that one signal reveails the secret key. Note that shares used in different epochs cannot be used to derive the secret key. ### Nullifiers `epoch` is external nullfier. Internal nullifier is calculated as `nullifier = hash(a_1, rln_identifier)`. Note that `a_1` has already a secret id key ingredient `a_1` and `epoch` ingredient, so each epoch a member can signal to only one nullifier. The `rln_identifier` is a random value from a finite field, unique per RLN app, and is used for additional cross-application security - to protect the user secrets being compromised if they use the same credentials accross different RLN apps. If `rln_identifier` is not present, the user uses the same credentials and sends a different message for two different RLN apps using the same epoch, then their secret key can be revealed. With 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. ### Circuit #### Constraints To send a valid signal member should provide: * Membership proof * A share satisfies the line equation * Correct nullifier. These are constraints of RLN circuit. #### Public Inputs * `x` * `epoch` * `rln_identifier` #### Private Inputs * `a_0` (`identity_secret`, secret/private key) * `witness` (`path_elements` and `identity_path_index`, elements from the witness component) #### Outputs * `y` * `root` (The membership tree root) * `nullifier` (The internal nullifier) ## Slashing Members reveal a single share of secret key for each signal in an epoch. A share `(x, y)` is a valid point at the polynomial of a member. If a member signals more than one, secret key is enforced to be exposed. It means that watchtower nodes can calculate coefficients of this line equation, so the secret key `a_0`. Therefore, a member who spams goes under a risk to be slashed that is burn of the deposit. The risk remains until the end of withdrawal period. We can also dismember the related public key from membership tree. ## Extra: The arbitrary polynomial degree (spam threshold) usecase Other than the single signal per epoch usecase, we've implemented circuits that allow for (pseudo) arbitrary signals per epoch. To enable this we use polynomials of arbitrary degree, depending on the spam threshold requirement for the certain usecase. For this implementation the user secret is represented as an array of random finite field values (instead of a single finite field value). Let's say this array is denoted by: `rln_secret[n]` The polynomial is now represented as: ``` y_n = a_0 + x*a_1 + x^2*a_2 + x^3*a_3 + ... + x^n*a_n ``` where `a_0 = hash(rln_secret[0], rln_secret[1],..., rln_secret[limit - 1])`, each `a_i`, when `i > 0 && i <= n` = `a_i = hash(rln_secret[i-1] * epoch)` The user will need to send more than `n` signals per epoch to be eligible for slashing. The internal nullifier is calculated as: ``` nullifier = hash(a_1, a_2, ... a_n, rln_identifier) ``` ## Implementation RLN circuits for the base case - polynomial with degree 1, can be found at [github.com/appliedzkp/rln](https://github.com/appliedzkp/rln) RLN circuits for the general case - polynomial with arbitrary degree, can be found at: [github.com/appliedzkp/rln/tree/nrln](https://github.com/appliedzkp/rln/tree/nrln) Library providing API for the RLN construct, written in JavaScript can be found here: [github.com/appliedzkp/libsemaphore](https://github.com/appliedzkp/libsemaphore). A tutorial on how to use the library provided above, and implement a simple chat protocol (completely offchain): [github.com/bdim1/rln-anonymous-chat-app](https://github.com/bdim1/rln-anonymous-chat-app) The circuits are implemented in [Circom 2.0](https://github.com/iden3/circom). ### Poseidon Hasher Canonical poseidon implementation is used, as implemented in the [circomlib library](https://github.com/iden3/circomlib), according to the [Poseidon paper](https://eprint.iacr.org/2019/458.pdf). Hashes are generated for 1 and 2 inputs only, so the `width (t)` parameter of the hasher is either 2 or 3. ### Merkle Tree implementation IncrementalQuinTree structure is used for the Membership tree. The circuits are reused from [this repository](https://github.com/appliedzkp/incrementalquintree). You can find out more details about the IncrementalQuinTree algorithm [here](https://arxiv.org/pdf/2105.06009v1.pdf).
Last changed by  
 
Blagoj Dimovski
1023

Read more

Account abstraction multifactor authorization using WebAuthn

Project Abstract Given all the possibilities created by the account abstraction implementation, authorization from a user perspective will be always a challenge. We intend to solve that by providing a generic way for users to be protecting their wallets with an extra layer of security when authorizing transactions - which can be their fingerprint, face, a usb device etc. A lot of existing technologies, that can be found in both desktop and mobile, like TouchID, FaceID etc., currently make this possible via the WebAuthn standard, and we plan to research and build a generic and easy to use way for integrating this in a smart contract wallet and in any Web 3 application. Objectives Our main objective is to provide a great UX for developers to easily integrate this feature in their applications, without much hassle, and the same great UX experience for the end users that will be using this. We intend to achieve that by setting a goal to define generic primitives that any Web 3 project can use to integrate WebAuthn for their use case that uses smart contract wallets. These generic primitives will enable integration with the smart contract wallet account (via extensibility or pluggable component), as well as an integration in the application’s backend, in a seamless way. Any new or existing Web3 project that wishes to either include an extra layer of security for their user’s access to their wallets, should find it really easy to do.

3/12/2023
Anonymous chat app <-> ZK Keeper integration

Register to InterRep with an identity commitment Once registered, you can use the same identity commitment for using the RLN anonymous chat app. ZK-Keeper can be used for managing identities The RLN anonymous chat app can check if the identity is registered to InterRep (part of InterRep group) If the identity is not registered, the user should be redirected to InterRep for registration If the identity is registered the user can use the app (send messages) The ZK-Keeper extension can generate proof based on the user's active identity. Once proof is generated, it can be send from the RLN chat app client to the RLN chat app server for proof verification and further message broadcasting. If the message is a spam, the user should be slashed -> removed from the RLN merkle tree and the user's id commitment should be added into a ban list, so that the user can not register again.

1/30/2022
Project lead for the CloudFlare-RLN project, Privacy and Scaling Explorations Research Group

Research and development · Fully Remote, RM About the Privacy and Scaling Explorations Research Group We are a cutting-edge technological research group exploring practical applications for Zero-Knowledge Proofs and Scaling solutions, in partnership with the Ethereum Foundation. Our mission is to build the cryptographic primitives that will form the bedrock of a rich and vibrant ecosystem of decentralized applications (dapps), built on Ethereum. We do this through pure research projects, by building proofs of concept, and by facilitating the integration of technological primitives into decentralized applications. Your mission We've been working on several ideas, as well as multiple different libraries for the RLN ZK construct. Our goal is to make the broader community more aware of the construct and the possibilities enabled by it, as well as develop real-life products which use the RLN construct. The CloudFlare-like rate limiting using RLN and InterRep is currently in Proof-of-Concept stage. We've made the core architecture and user interaction decisions, and also created a prototype which demonstrates the concepts: https://github.com/bdim1/rln-interrep-cloudflare. The network design is not set in place, and we expect it to be changed so that the rate limiting works on a lower level of the network stack. Your mission will involve researching and developing an optimal network architecture for the Rate Limiting product. It also involves taking the lead of the product and bringing it to production ready state.

10/22/2021
Project lead for the Private messaging for ETH2 validators project, Privacy and Scaling Explorations Research Group

Research and development · Fully Remote, RM About the Privacy and Scaling Explorations Research Group We are a cutting-edge technological research group exploring practical applications for Zero-Knowledge Proofs and Scaling solutions, in partnership with the Ethereum Foundation. Our mission is to build the cryptographic primitives that will form the bedrock of a rich and vibrant ecosystem of decentralized applications (dapps), built on Ethereum. We do this through pure research projects, by building proofs of concept, and by facilitating the integration of technological primitives into decentralized applications. Your mission We've been working on several ideas, as well as multiple different libraries for the RLN ZK construct. Our goal is to make the broader community more aware of the construct and the possibilities enabled by it, as well as develop real-life products which use the RLN construct. The Private message sharing for ETH2 validators project is currently only a specification for a promissing tool which will enable the Ethereum 2 validators to communicate privately. There is a written specification for scope of the projects, the underlying tools to be used as well as the user interactions. Your mission will involve developing the tools needed for enabling the project (gossipsub-rln), as well as developing the project by using these tools.

10/22/2021
Read more from Blagoj Dimovski
Published on HackMD