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?

Laundry list of things we could be doing

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
  2. Improved bundle size for embedding (both for mobile targets as we asll browsers
  3. Debugging/testability
  4. Ability to interact with circom without using JS-stack at all (similar in spirit to Foundry)
  5. …

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

Notes

Action items

  • Coolaboration approach on zerokit
  • (G) to open a GH issue to integrate pmtree into zerokit RLN module
  • Collaboration with a new grantee on RLNP2P
  • Check the Gh issue and share Interrep+RLN
  • 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

Select a repo