diff --git a/requirements/consensus.md b/requirements/consensus.md index 3407864..e3c2364 100644 --- a/requirements/consensus.md +++ b/requirements/consensus.md @@ -1,74 +1,61 @@ # Waku's Requirements on a Consensus Mechanism -Note: it is unclear at this stage whether those requirements should be fulfilled by Nomos, Status Network, both or neither. +**Note:** It is unclear at this stage whether these requirements should be fulfilled by Nomos, Status Network, both, or neither. -The attempt here is to list the limitation of the current usage of Smart Contract by Waku, -and how it impedes in delivery Waku's desired properties of privacy, anonymity and censorship-resistance. +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 +## RLN Protocol Dependency -Waku relies on RLN - Rate Limit Nullifier - protocol to rate limit message publishers in a permission-less, -censorship-resistant and privacy-preserving manner (unlinkability between wallet address and messages, and between separate messages). +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 `root` of the tree is used for incoming message validation (proof verification), -And the Merkle proof for proof generation (sending messages). -`root` and `getMerkeProof` are ABI available on RLN EVM smart contract. -Note that the users' RLN identity (commitment) is needed when calling `getMerkleProof`. +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 nodes in the Waku network must behave similarly in terms of message validation, to ensure the network does not split at the libp2p-gossipsub layer. -Which means there needs to be consensus on what the Merkle tree is, so that the same validation rules apply across the network. +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 help ensure it happens, range validation is used: -a node verify messages against the current root, and a set of previous roots. In case the message proof was generated on a previous (recent) root. +To achieve this, range validation is employed: a node verifies messages against the current root and a set 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. -However, it does mean that a Waku needs to keep up to date with the root of the smart contract, which change any time someone registers or withdraws a membership. -On a L2, this may happen every couple of seconds. -Making Waku a heavy user of Web3 RPC API. +**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. -To remediate to this, we intend to improve the smart contract and make available a set of the previous `root`. -This will enable less frequent RPC usage, to a point. The scalability of this strategy is yet to be defined. +*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 messages without forwarding them (unlike relays, which must validate before propagation). -Note that using event subscription is also an option to reduce RPC calls. -We moved away from this due to unstability encountered with RPC providers (shift from WebSocket to http long polling), -we may review when migrating to the Status Network, as we'll have a closer relation with RPC providers. +### Deposits and RLN Entrypoints -Note that the above mainly applies for Waku Relay nodes (in the cloud, on a laptop). -Edge nodes (mobile, browser), still needs frequent RPC access. -But to a lesser degree as the volume of messages is reduced, and message verification are not as time constraint as messages are not being forwarded. -(a relay node need to validate messages before forwarding aka relaying them). +While RLN mitigates network DoS attacks by limiting message propagation, the smart contract itself requires protection against membership influx surges. Proposed strategies include: -### Deposits and Other RLN Entrypoints +- zk-based proof-of-humanity protocols (e.g., zkPassport) +- On-chain heuristics (e.g., Karma, ENS, or POAP ownership) -While RLN protects the network from DoS, by limiting the number of messages propagated, -the smart contract needs to be protected from large influx of membership. +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. -The intent is to develop a variety of strategies, such as usage of zk PoH protocols (e.g. zkPassport) or other onchain heuristics (e.g Karma, ENS or POAP ownership). +## Waku’s Desired Privacy Properties -The first iteration is an ERC-20 deposit: The user needs to deposit an amount of DAI that is proportional to the rate limit they desired. -The DAI is locked in for the membership length (e.g. 6 or 12 months), and can refunded after expiry. +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). -### Waku Desired Privacy Properties +## Risks of Current Implementation -A note on the privacy that Waku brings, or intends to: - -Participation anonymity within the Waku network: -While it is possible for an observer to know that a given IP uses Waku, what Waku app they use (assuming usage of a common network) is not revealed. - -Receiver anonymity: An external observer cannot determine what specific messages a Waku user (aka IP) are interested. -Sender anonymity (wip): An external observer cannot determine what specific messages a Waku user aka IP has sent. -Message relation: An external observer cannot determine whether two messages are related, sent by the same user or for the same receiver. -Wallet to message un-linkability: An external observer, or RPC API endpoint, cannot link messages with a specific wallet address (eg used to insert RLN membership). - -### Risks - -In summary, the risks of using an EVM smart contract with a Web3 RPC API endpoint are as follows: - -- RPC API queries and scalability: Every application using Waku needs frequent access to a Web3 RPC API, especially relay node. This includes your average desktop app user. -- Smart contract censorship via Web3 RPC API: blocking access to the RLN smart contract by major RPC API providers would make create an effective outage on the Waku network. -- Privacy IP<>Wallet: By needing access to a smart contract, there is risk for a users to reveal unintended PII such as wallet to IP relation. Do note that "IP X uses Waku" is something Waku itself does not protect against. -- Privacy Wallet<>Waku: By introducing a smart contract element on a transparent chain, a user using Waku (and RLN), will reveal that their wallet uses Waku. +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