Privacy-preserving p2p economic spam protection

[staheri14]

Below is the description of a network-level spam protection method using rate-limiting nullifiers. Unlike libp2p peer scoring, this new method allows finding and eliminating spammers globally (and has other features which are explained next). The proof-of-concept of this method has been implemented and is actively being developed in WAKU2-RLN-RELAY which is a minor extension of libp2p GossipSub. This spam prevention method may also help with addressing the spam attacks against rendezvous points as mentioned in this libp2p issue [Rendezvous] Tracking issue on how to mitigate spam attacks.

More details follow.

We (the Vac team https://vac.dev/) are actively developing WAKU which is a stack of modular peer-to-peer and privacy preserving protocols for privacy preserving messaging systems. The implementation is available in Nim: Nim-Waku reposiroty, Go: Go-Waku and in JavaScript: JS-Waku.

We have been using libp2p and GossipSub; the transport layer of WAKU is a minor extension of the libp2p GossipSub. As part of our development, we have identified the need for a global (and privacy-preserving) p2p spam protection.
The current spam-protection method of libp2p i.e., peer scoring does not have global control over the network spammers. In peer scoring, each peer monitors and scores its own local connections and filters those with low scores. However, spammers would be still able to continue their activity by constantly switching their connections from one peer to another as soon their score drops the desired threshold. It is also subject to inexpensive attacks where the spammer can send bulk messages by deploying millions of bots.

In an attempt to provide global spam protection, we developed the proof-of-concept implementation of WAKU2-RLN-RELAY which is a thin layer on top of libp2p GossipSub and additionally features a privacy-preserving p2p economic spam protection relying on the novel construct of rate-limiting nullifier.

There are two major benefits in this new spam protection technique: 1- it allows global identification and removal of network spammers 2- it is privacy-preserving since there is no need to personally identifiable information e.g., email address, IP, etc. about peers to be able to identify and block spammers (below I will explain why the privacy aspect matters).

Please see below for more context.

Privacy-preserving messaging and the need for a privacy-preserving spam protection

Anonymity is one of the desired features in a privacy-preserving messaging system. Users wish to exchange messages without disclosing their identity and leaving a trace to their published messages. To address this need, we developed the privacy-preserving transport protocol of WAKU2-RELAY which is a minor extension of the libp2p GossipSub protocol and modifies it to achieve a higher level of anonymity. The modifications are about excluding personally identifiable information from libp2p Gossipsub protocol messages in order to hide the link between messages and their owners (the security analysis of our protocol, which also applies to libp2p Gossipsub protocol, is available in security analysis of WAKU2-RELAY and might be of interest for the community.)

Global spam protection in an anonymous and private transport protocol like WAKU2-RELAY is not as easy as in non-private counterparts. The reason is that messages are anonymous and not attributable to their origin, hence techniques like blocking messages based on their IP address or peer ID do not work. The proof-of-work technique, which prevents spam activity by lowering the messaging rate, is also computationally heavy and does not fit resource-restricted devices like mobile phones.

We have done research on this matter over the past year and encountered and resolved various blockers. The outcome of our research and development resulted in the proof-of-concept implementation of WAKU2-RLN-RELAY which provides privacy-preserving spam protection on top of WAKU2-RELAY (hence libp2p GossipSub).

How it works: The spam protection works by limiting the messaging rate of all the network participants (peers of the pubsub network). Peers that exceed the messaging rate are considered spammers and will be identified, financially punished, and removed from the system (so that they won't be able to message again even by switching their connections). Peers who find spammers will be rewarded as well. Spam protection does not rely on any personally identifiable information e.g., email address, IP of peers. Peers can message anonymously and yet will be caught and financially punished if they exceed the messaging rate.

Usecases

A p2p PubSub protocol that offers privacy and spam protection on the network level can be used as a building block for applications that need strong privacy and spam resilience.

Blagoj has a great post on the use-case of a gossipsub-rln libp2p protocol for Ethereum validators which you can read it in the following link: RLN libp2p protocol and usecases.

The private messaging application of Status is another consumer of such private and spam-resilient transport protocol. Status is already using the first version of WAKU.

Next Step

At this stage, we primarily want to share the current state of our efforts here.

Is there interest to upstream this as a libp2p spec?

Resources

1. Waku-rln-relay specs: https://rfc.vac.dev/spec/17/
2. Waku-rln-relay paper: https://github.com/vacp2p/research/blob/master/rln-research/Waku_RLN_Relay.pdf
3. Vac post on Waku-rln-relay: https://vac.dev/rln-relay
4. Nim-Waku implementation: https://github.com/status-im/nim-waku
5. js-Waku implementation: https://github.com/status-im/js-waku
6. Go-Waku implementation: https://github.com/status-im/go-waku
7. RLN Ethereum research post: https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009
8. RLN medium post: https://medium.com/privacy-scaling-explorations/rate-limiting-nullifier-a-spam-protection-mechanism-for-anonymous-environments-bbe4006a57d
9. RLN circuits: https://github.com/appliedzkp/rln
10. RLN circuits spec: https://hackmd.io/7GR5Vi28Rz2EpEmLK0E0Aw
11. RLN in Rust: https://github.com/kilic/rln

[mxinden]

Thank you for the detailed report @staheri14 and sorry for the late reply.

Do I understand correctly that a rate-limiting nullifier would depend on an external mechanism to enforce membership, i.e. that it would require an external mechanism to prevent sybil attacks?

Is there interest to upstream this as a libp2p spec?

I don't have enough context to judge how many use cases there would be for rate-limiting nullifiers across the libp2p landscape. Either way feel free to propose a Working Draft specification. Also adding @vyzo here as a Gossipsub expert.

[vyzo]

this is very interesting and i would certainly be interested in upstreaming it.

I think the best way to do it would be through a custom pluggable scoring function. We can do this if we turn peer scoring into an interface, which should be straightforward.

[staheri14]

Thanks @vyzo and @mxinden for you replies and positive feedback (sorry for my late reply)!

I think the best way to do it would be through a custom pluggable scoring function. We can do this if we turn peer scoring into an interface, which should be straightforward

The way that we currently have it implemented is through a pubsub topic validator through which messages that violate the messaging rate limit get blocked and won't be routed. We can also explore the use of the custom pluggable scoring function.

We will update you once the working draft gets ready!

[vyzo]

Actually a validator based implementation might be the simplest approach.
go-libp2p-pubsub already has support for multiple validators per topic internally, so this could coexist with existing validators very easily, and augment the score function protections.
Definitely worth exploring upstreaming within the library, as a predefined validator (or validator wrapper).

[b-d1]

Thank you for the detailed report @staheri14 and sorry for the late reply.

Do I understand correctly that a rate-limiting nullifier would depend on an external mechanism to enforce membership, i.e. that it would require an external mechanism to prevent sybil attacks?

Is there interest to upstream this as a libp2p spec?

I don't have enough context to judge how many use cases there would be for rate-limiting nullifiers across the libp2p landscape. Either way feel free to propose a Working Draft specification. Also adding @vyzo here as a Gossipsub expert.

I and few other people are currently working on ETH2 validator privacy (for the consensus layer messages and a separate side channel), and RLN seems to be a great fit for this. ETH2 uses gossipsub at its gossip domain (part of ETH2 networking stack).

I think gossipsub-rln would be very useful for applications that need anonymity and spam protection, that need to operate in decentralised manner.

@vyzo, @mxinden thanks for the feedback, we will be researching what's the best way for including gossipsub-rln (or the rln extension of gossipsub) as part of libp2p