diff --git a/vac/raw/semaphore-rln.md b/vac/raw/semaphore-rln.md new file mode 100644 index 0000000..67569dc --- /dev/null +++ b/vac/raw/semaphore-rln.md @@ -0,0 +1,198 @@ +--- +title: WAKU2-SEMAPHORE-RATE-LIMIT +name: Semaphore-based Rate Limiting for Waku +status: raw +category: Standards Track +tags: [waku/core-protocol] +editor: [Your Name] +contributors: +--- + +## Abstract + +This document specifies how the Semaphore zero-knowledge protocol can be used to implement rate-limiting functionality in Waku, either as an alternative to or alongside the existing Rate-Limiting Nullifier (RLN) mechanism. Semaphore provides a privacy-preserving way to enforce message rate limits while maintaining sender anonymity. This approach offers potential advantages in flexibility, scalability, and implementation complexity when compared to the current RLN implementation. + +## Background / Rationale / Motivation + +Waku currently uses the Rate-Limiting Nullifier (RLN) protocol as its primary mechanism for spam prevention in anonymous peer-to-peer settings. RLN is built on top of Semaphore but with additional components for rate limiting and slashing. While effective, the current implementation has some limitations: + +1. **Fixed Rate Limits**: The current RLN implementation in Waku enforces a global rate limit that is the same for all users. + +2. **Implementation Complexity**: The current RLN implementation involves complex components such as Shamir's Secret Sharing for slashing, making it potentially more difficult to maintain and extend. + +3. **Limited Flexibility**: The current architecture may not easily support dynamic rate limits or different rate-limiting strategies for different use cases. + +Semaphore, as a more fundamental primitive, provides an opportunity to implement rate limiting with greater flexibility while still preserving the privacy benefits needed for Waku protocols. + +## Theory / Semantics + +### Semaphore Overview + +Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send signals anonymously. It uses zero-knowledge proofs to verify membership in a Merkle tree without revealing the member's identity. + +The key components of Semaphore include: + +1. **Identity**: A user's private identity, typically consisting of a trapdoor and a nullifier +2. **Identity Commitment**: A public commitment of the user's identity added to the Merkle tree +3. **External Nullifier**: A value that prevents double-signaling for a given context +4. **Signal**: The actual data being transmitted anonymously + +### Semaphore-based Rate Limiting Approach + +This proposal outlines a more flexible approach to rate limiting using Semaphore: + +1. **Time-based External Nullifiers**: External nullifiers are generated based on time epochs. For example, each minute (or configurable time unit) generates a new external nullifier. + +2. **Customizable Rate Limits**: Different groups of users can have different rate limits enforced by Semaphore. + +3. **Scalable Implementation**: Allow for a simpler implementation that can be easily scaled according to network needs. + +### Differences from Current RLN Implementation + +The key differences from the current RLN implementation are: + +1. **Simplified Approach**: We use basic Semaphore properties without the additional layer of secret sharing for slashing. + +2. **Flexible Rate Limits**: Support for different rate limits for different user groups. + +3. **Deterministic Time Windows**: Rate limiting based on deterministic time windows rather than message sequence. + +## Wire Format Specification / Syntax + +### Message Format + +Messages using Semaphore-based rate limiting will contain the following fields: + +```protobuf +message SemaphoreRateLimitProof { + // The Merkle root of the group + bytes merkle_root = 1; + + // The external nullifier (derived from current time epoch) + bytes external_nullifier = 2; + + // The nullifier hash + bytes nullifier_hash = 3; + + // The zero-knowledge proof + bytes proof = 4; + + // Optional: Intended message rate limit (messages per epoch) + uint32 rate_limit = 5; + + // Optional: Group identifier + bytes group_id = 6; +} + +// Extend the existing WakuMessage +message WakuMessage { + // Existing fields... + + // Optional Semaphore rate limiting proof + SemaphoreRateLimitProof semaphore_proof = 7; +} +``` + +### Protocol Flow + +1. **Group Registration**: + - Users register their identity commitments to a Semaphore group + - Group parameters include the rate limit (messages per epoch) + - Multiple groups with different rate limits can exist simultaneously + +2. **Message Sending**: + - When sending a message, a user generates a current epoch external nullifier + - The user creates a zero-knowledge proof of their membership in the group + - The proof and associated data are attached to the Waku message + +3. **Message Verification**: + - Receiving nodes verify the Semaphore proof + - Nodes maintain a record of nullifier hashes seen for each epoch + - If a nullifier is reused within the same epoch more times than the rate limit allows, the message is rejected + +### Implementation Requirements + +Nodes implementing Semaphore-based rate limiting for Waku MUST: + +1. Maintain at least one Merkle tree of registered identity commitments +2. Track nullifier hashes for each time epoch to enforce rate limits +3. Verify Semaphore proofs attached to incoming messages +4. Reject messages that exceed their rate limit + +Nodes implementing Semaphore-based rate limiting for Waku SHOULD: + +1. Support multiple Semaphore groups with different rate limits +2. Implement a mechanism to garbage collect old nullifier records +3. Optimize proof verification to minimize performance impact + +## Integration with Existing Waku Protocols + +### Relay Integration + +Semaphore-based rate limiting can be integrated with Waku Relay protocol as a validation mechanism. Nodes can validate incoming messages against rate limits before relaying them to other peers. + +### Store Integration + +Waku Store nodes can implement Semaphore validation for queries to prevent spam. + +### Filter Integration + +Filter nodes can use Semaphore validation to ensure clients don't exceed subscription limits. + +### Compatibility with RLN + +This specification is designed to be compatible with the existing RLN implementation. Nodes can support both mechanisms simultaneously or use one based on configuration preferences. This allows for a smooth transition between mechanisms if desired. + +## Security/Privacy Considerations + +### Privacy Benefits + +Semaphore-based rate limiting preserves user privacy by: + +1. Not revealing the sender's identity when sending messages +2. Ensuring that messages cannot be linked to a specific user identity +3. Protecting against tracking across different content topics + +### Security Considerations + +Key security aspects to consider: + +1. **Collusion Resistance**: The system should be resistant to collusion between users to exceed rate limits. + +2. **Sybil Resistance**: The registration process must have sufficient barriers to prevent Sybil attacks. + +3. **Denial of Service Protection**: The verification of zero-knowledge proofs must be efficient enough to prevent computational DoS attacks. + +4. **Parameter Selection**: The choice of epoch duration and rate limits must balance between usability and spam prevention. + +5. **Time Synchronization**: Nodes must have reasonably synchronized clocks for epoch-based rate limiting to function properly. + +## Limitations + +1. **No Slashing Mechanism**: Unlike RLN, this approach doesn't inherently support slashing (economic penalization) of spammers. + +2. **Group Size Limits**: Very large Merkle trees may impact performance, potentially limiting the maximum group size. + +3. **Time Sensitivity**: The approach relies on time-based epochs, making it sensitive to clock synchronization issues. + +## Future Work + +1. **Dynamic Rate Limiting**: Implement mechanisms for dynamically adjusting rate limits based on network conditions. + +2. **Optional Slashing Layer**: Add an optional slashing mechanism for environments where economic penalties are desired. + +3. **Proof Aggregation**: Explore techniques to aggregate multiple Semaphore proofs to improve efficiency in high-volume scenarios. + +4. **Cross-Group Rate Limiting**: Develop mechanisms to enforce limits across multiple groups. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +1. [Semaphore Protocol](https://semaphore.appliedzkp.org/) +2. [Rate Limiting Nullifier Protocol](https://rate-limiting-nullifier.github.io/rln-docs/) +3. [Waku RLN Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md) +4. [Semaphore RLN, rate limiting nullifier for spam prevention](https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009) +5. [Strengthening Anonymous DoS Prevention with Rate Limiting Nullifiers in Waku](https://vac.dev/rlog/rln-anonymous-dos-prevention/) \ No newline at end of file