You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, we have seen waku-rln-relay as a spam-protected routing protocol of the waku protocol stack, though, it is a limited view of this powerful scheme. The way that it is currently presented, it seems like an intertwined part of the waku code that only serves the Waku stack and is not reusable in any other projects unless they want to use waku. However, this view is not correct, since the rln-relay has a modular design and can live outside of the waku stack, and must be presented as a rate-limiting tool (further abstraction of the rln lib) to the developers and other projects. In the current implementation, the rln-rlay is a separate nim-module whose functions are properly called in different parts of the nwaku node life-cycle including as a topic validator. We would like to shed more light on this fact and present rln-relay as a reusable lib and tool and to do so, the following tasks are envisioned:
Creating a C API for the rln-relay in which all the zk details are abstracted away and a nice minimal interface concerning the rate-limiting logic is exposed to the developer. The code will live in the nim repo and we give a pointer to the nim repo as the host of the rln-relay modular lib. This task will correspond to a nwaku issue which will be linked later.
Creating a landing page for rln-relay to present the concept as well as to explore usecases of rln-relay in other existing projects and Blockchains e.g., Polkadot, Flow, Ethereum.
Writing a proposal on how to use rln-relay to enable Validator privacy in the Ethereum blockchain. This will turn into (potentially) a research post that may live in the Vac.dev or in the Ethereum research forum. Prior to the publication of the post, will get Blagoj, Barry, and Oskar reviews. (Update: after careful investigation and research, found out the rln can only be deployed for rate limiting in Eth privacy scenario if the messages are encrypted and not tied to their origin, a more detailed description of this is already shared with the relevant stakeholders)
The text was updated successfully, but these errors were encountered:
oskarth
changed the title
Milestone: Applied rln-relay (Waku-Rln-Relay as a stand-alone scheme)
Milestone: RLNlib - RLN-Relay as a standalone scheme
Aug 24, 2022
So far, we have seen waku-rln-relay as a spam-protected routing protocol of the waku protocol stack, though, it is a limited view of this powerful scheme. The way that it is currently presented, it seems like an intertwined part of the waku code that only serves the Waku stack and is not reusable in any other projects unless they want to use waku. However, this view is not correct, since the rln-relay has a modular design and can live outside of the waku stack, and must be presented as a rate-limiting tool (further abstraction of the rln lib) to the developers and other projects. In the current implementation, the rln-rlay is a separate nim-module whose functions are properly called in different parts of the nwaku node life-cycle including as a topic validator. We would like to shed more light on this fact and present rln-relay as a reusable lib and tool and to do so, the following tasks are envisioned:
The text was updated successfully, but these errors were encountered: