# Privacy-preserving p2p economic spam protection

Below is the description of a **network-level spam protection** method using [rate-limiting nullifiers](https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009). 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](https://rfc.vac.dev/spec/17/) 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](https://github.com/libp2p/specs/issues/341).

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](https://github.com/status-im/nim-waku), Go: [Go-Waku](https://github.com/status-im/go-waku) and in JavaScript: [JS-Waku](https://github.com/status-im/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](https://rfc.vac.dev/spec/17/) 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](https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009).

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](https://rfc.vac.dev/spec/11/) 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](https://rfc.vac.dev/spec/11/#security-analysis) 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](https://rfc.vac.dev/spec/17/) 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](https://ethresear.ch/u/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](https://sugared-hospital-6a3.notion.site/RLN-libp2p-protocol-and-usecases-6c82036957df41c38897bfe38e0cff02).

The private messaging application of [Status](https://status.im/) 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