diff --git a/content/docs/rfcs/10/README.md b/content/docs/rfcs/10/README.md index bacadb5b..3a0664e5 100644 --- a/content/docs/rfcs/10/README.md +++ b/content/docs/rfcs/10/README.md @@ -124,7 +124,7 @@ Waku is using gossiping to disseminate messages throughout the network. See [11/WAKU2-RELAY](/spec/11) spec for more details. -For an experimental privacy-preserving economic spam protection mechanism, see [17/WAKU2-RLNRELAY](/spec/17). +For an experimental privacy-preserving economic spam protection mechanism, see [17/WAKU2-RLN-RELAY](/spec/17). See [23/WAKU2-TOPICS](/spec/23) for more information about recommended topic usage. @@ -373,7 +373,7 @@ This includes Waku v1 specs, as they are used for bridging between the two netwo |[14/WAKU2-MESSAGE](/spec/14)|✔|✔|✔|✔| |[15/WAKU2-BRIDGE](/spec/15)|✔||| |[16/WAKU2-RPC](/spec/16)|✔||| -|[17/WAKU2-RLNRELAY](/spec/17)|🚧||| +|[17/WAKU2-RLN-RELAY](/spec/17)|🚧||| |[18/WAKU2-SWAP](/spec/18)|🚧||| |[19/WAKU2-LIGHTPUSH](/spec/19)|✔|✔|✔\**|✔\**| |[21/WAKU2-FAULT-TOLERANT-STORE](/spec/21)|✔|✔|| @@ -407,7 +407,7 @@ The following features are currently experimental and under research and initial **Economic Spam resistance**: We aim to enable an incentivized spam protection technique to enhance `11/WAKU2-RELAY` by using rate limiting nullifiers. -More details on this can be found in [17/WAKU2-RLNRELAY](/spec/17). +More details on this can be found in [17/WAKU2-RLN-RELAY](/spec/17). In this advanced method, peers are limited to a certain rate of messaging per epoch and an immediate financial penalty is enforced for spammers who break this rate. **Prevention of Denial of Service (DoS) and Node Incentivization**: @@ -455,7 +455,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 14. [14/WAKU2-MESSAGE spec](/spec/14) -15. [14/WAKU2-RLNRELAY spec](/spec/17) +15. [17/WAKU2-RLN-RELAY spec](/spec/17) 16. [18/WAKU2-SWAP spec](/spec/18) diff --git a/content/docs/rfcs/11/README.md b/content/docs/rfcs/11/README.md index 8b4a73aa..1bcccc99 100644 --- a/content/docs/rfcs/11/README.md +++ b/content/docs/rfcs/11/README.md @@ -151,7 +151,7 @@ Spam protection is partly provided by GossipSub v1.1 through [scoring mechanism] At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score. `11/WAKU2-RELAY` aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers. In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate. -More details on this new technique can be found in [`17/WAKU-RLN-RELAY`](/spec/17). +More details on this new technique can be found in [`17/WAKU2-RLN-RELAY`](/spec/17). - Providing **Unlinkability**, **Integrity** and **Authenticity** simultaneously: diff --git a/content/docs/rfcs/17/README.md b/content/docs/rfcs/17/README.md index 0b53e575..6b0496c7 100644 --- a/content/docs/rfcs/17/README.md +++ b/content/docs/rfcs/17/README.md @@ -1,15 +1,16 @@ --- slug: 17 -title: 17/WAKU-RLN-RELAY +title: 17/WAKU2-RLN-RELAY name: Waku v2 RLN Relay status: draft tags: waku-core editor: Sanaz Taheri contributors: - Oskar Thorén + - Aaryamann Challani --- -The `17/WAKU-RLN-RELAY` protocol is an extension of `11/WAKU-RELAY` which additionally provides spam protection using [Rate Limiting Nullifiers (RLN)](/spec/32). +The `17/WAKU2-RLN-RELAY` protocol is an extension of `11/WAKU2-RELAY` which additionally provides spam protection using [Rate Limiting Nullifiers (RLN)](/spec/32). The security objective is to contain spam activity in a GossipSub network by enforcing a global messaging rate to all the peers. Peers that violate the messaging rate are considered spammers and their message is considered spam. @@ -35,7 +36,7 @@ We define an `epoch` as $\lceil$ `unix_time` / `period` $\rceil$. For example, i Note that `epoch` refers to epoch in RLN and not Unix epoch. This means a message can only be sent every period, where period is up to the application. See see section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible `period` value depending on the application. Peers subscribed to a spam-protected `pubsubTopic` are only allowed to send one message per `epoch`. -The higher-level layers adopting `17/WAKU-RLN-RELAY` MAY choose to enforce the messaging rate for `WakuMessages` with a specific `contentTopic` published on a `pubsubTopic`. +The higher-level layers adopting `17/WAKU2-RLN-RELAY` MAY choose to enforce the messaging rate for `WakuMessages` with a specific `contentTopic` published on a `pubsubTopic`. @@ -85,7 +86,7 @@ For more details about the proof generation check [RLN](/spec/32) The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`. The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. The proof generation also requires a set of public inputs which are: the Merkle tree root `merkle_root`, the current `epoch`, and the message for which the proof is going to be generated. -In `17/WAKU-RLN-RELAY`, the message is the concatenation of `WakuMessage`'s `payload` filed and its `contentTopic` i.e., `payload||contentTopic`. +In `17/WAKU2-RLN-RELAY`, the message is the concatenation of `WakuMessage`'s `payload` filed and its `contentTopic` i.e., `payload||contentTopic`. ## Group Synchronization @@ -110,6 +111,13 @@ If the `epoch` attached to the message is more than `max_epoch_gap` apart from t This is to prevent a newly registered peer from spamming the system by messaging for all the past epochs. `max_epoch_gap` is a system parameter for which we provide some recommendations in section [Recommended System Parameters](#recommended-system-parameters). +**Merkle Root Validation** +The routing peers MUST check whether the provided Merkle root in the `RateLimitProof` is valid. +It can do so by maintaining a local set of valid Merkle roots, which consist of `acceptable_root_window_size` past roots. +This allows peers which are not well connected to the network to be able to send messages, accounting for network delay. +This network delay is related to the nature of asynchronous network conditions, which means that peers see membership changes asynchronously, and therefore may have differing local Merkle trees. +See [Recommended System Parameters](#recommended-system-parameters) on choosing an appropriate `acceptable_root_window_size`. + **Proof Verification** The routing peers MUST check whether the zero-knowledge proof `proof` is valid. It does so by running the zk verification algorithm as explained in [RLN](/spec/32). @@ -181,15 +189,16 @@ The system parameters are summarized in the following table, and the recommended | Parameter | Description | | ----: |----------- | | `period` | the length of `epoch` in seconds | -| `staked_fund` | the amount of ether to be staked by peers at the registration | +| `staked_fund` | the amount of wei to be staked by peers at the registration | | `reward_portion` | the percentage of `staked_fund` to be rewarded to the slashers | | `max_epoch_gap` | the maximum allowed gap between the `epoch` of a routing peer and the incoming message | +| `acceptable_root_window_size` | The maximum number of past Merkle roots to store | ## Epoch Length A sensible value for the `period` depends on the application for which the spam protection is going to be used. For example, while the `period` of `1` second i.e., messaging rate of `1` per second, might be acceptable for a chat application, might be too low for communication among Ethereum network validators. One should look at the desired throughput of the application to decide on a proper `period` value. -In the proof of concept implementation of `17/WAKU-RLN-RELAY` protocol which is available in [nim-waku](https://github.com/status-im/nim-waku), the `period` is set to `1` second. +In the proof of concept implementation of `17/WAKU2-RLN-RELAY` protocol which is available in [nim-waku](https://github.com/status-im/nim-waku), the `period` is set to `1` second. Nevertheless, this value is also subject to change depending on user experience. ## Maximum Epoch Gap @@ -203,6 +212,18 @@ With a reasonable approximation of the preceding values, one can set `max_epoch `Network_Delay` and `Clock_Asynchrony` MUST have the same resolution as `period` . By this formulation, `max_epoch_gap` indeed measures the maximum number of `epoch`s that can elapse since a message gets routed from its origin to all the other peers in the network. +`acceptable_root_window_size` depends upon the underlying chain's average blocktime, `block_time` + +The lower bound for the `acceptable_root_window_size` SHOULD be set as $acceptable_root_window_size=(Network_Delay)/block_time$ + +`Network_Delay` MUST have the same resolution as `block_time`. + +By this formulation, `acceptable_root_window_size` will provide a lower bound of how many roots can be acceptable by a routing peer. + +The `acceptable_root_window_size` should indicate how many blocks may have been mined during the time it takes for a peer to receive a message. +This formula represents a lower bound of the number of acceptable roots. + + # Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). @@ -212,4 +233,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 1. [RLN documentation](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view) 2. [Public inputs to the RLN circuit](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Public-Inputs) 3. [Shamir secret sharing scheme used in RLN](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Linear-Equation-amp-SSS) -4. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers) \ No newline at end of file +4. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers) diff --git a/content/docs/rfcs/32/README.md b/content/docs/rfcs/32/README.md index 12d52f7a..8f6b6fe4 100644 --- a/content/docs/rfcs/32/README.md +++ b/content/docs/rfcs/32/README.md @@ -23,7 +23,7 @@ RLN guarantees a messaging rate is enforced cryptographically while preserving t A wide range of applications can benefit from RLN and provide desirable security features. For example, an e-voting system can integrate RLN to contain the voting rate while protecting the voters-vote unlinkability. Another use case is to protect an anonymous messaging system against DDoS and spam attacks by containing messaging rate of users. -This latter use case is explained in [17/Waku-RLN-Relay RFC](/spec/17). +This latter use case is explained in [17/WAKU2-RLN-RELAY RFC](/spec/17). # Flow diff --git a/content/menu/index.md b/content/menu/index.md index 952b4e6e..54493446 100644 --- a/content/menu/index.md +++ b/content/menu/index.md @@ -24,7 +24,7 @@ bookMenuLevels: 1 - [14/WAKU2-MESSAGE]({{< relref "/docs/rfcs/14/README.md" >}}) - [15/WAKU2-BRIDGE]({{< relref "/docs/rfcs/15/README.md" >}}) - [16/WAKU2-RPC]({{< relref "/docs/rfcs/16/README.md" >}}) - - [17/WAKU2-RLNRELAY]({{< relref "/docs/rfcs/17/README.md" >}}) + - [17/WAKU2-RLN-RELAY]({{< relref "/docs/rfcs/17/README.md" >}}) - [18/WAKU2-SWAP]({{< relref "/docs/rfcs/18/README.md" >}}) - [19/WAKU2-LIGHTPUSH]({{< relref "/docs/rfcs/19/README.md" >}}) - [21/WAKU2-FTSTORE]({{< relref "/docs/rfcs/21/README.md" >}})