logos-messaging/pm
1
0
Fork 0
mirror of https://github.com/logos-messaging/pm.git synced 2026-01-02 14:13:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

AI fixing up

Browse Source
This commit is contained in:
fryorcraken 2025-08-05 13:44:42 +10:00
parent 2fe5df6498
commit 7ca83d565b
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
1 changed files with 38 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
requirements/consensus.md
View File

@ -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