jm-clius
commented
4 months ago @shash256 closing this, as I think we can create follow-up issues for any new features requested,
Closed jm-clius closed 4 months ago
jm-clius
commented
4 months ago @shash256 closing this, as I think we can create follow-up issues for any new features requested,
Description
The Waku Network's main DoS protection mechanism is rate-limiting nullifiers. RLN requires publishers to attach a valid proof to each published Waku Message. In order to attach a valid RLN proof to a message, the publisher needs an active on-chain RLN membership, requiring at least one registration transaction. For light clients or newcomers trialing the Waku Network, acquiring an RLN membership might be a prohibitive barrier of entry, even if the registration transaction costs are low. There may also be cases where an application provider want to use the Waku Network without the overhead of distributing memberships to all application users and want to opt for sharing an RLN membership between app instances.
Suggested Solution
A protocol that allows light clients to publish messages to the Waku Network via an intermediary service node and request the service node to attach a proof to the message on their behalf. The service node needs an active (preferably high-rate) RLN membership. Light clients already use lightpush protocol to request service nodes to publish to the Waku Network. This can simply be an extension to Lightpush where the service node also attaches an RLN proof.
Note on approach to RLN
Note that the most effective (and principled) approach to RLN is for each publishing node (whether full node or resource-restricted light client), to have their own RLN membership. With recent changes to the RLN contract it is now feasible for light clients to run full RLN (including proof generation and validation) with minimal resource requirements. There are also workflows where service nodes can register memberships on behalf of light clients, removing the complexity of light clients having to effect their own registration transaction. This self-sovereign usage of RLN should be our main aim for TWN.
RLN proofs as a service is merely an alternative service use case that also allows "free" usage of RLN (costs covered by the service nodes) and is therefore attractive to e.g. provide a free tier to publish to the Waku Network, provide free Status 1:1 chats (up to a certain capacity), etc. It may become an incentivised service in deployments where individual RLN memberships for app users do not make sense.
Acceptance Criteria