# Vac<>PSE

## Initial questions

1) What are our common goals?
- Do goals diverge in some sense?
2) What work needs to be done?
- How should it be divided?
3) What are some priorities?
- Do we have different priorities in some sense?
4) How should we coordinate?
- Agenda for call?
- Desired outcomes?

## Context and links

- RLN spec: https://rfc.vac.dev/spec/32/
- Zerokit positioning: https://notes.status.im/UAFvOj1tTQ6uW2li0ZeXfw#
- ...

## Laundry list of things we could be doing

- WASM support
- WASM support + Multithreading, to avoid having to disable the 'parallel' feature.
- Being able to generate wrapper JS code as ESM in addition of CJS (currently CJS only).
- Running on mobile
- Both perf and APIs here (e.g. interfaces for mobile apps, 0xPARC people were for this)
- Metadata wrapper format for RLN proofs (circuits)
- JS-less stack
- ark-r1cs (rationale?)
- RLN smart contract audit
- For the RLN contract, the ongoing effors are capture in this meta-issue https://github.com/vacp2p/research/issues/128, namely:
- Service fee and pool management (https://github.com/vacp2p/rfc/issues/485)
- Standardizing the contract API (https://github.com/vacp2p/rfc/issues/511)
- On-chain secure slashing strategies (https://github.com/vacp2p/research/issues/137)
- ERC20 token support (https://github.com/vacp2p/rln-contract/issues/1)
- RLN trusted setup
- Better support for RLN ops from zerokit e.g.
- CLI for common operations
- Smart contract interaction (a la Foundry)
- Hybrid architecutre for the membership Merkle tree storage management (super-peer/light-peer) - https://github.com/vacp2p/research/blob/master/rln-research/merkle-tree-update.md
- ...

## Upstream laundry list

Things that needs to be done upstream, and we might get further assistance on. E.g. ark-circom:

ark-circom:

1) WASM support
- https://github.com/vacp2p/zerokit/pull/38#discussion_r972158719
3) Improved bundle size for embedding (both for mobile targets as we asll browsers
- https://github.com/vacp2p/zerokit/issues/37
- https://github.com/waku-org/js-rln/issues/1#issuecomment-1246067128
5) Debugging/testability
6) Ability to interact with circom without using JS-stack at all (similar in spirit to Foundry)
7) ...

---

### Feb 15, 2023

Attendees: Rasul, Tyler, Kevin, G, Aaryamann
### Agenda and Discussion Points

- RLN contract in foundry
- RLN+Interep PoC complete
- Algebraic attack mitigation in Circuit
- Circuit changes (update to https://hackmd.io/oRPaogmvTmG9fyYcNSzz7w WIP)
- Pmtree integration (ready, only need WASM Support)
- 32/RLN rfc editor

### Notes
- WASM support on ark-circom ~ no status yet
- pmtree:
- Parallelization using rayon
- 3.5x performance of current implementation
- has tests too
- rayon is not compatible with wasm, need to use a bindgen
- batch insertions implemented
- config trait implemented
- `Box<dyn error>` used vs custom errors

- RLN contract has been implemented in foundry:
- Need to work on invariant testing/fuzzing
- ERC721/1155 support to rln-contract
- Proof of Slashing
- can be used in governance/reputation systems
- RLN contract work can be done in parallel to zerokit implementation of rln v2 circuits

- RLN trusted setup
- Will schedule when circuits/zerokit/waku impl are prod ready
- Not required with v3 (halo2)

- 2 versions of rln circuits have been created: https://hackmd.io/oRPaogmvTmG9fyYcNSzz7w
- 1 with same epoch limits
- 1 with different epoch limits
- constraints haven't changed after using abstractions
- They look secure

- Algebraic attacks:
- Complexity of an attack at the current moment is 2^150
- Modulo reduction is susceptible to attacks
- Poseidon is a sponge hash function; it can be used in key-derivation functions
- The inputs must have more entropy to be secure
- Coefficients of SSS in RLN need to be semi-independant
- Using the identity_trapdoor and identity_nullifier, both coefficients must be generated
- The attack may be infeasable, and it must be communicated to users
- should be mentioned in the rfc
- If poseidon is replaced with keccak, it is sound but not zk-friendly
- If we switch to halo2 then rln will be secure (if we use a different hashing fn)

- RLN v2 circuit integration into zerokit/nwaku
- metadata should probably be included in the proof
- should be a public input to the circuit
- verification will fail regardless, if they were generated with different provers/have diff circuits
- tree depth for the circuit = 20, needs to be known beforehand

- Halo2:
- Conversion from circom to halo2 is not trivial since the primitives would be different

- js-waku & rln-js integration
- fn to convert js-waku proofs to rln-js proofs (Kevin is working on this)

- RLN cli
- API for proofs, verifications
- Interactions with smart contracts

### Action Points
- [ ] Make pmtree wasm-friendly
- [ ] G: Make introductions between Rahul/Rostyslav and Rasul
- [ ] A: review rln versioning for nwaku/zerokit

---
### Nov 16, 2022
Attendees: Rasul, Tyler, Richard, G, Felicio, Sanaz, Aaryamann
### Agenda and Discussion Points
- Zerokit (which one of the folllowing issues to tackle next)
- https://github.com/vacp2p/zerokit/issues/69 - Docs/Tutorial
- To mirror/expand in https://rate-limiting-nullifier.github.io/rln-docs/references.html
- https://github.com/vacp2p/zerokit/issues/70 - CLI
- https://github.com/vacp2p/zerokit/issues/71 - Generalize API
- https://github.com/vacp2p/zerokit/issues/47 - Mobile Target
- RLNP2P as fyi
- RLN+Interep https://github.com/vacp2p/research/issues/147 (js PoC implementation maybe)
- RLN membership contract, any interest from PSE
- Standardizing the interface and working through missing features like slashing
- Fee option and pool management
- ERC20 for membership payment
- Persistence Merkle tree, DB management part and how it interfaces with the current DBs in nwaku, having Hanno or Lorenzo involved in that part
- [pmtree](https://github.com/Rate-Limiting-Nullifier/pmtree) integration to zerokit

- RLN spec state and update
- Project that uses RLN (PoC app)
- > I just noticed https://rfc.vac.dev/spec/32/#generating-identity-credentials this spec (written by Blagoj) refers to zk-kit but seems out of date, perhaps we should also update this spec? (I believe it should be draft now too, and probably a bunch of other updates to make) /O
### Notes
- PMtree lives in a separate repo than the zerokit, https://github.com/Rate-Limiting-Nullifier/pmtree
- MT Batch insetion and parallelization
- Relevant PR in zerokit - https://github.com/vacp2p/zerokit/pull/66
- Why not merging the two repos:
- PMTree is just a dependency
- We are not the main developers
- For modularity is better to keep them separate
- For good clarity
- For branding it is more clear not be under zerokit
- for maintainability
- Why merging:
- less data type wrapping
- easier collaboration
- Integrating the pmtree into zerokit RLN
- Browser-based db support
- There is a choice to choose bw Full, optimal and persistance MT in zerokit RLN API

- RLNP2P: a new grantee for RLN zkchat https://github.com/kayleegeorge/zk-chat and https://hackmd.io/dX1qoy6cTtSXJ7TdB8muIw?both
- A server client version already existed
- Allowing in-game web3 chat like
- Possible collaboration/improvements: add zk-verification of message encryption
- RLNP2P links: https://github.com/vacp2p/research/issues/146 and https://github.com/vacp2p/research/issues/110
- Moile Target: not of PSE interest
- Documentation of the rln-relay: https://rate-limiting-nullifier.github.io/rln-docs/protocol_spec.html intersted to work
- CLI interface for RLN, is of PSE interest. First identifying the common API, and then add to the CLI.

### Action items
- [x] Coolaboration approach on zerokit
- [x] (G) to open a GH issue to integrate pmtree into zerokit RLN module
- [ ] Collaboration with a new grantee on RLNP2P
- [x] Check the Gh issue and share Interrep+RLN
- [x] Ensure Rasul has access to issues assignments/merges/prs
- [ ] CLI issue for Rasul/G

---
## Oct 6, 2022
Attendees: Rasul, Sanaz, Giuseppe, Richard

### Agenda and Discussion Points
- Vac PSE positioning https://hackmd.io/DOXcKigoR224QEvC6cV33w
- RLN future development from PSE pov
1) What are our common goals? Do goals diverge in some sense?
2) What work needs to be done? How should it be divided?
3) What are some priorities? Do we have different priorities in some sense?
4) How should we coordinate? Agenda for call? Desired outcomes?
- Creating GH issues about suggested improvements, bugs, etc.
- Collaboration on the RLN specifications and RLN-Relay specs
- A hybrid architecture to serve Merkle tree assocaited data to the light clients, specially in a privacy-preserving fashion. Also, how to manage trust and malicious actors.
- Collaboration on the RLN contract side, support for ERC20, adding protocol fee for incentivization
- Collaboration on zero-kit:
- Persistant Merkle tree storage
- JS-less stack
- RLN in ark-r1cs: benefits and rationale could be good to be discussed in a GH issue
- Better documentation for the RLN
- The documentation https://rate-limiting-nullifier.github.io/rln-docs/ can benefit from the existing RLN-Relay and RLN specification under the vacp2p repo

### Notes
- RLN-Rust library in RLN group of PSE, PoC apps on top RLN, documentation of the code, explanation of the code, user friendliness of the library, wasm support and mobile support
- RLN contract side
- Two implementation of chats in PSE: RLN-chat and zk-chat, and chat app in Rust
- PSE interest in the contract
- Tyler is gonna present the RLN in the Devcon
- Parallesim in wasm
- Persisting Merkle tree
- Rate limiting auction from PSE side (https://rfc.vac.dev/spec/17/)

### Action items
- [ ] Once call per month, for the date and time will discuss in the discrod
- [ ] Next task to be persisting Merkle tree (Rasul to ask from Tyler) (Giuseppe to create the GH issue)
- [ ] https://github.com/thyeem/monotree
- [ ] Rasul to talk with Tyler about the contract collaboration https://github.com/vacp2p/rln-contract
- [ ] Elaborate on this issue https://github.com/vacp2p/zerokit/issues/42
- [ ] Rate limiting auction from PSE side (https://rfc.vac.dev/spec/17/) (Rasul talk with Tyler)