mirror of https://github.com/vacp2p/rfc.git
feat(17/WAKU2-RLN-RELAY): multiple acceptable roots (#539)
* feat(17/WAKU2-RLN-RELAY): multiple acceptable roots * chore(17/WAKU2-RLN-RELAY): fix inconsistency with naming * fix(17/WAKU2-RLN-RELAY): waku-relay naming Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com> * chore(17/WAKU2-RLN-RELAY): naming Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com> * fix(17/WAKU2-RLN-RELAY): clear reasoning behind why nodes have diff roots * fix(17/WAKU2-RLN-RELAY): sembr and wording * chore(17/WAKU2-RLN-RELAY): s/merkle/Merkle/ and network delay * chore(17/WAKU2-RLN-RELAY): contributor notes * fix(17/WAKU2-RLN-RELAY): formula for window size * chore(17/WAKU2-RLN-RELAY): add explanation of formula * chore(17/WAKU2-RLN-RELAY): address review Co-authored-by: Sanaz Taheri <35961250+staheri14@users.noreply.github.com> * chore(17/WAKU2-RLN-RELAY): block_time var Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com> Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com> Co-authored-by: Sanaz Taheri <35961250+staheri14@users.noreply.github.com>
This commit is contained in:
Aaryamann Challani
GitHub
parent
977955ebfd
commit
c8e14ed836
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
<!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code -->
|
||||
|
||||
- Providing **Unlinkability**, **Integrity** and **Authenticity** simultaneously:
|
||||
|
|
|
|||
|
|
@ -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 <sanaz@status.im>
|
||||
contributors:
|
||||
- Oskar Thorén <oskar@status.im>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
---
|
||||
|
||||
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. <!-- TODO refer to RLN RFC for authPath def -->
|
||||
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)
|
||||
4. [RLN internal nullifier](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Nullifiers)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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" >}})
|
||||
|
|
|
|||
Loading…
Reference in New Issue