Milestone: RLN-Relay cross-client testnet

[staheri14]

Problem

We would ultimately like 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. This is to capture the necessary steps towards this goal.

Scope

This milestone is about the second testnet of waku-rln-relay which targets cross-client communication. In this testnet, we want to make js, go and nim chat2 clients communicate over a spam-protected content topic seemlessly. At the bare minimum, the cross-client testnet would mirror testnet1 except that js-chat2 go-chat2 would be also part of the testnet.

• [x] In order to get there, we need to make sure js-waku and Go-waku have feature parity with the current implementation of waku-rln-relay and chat2 i.e.,
  • [x] Have the essential logic (including proof generation and verification) implemented to support the current waku-rln-relay RFC. In go-waku, integration of zero-kit would be sufficient to support the core zk.
  • [x] Group management is handled on-chain and dynamically using the membership smart contract deployed on Goerli testnet
  • [x] Waku-rln-relay is integrated into chat app, so that users can run it in spam-protected mode over a specific content-topic
• (Scoped out) [ ] Support for key store for secure persistence of rln credentials (js/nim/go)
• (Scoped out) [ ] wallet integration to handle registration tx without users needing to expose their Ethereum account private keys (js/nim/go)
• [x] Preparing tutorials for js/go/nim chat2 clients on how to setup chat2 in spam-protected mode
• [ ] (a decision was made to put it on hold until rebranding happens) A writeup describing the goal of the cross-client testnet, the journey, future steps, studies around performance, relation to operator outreach
• [x] Some coordination tasks like setting up a discord channel, reaching out to interested parties to get involved in the dogfooding, etc.
• [x] Collecting feedbacks from the cross-client testnet and taking necessary actions/edits

Given that we are a bit short on time, we may consider the key store and wallet integration optional/nice-to-have for testnet2.

Risks and uncertainty

The only uncertainty is the expected deadline, given that everyone involved in this milestone is actively working on a couple of other tasks, we need to make sure the specified tasks are reasonable for the given timeline. I'd kindly ask @D4nte @richard-ramos to take a look and let me know if there is any concern about the timeline, or what is the minimum set of features feasible given the timeline.

Expected timeline: End of September prior to Devcon.

Acceptance criteria

Identified tasks to be done. The testnet2 is run, and feedbacks collected.

Out of scope

• Support of ERC20 as a payment method for rln-relay membership is out of the scope of this milestone.
• Merkle tree and zero-kit performance

Notes and links

Future steps

• Circuit audit
• RLN-Relay trusted setup

[staheri14]

cc: @oskarth Would you please have a look and let me know your thoughts? thanks

[oskarth]

In general it looks good!

I'd say another risk is that proofs aren't compatible for some reason with Circom/Zerokit across js-waku and nwaku (e.g.). One way to derisk this early is to make sure proofs generated in JS-world can be verified in nwaku e.g.

@D4nte @richard-ramos what are your thought on this?

For browser side of things we should be able to use a lot of work done in zk-kit and zkitter etc.

Merkle tree and zero-kit performance

I think to the extent this isn't blocking we can try to make sure Zerokit perf works OK. I guess incremental MT here is enough?

Re ERC20 and other contract things:

Considering it is different people working these things, I think we can treat ERC20 and fee as nice-to-haves, though not on critical path of milestone. I think it should be doable to have these done too assuming it is someone else working on it, and we don't have to directly use it for chat2.

Ditto getting smart contract spec to draft.

[fryorcraken]

js-waku RLN work: https://github.com/waku-org/js-rln/issues/1

Some comments:

Proof verification is not in the scope of the first deliverable for js-waku, focus is on generating proof. This enables a user to use an RLN web-chat to participate to RLN. Proof verification can come later:

• for security reason, to not have to trust store/filter node
• when using relay in the browser, but best if we fix relay scalability in the browser first.

We have put generate RLN credentials in the zerokit integration first (user story 1). Should we instead do proof generation first (using RLN credentials generated by nwaku)? Meaning swap user story 1 and 2?

We expect to use wallet API from the get go in js-waku (no handling of private key).

I am hoping we make the web UX good enough so that a guide is not necessary :)

[staheri14]

We have put generate RLN credentials in the zerokit integration first (user story 1). Should we instead do proof generation first (using RLN credentials generated by nwaku)? Meaning swap user story 1 and 2?

I'd say the current ordering makes sense and there is no need to swap. The zero-kit integration will provide 1) RLN credential generation and 2) proof generation and verification. Considering this, I believe they both are addressable as soon as zero-kit is integrated, hence they can be part of one user story. I am not sure how using nwaku for RLN credential generation can be of help.

[staheri14]

One minor point regarding @fryorcraken comment for those who have not been in our yesterday call, and that is

Proof verification is not in the scope of the first deliverable for js-waku,

Proof verification = spam protection The zkSNARKs proof verification logic will be available in js due to the zerokit integration, however, the js-waku node does not have to identify spam messages considering that it fetches messages via an intermediary e.g., a filter node or a store node which presumably must have filtered messages if being honest and running rln-relay in that specific topic.

[fryorcraken]

One minor point regarding @fryorcraken comment for those who have not been in our yesterday call, and that is

Proof verification is not in the scope of the first deliverable for js-waku,

Proof verification = spam protection The zkSNARKs proof verification logic will be available in js due to the zerokit integration, however, the js-waku node does not have to identify spam messages considering that it fetches messages via an intermediary e.g., a filter node or a store node which presumably must have filtered messages if being honest and running rln-relay in that specific topic.

Proof verification is user story 6. 4 & 5 are small app features. While we did not scope 6 for devcon, we should be able to achieve shortly after.

[staheri14]

Thank you everyone for your contribution to the second testnet, now we can officially conclude this milestone!