mirror of https://github.com/vacp2p/rfc-index.git
Update waku2.md
This commit is contained in:
Jimmy Debe
GitHub
parent
f7733cb7df
commit
53ade5283a
|
|
@ -3,40 +3,43 @@ slug: 10
|
|||
title: 10/WAKU2
|
||||
name: Waku v2
|
||||
status: draft
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
- Reeshav Khan <reeshav@status.im>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
Waku v2 is family of modular peer-to-peer protocols for secure communication.
|
||||
The protocols are designed to be secure, privacy-preserving, censorship-resistant and being able to run in resource restricted environments.
|
||||
At a high level, it implements Pub/Sub over [libp2p](https://github.com/libp2p/specs) and adds a set of capabilities to it.
|
||||
Waku v2 is a family of modular peer-to-peer protocols for secure communication.
|
||||
These protocols are designed to be secure, privacy-preserving,
|
||||
censorship-resistant and run in resource-restricted environments.
|
||||
At a high level, it implements a publish/subscribe, PubSub,
|
||||
messaging mechanism over [libp2p](https://github.com/libp2p/specs) and adds capabilities.
|
||||
|
||||
These capabilities are things such as:
|
||||
(i) retrieving historical messages for mostly-offline devices
|
||||
(ii) adaptive nodes, allowing for heterogeneous nodes to contribute to the network
|
||||
(iii) preserving bandwidth usage for resource-restriced devices
|
||||
- Retrieving historical messages for mostly-offline devices.
|
||||
- Adaptive nodes, allowing for heterogeneous nodes to contribute to the network.
|
||||
- Preserving bandwidth usage for resource-restriced devices.
|
||||
|
||||
This makes Waku ideal for running a p2p protocol on mobile and in similarly restricted environments.
|
||||
This makes Waku v2 ideal for running a p2p protocol on mobile devices and other similar restricted environments.
|
||||
|
||||
Historically, it has its roots in [6/WAKU1](../6/waku1.md),
|
||||
Historically, it has its roots in [Waku v1](/spec/6),
|
||||
which stems from [Whisper](https://eips.ethereum.org/EIPS/eip-627), originally part of the Ethereum stack.
|
||||
However, Waku v2 acts more as a thin wrapper for PubSub and has a different API.
|
||||
It is implemented in an iterative manner where initial focus is on porting essential functionality to libp2p.
|
||||
See [rough road map (2020)](https://vac.dev/waku-v2-plan) for more historical context.
|
||||
|
||||
## Motivation and goals
|
||||
## Motivation and Goals
|
||||
|
||||
Waku as a family of protocols is designed to have a set of properties that are useful for many applications:
|
||||
|
||||
1. **Useful for generalized messaging.**
|
||||
|
||||
Many applications require some form of messaging protocol to communicate between different subsystems or different nodes.
|
||||
This messaging can be human-to-human or machine-to-machine or a mix.
|
||||
This messaging can be human-to-human, machine-to-machine or a mix.
|
||||
Waku is designed to work for all these scenarios.
|
||||
|
||||
2. **Peer-to-peer.**
|
||||
|
|
@ -74,15 +77,17 @@ For example:
|
|||
- Stronger guarantees for spam protection vs economic registration cost
|
||||
|
||||
For more on the concept of adaptive nodes and what this means in practice,
|
||||
please see the [30/ADAPTIVE-NODES](../../../informational/30/adaptive-nodes.md) spec.
|
||||
please see the [30/ADAPTIVE-NODES](/spec/30) spec.
|
||||
|
||||
## Network interaction domains
|
||||
## Network Interaction Domains
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
|
||||
“MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
While Waku is best thought of as a single cohesive thing, there are three network interaction domains:
|
||||
While Waku v2 is best thought of as a single cohesive thing, there are three network interaction domains:
|
||||
|
||||
(a) gossip domain
|
||||
(b) discovery domain
|
||||
(c) req/resp domain
|
||||
(c) request/response domain
|
||||
|
||||
### Protocols and identifiers
|
||||
|
||||
|
|
@ -94,19 +99,19 @@ The current main [protocol identifiers](https://docs.libp2p.io/concepts/protocol
|
|||
3. `/vac/waku/filter/2.0.0-beta1`
|
||||
4. `/vac/waku/lightpush/2.0.0-beta1`
|
||||
|
||||
This is in addition to protocols that specify messages, payloads, and recommended usages.
|
||||
This is in addition to protocols that specify messages, payloads, and RECOMMENDED usages.
|
||||
Since these aren't negotiated libp2p protocols, they are referred to by their RFC ID.
|
||||
For example:
|
||||
|
||||
- [14/WAKU2-MESSAGE](../14/message.md) and [26/WAKU-PAYLOAD](../../application/26/payload.md) for message payloads
|
||||
- [23/WAKU2-TOPICS](../../../informational/23/topics.md) and [27/WAKU2-PEERS](../../../informational/27/peers.md) for recommendations around usage
|
||||
- [14/WAKU2-MESSAGE](/spec/14) and [26/WAKU2-PAYLOAD](/spec/26) for message payloads
|
||||
- [23/WAKU2-TOPICS](/spec/23) and [27/WAKU2-PEERS](/spec/27) for recommendations around usage
|
||||
|
||||
There are also more experimental libp2p protocols such as:
|
||||
|
||||
1. `/vac/waku/swap/2.0.0-beta1`
|
||||
2. `/vac/waku/waku-rln-relay/2.0.0-alpha1`
|
||||
|
||||
These protocols and their semantics are elaborated on in their own specs.
|
||||
These protocols and their semantics are elaborated on in their own specifications.
|
||||
|
||||
|
||||
### Use of libp2p and protobuf
|
||||
|
|
@ -120,17 +125,18 @@ This length integer is encoded as a [protobuf varint](https://developers.google.
|
|||
|
||||
Waku is using gossiping to disseminate messages throughout the network.
|
||||
|
||||
**Protocol identifier**: `/vac/waku/relay/2.0.0`
|
||||
**Protocol identifier***: `/vac/waku/relay/2.0.0`
|
||||
|
||||
See [11/WAKU2-RELAY](../11/relay.md) spec for more details.
|
||||
See [11/WAKU2-RELAY](/spec/11) spec for more details.
|
||||
|
||||
For an experimental privacy-preserving economic spam protection mechanism, see [17/WAKU2-RLN-RELAY](../17/rln-relay.md).
|
||||
For an experimental privacy-preserving economic spam protection mechanism, see [17/WAKU2-RLN-RELAY](/spec/17).
|
||||
|
||||
See [23/WAKU2-TOPICS](../../../informational/23/topics.md) for more information about recommended topic usage.
|
||||
See [23/WAKU2-TOPICS](/spec/23) for more information about the RECOMMENDED topic usage.
|
||||
|
||||
### Direct use of libp2p protocols
|
||||
|
||||
In addition to `/vac/waku/*` protocols, Waku v2 MAY directly use the following libp2p protocols:
|
||||
In addition to `/vac/waku/*` protocols,
|
||||
Waku v2 MAY directly use the following libp2p protocols:
|
||||
|
||||
* [libp2p ping protocol](https://docs.libp2p.io/concepts/protocols/#ping) with protocol id
|
||||
|
||||
|
|
@ -155,52 +161,55 @@ and
|
|||
|
||||
respectively, as basic means for capability discovery.
|
||||
These protocols are anyway used by the libp2p connection establishment layer Waku v2 is built on.
|
||||
We plan to introduce a new Vac capability discovery protocol with better anonymity properties and more functionality.
|
||||
We plan to introduce a new Waku capability discovery protocol with better anonymity properties and
|
||||
more functionality.
|
||||
|
||||
# Transports
|
||||
### Transports
|
||||
|
||||
Waku v2 is built in top of libp2p, and like libp2p it strives to be transport agnostic.
|
||||
We define a set of recommended transports in order to achieve a baseline of interoperability between clients.
|
||||
Waku v2 is built on top of libp2p, and like libp2p, it strives to be transport agnostic.
|
||||
We define a set of RECOMMENDED transports in order to achieve a baseline of interoperability between clients.
|
||||
|
||||
This section describes these recommended transports.
|
||||
Waku v2 node implementations SHOULD support the TCP transport.
|
||||
|
||||
Waku client implementations SHOULD support the TCP transport.
|
||||
Where TCP is supported, it MUST be enabled for both dialing and listening,
|
||||
even if other transports are available.
|
||||
|
||||
Where TCP is supported it MUST be enabled for both dialing and listening, even if other transports are available.
|
||||
Waku v2 nodes, whose environment do not allow use of TCP directly,
|
||||
MAY use other transports.
|
||||
|
||||
Waku v2 nodes where the environment do not allow to use TCP directly, MAY use other transports.
|
||||
|
||||
A Waku v2 node SHOULD support secure websockets for bidirectional communication streams, for example in a web browser context.
|
||||
A Waku v2 node SHOULD support secure websockets for bidirectional communication streams,
|
||||
for example in a web browser context.
|
||||
|
||||
A node MAY support unsecure websockets if required by the application or running environment.
|
||||
|
||||
|
||||
### Discovery domain
|
||||
|
||||
#### Discovery methods
|
||||
|
||||
Waku v2 can retrieve a list of nodes to connect to using DNS-based discovery as per [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459).
|
||||
While this is a useful way of bootstrapping connection to a set of peers,
|
||||
it MAY be used in conjunction with an [ambient peer discovery](https://docs.libp2p.io/concepts/publish-subscribe/#discovery) procedure to find still other nodes to connect to,
|
||||
it MAY be used in conjunction with an
|
||||
[ambient peer discovery](https://docs.libp2p.io/concepts/publish-subscribe/#discovery) procedure to find still other nodes to connect to,
|
||||
such as [Node Discovery v5](https://github.com/ethereum/devp2p/blob/8fd5f7e1c1ec496a9d8dc1640a8548b8a8b5986b/discv5/discv5.md).
|
||||
More ambient peer discovery methods are being tested for Waku v2,
|
||||
and will be specified for wider adoption.
|
||||
It is possible to bypass the discovery domain by specifying static nodes.
|
||||
A ambient peer discovery method used by Waku v2 is described in [33/WAKU2-DISCV5](/spec/33).
|
||||
A Waku v2 node MAY bypass the discovery domain by specifying static nodes.
|
||||
|
||||
#### Use of ENR
|
||||
|
||||
[31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md) describes the usage of [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778) for Waku v2 discovery purposes.
|
||||
It introduces two new ENR fields, `multiaddrs` and `waku2`, that a Waku v2 node MAY use for discovery purposes.
|
||||
These fields MUST be used under certain conditions, as set out in the spec.
|
||||
[31/WAKU2-ENR](/spec/31) describes the usage of [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778) for Waku v2 discovery purposes.
|
||||
It introduces two new ENR fields, `multiaddrs` and `waku2`,
|
||||
that a Waku v2 node MAY use for discovery purposes.
|
||||
These fields MUST be used under certain conditions, as set out in the specification.
|
||||
Both EIP-1459 DNS-based discovery and Node Discovery v5 operates on ENR,
|
||||
and it's reasonable to expect even wider utility for ENR in Waku v2 networks in future.
|
||||
|
||||
|
||||
### Request/Reply domain
|
||||
### Request/Response domain
|
||||
|
||||
In addition to the Gossip domain,
|
||||
Waku provides a set of Request/Reply protocols.
|
||||
They are primarily used in order to get Waku to run in resource restricted environments,
|
||||
Waku v2 provides a set of Request/Response protocols.
|
||||
They are primarily used in order to get Waku v2 to run in resource restricted environments,
|
||||
such as low bandwidth or being mostly offline.
|
||||
|
||||
#### Historical message support
|
||||
|
|
@ -208,85 +217,100 @@ such as low bandwidth or being mostly offline.
|
|||
**Protocol identifier***: `/vac/waku/store/2.0.0-beta4`
|
||||
|
||||
This is used to fetch historical messages for mostly offline devices.
|
||||
See [13/WAKU2-STORE spec](../13/store.md) spec for more details.
|
||||
See [13/WAKU2-STORE](/spec/13) specifiction for more details.
|
||||
|
||||
There is also an experimental fault-tolerant addition to the store protocol that relaxes the high availability requirement.
|
||||
See [21/WAKU2-FT-STORE](../../application/21/ft-store.md)
|
||||
An experimental fault-tolerant addition to the store protocol,
|
||||
as described in [21/WAKU2-FT-STORE](/spec/21), relaxes the high availability requirement.
|
||||
|
||||
#### Content filtering
|
||||
|
||||
**Protocol identifier***: `/vac/waku/filter/2.0.0-beta1`
|
||||
|
||||
This is used to make fetching of a subset of messages more bandwidth preserving.
|
||||
See [12/WAKU2-FILTER](../12/filter.md) spec for more details.
|
||||
See [12/WAKU2-FILTER](/spec/12) specification for more details.
|
||||
|
||||
#### Light push
|
||||
|
||||
**Protocol identifier***: `/vac/waku/lightpush/2.0.0-beta1`
|
||||
|
||||
This is used for nodes with short connection windows and limited bandwidth to publish messages into the Waku network.
|
||||
See [19/WAKU2-LIGHTPUSH](../19/lightpush.md) spec for more details.
|
||||
This is used for nodes with short connection windows and
|
||||
limited bandwidth to publish messages to the Waku network.
|
||||
See [19/WAKU2-LIGHTPUSH](/spec/19) specification for more details.
|
||||
|
||||
#### Other protocols
|
||||
|
||||
The above is a non-exhaustive list,
|
||||
and due to the modular design of Waku there may be other protocols here that provide a useful service to the Waku network.
|
||||
The above is a non-exhaustive list, and
|
||||
due to the modular design of Waku v2 there may be other protocols here that provide a useful service to the Waku network.
|
||||
|
||||
### Overview of protocol interaction
|
||||
|
||||
See the sequence diagram below for an overview of how different protocols interact.
|
||||
|
||||
|
||||
|
||||
|
||||
0. We have six nodes, A-F.
|
||||
We have six nodes, A-F.
|
||||
The protocols initially mounted are indicated as such.
|
||||
The PubSub topics `pubtopic1` and `pubtopic2` is used for routing and indicates that it is subscribed to messages on that topic for relay, see [11/WAKU2-RELAY](../11/relay.md) for details.
|
||||
Ditto for [13/WAKU2-STORE](../13/store.md) where it indicates that these messages are persisted on that node.
|
||||
The PubSub topics `pubTopic1` and `pubsubTopic2` is used for routing and
|
||||
indicates that it is subscribed to messages on that topic for relay,
|
||||
see [11/WAKU2-RELAY](/spec/11) for details.
|
||||
Ditto for [13/WAKU2-STORE](/spec/13),
|
||||
where it indicates that these messages are persisted on that node.
|
||||
|
||||
1. Node A creates a WakuMessage `msg1` with a ContentTopic `contentTopic1`.
|
||||
See [14/WAKU2-MESSAGE](../core/14/message.md) for more details.
|
||||
If WakuMessage version is set to 1, we use the [6/WAKU1](../6/waku1.md) compatible `data` field with encryption.
|
||||
See [7/WAKU-DATA](../../application/7/data.md) for more details.
|
||||
1. Node A creates a `WakuMessage` `msg1` with a ContentTopic `contentTopic1`.
|
||||
See [14/WAKU2-MESSAGE](/spec/14) for more details.
|
||||
If `WakuMessage` `version` is set to 1,
|
||||
we use the [6/WAKU1](/spec/6) compatible `data` field with encryption.
|
||||
See [7/WAKU-DATA](/spec/7) for more details.
|
||||
|
||||
2. Node F requests to get messages filtered by PubSub topic `pubtopic1` and ContentTopic `contentTopic1`.
|
||||
Node D subscribes F to this filter and will in the future forward messages that match that filter.
|
||||
See [12/WAKU2-FILTER](../12/filter.md) for more details.
|
||||
2. Node F requests to get messages filtered by PubSub topic `pubTopic1` and
|
||||
ContentTopic `contentTopic1`.
|
||||
Node D subscribes F to this filter and, in the future,
|
||||
will forward messages that match this filter.
|
||||
See [12/WAKU2-FILTER](/spec/12) for more details.
|
||||
|
||||
3. Node A publishes `msg1` on `pubtopic1` and subscribes to that relay topic pick it up.
|
||||
It then gets relayed further from B to D, but not C since it doesn't subscribe to that topic.
|
||||
See [11/WAKU2-RELAY](../11/relay.md).
|
||||
3. Node A publishes `msg1` on `pubTopic1` and
|
||||
subscribes to that pubsub topic so relay node B can receive it.
|
||||
It then gets relayed further from B to D, but
|
||||
not C since it doesn't subscribe to that pubsub topic.
|
||||
See [11/WAKU2-RELAY](/spec/11).
|
||||
|
||||
4. Node D saves `msg1` for possible later retrieval by other nodes.
|
||||
See [13/WAKU2-STORE](../13/store.md).
|
||||
See [13/WAKU2-STORE](/spec/13).
|
||||
|
||||
5. Node D also pushes `msg1` to F, as it has previously subscribed F to this filter.
|
||||
See [12/WAKU2-FILTER](../12/filter.md).
|
||||
See [12/WAKU2-FILTER](/spec/12).
|
||||
|
||||
6. At a later time, Node E comes online.
|
||||
It then requests messages matching `pubtopic1` and `contentTopic1` from Node D.
|
||||
Node D responds with messages meeting this (and possibly other) criteria. See [13/WAKU2-STORE](../13/store.md).
|
||||
Node D responds with messages meeting this (and possibly other) criteria.
|
||||
See [13/WAKU2-STORE](/spec/13).
|
||||
|
||||
## Appendix A: Upgradability and Compatibility
|
||||
### Appendix A: Upgradability and Compatibility
|
||||
|
||||
### Compatibility with Waku v1
|
||||
#### Compatibility with Waku v1
|
||||
|
||||
Waku v1 and Waku v2 are different protocols all together.
|
||||
They use a different transport protocol underneath; Waku v1 is devp2p RLPx based while Waku v2 uses libp2p.
|
||||
They use a different transport protocol underneath;
|
||||
Waku v1 is devp2p RLPx based while Waku v2 uses libp2p.
|
||||
The protocols themselves also differ as does their data format.
|
||||
Compatibility can be achieved only by using a bridge that not only talks both devp2p RLPx and libp2p, but that also transfers (partially) the content of a packet from one version to the other.
|
||||
Compatibility can be achieved only by using a bridge that not only talks both devp2p RLPx and libp2p, but
|
||||
that also transfers (partially) the content of a packet from one version to the other.
|
||||
|
||||
See [15/WAKU-BRIDGE](../15/bridge.md) for details on a bidirectional bridge mode.
|
||||
See [15/WAKU-BRIDGE](/spec/15) for details on a bidirectional bridge mode.
|
||||
|
||||
# Appendix B: Security
|
||||
### Appendix B: Security
|
||||
|
||||
Each protocol layer of Waku v2 provides a distinct service and is associated with a separate set of security features and concerns.
|
||||
Each protocol layer of Waku v2 provides a distinct service and
|
||||
is associated with a separate set of security features and concerns.
|
||||
Therefore, the overall security of Waku v2 depends on how the different layers are utilized.
|
||||
In this section, we overview the security properties of Waku v2 protocols against a static adversarial model which is described below.
|
||||
Note that a more detailed security analysis of each Waku protocol is supplied in its respective specification as well.
|
||||
In this section, we overview the security properties of Waku v2 protocols against a static adversarial model,
|
||||
which is described below.
|
||||
Note that a more detailed security analysis of each Waku v2 protocol is supplied in its respective specification as well.
|
||||
|
||||
## Primary Adversarial Model
|
||||
#### Primary Adversarial Model
|
||||
|
||||
In the primary adversarial model, we consider adversary as a passive entity that attempts to collect information from others to conduct an attack,
|
||||
In the primary adversarial model,
|
||||
we consider adversary as a passive entity that attempts to collect information from others to conduct an attack,
|
||||
but it does so without violating protocol definitions and instructions.
|
||||
|
||||
The following are **not** considered as part of the adversarial model:
|
||||
|
|
@ -295,61 +319,73 @@ The following are **not** considered as part of the adversarial model:
|
|||
(unless the adversary is one end of the communication).
|
||||
Specifically, the communication channels are assumed to be secure.
|
||||
|
||||
## Security Features
|
||||
#### Security Features
|
||||
|
||||
### Pseudonymity
|
||||
##### Pseudonymity
|
||||
|
||||
Waku v2 by default guarantees pseudonymity for all of the protocol layers since parties do not have to disclose their true identity
|
||||
and instead they utilize libp2p `PeerID` as their identifiers.
|
||||
While pseudonymity is an appealing security feature, it does not guarantee full anonymity since the actions taken under the same pseudonym
|
||||
i.e., `PeerID` can be linked together and potentially result in the re-identification of the true actor.
|
||||
Waku v2, by default, guarantees pseudonymity for all of the protocol layers since parties do not have to disclose their true identity and
|
||||
instead they utilize libp2p `PeerID` as their identifiers.
|
||||
While pseudonymity is an appealing security feature,
|
||||
it does not guarantee full anonymity since the actions taken under the same pseudonym i.e.,
|
||||
`PeerID` can be linked together and potentially result in the re-identification of the true actor.
|
||||
|
||||
### Anonymity / Unlinkability
|
||||
##### Anonymity / Unlinkability
|
||||
|
||||
At a high level, anonymity is the inability of an adversary in linking an actor to its data/performed action (the actor and action are context-dependent).
|
||||
To be precise about linkability, we use the term Personally Identifiable Information (PII) to refer to any piece of data that could potentially be used to uniquely identify a party.
|
||||
For example, the signature verification key, and the hash of one's static IP address are unique for each user and hence count as PII.
|
||||
Notice that users' actions can be traced through their PIIs (e.g., signatures) and hence result in their re-identification risk.
|
||||
As such, we seek anonymity by avoiding linkability between actions and the actors / actors' PII. Concerning anonymity, Waku v2 provides the following features:
|
||||
At a high level, anonymity is the inability of an adversary in linking an actor to its data/performed action
|
||||
(the actor and action are context-dependent).
|
||||
To be precise about linkability, we use the term,
|
||||
Personally Identifiable Information (PII) refers to any piece of data that could potentially be used to uniquely identify a party.
|
||||
For example, the signature verification key, and
|
||||
the hash of one's static IP address are unique for each user and hence count as PII.
|
||||
Notice that users' actions can be traced through their PIIs
|
||||
(e.g., signatures) and hence result in their re-identification risk.
|
||||
As such, we seek anonymity by avoiding linkability between actions and
|
||||
the actors / actors' PII.
|
||||
Concerning anonymity, Waku v2 provides the following features:
|
||||
|
||||
**Publisher-Message Unlinkability**:
|
||||
This feature signifies the unlinkability of a publisher to its published messages in the 11/WAKU2-RELAY protocol.
|
||||
The [Publisher-Message Unlinkability](../11/relay.md/#security-analysis) is enforced through the `StrictNoSign` policy due to which the data fields of pubsub messages that count as PII for the publisher must be left unspecified.
|
||||
This feature signifies the unlinkability of a publisher to its published messages in the [11/WAKU2-RELAY](/spec/11) protocol.
|
||||
The [Publisher-Message Unlinkability](/spec/11#security-analysis) is enforced through the `StrictNoSign` policy,
|
||||
due to the data fields of pubsub messages that count as PII for the publisher must be left unspecified.
|
||||
|
||||
**Subscriber-Topic Unlinkability**:
|
||||
This feature stands for the unlinkability of the subscriber to its subscribed topics in the 11/WAKU2-RELAY protocol.
|
||||
The [Subscriber-Topic Unlinkability](../11/relay.md/#security-analysis) is achieved through the utilization of a single PubSub topic.
|
||||
As such, subscribers are not re-identifiable from their subscribed topic IDs as the entire network is linked to the same topic ID.
|
||||
This level of unlinkability / anonymity is known as [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/) where k is proportional to the system size (number of subscribers).
|
||||
Note that there is no hard limit on the number of the pubsub topics, however, the use of one topic is recommended for the sake of anonymity.
|
||||
This feature stands for the unlinkability of the subscriber to its subscribed topics in the [11/WAKU2-RELAY](/spec/11) protocol.
|
||||
The [Subscriber-Topic Unlinkability](/spec/11/#security-analysis) is achieved through the utilization of a single PubSub topic.
|
||||
As such, subscribers are not re-identifiable from their subscribed topic IDs (`pubsub_topic`) as the entire network is linked to the same topic ID (`pubsub_topic`).
|
||||
This level of unlinkability / anonymity is known as [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/),
|
||||
where k is proportional to the system size (number of subscribers).
|
||||
Note that there is no hard limit on the number of the pubsub topics, however,
|
||||
the use of one pubsub topic is RECOMMENDED for the sake of anonymity.
|
||||
|
||||
### Spam protection
|
||||
##### Spam protection
|
||||
|
||||
This property indicates that no adversary can flood the system (i.e., publishing a large number of messages in a short amount of time), either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful.
|
||||
Spam protection is partly provided in `11/WAKU2-RELAY` through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1.
|
||||
At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score.
|
||||
This property indicates that no adversary can flood the system
|
||||
(i.e., publishing a large number of messages in a short amount of time),
|
||||
either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful.
|
||||
Spam protection is partly provided in `11/WAKU2-RELAY` through the
|
||||
[scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1.
|
||||
At a high level, peers utilize a scoring function to locally score the behavior of their connections and
|
||||
remove peers with a low score.
|
||||
|
||||
### Data confidentiality, Integrity, and Authenticity
|
||||
##### Data confidentiality, Integrity, and Authenticity
|
||||
|
||||
Confidentiality can be addressed through data encryption whereas integrity and authenticity are achievable through digital signatures.
|
||||
These features are provided for in [14/WAKU2-MESSAGE (version 1)](../14/message.md/#version-1)` through payload encryption as well as encrypted signatures.
|
||||
Confidentiality can be addressed through data encryption whereas integrity and
|
||||
authenticity are achievable through digital signatures.
|
||||
These features are provided for in [14/WAKU2-MESSAGE (version 1)](/spec/14#version-1)` through payload encryption as well as encrypted signatures.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
**Lack of anonymity/unlinkability in the protocols involving direct connections including `13/WAKU2-STORE` and `12/WAKU2-FILTER` protocols**:
|
||||
The anonymity/unlinkability is not guaranteed in the protocols like `13/WAKU2-STORE` and `12/WAKU2-FILTER` where peers need to have direct connections to benefit from the designated service.
|
||||
The anonymity/unlinkability is not guaranteed in the protocols like `13/WAKU2-STORE` and
|
||||
`12/WAKU2-FILTER` where peers need to have direct connections to benefit from the designated service.
|
||||
This is because during the direct connections peers utilize `PeerID` to identify each other,
|
||||
therefore the service obtained in the protocol is linkable to the beneficiary's `PeerID` (which counts as PII).
|
||||
For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics.
|
||||
For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics(`contentTopic`).
|
||||
Likewise, in the `12/WAKU2-FILTER`, a full node can link the light node's `PeerID`s to its content filter.
|
||||
|
||||
<!-- TODO: to inspect the nim-libp2p codebase and figure out the exact use of PeerIDs in direct communication, it might be the case that the requester does not have to disclose its PeerID-->
|
||||
### Appendix C: Implementation Notes
|
||||
|
||||
<!--TODO: might be good to add a figure visualizing the Waku protocol stack and the security features of each layer-->
|
||||
|
||||
## Appendix C: Implementation Notes
|
||||
|
||||
### Implementation Matrix
|
||||
#### Implementation Matrix
|
||||
|
||||
There are multiple implementations of Waku v2 and its protocols:
|
||||
|
||||
|
|
@ -357,69 +393,71 @@ There are multiple implementations of Waku v2 and its protocols:
|
|||
- [go-waku (Go)](https://github.com/status-im/go-waku/)
|
||||
- [js-waku (NodeJS and Browser)](https://github.com/status-im/js-waku/)
|
||||
|
||||
Below you can find an overview of the specs that they implement as they relate to Waku v2.
|
||||
This includes Waku v1 specs, as they are used for bridging between the two networks.
|
||||
In the following overview, you can find the implemented specifcations utilizing Waku v2.
|
||||
This includes Waku v1 specifications, as they are used for bridging between the two networks.
|
||||
|
||||
| Spec | nim-waku (Nim) | go-waku (Go) | js-waku (Node JS) | js-waku (Browser JS) |
|
||||
| ---- | -------------- | ------------ | ----------------- | -------------------- |
|
||||
|[6/WAKU1](../6/waku1.md)|✔|||
|
||||
|[7/WAKU-DATA](../7/data.md)|✔|✔||
|
||||
|[8/WAKU-MAIL](../../application/8/mail.md)|✔|||
|
||||
|[9/WAKU-RPC](../9/waku2-rpc.md)|✔|||
|
||||
|[10/WAKU2](../10/waku2.md)|✔|🚧|🚧|🚧|
|
||||
|[11/WAKU2-RELAY](../11/relay.md)|✔|✔|✔|✔|
|
||||
|[12/WAKU2-FILTER](../12/filter.md)|✔|✔||
|
||||
|[13/WAKU2-STORE](../13/store.md)|✔|✔|✔\*|✔\*|
|
||||
|[14/WAKU2-MESSAGE](../14/message.md))|✔|✔|✔|✔|
|
||||
|[15/WAKU2-BRIDGE](../15/bridge.md)|✔|||
|
||||
|[16/WAKU2-RPC](../16/rpc.md)|✔|||
|
||||
|[17/WAKU2-RLN-RELAY](../17/rln-relay.md)|🚧|||
|
||||
|[18/WAKU2-SWAP](../../application/18/swap.md)|🚧|||
|
||||
|[19/WAKU2-LIGHTPUSH](../19/lightpush.md)|✔|✔|✔\**|✔\**|
|
||||
|[21/WAKU2-FAULT-TOLERANT-STORE](../../application/21/fault-tolerant-store.md)|✔|✔||
|
||||
|
||||
*js-waku implements [13/WAKU2-STORE](../13/store.md) as a querying node only.
|
||||
**js-waku only implements [19/WAKU2-LIGHTPUSH](../19/lightpush.md) requests.
|
||||
|[6/WAKU1](/spec/6)|✔|||
|
||||
|[7/WAKU-DATA](/spec/7)|✔|✔||
|
||||
|[8/WAKU-MAIL](/spec/8)|✔|||
|
||||
|[9/WAKU-RPC](/spec/9)|✔|||
|
||||
|[10/WAKU2](/spec/10)|✔|🚧|🚧|🚧|
|
||||
|[11/WAKU2-RELAY](/spec/11)|✔|✔|✔|✔|
|
||||
|[12/WAKU2-FILTER](/spec/12)|✔|✔||
|
||||
|[13/WAKU2-STORE](/spec/13)|✔|✔|✔\*|✔\*|
|
||||
|[14/WAKU2-MESSAGE](/spec/14)|✔|✔|✔|✔|
|
||||
|[15/WAKU2-BRIDGE](/spec/15)|✔|||
|
||||
|[16/WAKU2-RPC](/spec/16)|✔|||
|
||||
|[17/WAKU2-RLN-RELAY](/spec/17)|🚧|||
|
||||
|[18/WAKU2-SWAP](/spec/18)|🚧|||
|
||||
|[19/WAKU2-LIGHTPUSH](/spec/19)|✔|✔|✔\**|✔\**|
|
||||
|[21/WAKU2-FAULT-TOLERANT-STORE](/spec/21)|✔|✔||
|
||||
|
||||
*js-waku implements [13/WAKU2-STORE](/spec/13) as a querying node only.
|
||||
**js-waku only implements [19/WAKU2-LIGHTPUSH](/spec/19) requests.
|
||||
|
||||
### Recommendations for clients
|
||||
|
||||
To implement a minimal Waku v2 client, we recommend implementing the following subset in the following order:
|
||||
To implement a minimal Waku v2 client, the following subset of protocols is RECOMMENDED to be implemented in the following order:
|
||||
|
||||
- [10/WAKU2](../10/waku2.md) - this spec
|
||||
- [11/WAKU2-RELAY](../11/relay.md) - for basic operation
|
||||
- [14/WAKU2-MESSAGE](../14/message.md) - version 0 (unencrypted)
|
||||
- [13/WAKU2-STORE](../13/store.md) - for historical messaging (query mode only)
|
||||
- [10/WAKU2](/spec/10) - this specification
|
||||
- [11/WAKU2-RELAY](/spec/11) - for basic operation
|
||||
- [14/WAKU2-MESSAGE](/spec/14) - version 0 (unencrypted)
|
||||
- [13/WAKU2-STORE](/spec/13) - for historical messaging (query mode only)
|
||||
|
||||
To get compatibility with Waku v1:
|
||||
|
||||
- [7/WAKU-DATA](../7/data.md)
|
||||
- [14/WAKU2-MESSAGE](../14/message.md) - version 1 (encrypted with `7/WAKU-DATA`)
|
||||
- [7/WAKU-DATA](/spec/7)
|
||||
- [14/WAKU2-MESSAGE](/spec/14) - version 1 (encrypted with `7/WAKU-DATA`)
|
||||
|
||||
For an interoperable keep-alive mechanism:
|
||||
|
||||
- [libp2p ping protocol](https://docs.libp2p.io/concepts/protocols/#ping),
|
||||
with periodic pings to connected peers
|
||||
with periodic pings to connected peers.
|
||||
|
||||
## Appendix D: Future work
|
||||
### Appendix D: Future work
|
||||
|
||||
The following features are currently experimental and under research and initial implementation:
|
||||
The following features are currently experimental, under research and initial implementations:
|
||||
|
||||
**Economic Spam resistance**:
|
||||
**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-RLN-RELAY](../17/rln-relay.md).
|
||||
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.
|
||||
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**:
|
||||
Denial of service signifies the case where an adversarial node exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system.
|
||||
DoS attack is to be mitigated through the accounting model as described in [18/WAKU2-SWAP](../../application/18/swap.md).
|
||||
Denial of service signifies the case where an adversarial node exhausts another node's service capacity
|
||||
(e.g., by making a large number of requests) and makes it unavailable to the rest of the system.
|
||||
DoS attack is to be mitigated through the accounting model as described in [18/WAKU2-SWAP](/spec/18).
|
||||
In a nutshell, peers have to pay for the service they obtain from each other.
|
||||
In addition to incentivizing the service provider, accounting also makes DoS attacks costly for malicious peers.
|
||||
The accounting model can be used in `13/WAKU2-STORE` and `12/WAKU2-FILTER` to protect against DoS attacks.
|
||||
In addition to incentivizing the service provider,
|
||||
accounting also makes DoS attacks costly for malicious peers.
|
||||
The accounting model can be used in [`13/WAKU2-STORE`](/spec/13) and
|
||||
[`12/WAKU2-FILTER`](/spec/12) to protect against DoS attacks.
|
||||
|
||||
Additionally, this gives node operators who provide a useful service to the network an incentive to perform that service.
|
||||
See [18/WAKU2-SWAP](../../application/18/swap.md) for more details on this piece of work.
|
||||
|
||||
See [18/WAKU2-SWAP](/spec/18) for more details on this piece of work.
|
||||
|
||||
## Copyright
|
||||
|
||||
|
|
@ -429,71 +467,46 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
|
|||
|
||||
1. [libp2p specs](https://github.com/libp2p/specs)
|
||||
|
||||
2. [6/WAKU1](../6/waku1.md)
|
||||
2. [6/WAKU1 spec](/spec/6)
|
||||
|
||||
3. [Whisper spec (EIP627)](https://eips.ethereum.org/EIPS/eip-627)
|
||||
|
||||
4. [Waku v2 plan](https://vac.dev/waku-v2-plan)
|
||||
|
||||
5. [30/ADAPTIVE-NODES](../../../informational/30/adaptive-nodes.md)
|
||||
5. [Protocol Identifiers](https://docs.libp2p.io/concepts/protocols/)
|
||||
|
||||
6. [Protocol Identifiers](https://docs.libp2p.io/concepts/protocols/)
|
||||
6. [Protobuf varint encoding](https://developers.google.com/protocol-buffers/docs/encoding#varints)
|
||||
|
||||
7. [14/WAKU2-MESSAGE](../14/message.md)
|
||||
7. [7/WAKU-DATA spec](/spec/7)
|
||||
|
||||
8. [26/WAKU-PAYLOAD](../../application/26/payload.md)
|
||||
8. [11/WAKU2-RELAY spec](/spec/11)
|
||||
|
||||
9. [23/WAKU2-TOPICS](../../../informational/23/topics.md)
|
||||
9. [13/WAKU2-STORE spec](/spec/13)
|
||||
|
||||
10. [27/WAKU2-PEERS](../../../informational/27/peers.md)
|
||||
10. [12/WAKU2-FILTER spec](/spec/12)
|
||||
|
||||
11. [bi-directional binary stream](https://docs.libp2p.io/concepts/protocols/)
|
||||
11. [15/WAKU2-BRIDGE spec](/spec/15)
|
||||
|
||||
12. [Protobuf varint encoding](https://developers.google.com/protocol-buffers/docs/encoding#varints)
|
||||
12. [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/)
|
||||
|
||||
13. [11/WAKU2-RELAY spec](../11/relay.md)
|
||||
13. [GossipSub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)
|
||||
|
||||
14. [17/WAKU2-RLN-RELAY](../17/rln-relay.md)
|
||||
14. [14/WAKU2-MESSAGE spec](/spec/14)
|
||||
|
||||
15. [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459)
|
||||
15. [17/WAKU2-RLN-RELAY spec](/spec/17)
|
||||
|
||||
16. [Ambient peer discovery](https://docs.libp2p.io/concepts/publish-subscribe/#discovery)
|
||||
16. [18/WAKU2-SWAP spec](/spec/18)
|
||||
|
||||
17. [Node Discovery v5](https://github.com/ethereum/devp2p/blob/8fd5f7e1c1ec496a9d8dc1640a8548b8a8b5986b/discv5/discv5.md)
|
||||
17. [Ping protocol](https://docs.libp2p.io/concepts/protocols/#ping)
|
||||
|
||||
18. [31/WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md)
|
||||
18. [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459)
|
||||
|
||||
19. [EIP-778 ENR (Ethereum Node Records)](https://eips.ethereum.org/EIPS/eip-778)
|
||||
19. [Ambient peer discovery](https://docs.libp2p.io/concepts/publish-subscribe/#discovery)
|
||||
|
||||
20. [13/WAKU2-STORE spec](../13/store.md)
|
||||
20. [Node Discovery v5](https://github.com/ethereum/devp2p/blob/8fd5f7e1c1ec496a9d8dc1640a8548b8a8b5986b/discv5/discv5.md)
|
||||
|
||||
21. [21/WAKU2-FT-STORE](../../application/21/ft-store.md)
|
||||
21. [33/WAKU2-DISCV5](/spec/33)
|
||||
|
||||
22. [12/WAKU2-FILTER](../12/filter.md)
|
||||
|
||||
23. [19/WAKU2-LIGHTPUSH](../19/lightpush.md)
|
||||
|
||||
24. [7/WAKU-DATA](../../application/7/data.md)
|
||||
|
||||
25. [15/WAKU-BRIDGE](../15/bridge.md)
|
||||
|
||||
26. [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/)
|
||||
|
||||
27. [GossipSub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)
|
||||
|
||||
28. [nim-waku (Nim)](https://github.com/status-im/nim-waku/)
|
||||
|
||||
29. [go-waku (Go)](https://github.com/status-im/go-waku/)
|
||||
|
||||
30. [js-waku (NodeJS and Browser)](https://github.com/status-im/js-waku/)
|
||||
|
||||
31. [8/WAKU-MAIL](../../application/8/mail.md)
|
||||
|
||||
32. [9/WAKU-RPC](../9/waku2-rpc.md)
|
||||
|
||||
33. [16/WAKU2-RPC](../16/rpc.md)
|
||||
|
||||
34. [18/WAKU2-SWAP spec](../../application/18/swap.md)
|
||||
|
||||
35. [21/WAKU2-FAULT-TOLERANT-STORE](../../application/21/fault-tolerant-store.md)
|
||||
22. [31/WAKU2-ENR spec](/spec/31)
|
||||
|
||||
23. [EIP-778](https://eips.ethereum.org/EIPS/eip-778)
|
||||
|
|
|
|||
Loading…
Reference in New Issue