Milestone: Secure, sound and stateful waku-rln-relay

staheri14 commented 1 year ago

Problem

This milestone is focused on making waku-rln-relay nodes stateful and more secure.

Security Rln credential confidentiality: Rln credentials were previously stored in plaintext inside a txt file, which is clearly not secure. To achieve better security we need to ensure that rln credentials are protected and immune to unauthorized access. This can translate to different solutions for different clients. For example, we can benefit from a password-protected and encrypted rln credential file in Go and Nim waku. In contrast, in js-waku we can use a deterministic derivation function that computes the rln credentials from a user's web wallet.

Soundness Group state verification (Merkle root verification): We need to ensure membership proofs of the incoming messages are for the intended rln group and not any arbitrary one. Due to this, the Merkle root of the incoming messages should be verified against the node's local Merkle tree root. However, due to network delay, rln-relay nodes perceive the updates, not at the same time, thus they may fall behind the current group state and their proofs won't be verified by the other relayers. To account for such delays, 1) the Merkle tree root shall be updated on a per-block basis that is all the membership group updates in each Ethereum block are processed and applied to the Merkle tree in an atomic fashion 2) each node then keeps the roots of the last 5 processed blocks.

Statefullness Waku-rln-relay is stateless in two aspects: 1) the state of the group gets lost upon node restarts 2) the node cannot detect a disconnect from an eth client (while polling group events), and has no way to resume its state even after a reconnect. In a stateful mode, 1) the membership Merkle tree should be persisted and hence is available even after restart 2) a node should be able to detect disconnect from the eth client and recommence events polling from where it was left off.

Scope

List of issues:

[x] Support for password-protected and encrypted rln credentials in Nim-waku
[ ] Support for password-protected and encrypted rln credentials in Go-waku.
[ ] Support for password-protected and encrypted rln credentials or its equivalent in JS-waku. https://github.com/waku-org/js-rln/issues/28
[x] Updating membership Merkle tree on a per-block basis in Nim
[ ] Updating membership Merkle tree on a per-block basis in Go
[ ] Updating membership Merkle tree on a per block basis in Js
[ ] Adding MT persistence in zerokit
[ ] Detecting disconnect from eth client and resuming event listening from the most recent state in Nim
[ ] Detecting disconnect from eth client and resuming event listening from the most recent state in Go
[ ] Detecting disconnect from eth client and resuming event listening from the most recent state in Js
[ ] Dogfooding and collecting feedbacks

Risks and uncertainty

Not sure whether all three clients can progress with the same speed considering they may have other priorities.

(Optional) End of November is the expected/latest deadline for the Nim waku client. We can discuss the timeline of other clients and see what makes sense for them.

Acceptance criteria

All the tasks specified above should be addressed.

Out of scope

Slashing.

Notes and links

Some of the tasks related to the nwaku client are already captured in this issue https://github.com/status-im/nwaku/issues/1268

Future steps

Slashing implementation.

cc: @richard-ramos, @fryorcraken, @oskarth @s1fr0, @rymnc

oskarth commented 1 year ago

LGTM

s1fr0 commented 1 year ago

Looks feasible to me. I believe go-waku already supports password-encrypted RLN credentials in a format interchangeable with nwaku implementation. @richard-ramos could clarify better (we didn't test any cross-client credential exchange though).

fryorcraken commented 1 year ago

For js-waku, the first milestone sounds fine for end of November. However, the other milestone might be end of January instead (December is slow). This is also because there is unknows around ethersjs and also whether we should start to provide helper functions to interact with the smart contract (right now we use etherjs directly from the example).

fryorcraken commented 1 year ago

Tracking js-waku work with https://github.com/waku-org/js-rln/issues/28. I have a bunch of questions, please review.

staheri14 commented 1 year ago

For js-waku, the first milestone sounds fine for end of November. However, the other milestone might be end of January instead (December is slow). This is also because there is unknows around ethersjs and also whether we should start to provide helper functions to interact with the smart contract (right now we use etherjs directly from the example).

Thanks @fryorcraken for your response, by the the first milestone do you mean the security part?

fryorcraken commented 1 year ago

Thanks @fryorcraken for your response, by the the first milestone do you mean the security part?

Yes, tracked with https://github.com/waku-org/js-rln/issues/28

staheri14 commented 1 year ago

@fryorcraken The statefulness and soundness only makes sense if js-waku is to integrate the relay logic which is not the case right now, right? so the soundness will be already taken care of in the filter node to which the js node is connected (or is it only the case when using rln web chat?). Likewise, for the statefulness. The lack of these two features won't affect the interoperability of the js-waku with the Go and Nim given that js is gonna use a filter for connection to the network.

fryorcraken commented 1 year ago

Indeed, right now we haven't integrated RLN validation in Relay for JS.

For now the rln-js example uses light push and filter. While we hope the remote node would drop messages with invalid proof, we do check the proof locally.

I agree it won't affect interoperability and it may make sense to handle it "later" in JS and focus in being able to send messages with proof from JS for now.

staheri14 commented 1 year ago

@rymnc Do you already have a tracking issue for the following? I would like to open one if there isn't any

Detecting disconnect from eth client and resuming event listening from the most recent state in Nim

staheri14 commented 1 year ago

Below are the aspects to be examined in the current milestone:

Testing the encrypted credential at each client in isolation and identifying the bugs
Testing the exchangeability of the encrypted rln credentials between Go and Nim clients
Activating the Merkle tree root validation and making sure that messages can be correctly routed between nodes, including Go and Nim
Ensuring that a waku-rln-relay node can reconnect to an eth client when a disconnect happens and can resume fetching events from where it lefts off
Restarting waku-rln-relay nodes and making sure they can resume synchronization with the membership group state from where they left off

I believe we are ready for #1 and #2 in nwaku, @richard-ramos is the rln credential encryption in Go waku compatible with the nwaku implementation? Part 3 is done on the nwaku side, how about Go waku @richard-ramos? Part 4 is not yet started in nwaku, @rymnc can we get started on this? For part 5, @s1fr0 can you please let us know when can we expect to have persistence MT to be ready? how much work is left?

richard-ramos commented 1 year ago

is the rln credential encryption in Go waku compatible with the nwaku implementation?

It is now :) previously i had added the encryption mechanism only for the service node, but chat2 is now using the same encryption mechanism

Part 3 is done on the nwaku side (Activating the Merkle tree root validation), how about Go waku

Done too!

vacp2p / research