pm/requirements/consensus.md

# Waku's Requirements on a Consensus Mechanism

**Note:** It is unclear at this stage whether these requirements should be fulfilled by Nomos, Status Network, both, or neither.

This document outlines limitations in Waku's current reliance on smart contracts and explains how they impede the delivery of Waku's desired properties: privacy, anonymity, and censorship-resistance.

## RLN Protocol Dependency

Waku relies on the RLN (Rate Limit Nullifier) protocol to rate-limit message publishers in a permissionless, censorship-resistant, and privacy-preserving manner.
This ensures unlinkability between wallet addresses and messages, as well as between separate messages.

### RPC API Usage

Commitments are added to a Merkle tree. The tree’s `root` is used to validate incoming messages (proof verification), while Merkle proofs enable proof generation (for sending messages).
The `root` and `getMerkleProof` functions are available on the RLN EVM smart contract ABI. Note that a user’s RLN identity (commitment) is required when calling `getMerkleProof`.

All Waku network nodes must enforce identical message validation rules to prevent network splits at the libp2p-gossipsub layer.
This necessitates consensus on the Merkle tree’s state across the network.

To achieve this, a node verifies messages against the current root and a window of previous roots, accommodating proofs generated on recent prior roots.
However, this requires Waku nodes to constantly track the smart contract’s root, which updates whenever a user registers or withdraws membership.
On L2 networks, roots may change every few seconds, making Waku a heavy consumer of Web3 RPC APIs.

**Mitigation Strategy:**  
We intend to enhance the smart contract to expose a set of historical `root` values.
This would reduce RPC call frequency, though scalability remains unproven.
Event subscriptions (e.g., WebSocket) could also minimize RPC usage, but we abandoned this approach due to RPC provider instability (shift from WebSocket to HTTP long polling).
Re-evaluation may occur during migration to Status Network, given potential closer relation with RPC providers.

*Note:* These constraints primarily affect Waku Relay nodes (cloud/laptop-based).
Edge nodes (mobile/browser) require less frequent RPC access due to lower message volume and relaxed time constraints—since they verify only the small subset of messages of interest to them.

### Deposits and RLN Entrypoints

While RLN mitigates network DoS attacks by limiting message propagation, the smart contract itself requires protection against membership influx surges. Proposed strategies include:

- zk-based proof-of-humanity protocols (e.g., zkPassport)
- On-chain heuristics (e.g., Karma, ENS, or POAP ownership)

The initial implementation uses an ERC-20 deposit: users lock DAI proportional to their desired rate limit for a fixed membership period (e.g., 6–12 months). Deposits are refundable post-expiry.

## Waku’s Desired Privacy Properties

Waku aims to provide:
- **Participation anonymity:** Observers can detect Waku usage by an IP but cannot identify which Waku application is in use (assuming a shared network).
- **Receiver anonymity:** External observers cannot determine which specific messages a Waku user (IP) is interested in.
- **Sender anonymity (work in progress):** External observers cannot identify messages sent by a specific Waku user (IP).
- **Message relation unlinkability:** External observers cannot link messages as originating from the same user or targeting the same receiver.
- **Wallet-to-message unlinkability:** External observers or RPC endpoints cannot associate messages with specific wallet addresses (e.g., those used for RLN membership registration).

## Risks of Current Implementation

The use of EVM smart contracts with Web3 RPC API endpoints introduces critical risks:
- **RPC scalability burden:** All Waku applications—especially Relay nodes—require frequent Web3 RPC access. This affects even casual desktop users.
- **Smart contract censorship:** Major RPC providers blocking access to the RLN contract would cause a network-wide outage.
- **Privacy leak: IP-to-wallet linkage:** RPC interactions risk exposing unintended PII, such as correlating user IPs with wallet addresses. (Note: Waku does not conceal "IP X uses Waku" by design.)
- **Privacy leak: Wallet-to-Waku association:** Smart contract interactions on transparent chains publicly reveal that a wallet uses Waku via RLN.
- **Privacy leak: IP-to-RLN-credentials:** RPC interactions risk a given IP revealing their specific membership commitment. Note it is unclear how important this point is at this stage.

### FURPS

In summary, we could summarize Waku's needs for a consensus mechanism, due to RLN, as follows:

TODO



## de-MLS

TODO: This section will most likely be filled at a later stage in 2025.
We believe that de-MLS is likely to be the right technology to scale the Waku Chat SDK.
However, its implementation is not yet planned.

We already understand that message ordering for group management purposes is required,
and hence a consensus mechanism will be required.
It may be possible for such mechanism to be done within Waku.
Alternatively, it needs to be out-of-band, hence the present section.