RLN Research Roadmap #115
Description
Background
RLN has evolved significantly over the last couple of years. We are on the cusp of releasing a version for the Waku Network with on-chain Merkle proofs and roots, eliminating the need for nodes to sync the membership tree. We've also introduced some basic membership management functionality. We also have some of the next steps for RLN already scheduled in the Waku Roadmap. Beyond the roadmapped items, we've also opened some longer-term investigations that have not yet been prioritised.
Many Waku subteams are involved with the various RLN efforts. This issue tracks the roadmapped and foreseen but not-yet-roadmapped items for a productionised RLN from a Waku Research perspective.
RLN roadmap tasks, roughly in order of priority:
1. Testnet with onchain RLN and basic membership
Issue: https://github.com/waku-org/pm/milestone/34
Note: In progress. Research is responsible for implementing and adapting nwaku to the new RLN contract. This deliverable is soon to be delivered.
Outstanding tasks:
- Monitor behaviour of new contract and basic interactions during testnet period
2. Support advanced RLN integration in nwaku/js-waku
Issue: TBD
Note: In progress. This work item is described in the FURPS and is owned by the js-waku and nwaku teams. The role of Research is to actively help monitor that more advanced Smart Contract functions (like expiry, membership extension, fund withdrawals, etc.) work as expected.
Outstanding tasks:
- Monitor behaviour of new contract when using advanced functions like membership extension, withdrawal, etc.
- Ensure the spec is fully implemented and identify any gaps from testnet learnings
3. Extend contract to reduce number of Web3 RPC calls
Issue: TBD
Note: This item is described in the roadmap. It probably entails extending the contract to keep track of some past roots on top of the current root, allowing clients to validate messages against past roots without constant polling of the contract.
RLN non-roadmapped tasks, roughly in order of priority:
The following items have not yet been roadmapped, but are foreseen to be prioritised after the items listed above:
4. Modularise contract architecture to split business logic and funds vault; harden upgrading strategy
Issue: TBD
Note: This is inspired by Codex's approach to upgradability, security and management of their contracts. We can likely follow their pattern exactly - splitting the "vault" functionality interacting and keeping the deposited funds from the more complex "business logic" of membership management. As part of this work item we should formalise an upgrade/disaster recovery strategy.
5. Setup multisig ownership of contract
Issue: TBD
Note: Probably Safe, as discussed in the forum
6. Formal verification and audit of contract
Issue: TBD
Note: Following Codex's parallel roadmap, we can perform both a formal verification (see Certora) and audit of the contract(s). For this we'll involve the Smart Contract and Security service teams.
7. Deploy contract to a mainnet
Issue: TBD
Note: Most likely Status Network or Linea
8. Set up contract monitoring
Issue: TBD
Note: In order to understand if the contract is behaving as expected, we should set up at least a semi-formalised system for contract monitoring. The exact tooling/strategy here will depend on the chain we chose for the deployment.
9. Alternative routes to RLN membership (this can be started in parallel to issues above)
Issue: TBD, likely several
Note: This is a collection of several tasks to allow memberships to be acquired outside of the deposit-expire-withdraw model. This requires coordination with other Waku/IFT efforts, such as membership distribution to Chat SDK clients (project-sponsored), membership based on Karma ownership in Status Network, etc.
10. Rate-limiting over multiple shards (or: The Return of Slashing)
Issue: #109
Note: This is a significant work item that will likely lead to slashing being reintroduced for RLN to allow rate-limiting over multiple shards.