List of remaining tasks in different tracks

[staheri14]

Below, I am capturing all the outstanding tasks from my POV in different tracks. This issue is only for the sake of documentation and does not make sense to be followed with a PR. I tried to add some relevant GH issues in front of each task. However, there may be other relevant GH issues as well.
Projects/tasks that are/can be pursued in collaboration with the PSE group are annotated accordingly.

RLN-Relay track

• Making Waku-RLN-Relay nodes stateful (mentioned in Milestone: Secure, sound and stateful waku-rln-relay #144)
• Persistent Merkle tree (mentioned in Milestone: Secure, sound and stateful waku-rln-relay #144)
• Encrypted RLN credentials in different waku clients (mentioned in Milestone: Secure, sound and stateful waku-rln-relay #144)
• Exchangeability of the encrypted RLN credentials
• Wallet integration for secure Ethereum key management Wallet integration into waku-rln-relay waku-org/nwaku#819
• Slashing functionality Enabling slashing spammers in RLN-Relay #136
  • part of this task may require updating the constants in the Poseidon smart contract and re-deploying it, and testing it on a testnet (together with the RLN contract)
• Decoupling the group synchronization logic from the mounting process feat(rln-relay): group management interface waku-org/nwaku#1370
• Separation of group registration from rln-relay mounting process chore(rln-relay): Separation of group registration from rln-relay mounting process waku-org/nwaku#1369
• General improvement of user interface in chat2 and nwaku. There are various clean up and improvements GH issues in this regard.
• Making RLN-Relay module structure compliant with the other Waku protocols (priority of this should be discussed in collaboration with the production team)
• Security audit of
  • the RLN contract
  • the RLN circuit
  • the Waku-RLN-Relay codebase (not sure whether this one would be necessary or not)
• Enabling RLN-Relay mode in the lightpush protocol bug(rln-relay): light push does not check proofs before forwarding to relay waku-org/nwaku#1226
• Conducting the RLN circuit-dependent trusted setup
• Providing zero entry for RLN-Relay message publisher (no crypto asset required): one solution relies on the lightpush protocol where a lightpush service provider makes a batch registration to the RLN membership group and utilizes its aggregated messaging rate to publish spam-protected messages on behalf of the light push requesters
• Multi credential management: enabling higher messaging rate per Waku-RLN-Relay node feat (rln-relay): allow higher messaging rate using multiple valid registrations waku-org/nwaku#1264
• Hybrid architecture for the membership Merkle tree storage management (super-peer/light-peer)
• Better understanding of the risk of the zkSNARKs proofs malleability (perhaps will fall into the Waku message integrity area)
• Evaluating and improving the security of the RLN-Relay: Identifying attack vectors like MEV and devising proper measures
• Proper integration of pubsub topic and content topic in the rln identifier. Also, it would be good to think about a solution to derive rln secret shares based on the rln_identifier so that secret shares of two different app wont be combinable. The computation of rln_identifier should also be clarified in the RLN-Relay RFC.
• Storage efficient maintenance of Merkle tree, a rough solution is captured in https://github.com/vacp2p/research/blob/master/rln-research/merkle-tree-update.md
  Research and RFC tasks:
• Updating the rln-relay contract according to the current state of implementation e.g., atomic processing of the blocks to calculate valid and acceptable Merkle tree roots
• Standardizing the RLN membership group contract interface 17/Waku-RLN-Relay: Standardizing the interface of rln/rln-relay membership contract  rfc#511
• Upstreaming a working draft for the RLN-Relay project to the libp2p repo (PSE). Relevant issue Privacy-preserving p2p economic spam protection libp2p/specs#374
• Research publications:
  • Waku-RLN-Relay demo paper: chat2 use-case
  • RLN paper: introducing the RLN construct to academia (PSE + Blagoj?)
  • an extended version of RLN-Relay for a journal submission with the addition of performance and security analysis Waku-Rln-Relay Extension (Journal submission) #100

RLNP2P track

• Some rearchitecting in the current Waku-RLN-Relay module is desirable to be aligned with the positioning of the RLNP2P. The components outside of the core RLN functionality e.g., the group synchronization layer, should be extracted and converted into a separate module with a proper interface as a reusable lib. This can be initially done in nwaku codebase, then proper C APIs can be generated for those separate modules. It was discussed that the final implementation of RLNP2P can be in Rust rather than Nim (due to language features). Some relevant issues are: Milestone: RLNlib - RLN-Relay as a standalone scheme #110 another relevant issue Positioning: RLNP2P #146
• A potential collaboration opportunity with PSE about RLNP2P and its use cases (see the following comment Positioning: RLNP2P #146 (comment))

Incentive track

• RLN contract improvements: ERC20 for membership payment, supporting service fee(Incorporating fee option in the rln contract rfc#485)
• RLN contract multisig for the management of collected service fees
• Secure slashing functionality
• There are further GH issues in the rln-contract and RFC repos
• Basic private settlement for store protocol. (relevant issues include The development roadmap of Waku store protocol incentivization using service credentials #135 and Incentivizing Waku Services using Service Credentials (store protocol) #99 and Milestone: Private off-chain settlement for the waku store protocol  #138)

FT-store (w/ data sync) track

The problem of state synchronization among store nodes is described in #74.
Solutions can fall into the following categories depending on the nodes failure model:

• Fail-stop fault-tolerant store protocol, provide state consistency across store nodes in the fail-stop failure model (intermittent availability of peers)
• Byzantine fault-tolerant store protocol; provide state consistency across store nodes in the Byzantine failure model

An initial solution idea utilizing MVDS is drafted in the following issue vacp2p/rfc#384 which is later moved to #73.

Applied ZK/Explorations tracks

• Validator privacy (PSE?)

Unknown track

• Decentralized CAPTCHA using Interrep (PSE?)

cc: @oskarth