logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-04 07:03:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #24 from waku-org/fix-links

Browse Source 
Fix Broken Links
This commit is contained in:
Jimmy Debe 2024-07-10 09:49:08 -04:00 committed by GitHub
commit 4fee41165e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
9 changed files with 104 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
informational/adversarial-models.md
View File

@ -13,7 +13,7 @@ This document lists adversarial models and attack-based threats relevant in the
## Motivation and Background ## Motivation and Background
Future versions of this document will serve as a comprehensive list of adversarial models and attack based threats relevant for [Waku v2](https://rfc.vac.dev/spec/10/). Future versions of this document will serve as a comprehensive list of adversarial models and attack based threats relevant for [Waku v2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md).
The main purpose of this document is being a linkable resource for specifications that address protection as well as mitigation mechanisms within the listed models. The main purpose of this document is being a linkable resource for specifications that address protection as well as mitigation mechanisms within the listed models.
Discussing and introducing countermeasures to specific attacks in specific models is out of scope for this document. Discussing and introducing countermeasures to specific attacks in specific models is out of scope for this document.
@ -73,7 +73,7 @@ We subdivide anonymity into _receiver anonymity_ and _sender anonymity_.
#### Receiver Anonymity #### Receiver Anonymity
We define receiver anonymity as _unlinkability of users' identities and the data they receive and/or related actions_. We define receiver anonymity as _unlinkability of users' identities and the data they receive and/or related actions_.
Because each [Waku message](https://rfc.vac.dev/spec/14/) is associated with a content topic, and each receiver is interested in messages with specific content topics, Because each [Waku message](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) is associated with a content topic, and each receiver is interested in messages with specific content topics,
receiver anonymity in the context of Waku corresponds to _subscriber-topic unlinkability_. receiver anonymity in the context of Waku corresponds to _subscriber-topic unlinkability_.
An example for the "action" part of our receiver anonymity definition is subscribing to a specific topic. An example for the "action" part of our receiver anonymity definition is subscribing to a specific topic.
@ -175,8 +175,8 @@ An entity with this power would, in practice, also have the power of the interna
## Attack-based Threats ## Attack-based Threats
The following lists various attacks against [Waku v2](https://rfc.vac.dev/spec/10/) protocols. The following lists various attacks against [Waku v2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) protocols.
If not specifically mentioned, the attacks refer to [Waku relay](https://rfc.vac.dev/spec/11/) and the underlying [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). If not specifically mentioned, the attacks refer to [Waku relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) and the underlying [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
We also list the weakest attacker model in which the attack can be successfully performed against. We also list the weakest attacker model in which the attack can be successfully performed against.
An attack is considered more powerful if it can be successfully performed in a weaker attacker model. An attack is considered more powerful if it can be successfully performed in a weaker attacker model.
@ -202,11 +202,11 @@ which in turn significantly increases the probability of attacker nodes ending u
This section lists attacks that aim at deanonymizing a message sender. This section lists attacks that aim at deanonymizing a message sender.
We assume that protocol messages are transmitted within a secure channel set up using the [Noise Protocol Framework](https://noiseprotocol.org/). We assume that protocol messages are transmitted within a secure channel set up using the [Noise Protocol Framework](https://noiseprotocol.org/).
For [Waku Relay](https://rfc.vac.dev/spec/11/) this means we only consider messages with version field `2`, For [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) this means we only consider messages with version field `2`,
which indicates that the payload has to be encoded using [Noise](../standards/application/noise.md). which indicates that the payload has to be encoded using [Noise](../standards/application/noise.md).
Note: The currently listed attacks are against libp2p in general. Note: The currently listed attacks are against libp2p in general.
The [data field of Waku v2 relay](https://rfc.vac.dev/spec/11/#message-fields) must be a [Waku v2 message](https://rfc.vac.dev/spec/14/). The [data field of Waku v2 relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md/#message-fields) must be a [Waku v2 message](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md).
The attacks listed in the following do not leverage that fact. The attacks listed in the following do not leverage that fact.
#### Replay Attack #### Replay Attack
@ -217,7 +217,7 @@ Waku relay is inherently safe against replay attack,
because GossipSub nodes, and by extension Waku relay nodes, because GossipSub nodes, and by extension Waku relay nodes,
feature a `seen` cache, and only relay messages they have not seen before. feature a `seen` cache, and only relay messages they have not seen before.
Further, replay attacks will be punished by [RLN Relay](https://rfc.vac.dev/spec/17/). Further, replay attacks will be punished by [RLN Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md).
#### Observing Messages #### Observing Messages
@ -287,8 +287,8 @@ which can be learned via _graph learning_ attacks.
In a flooding attack, attackers flood the network with bogus messages. In a flooding attack, attackers flood the network with bogus messages.
Waku employs [RLN Relay](https://rfc.vac.dev/spec/17/) as the main countermeasure to flooding. Waku employs [RLN Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md) as the main countermeasure to flooding.
[SWAP](https://rfc.vac.dev/spec/18/) also helps mitigating DoS attacks. [SWAP](https://github.com/vacp2p/rfc-index/blob/main/waku/deprecated/18/swap.md) also helps mitigating DoS attacks.
#### Black Hole (internal) #### Black Hole (internal)
@ -317,20 +317,20 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References ## References
- [10/WAKU2](https://rfc.vac.dev/spec/10/) - [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md)
- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/) - [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md)
- [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) - [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
- [Security](https://en.wikipedia.org/wiki/Information_security) - [Security](https://en.wikipedia.org/wiki/Information_security)
- [Authentication](https://en.wikipedia.org/wiki/Authentication) - [Authentication](https://en.wikipedia.org/wiki/Authentication)
- [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) - [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
- [Waku v2 message](https://rfc.vac.dev/spec/14/) - [Waku v2 message](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md)
- [Pluggable Transports](https://www.pluggabletransports.info/about/) - [Pluggable Transports](https://www.pluggabletransports.info/about/)
- [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack) - [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
- [Dolev-Yao model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model) - [Dolev-Yao model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model)
- [Noise Protocol Framework](https://noiseprotocol.org/) - [Noise Protocol Framework](https://noiseprotocol.org/)
- [Noise](../standards/application/noise.md) - [Noise](../standards/application/noise.md)
- [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/) - [17/WAKU-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md)
- [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18/) - [18/WAKU2-SWAP](https://github.com/vacp2p/rfc-index/blob/main/waku/deprecated/18/swap.md)
- [Dandelion++](https://arxiv.org/abs/1805.11060) - [Dandelion++](https://arxiv.org/abs/1805.11060)
- [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860) - [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860)
- [Waku Dandelion](../standards/application/dandelion.md)) - [Waku Dandelion](../standards/application/dandelion.md))

80
standards/application/dandelion.md
View File

@ -21,8 +21,8 @@ instead of disseminating messages as per usual relay operation.
## Background and Motivation ## Background and Motivation
[Waku Relay](https://rfc.vac.dev/spec/11/), offers privacy, pseudonymity, and a first layer of anonymity protection by design. [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md), offers privacy, pseudonymity, and a first layer of anonymity protection by design.
Being a modular protocol family [Waku v2](https://rfc.vac.dev/spec/10/) Being a modular protocol family [Waku v2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md)
offers features that inherently carry trade-offs as separate building blocks. offers features that inherently carry trade-offs as separate building blocks.
Anonymity protection is such a feature. Anonymity protection is such a feature.
The [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) The [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
@ -30,14 +30,14 @@ states that an anonymous communication network can only have two out of
low bandwidth consumption, low latency, and strong anonymity. low bandwidth consumption, low latency, and strong anonymity.
Even when choosing low bandwidth and low latency, which is the trade-off that basic Waku Relay takes, Even when choosing low bandwidth and low latency, which is the trade-off that basic Waku Relay takes,
better anonymity properties (even though not strong per definition) can be achieved by sacrificing some of the efficiency properties. better anonymity properties (even though not strong per definition) can be achieved by sacrificing some of the efficiency properties.
44/WAKU2-DANDELION specifies one such technique, and aims at gaining the best "bang for the buck" WAKU2-DANDELION specifies one such technique, and aims at gaining the best "bang for the buck"
in terms of efficiency paid for anonymity gain. in terms of efficiency paid for anonymity gain.
44/WAKU2-DANDELION is based on [Dandelion](https://arxiv.org/abs/1701.04439) WAKU2-DANDELION is based on [Dandelion](https://arxiv.org/abs/1701.04439)
and [Dandelion++](https://arxiv.org/abs/1805.11060). and [Dandelion++](https://arxiv.org/abs/1805.11060).
Dandelion is a message spreading method, which, compared to other methods, Dandelion is a message spreading method, which, compared to other methods,
increases the uncertainty of an attacker when trying to link messages to senders. increases the uncertainty of an attacker when trying to link messages to senders.
Libp2p gossipsub aims at spanning a [d-regular graph](https://en.wikipedia.org/wiki/Regular_graph) topology, with d=6 as the [default value](https://rfc.vac.dev/spec/29/#gossipsub-v10-parameters). Libp2p gossipsub aims at spanning a [d-regular graph](https://en.wikipedia.org/wiki/Regular_graph) topology, with d=6 as the [default value](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/29/config.md/#gossipsub-v10-parameters).
Messages are forwarded within this (expected) symmetric topology, Messages are forwarded within this (expected) symmetric topology,
which reduces uncertainty when trying to link messages to senders. which reduces uncertainty when trying to link messages to senders.
Dandelion breaks this symmetry by subdividing message spreading into a "stem" and a "fluff" phase. Dandelion breaks this symmetry by subdividing message spreading into a "stem" and a "fluff" phase.
@ -61,11 +61,11 @@ Further information on Waku anonymity may be found in our [Waku Privacy and Anon
## Theory and Functioning ## Theory and Functioning
44/WAKU2-DANDELION can be seen as an anonymity enhancing add-on to [Waku Relay](https://rfc.vac.dev/spec/11/) message dissemination, WAKU2-DANDELION can be seen as an anonymity enhancing add-on to [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) message dissemination,
which is based on [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). which is based on [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
44/WAKU2-DANDELION subdivides message dissemination into a "stem" and a "fluff" phase. WAKU2-DANDELION subdivides message dissemination into a "stem" and a "fluff" phase.
This specification is mainly concerned with specifying the stem phase. This specification is mainly concerned with specifying the stem phase.
The fluff phase corresponds to [Waku Relay](https://rfc.vac.dev/spec/11/), The fluff phase corresponds to [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md),
with optional fluff phase augmentations such as random delays. with optional fluff phase augmentations such as random delays.
Adding random delay in the fluff phase further reduces symmetry in dissemination patterns and Adding random delay in the fluff phase further reduces symmetry in dissemination patterns and
introduces more uncertainty for the attacker. introduces more uncertainty for the attacker.
@ -78,7 +78,7 @@ The Dandelion stem and fluff phases instantiate these concepts.
Future stem specifications might comprise: none (standard relay), Dandelion stem, Tor, and mix-net. Future stem specifications might comprise: none (standard relay), Dandelion stem, Tor, and mix-net.
As for future fluff specifications: none (standard relay), diffusion (random delays), and mix-net._ As for future fluff specifications: none (standard relay), diffusion (random delays), and mix-net._
Messages relayed by nodes supporting 44/WAKU2-DANDELION are either in stem phase or in fluff phase. Messages relayed by nodes supporting WAKU2-DANDELION are either in stem phase or in fluff phase.
We refer to the former as a stem message and to the latter as a fluff message. We refer to the former as a stem message and to the latter as a fluff message.
A message starts in stem phase, and at some point, transitions to fluff phase. A message starts in stem phase, and at some point, transitions to fluff phase.
Nodes, on the other hand, are in stem state or fluff state. Nodes, on the other hand, are in stem state or fluff state.
@ -92,14 +92,14 @@ are always sent as stem messages.
The stem phase can be seen as a different protocol, and messages are introduced into Waku Relay, and by extension gossipsub, The stem phase can be seen as a different protocol, and messages are introduced into Waku Relay, and by extension gossipsub,
once they arrive at a node in fluff state for the first time. once they arrive at a node in fluff state for the first time.
44/WAKU2-DANDELION uses [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) as the protocol for relaying stem messages. WAKU2-DANDELION uses [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) as the protocol for relaying stem messages.
There are no negative effects on gossipsub peer scoring, There are no negative effects on gossipsub peer scoring,
because Dandelion nodes in _stem state_ still normally relay Waku Relay (gossipsub) messages. because Dandelion nodes in _stem state_ still normally relay Waku Relay (gossipsub) messages.
## Specification ## Specification
Nodes $v$ supporting 44/WAKU2-DANDELION MUST either be in stem state or in fluff state. Nodes $v$ supporting WAKU2-DANDELION MUST either be in stem state or in fluff state.
This does not include relaying messages originated in $v$, for which $v$ SHOULD always be in stem state. This does not include relaying messages originated in $v$, for which $v$ SHOULD always be in stem state.
### Choosing the State ### Choosing the State
@ -114,18 +114,18 @@ corresponding to 10 minute epochs.
### Stem State ### Stem State
On entering stem state, On entering stem state,
nodes supporting 44/WAKU2-DANDELION MUST randomly select two nodes for each pubsub topic from the respective gossipsub mesh node set. nodes supporting WAKU2-DANDELION MUST randomly select two nodes for each pubsub topic from the respective gossipsub mesh node set.
These nodes are referred to as stem relays. These nodes are referred to as stem relays.
Stem relays MUST support [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/). Stem relays MUST support [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md).
If a chosen peer does not support [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), If a chosen peer does not support [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md),
the node SHOULD switch to fluff state. the node SHOULD switch to fluff state.
(We may update this strategy in future versions of this document.) (We may update this strategy in future versions of this document.)
Further, the node establishes a map that maps each incoming stem connection Further, the node establishes a map that maps each incoming stem connection
to one of its stem relays chosen at random (but fixed per epoch). to one of its stem relays chosen at random (but fixed per epoch).
Incoming stem connections are identified by the [Peer IDs](https://docs.libp2p.io/concepts/peers/#peer-id/) Incoming stem connections are identified by the [Peer IDs](https://docs.libp2p.io/concepts/peers/#peer-id/)
of peers the node receives [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) messages from. of peers the node receives [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) messages from.
Incoming [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) connections from peers that do not support 44/WAKU2-DANDELION are identified and mapped in the same way. Incoming [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) connections from peers that do not support WAKU2-DANDELION are identified and mapped in the same way.
This makes the protocol simpler, increases the anonymity set, and offers Dandelion anonymity properties to such peers, too. This makes the protocol simpler, increases the anonymity set, and offers Dandelion anonymity properties to such peers, too.
The node itself is mapped in the same way, so that all messages originated by the node are relayed via a per-epoch-fixed Dandelion relay, too. The node itself is mapped in the same way, so that all messages originated by the node are relayed via a per-epoch-fixed Dandelion relay, too.
@ -133,7 +133,7 @@ The node itself is mapped in the same way, so that all messages originated by th
While in stem state, nodes MUST relay stem messages to the respective stem relay. While in stem state, nodes MUST relay stem messages to the respective stem relay.
Received fluff messages MUST be relayed as specified in the fluff state section. Received fluff messages MUST be relayed as specified in the fluff state section.
The stem protocol ([19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/)) is independent of the fluff protocol ([Waku Relay](https://rfc.vac.dev/spec/11/)). The stem protocol ([19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md)) is independent of the fluff protocol ([Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md)).
While in stem state, nodes MUST NOT gossip about stem messages, While in stem state, nodes MUST NOT gossip about stem messages,
and MUST NOT send control messages related to stem messages. and MUST NOT send control messages related to stem messages.
(An existing gossipsub implementation does _not_ have to be adjusted to not send gossip about stem messages, (An existing gossipsub implementation does _not_ have to be adjusted to not send gossip about stem messages,
@ -161,7 +161,7 @@ this regular forwarding already comprises random delays.
## Implementation Notes ## Implementation Notes
Handling of the 44/WAKU2-DANDELION stem phase can be implemented as an extension to an existing [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) implementation. Handling of the WAKU2-DANDELION stem phase can be implemented as an extension to an existing [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) implementation.
Fluff phase augmentations might alter gossipsub message dissemination (e.g. adding random delays). Fluff phase augmentations might alter gossipsub message dissemination (e.g. adding random delays).
If this is the case, they have to be implemented on the libp2p gossipsub layer. If this is the case, they have to be implemented on the libp2p gossipsub layer.
@ -182,22 +182,22 @@ The fail-safe mechanism specified in this document (proposed in the Dandelion pa
#### Attacker Model and Anonymity Goals #### Attacker Model and Anonymity Goals
44/WAKU2-DANDELION provides significant mitigation against mass deanonymization in the WAKU2-DANDELION provides significant mitigation against mass deanonymization in the
passive [scaling multi node model](../../informational/adversarial-models.md/#scaling-multi-node). passive [scaling multi node model](../../informational/adversarial-models.md/#scaling-multi-node).
in which the attacker controls a certain percentage of nodes in the network. in which the attacker controls a certain percentage of nodes in the network.
44/WAKU2-DANDELION provides significant mitigation against mass deanonymization WAKU2-DANDELION provides significant mitigation against mass deanonymization
even if the attacker knows the network topology, i.e. the anonymity graph and the relay mesh graph. even if the attacker knows the network topology, i.e. the anonymity graph and the relay mesh graph.
Mitigation in stronger models, including the _active scaling multi-node_ model, is weak. Mitigation in stronger models, including the _active scaling multi-node_ model, is weak.
We will elaborate on this in future versions of this document. We will elaborate on this in future versions of this document.
44/WAKU2-DANDELION does not protect against targeted deanonymization attacks. WAKU2-DANDELION does not protect against targeted deanonymization attacks.
#### Non-Dandelion Peers #### Non-Dandelion Peers
Stem relays receiving messages can either be in stem state or in fluff state themselves. Stem relays receiving messages can either be in stem state or in fluff state themselves.
They might also not support 44/WAKU2-DANDELION, They might also not support WAKU2-DANDELION,
and interpret the message as classical [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), and interpret the message as classical [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md),
which effectively makes them act as fluff state relays. which effectively makes them act as fluff state relays.
While such peers lower the overall anonymity properties, While such peers lower the overall anonymity properties,
the [Dandelion++ paper](https://arxiv.org/abs/1805.11060) the [Dandelion++ paper](https://arxiv.org/abs/1805.11060)
@ -218,7 +218,7 @@ Generally, there are several design choices to be made for the stem phase of a D
#### Bound Stem Length #### Bound Stem Length
Choosing $q = 0.2$, 44/WAKU2-DANDELION has an expected stem length of 5 hops, Choosing $q = 0.2$, WAKU2-DANDELION has an expected stem length of 5 hops,
Assuming $100ms$ added delay per hop, the stem phase adds around 500ms delay on average. Assuming $100ms$ added delay per hop, the stem phase adds around 500ms delay on average.
There is a possibility for the stem to grow longer, There is a possibility for the stem to grow longer,
@ -233,10 +233,10 @@ We will quantify the resulting loss of anonymity in future versions of this docu
#### Stem Relay Selection #### Stem Relay Selection
In its current version, 44/WAKU2-DANDELION nodes default to fluff state In its current version, WAKU2-DANDELION nodes default to fluff state
if the random stem relay selection yields at least one peer that does not support [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) (which is the stem protocol used in [44/WAKU2-DANDELION](https://rfc.vac.dev/spec/44/). if the random stem relay selection yields at least one peer that does not support [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) (which is the stem protocol used in WAKU2-DANDELION.
If nodes would reselect peers until they find peers supporting [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), If nodes would reselect peers until they find peers supporting [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md),
malicious nodes would get an advantage if a significant number of honest nodes would not support [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19). malicious nodes would get an advantage if a significant number of honest nodes would not support [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md).
Even though this causes messages to enter fluff phase earlier, Even though this causes messages to enter fluff phase earlier,
we choose the trade-off in favour of protocol stability and sacrifice a bit of anonymity. we choose the trade-off in favour of protocol stability and sacrifice a bit of anonymity.
(We will look into improving this in future versions of this document.) (We will look into improving this in future versions of this document.)
@ -245,7 +245,7 @@ we choose the trade-off in favour of protocol stability and sacrifice a bit of a
[Dandelion](https://arxiv.org/abs/1701.04439) and [Dandelion++](https://arxiv.org/abs/1805.11060) [Dandelion](https://arxiv.org/abs/1701.04439) and [Dandelion++](https://arxiv.org/abs/1805.11060)
assume adding random delays in the fluff phase as they build on Bitcoin diffusion. assume adding random delays in the fluff phase as they build on Bitcoin diffusion.
44/WAKU2-DANDELION (in its current state) allows for zero delay in the fluff phase and outsources fluff augmentations to dedicated specifications. WAKU2-DANDELION (in its current state) allows for zero delay in the fluff phase and outsources fluff augmentations to dedicated specifications.
While this lowers anonymity properties, it allows making Dandelion an opt-in solution in a given network. While this lowers anonymity properties, it allows making Dandelion an opt-in solution in a given network.
Nodes that do not want to use Dandelion do not experience any latency increase. Nodes that do not want to use Dandelion do not experience any latency increase.
We will quantify and analyse this in future versions of this specification. We will quantify and analyse this in future versions of this specification.
@ -254,7 +254,7 @@ We plan to add a separate fluff augmentation specification that will introduce r
Optimal delay times depend on the message frequency and patterns. Optimal delay times depend on the message frequency and patterns.
This delay fluff augmentation specification will be oblivious to the actual message content, This delay fluff augmentation specification will be oblivious to the actual message content,
because Waku Dandelion specifications add anonymity on the routing layer. because Waku Dandelion specifications add anonymity on the routing layer.
Still, it is important to note that [Waku2 messages](https://rfc.vac.dev/spec/14/#payloads) (in their current version) carry an originator timestamp, Still, it is important to note that [Waku2 messages](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md/#payloads) (in their current version) carry an originator timestamp,
which works against fluff phase random delays. which works against fluff phase random delays.
An analysis of the benefits of this timestamp versus anonymity risks is on our roadmap. An analysis of the benefits of this timestamp versus anonymity risks is on our roadmap.
@ -266,15 +266,15 @@ Note: Introducing random delays can have a negative effect on
#### Stem Flag #### Stem Flag
While 44/WAKU2-DANDELION without fluff augmentation does not effect Waku Relay nodes, While WAKU2-DANDELION without fluff augmentation does not effect Waku Relay nodes,
messages sent by nodes that only support [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) might be routed through a Dandelion stem without them knowing. messages sent by nodes that only support [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) might be routed through a Dandelion stem without them knowing.
While this improves anonymity, as discussed above, it also introduces additional latency and lightpush nodes cannot opt out of this. While this improves anonymity, as discussed above, it also introduces additional latency and lightpush nodes cannot opt out of this.
In future versions of this specification we might In future versions of this specification we might
- add a flag to [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/) indicating a message should be routed over a Dandelion stem (opt-in), or - add a flag to [14/WAKU2-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) indicating a message should be routed over a Dandelion stem (opt-in), or
- add a flag to [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/) indicating a message should _not_ be routed over a Dandelion stem (opt-out), or - add a flag to [14/WAKU2-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) indicating a message should _not_ be routed over a Dandelion stem (opt-out), or
- introducing a fork of [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) exclusively used for Dandelion stem. - introducing a fork of [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) exclusively used for Dandelion stem.
In the current version, we decided against these options in favour of a simpler protocol and an increased anonymity set. In the current version, we decided against these options in favour of a simpler protocol and an increased anonymity set.
@ -287,11 +287,13 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
- [Dandelion](https://arxiv.org/abs/1701.04439) - [Dandelion](https://arxiv.org/abs/1701.04439)
- [Dandelion++](https://arxiv.org/abs/1805.11060) - [Dandelion++](https://arxiv.org/abs/1805.11060)
- [multi-node (botnet) attacker model](../../informational/adversarial-models.md/#multi-node) - [multi-node (botnet) attacker model](../../informational/adversarial-models.md/#multi-node)
- [Waku Relay](https://rfc.vac.dev/spec/11/) - [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md)
- [Waku v2](https://rfc.vac.dev/spec/10/) - [Waku v2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md)
- [d-regular graph](https://en.wikipedia.org/wiki/Regular_graph) - [d-regular graph](https://en.wikipedia.org/wiki/Regular_graph)
- [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) - [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
- [Waku Privacy and Anonymity Analysis](https://vac.dev/wakuv2-relay-anon). - [Waku Privacy and Anonymity Analysis](https://vac.dev/wakuv2-relay-anon).
- [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860.pdf) - [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860.pdf)
- [Adversarial Models](https://rfc.vac.dev/spec/45/) - [Adversarial Models](../../informational/adversarial-models.md)
- [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/) - [14/WAKU2-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md)
- [29/WAKU-CONFIG](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/29/config.md)
- [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md)

5
standards/application/device-pairing.md
View File

@ -55,7 +55,7 @@ This protocol is designed in order to achieve two main security objectives:
The devices execute a custom handshake derived from `XX`, The devices execute a custom handshake derived from `XX`,
where they mutually exchange and authenticate their respective device static key where they mutually exchange and authenticate their respective device static key
by exchanging messages over the content topic with the following [format](https://rfc.vac.dev/spec/23/#content-topic-format) by exchanging messages over the content topic with the following [format](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md/#content-topic-format)
``` ```
contentTopic = /{application-name}/{application-version}/wakunoise/1/sessions_shard-{shard-id}/proto contentTopic = /{application-name}/{application-version}/wakunoise/1/sessions_shard-{shard-id}/proto
@ -369,7 +369,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
### Informative ### Informative
- [26/WAKU2-PAYLOAD](https://rfc.vac.dev/spec/35/#abnf) - [26/WAKU2-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md/#abnf)
- [format](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md/#content-topic-format)
- [The Double-Ratchet Algorithm](https://signal.org/docs/specifications/doubleratchet/) - [The Double-Ratchet Algorithm](https://signal.org/docs/specifications/doubleratchet/)
- [The Noise Protocol Framework specifications](http://www.noiseprotocol.org/noise.html) - [The Noise Protocol Framework specifications](http://www.noiseprotocol.org/noise.html)
- [IETF RFC 4648 - The Base16, Base32, and Base64 Data Encodings](https://datatracker.ietf.org/doc/html/rfc4648) - [IETF RFC 4648 - The Base16, Base32, and Base64 Data Encodings](https://datatracker.ietf.org/doc/html/rfc4648)

4
standards/application/noise-sessions.md
View File

@ -60,7 +60,7 @@ The above mechanism allows a Noise session to be marked as stale either privatel
depending if `Hash(session-id)` is sent on `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto` to the other party in encrypted form or not, respectively. depending if `Hash(session-id)` is sent on `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto` to the other party in encrypted form or not, respectively.
When a Noise session is publicly marked as stale, When a Noise session is publicly marked as stale,
network peers MAY discard all [stored](https://rfc.vac.dev/spec/13/) messages addressed to the content topic `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto`. network peers MAY discard all [stored](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md) messages addressed to the content topic `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto`.
In this the case and in order for parties to retrieve any eventually delayed message, In this the case and in order for parties to retrieve any eventually delayed message,
peers SHOULD wait a fixed amount of time before discarding stored messages corresponding to a stale Noise session. peers SHOULD wait a fixed amount of time before discarding stored messages corresponding to a stale Noise session.
@ -150,7 +150,7 @@ This session management mechanism is loosely based on [Signal's Sesame Algorithm
# References # References
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) - [13/WAKU2-STORE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md)
- [WAKU2-NOISE](./noise.md) - [WAKU2-NOISE](./noise.md)
- [The Noise Protocol Framework](http://www.noiseprotocol.org/noise.html) - [The Noise Protocol Framework](http://www.noiseprotocol.org/noise.html)
- [The Sesame Algorithm: Session Management for Asynchronous Message Encryption](https://signal.org/docs/specifications/sesame/) - [The Sesame Algorithm: Session Management for Asynchronous Message Encryption](https://signal.org/docs/specifications/sesame/)

24
standards/application/noise.md
View File

@ -6,11 +6,11 @@ editor: Giuseppe <giuseppe@status.im>
contributors: contributors:
--- ---
This specification describes how payloads of [Waku messages](https://rfc.vac.dev/spec/14/) with [version 2](https://rfc.vac.dev/spec/14/#version2) can be encrypted This specification describes how payloads of [Waku messages](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14) with [version 2](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14) can be encrypted
in order to achieve confidentiality, authenticity, and integrity in order to achieve confidentiality, authenticity, and integrity
as well as some form of identity-hiding on communicating parties. as well as some form of identity-hiding on communicating parties.
This specification extends the functionalities provided by [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/), This specification extends the functionalities provided by [26/WAKU-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md),
adding support to modern symmetric encryption primitives adding support to modern symmetric encryption primitives
and asymmetric key-exchange protocols. and asymmetric key-exchange protocols.
@ -58,7 +58,7 @@ We note that all [design requirements](#Design-requirements) on exchanged messag
corresponding to a total of 1 Round Trip Time communication _(1-RTT)_. corresponding to a total of 1 Round Trip Time communication _(1-RTT)_.
In particular, identity-hiding properties can be guaranteed only if the recommendation described in [After-handshake](#After-handshake) are implemented. In particular, identity-hiding properties can be guaranteed only if the recommendation described in [After-handshake](#After-handshake) are implemented.
In the following, we assume that communicating parties reciprocally know an initial [`contentTopic`](https://rfc.vac.dev/spec/14/#wakumessage) In the following, we assume that communicating parties reciprocally know an initial [`contentTopic`](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14/#wakumessage)
where they can send/receive the first handshake message(s). where they can send/receive the first handshake message(s).
We further assume that messages sent over a certain `contentTopic` can be efficiently identified by their intended recipients We further assume that messages sent over a certain `contentTopic` can be efficiently identified by their intended recipients
thanks to an arbitrary 16 bytes long `message-nametag` field embedded in the message payload thanks to an arbitrary 16 bytes long `message-nametag` field embedded in the message payload
@ -82,7 +82,7 @@ The symmetric primitives supported are:
## Specification ## Specification
When [14/WAKU-MESSAGE version](https://rfc.vac.dev/spec/14/#payload-encryption) is set to 2, When [14/WAKU-MESSAGE version](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14/#payload-encryption) is set to 2,
the corresponding `WakuMessage`'s `payload` will encapsulate the two fields `handshake-message` and `transport-message`. the corresponding `WakuMessage`'s `payload` will encapsulate the two fields `handshake-message` and `transport-message`.
The `handshake-message` field MAY contain The `handshake-message` field MAY contain
@ -218,26 +218,26 @@ by hashing the result of an ephemeral-ephemeral Diffie-Hellman exchange every 1-
## Backward Support for Symmetric/Asymmetric Encryption ## Backward Support for Symmetric/Asymmetric Encryption
It is possible to have backward compatibility to symmetric/asymmetric encryption primitives from [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/), It is possible to have backward compatibility to symmetric/asymmetric encryption primitives from [26/WAKU-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md),
effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](https://rfc.vac.dev/spec/14/#version1) in [version 2](https://rfc.vac.dev/spec/14/#version2). effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14/#version1) in [version 2](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14/#version2).
It suffices to extend the list of supported `protocol-id` to: It suffices to extend the list of supported `protocol-id` to:
- `254`: AES-256-GCM symmetric encryption; - `254`: AES-256-GCM symmetric encryption;
- `255`: ECIES asymmetric encryption. - `255`: ECIES asymmetric encryption.
and set the `transport-message` field to the [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26) `data` field, whenever these `protocol-id` values are set. and set the `transport-message` field to the [26/WAKU-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md) `data` field, whenever these `protocol-id` values are set.
Namely, if `protocol-id = 254, 255` then: Namely, if `protocol-id = 254, 255` then:
- `message-nametag`: is empty; - `message-nametag`: is empty;
- `handshake-message-len`: is set to `0`; - `handshake-message-len`: is set to `0`;
- `handshake-message`: is empty; - `handshake-message`: is empty;
- `transport-message`: contains the [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/) `data` field (AES-256-GCM or ECIES, depending on `protocol-id`); - `transport-message`: contains the [26/WAKU-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md) `data` field (AES-256-GCM or ECIES, depending on `protocol-id`);
- `transport-message-len` is set accordingly to `transport-message` length; - `transport-message-len` is set accordingly to `transport-message` length;
When a `transport-message` corresponding to `protocol-id = 254, 255` is retrieved, When a `transport-message` corresponding to `protocol-id = 254, 255` is retrieved,
it SHOULD be decoded as the `data` field in [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/) specification. it SHOULD be decoded as the `data` field in [26/WAKU-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md) specification.
## Appendix: Supported Handshakes Description ## Appendix: Supported Handshakes Description
@ -318,9 +318,9 @@ The main difference with `XX` is that Alice's and Bob's static keys, when transm
## References ## References
1. [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) 1. [5/SECURE-TRANSPORT](https://specs.status.im/spec/5)
2. [10/WAKU2](https://rfc.vac.dev/spec/10) 2. [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md)
3. [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26) 3. [26/WAKU-PAYLOAD](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/application/26/payload.md)
4. [14/WAKU-MESSAGE](https://rfc.vac.dev/spec/14/#version1) 4. [14/WAKU-MESSAGE](https://github.com/vacp2p/rfc-index/tree/main/waku/standards/core/14)
5. [Noise protocol](http://www.noiseprotocol.org/noise.html) 5. [Noise protocol](http://www.noiseprotocol.org/noise.html)
6. [Noise handshakes as key-exchange mechanism for Waku2](https://forum.vac.dev/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130) 6. [Noise handshakes as key-exchange mechanism for Waku2](https://forum.vac.dev/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130)
7. [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234) 7. [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234)

14
standards/application/tor-push.md
View File

@ -9,10 +9,10 @@ contributors:
## Abstract ## Abstract
This document extends the [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11), specifying Waku Tor Push, This document extends the [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md), specifying Waku Tor Push,
which allows nodes to push messages via Tor into the Waku relay network. which allows nodes to push messages via Tor into the Waku relay network.
Waku Tor Push builds on [46/GOSSIPSUB-TOR-PUSH](https://rfc.vac.dev/spec/46). Waku Tor Push builds on [GOSSIPSUB-TOR-PUSH](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/gossipsub-tor-push.md).
**Protocol identifier**: /vac/waku/relay/2.0.0 **Protocol identifier**: /vac/waku/relay/2.0.0
@ -22,13 +22,13 @@ This allows Waku relay nodes that are oblivious to Tor Push to process messages
## Functional Operation ## Functional Operation
In its current version, Waku Tor Push corresponds to [46/GOSSIPSUB-TOR-PUSH](https://rfc.vac.dev/spec/46) In its current version, Waku Tor Push corresponds to [GOSSIPSUB-TOR-PUSH](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/gossipsub-tor-push.md)
applied to [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/), applied to [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md),
instead of [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). instead of [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
## Security/Privacy Considerations ## Security/Privacy Considerations
see [46/GOSSIPSUB-TOR-PUSH](https://rfc.vac.dev/spec/46) see [GOSSIPSUB-TOR-PUSH](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/gossipsub-tor-push.md)
## Copyright ## Copyright
@ -36,7 +36,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References ## References
- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11) - [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md)
- [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) - [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
- [46/GOSSIPSUB-TOR-PUSH](https://rfc.vac.dev/spec/46) - [GOSSIPSUB-TOR-PUSH](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/gossipsub-tor-push.md)
- [Tor](https://www.torproject.org/) - [Tor](https://www.torproject.org/)

13
standards/core/enr.md
View File

@ -8,7 +8,7 @@ contributors:
## Abstract ## Abstract
This RFC describes the usage of the ENR (Ethereum Node Records) format for [10/WAKU2](https://rfc.vac.dev/spec/10/) purposes. This RFC describes the usage of the ENR (Ethereum Node Records) format for [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) purposes.
The ENR format is defined in [EIP-778](https://eips.ethereum.org/EIPS/eip-778) [[3]](#references). The ENR format is defined in [EIP-778](https://eips.ethereum.org/EIPS/eip-778) [[3]](#references).
This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR. This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR.
@ -41,7 +41,7 @@ Would carry some ambiguity: Is the certificate securing the websocket port valid
the ipv4 address? the ipv4 address?
the ipv6 address? the ipv6 address?
The [10/WAKU2](https://rfc.vac.dev/spec/10/) protocol family is built on the [libp2p](https://github.com/libp2p/specs) protocol stack. The [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) protocol family is built on the [libp2p](https://github.com/libp2p/specs) protocol stack.
Hence, it uses [multiaddr](https://github.com/multiformats/multiaddr) to format network addresses. Hence, it uses [multiaddr](https://github.com/multiformats/multiaddr) to format network addresses.
Directly storing one or several multiaddresses in the ENR would fix the issues listed above: Directly storing one or several multiaddresses in the ENR would fix the issues listed above:
@ -162,7 +162,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References ## References
- [1](https://github.com/status-im/nim-waku/pull/690) - [1](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md)
- [2](https://github.com/vacp2p/rfc/issues/462#issuecomment-943869940) - [2](https://github.com/status-im/nim-waku/pull/690)
- [3](https://eips.ethereum.org/EIPS/eip-778) - [3](https://github.com/vacp2p/rfc/issues/462#issuecomment-943869940)
- [4](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) - [4](https://eips.ethereum.org/EIPS/eip-778)
- [5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)

14
standards/core/incentivization.md
View File

@ -84,7 +84,7 @@ Note: this section may later be moved to Store RFC.
Store is one of Waku's request-response protocols. Store is one of Waku's request-response protocols.
A Store client queries the server for historic messages. A Store client queries the server for historic messages.
A Store server responds with a list of messages that pass the user's filter. A Store server responds with a list of messages that pass the user's filter.
See [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) for the definitions of `HistoryQuery` and `HistoryResponse`. See [13/WAKU2-STORE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md) for the definitions of `HistoryQuery` and `HistoryResponse`.
The PoC Store incentivization makes the following simplifying assumptions: The PoC Store incentivization makes the following simplifying assumptions:
@ -216,17 +216,17 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
### normative ### normative
- A high-level [incentivization outline](https://github.com/waku-org/research/blob/master/incentivization.md) - A high-level [incentivization outline](https://github.com/waku-org/research/blob/master/incentivization.md)
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) (for Store-specific sections) - [13/WAKU2-STORE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md) (for Store-specific sections)
### informative ### informative
RFCs of request-response protocols: RFCs of request-response protocols:
- [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12) - [12/WAKU2-FILTER](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/12/filter.md)
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) - [13/WAKU2-STORE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md)
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) - [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md)
RFCs of Relay and RLN-Relay: RFCs of Relay and RLN-Relay:
- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11) - [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md)
- [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17) - [17/WAKU2-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md)

21
standards/core/relay-sharding.md
View File

@ -11,7 +11,7 @@ contributors:
## Abstract ## Abstract
This document describes ways of sharding the [Waku relay](https://rfc.vac.dev/spec/11/) topic, This document describes ways of sharding the [Waku relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) topic,
allowing Waku networks to scale in the number of content topics. allowing Waku networks to scale in the number of content topics.
> _Note_: Scaling in the size of a single content topic is out of scope for this document. > _Note_: Scaling in the size of a single content topic is out of scope for this document.
@ -25,7 +25,7 @@ However, they do not scale to large traffic loads.
A single [libp2p gossipsub mesh](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#gossipsub-the-gossiping-mesh-router), A single [libp2p gossipsub mesh](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#gossipsub-the-gossiping-mesh-router),
which carries messages associated with a single pubsub topic, can be seen as a separate unstructured P2P network which carries messages associated with a single pubsub topic, can be seen as a separate unstructured P2P network
(control messages go beyond these boundaries, but at its core, it is a separate P2P network). (control messages go beyond these boundaries, but at its core, it is a separate P2P network).
With this, the number of [Waku relay](https://rfc.vac.dev/spec/11/) content topics that can be carried over a pubsub topic is limited. With this, the number of [Waku relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) content topics that can be carried over a pubsub topic is limited.
This prevents app protocols that aim to span many multicast groups (realized by content topics) from scaling. This prevents app protocols that aim to span many multicast groups (realized by content topics) from scaling.
This document specifies three pubsub topic sharding methods (with varying degrees of automation), This document specifies three pubsub topic sharding methods (with varying degrees of automation),
@ -35,7 +35,7 @@ This document also covers discovery of topic shards.
## Named Sharding ## Named Sharding
_Named sharding_ offers apps to freely choose pubsub topic names. _Named sharding_ offers apps to freely choose pubsub topic names.
It is RECOMMENDED for App protocols to follow the naming structure detailed in [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/). It is RECOMMENDED for App protocols to follow the naming structure detailed in [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md).
With named sharding, managing discovery falls into the responsibility of apps. With named sharding, managing discovery falls into the responsibility of apps.
From an app protocol point of view, a subscription to a content topic `waku2/xxx` on a shard named /mesh/v1.1.1/xxx would look like: From an app protocol point of view, a subscription to a content topic `waku2/xxx` on a shard named /mesh/v1.1.1/xxx would look like:
@ -82,7 +82,7 @@ an example for the 2nd shard in the global shard cluster:
`/waku/2/rs/0/2`. `/waku/2/rs/0/2`.
> _Note_: Because _all_ shards distribute payload defined in [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/) via [protocol buffers](https://developers.google.com/protocol-buffers/), > _Note_: Because _all_ shards distribute payload defined in [14/WAKU2-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) via [protocol buffers](https://developers.google.com/protocol-buffers/),
> the pubsub topic name does not explicitly add `/proto` to indicate protocol buffer encoding. > the pubsub topic name does not explicitly add `/proto` to indicate protocol buffer encoding.
> We use `rs` to indicate these are _relay shard_ clusters; further shard types might follow in the future. > We use `rs` to indicate these are _relay shard_ clusters; further shard types might follow in the future.
@ -102,7 +102,7 @@ so app protocols do not have to implement their own discovery method.
Nodes add information about their shard participation in their [WAKU2-ENR](./enr.md). Nodes add information about their shard participation in their [WAKU2-ENR](./enr.md).
Having a static shard participation indication as part of the ENR allows nodes Having a static shard participation indication as part of the ENR allows nodes
to discover peers that are part of shards via [33/WAKU2-DISCV5](https://rfc.vac.dev/spec/33/) as well as via DNS. to discover peers that are part of shards via [33/WAKU2-DISCV5](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/33/discv5.md) as well as via DNS.
> _Note:_ In the current version of this document, > _Note:_ In the current version of this document,
> sharding information is directly added to the ENR. > sharding information is directly added to the ENR.
@ -191,7 +191,7 @@ The shard to use is the modulo of the hash by the number of shards in the networ
### Content Topics Format for Autosharding ### Content Topics Format for Autosharding
Content topics MUST follow the format in [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topic-format). Content topics MUST follow the format in [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md/#content-topic-format).
In addition, a generation prefix MAY be added to content topics. In addition, a generation prefix MAY be added to content topics.
When omitted default values are used. When omitted default values are used.
Generation default value is `0`. Generation default value is `0`.
@ -242,7 +242,7 @@ but is planned to preserve the index range allocation.
Instead of adding the data to the ENR, it will treat each array index as a capability, Instead of adding the data to the ENR, it will treat each array index as a capability,
which can be hierarchical, having each shard in the indexed shard cluster as a sub-capability. which can be hierarchical, having each shard in the indexed shard cluster as a sub-capability.
When scaling to a very large number of shards, this will avoid blowing up the ENR size, and allows efficient discovery. When scaling to a very large number of shards, this will avoid blowing up the ENR size, and allows efficient discovery.
We currently use [33/WAKU2-DISCV5](https://rfc.vac.dev/spec/33/) for discovery, We currently use [33/WAKU2-DISCV5](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/33/discv5.md) for discovery,
which is based on Ethereum's [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). which is based on Ethereum's [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md).
While this allows to sample nodes from a distributed set of nodes efficiently and offers good resilience, While this allows to sample nodes from a distributed set of nodes efficiently and offers good resilience,
it does not allow to efficiently discover nodes with specific capabilities within this node set. it does not allow to efficiently discover nodes with specific capabilities within this node set.
@ -272,12 +272,13 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References ## References
- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/) - [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md)
- [Unstructured P2P network](https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks) - [Unstructured P2P network](https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks)
- [33/WAKU2-DISCV5](https://rfc.vac.dev/spec/33/) - [33/WAKU2-DISCV5](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/33/discv5.md)
- [WAKU2-ENR](./enr.md) - [WAKU2-ENR](./enr.md)
- [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/) - [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md)
- [Ethereum ENR sharding bit vector](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata) - [Ethereum ENR sharding bit vector](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata)
- [Ethereum discv5 specification](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md) - [Ethereum discv5 specification](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md)
- [Research log: Waku Discovery](https://vac.dev/wakuv2-apd) - [Research log: Waku Discovery](https://vac.dev/wakuv2-apd)
- [WAKU2-RELAY-STATIC-SHARD-ALLOC](../../informational/relay-static-shard-alloc.md) - [WAKU2-RELAY-STATIC-SHARD-ALLOC](../../informational/relay-static-shard-alloc.md)
- [14/WAKU2-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md)