Track: RLN-Relay

[staheri14]

RLn-Relay Track

The aim of this meta-issue is to shed light on

• The critical path of the RLN-Relay track
• RLN milestones
• The scope of each milestone and its tasks
• The ordering and inter-dependency between milestones and tasks.

Milestones

Currently, the RLN track embodies the following milestones (not fixed, open to suggestions and edits). The attached figure provides an instant overview of the RLN-Relay track and milestones/tasks and their dependencies.

• RLN-Relay testnet1: Testing the on-chain dynamic membership group management on the Goerli test network. This is to troubleshoot implementation related to the interaction of nwaku with the blockchain network. Milestone: RLN-Relay testnet1 - dynamic group and on-chain vacp2p/research#126

• RLN-Relay group management performance: it focuses on the performance of the membership group management i.e., bandwidth, storage, and computation. The aim is to make sure there is no bottleneck for resource-limited devices. Atm, the most pressing and evident issue is with the storage overhead of the Merkle tree which. More tasks can be added if further concerns arise. RLN-Relay group management performance vacp2p/research#127

• RLN-Relay testnet2: zero-kit rln-relay (@s1fr0 would you please link a milestone issue in here) Can be considered a task within Cross-client testnet milestone

• Cross-client testnet: The ultimate goal is to get waku-rln-relay implemented in all the waku clients i.e., js, go and nim and make sure they can properly communicate with each other over the waku network via e.g., chat2 command-line application. Rough steps towards this goal are shown in the figure as well. Milestone: RLN-Relay cross-client testnet vacp2p/research#129

• RLN trusted setup: It is to run the MPC for the rln circuit. (TODO: a GH issue) better to phrase it as a future task and then see if it deserves a milestone or not.

• Multi-chain/token RLN-Relay: Anything related to the membership contract interface and the payment method and fund management fall into this milestone. The exact tasks are shown in the figure. Multi-chain/token RLN-Relay vacp2p/research#128 Shall be integrated into cross client testnet milestone

• Applied RLN-Relay: Positioning rln-relay as a stand-alone scheme for external projects. Milestone: RLNlib - RLN-Relay as a standalone scheme vacp2p/research#110 not relevant to this track

• The "js rln-relay" and "Go rln-relay" milestones are related to other waku clients, however, they will impact the timing of the "Cross-client testnet" milestone, as such, they are mentioned in this issue. The requirements for these milestones are merely to have feature parity with their nim counterpart. Some of the relevant tasks are depicted in the figure below, but the order of operations purely depends on the corresponding project owners i.e., @fryorcraken and @richard-ramos. these are the constituents of the cross-client testnet milestone

Link to the flowchart source
Figure description:
Milestones are depicted on the left, and their tasks are shown next to them in order.
Milestones are separated from each other by straight lines.
All the dependency between milestones and their tasks is indicated by a directed arrow. So if no dependency is indicated between two tasks then they can be considered concurrent and independent.
Green shadows indicate a completed task.
Each milestone and its corresponding tasks will be traced through their respective GH issues.

cc: @oskarth @jm-clius @s1fr0

[oskarth]

Thanks for the overview of some of the work that needs to be done! Replied in discord thread, but I think there's a misunderstanding of milestones and their scope. As far as I see it, we have roughly the following milestones for RLN-Relay:

1. Testnet1 - Milestone: RLN-Relay testnet1 - dynamic group and on-chain vacp2p/research#126 (still needs a bit more work, both on scope and execution, but almost there)

2. Cross-client testnet2 - a lot of uncertainty and requires a lot more coordination work to kickstart and get critical path sorted, integrating Zerokit, making sure js-waku gets support, etc

maybe performance is a separate milestone, but in its current state I doubt it. It is a means to an end, not an end to itself. If we isolate a clear problem re MT storage and we have a specific idea for how to tackle it then it can be its own thing. But this is largely parallel to cross-client testnet, because you can just limit the scope of the participants.

It is a lot more valuable to have a complete end to end RLN testnet that's cross-client, i.e. works in browsers, but limited to even 100-1000 participants, than having something half-finished that "theoretically" supports a million users.

It isn't obvious to me there's much value in talking about other milestones regarding RLN-Relay at this stage. The contract work needs more clarity I believe, though there could be somehing separate there. I'd prefer to have this be integrated into e.g. testnet2 as part of the scope, e.g. ERC20 support should be part of that scope. Dealing with "multi network" (under specified) might be better for testnet3, e.g.

I have no idea why Zerokit would get its own testnet - this is the whole point of the cross-client testnet.

(Applied RLN is a separate one and warrants its own thing, but I don't think we need to confuse this issue even more)

[staheri14]

Thanks @oskarth for the clarification and explanation, I have revised the description of this issue accordingly.
The current active milestones are now 1- testnet1) vacp2p/research#126 and 2) testnet2 vacp2p/research#129
Going to close this issue and follow our progress from within the identified milestones.