From cd6791e42a20acc866589d3fb87a0e13ca95e4ea Mon Sep 17 00:00:00 2001 From: sanaz Date: Tue, 25 Oct 2022 18:07:56 -0700 Subject: [PATCH] addresses editorial comments --- rln-research/2022-07-22-rln-relay-journey.md | 52 ++++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/rln-research/2022-07-22-rln-relay-journey.md b/rln-research/2022-07-22-rln-relay-journey.md index 9fcd960..e28a639 100644 --- a/rln-research/2022-07-22-rln-relay-journey.md +++ b/rln-research/2022-07-22-rln-relay-journey.md @@ -17,35 +17,35 @@ In this post, we would like to shed light on the current state of the research a # WAKU-RLN-RELAY: Why and How -**Why**: The WAKU-RLN-RELAY project has been started more than two years ago to protect the open p2p messaging protocol of [WAKU-RELAY](https://rfc.vac.dev/spec/11/) against spam and DDoS attacks. +**Why**: The WAKU-RLN-RELAY project was started more than two years ago to protect the open p2p messaging protocol of [WAKU-RELAY](https://rfc.vac.dev/spec/11/) against spam and DDoS attacks. However, the use case of WAKU-RLN-RELAY is not limited to the WAKU-RELAY protocol and can be adopted by any open p2p routing system. It is worth mentioning that WAKU-RELAY is a minor extension of [Libp2p Gossipsub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md), hence the spam protection property of WAKU-RLN-RELAY is directly applicable to the libp2p Gossipsub protocol too. -In the nutshell, spam protection is achieved by limiting the messaging rate of every network participant so that no user can flood the network with a large number of messages and congest/DDoS relayers. +In a nutshell, spam protection is achieved by limiting the messaging rate of every network participant so that no user can flood the network with a large number of messages and congest/DDoS relayers. One special focus of WAKU-RLN-RELAY is user privacy which is aligned with the WAKU-RELAY privacy objectives. That is, it does not rely on any personally identifiable information of users like IP address or peer ID to control their messaging rate. -This makes it superior in terms of privacy guarantees compared to the centralized system where users are asked to share some PII like phone number, or email address for network participation. -Moreover, WAKU-RLN-RELAY is superior to its privacy-preserving counterparts i.e., proof-of-work in terms of performance. -The computational overhead imposed by proof-of-work is not suitable for resource-limited devices like mobile phones whereas the computational overhead incurred by the WAKU-RLN-RELAY protocol is minimal and as of the time of this post is approximately less than half a second. +This makes it superior in terms of privacy guarantees compared to centralized systems where users are asked to share some PII like a phone number, or an email address for network participation. +Moreover, WAKU-RLN-RELAY is superior to existing privacy-preserving counterparts e.g., proof-of-work in terms of performance. +The computational overhead imposed by proof-of-work is not suitable for resource-limited devices like mobile phones whereas the computational overhead incurred by the WAKU-RLN-RELAY protocol is minimal and at the time of writing this post is approximately less than half a second. **How**: Network participants which want to send messages in the network should be registered in the RLN group. The state of the group is moderated by a smart contract which holds a list of enrolled members. Each participant has a secret identity key and registers a commitment of that to the membership smart contract and deposits some funds. -The key to withdraw the locked fund is the user's secret identity key, so if someone knows someone's secret identity key then it can take the associated fund. +The key to withdraw the locked funds is the user's secret identity key, so if someone knows someone else's secret identity key, they can withdraw the associated funds. Messaging rate is enforced per some time interval called an epoch. -For each epoch, the user sends a message by proving that it knows the opening to one of the commitments registered in the RLN group as well as it reveals a Shamir share of its secret id key. -The share is derived in such a way that two of such shares for the same epoch allow the construction of the corresponding secret id key. -The secret sharing has another element which is an application-defined identifier i.e., RLN identifier by which you can make the secret sharing unique to your application. -That is, if a user wants to use the same RLN membership credential for messaging in two or more different applications, then it can do so without being worried to get slashed by combining the shares of its identity key published in those applications. +For each epoch, the user sends a message by proving that it knows the opening to one of the commitments registered in the RLN group as well as it reveals a [Shamir](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)'s share of its secret id key. +The share is derived in such a way that two of them when computed in the same epoch, allow the construction of the corresponding secret id key. +Shares are computed using also an application-defined identifier i.e., the RLN identifier that binds them to the application employing RLN-RELAY. +That is, if a user wants to use the same RLN membership credential for messaging in two or more different applications, then they can do so without being worried to get slashed by combining the shares of its identity key published in those applications. ## Current State **Specifications**: The specification of the WAKU-RLN-RELAY protocol is currently in draft mode and available in [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/). -In a separate effort, as part of a collaboration with the PSE group, the specification of the RLN construct, as a stand-alone primitive, has been standardized and published in [32/RLN](https://rfc.vac.dev/spec/32/). +In a separate effort, as part of a collaboration with the PSE group, the specification of the RLN construct, as a stand-alone primitive, has been standardized and published in [32/RLN](https://rfc.vac.dev/spec/32/). -**Academic publications**: The results of this project are published as 2 academic research articles in prestigious conferences of ICDCS and DINPS 2022. +**Academic publications**: The results of this project are published as 2 academic research articles in two prestigious conferences, namely, [ICDCS](https://icdcs2022.icdcs.org/programs/) and [DINPS](https://research.protocol.ai/sites/dinps/programme/) 2022. They are accessible at https://arxiv.org/pdf/2207.00117.pdf and https://ieeexplore.ieee.org/abstract/document/9912176/. @@ -53,7 +53,7 @@ They are accessible at https://arxiv.org/pdf/2207.00117.pdf and https://ieeexplo - Testnet1: In this testnet, we implemented the PoC of WAKU-RLN-RELAY in Nim and integrated it into a sample chat application. More on this can be found in [testnet1 tutorial](https://github.com/status-im/nwaku/blob/master/docs/tutorial/rln-chat2-live-testnet.md). The testnet launched successfully and we got great feedback from the participants to improve upon user experience and resolved identified concerns and comments. -- Testnet2: This testnet aimed to integrate WAKU-RLN-RELAY into all 3 waku clients namely, Nim-waku, Go-Waku, and js-Waku and test their interoperability over the waku network. +- Testnet2: This testnet aimed to integrate WAKU-RLN-RELAY into all 3 waku clients namely, Nim-waku (nwaku), Go-Waku, and js-Waku and test their interoperability over the waku network. All three clients consumed the [Zerokit RLN module](https://github.com/vacp2p/zerokit/tree/master/rln) to handle the zkSNARKs proof generation and verification logic. This testnet is still up and running and instructions on the participation can be found in the following tutorial: [WAKU-RLN-RELAY testnet2: cross-client](https://github.com/status-im/nwaku/blob/master/docs/tutorial/rln-chat-cross-client.md). Should you be interested in taking part in the testnet, or have any questions, let us know in our dedicated discord channel [WAKU-RLN-RELAY dogfooding](https://discord.com/channels/864066763682218004/945761301156753448). @@ -67,8 +67,8 @@ One of the driving factors of Zerokit is to facilitate the use of certain Zero K More on the Zerokit positioning is available in [Zerokit positioning](UAFvOj1tTQ6uW2li0ZeXfw). -**Incentivization**: Spam protection will not be realized unless with a sufficient number of relayers choose to run WAKU-RLN-RELAY and protect the p2p messaging network against spammers. -Since spam activities and DDoS attacks directly target and exhaust network resources, it is conceivable that relayers would be naturally incentivized to run WAKU-RLN-RELAY to save their local resources from being drained by attackers. +**Incentivization**: Spam protection will not be realized unless a sufficient number of relayers choose to run WAKU-RLN-RELAY and protect the p2p messaging network against spammers. +Since spam activities and DDoS attacks directly target and exhaust network resources, it is conceivable that relayers would be naturally incentivized to run WAKU-RLN-RELAY to prevent their local resources from being drained by attackers. Nevertheless, WAKU-RLN-RELAY comes with built-in economic incentives where relayers who detect spammers are rewarded with the ability to withdraw the spammer's staked funds from the membership contract. However, not every node gets to find a spammer and be rewarded for that. @@ -78,8 +78,8 @@ That is, a portion of the membership registration fee goes towards a non-refunda The distribution of the collected service fee is still a work in progress and its current state can be seen in the [rln contract repository](https://github.com/vacp2p/rln-contract). **Support for ERC20 tokens as RLN membership fee**: It is conceivable that many applications desire to have their tokens and want their RLN group membership fee to be paid in that token. -To enable so, we are working towards updating the RLN contract interface to support the ERC20 token for the membership fee. -The ERC20 support is in progress and its current state can be tracked in the [rln contract repository](https://github.com/vacp2p/rln-contract). +To enable this, we are working towards updating the RLN contract interface to support the ERC20 token for the membership fee. +The ERC20 support is in progress and its current state can be tracked in the [rln contract GitHub repository](https://github.com/vacp2p/rln-contract). **Evaluating storage overhead of membership Merkle tree**: In WAKU-RLN-RELAY, the relayers construct and maintain the membership Merkle tree locally. @@ -101,8 +101,8 @@ If you are interested in any of these, or if you have further research ideas, we * Compiling Zerokit to mobile architectures * Implementing a command-line interface for common operations of the Zerokit RLN module -**Next testnets**: Multiple other testnets are on the way one of which would be focused on secure slashing. -In that testnet, the goal is to build and examine the slashing part of WAKU-RLN-RELAY where network participants not only detect spam activities but also can slash spammers and claim their rewards from the contract. +**Next testnets**: Multiple other testnets are on the way, one of which would be focused on secure slashing. +In such testnet, the goal is to build and examine the slashing part of WAKU-RLN-RELAY where network participants not only detect spam activities but also can slash spammers and claim their rewards from the contract. Further testnets can be potentially on consuming and testing the new features of the RLN membership contract e.g., service fee option, and ERC20 integration. **Security audit**: We are planning to perform a security audit of the RLN membership group smart contract and the RLN module of the Zerokit lib. @@ -114,15 +114,15 @@ This will happen once they both get more mature in terms of functionality as wel While the storage overhead of Merkle tree is reasonable as discussed in the [WAKU-RLN-RELAY current state](#current-state), many applications may still wish to save that storage space in favor of other critical functionalities. To allow this, we are looking into a hybrid architecture in which only a subset of peers namely, super peers persist and maintain the membership Merkle tree. -Other peers namely light peers fetch their necessary information from the super peers via a req/response protocol. -Note that as in any req/reply protocol, privacy should be carefully addressed as the service providers may be able to infer the position of the requester's id commitment in the membership Merkle tree from the requests patterns. +Other peers namely light peers fetch their necessary information from the super peers via a request/response protocol. +Note that as in any request/response protocol, privacy should be carefully addressed as the service providers may be able to infer the position of the requester's id commitment in the membership Merkle tree from requests' patterns. -**Zero-entry**: Some applications may want to allow their users to benefit from a spam-protected network and publish messages without having any crypto account. -This can be realized through a req-reply protocol e.g., an extension of [WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/). +**Zero-entry**: Some applications may want to allow their users to benefit from a spam-protected network and publish messages without having any crypto assets. +This can be realized through a request/response protocol e.g., an extension of [WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/). That is, the lightpush service provider registers multiple accounts in the RLN group -hence, obtains a higher messaging rate i.e., one per membership. -Peers without RLN membership can then request the lightpush service provider to publish their messages using its batch of registered accounts. -This is one way to realize the zero-entry feature, and we haven't yet explored other possibilities. +in order to obtain a higher messaging rate i.e., one message per membership registration. +Peers without RLN membership can then request the lightpush service provider to publish their messages using its batch of registered identity commitments. +This is one way to realize the zero-entry feature, and other possibilities should be explored further. # Contact us If you are interested in being involved in the development or research side of WAKU-RLN-RELAY, please let us know: