<metaname="description"content="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 and adds a set of capabilities to it. 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">
<metaproperty="og:description"content="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 and adds a set of capabilities to it. 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"/>
<p>In addition to <code>/vac/waku/*</code> protocols, Waku v2 MAY directly use the following libp2p protocols:</p>
<ul>
<li><ahref="https://docs.libp2p.io/concepts/protocols/#ping">libp2p ping protocol</a> with protocol id</li>
</ul>
<pretabindex="0"><code>/ipfs/ping/1.0.0
</code></pre><p>for liveness checks between peers, or to keep peer-to-peer connections alive.</p>
<ul>
<li><ahref="https://docs.libp2p.io/concepts/protocols/#identify">libp2p identity and identity/push</a> with protocol IDs</li>
</ul>
<pretabindex="0"><code>/ipfs/id/1.0.0
</code></pre><p>and</p>
<pretabindex="0"><code>/ipfs/id/push/1.0.0
</code></pre><p>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.</p>
<h1id="transports">
Transports
<aclass="anchor"href="#transports">#</a>
</h1>
<p>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.</p>
<p>This section describes these recommended transports.</p>
<p>Waku client implementations SHOULD support the TCP transport.</p>
<p>Where TCP is supported it MUST be enabled for both dialing and listening, even if other transports are available.</p>
<p>Waku v2 nodes where the environment do not allow to use TCP directly, MAY use other transports.</p>
<p>A Waku v2 node SHOULD support secure websockets for bidirectional communication streams, for example in a web browser context.</p>
<p>A node MAY support unsecure websockets if required by the application or running environment.</p>
<h3id="discovery-domain">
Discovery domain
<aclass="anchor"href="#discovery-domain">#</a>
</h3>
<h4id="discovery-methods">
Discovery methods
<aclass="anchor"href="#discovery-methods">#</a>
</h4>
<p>Waku v2 can retrieve a list of nodes to connect to using DNS-based discovery as per <ahref="https://eips.ethereum.org/EIPS/eip-1459">EIP-1459</a>.
While this is a useful way of bootstrapping connection to a set of peers,
it MAY be used in conjunction with an <ahref="https://docs.libp2p.io/concepts/publish-subscribe/#discovery">ambient peer discovery</a> procedure to find still other nodes to connect to,
such as <ahref="https://github.com/ethereum/devp2p/blob/8fd5f7e1c1ec496a9d8dc1640a8548b8a8b5986b/discv5/discv5.md">Node Discovery v5</a>.
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.</p>
<h4id="use-of-enr">
Use of ENR
<aclass="anchor"href="#use-of-enr">#</a>
</h4>
<p><ahref="/spec/31">31/WAKU2-ENR</a> describes the usage of <ahref="https://eips.ethereum.org/EIPS/eip-778">EIP-778 ENR (Ethereum Node Records)</a> for Waku v2 discovery purposes.
It introduces two new ENR fields, <code>multiaddrs</code> and <code>waku2</code>, that a Waku v2 node MAY use for discovery purposes.
These fields MUST be used under certain conditions, as set out in the spec.
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.</p>
<h3id="requestreply-domain">
Request/Reply domain
<aclass="anchor"href="#requestreply-domain">#</a>
</h3>
<p>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,
such as low bandwidth or being mostly offline.</p>
<p>See the sequence diagram below for an overview of how different protocols interact.</p>
<p><imgsrc="../../../../rfcs/10/overview.png"alt="Overview of how protocols interact in Waku v2."/></p>
<olstart="0">
<li>
<p>We have six nodes, A-F.
The protocols initially mounted are indicated as such.
The PubSub topics <code>pubtopic1</code> and <code>pubtopic2</code> is used for routing and indicates that it is subscribed to messages on that topic for relay, see <ahref="/spec/11">11/WAKU2-RELAY</a> for details.
Ditto for <ahref="/spec/13">13/WAKU2-STORE</a> where it indicates that these messages are persisted on that node.</p>
</li>
<li>
<p>Node A creates a WakuMessage <code>msg1</code> with a ContentTopic <code>contentTopic1</code>.
See <ahref="/spec/14">14/WAKU2-MESSAGE</a> for more details.
If WakuMessage version is set to 1, we use the <ahref="/spec/6">6/WAKU1</a> compatible <code>data</code> field with encryption.
See <ahref="/spec/7">7/WAKU-DATA</a> for more details.</p>
</li>
<li>
<p>Node F requests to get messages filtered by PubSub topic <code>pubtopic1</code> and ContentTopic <code>contentTopic1</code>.
Node D subscribes F to this filter and will in the future forward messages that match that filter.
See <ahref="/spec/12">12/WAKU2-FILTER</a> for more details.</p>
</li>
<li>
<p>Node A publishes <code>msg1</code> on <code>pubtopic1</code> 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 <ahref="/spec/11">11/WAKU2-RELAY</a>.</p>
</li>
<li>
<p>Node D saves <code>msg1</code> for possible later retrieval by other nodes.
See <ahref="/spec/13">13/WAKU2-STORE</a>.</p>
</li>
<li>
<p>Node D also pushes <code>msg1</code> to F, as it has previously subscribed F to this filter.
See <ahref="/spec/12">12/WAKU2-FILTER</a>.</p>
</li>
<li>
<p>At a later time, Node E comes online.
It then requests messages matching <code>pubtopic1</code> and <code>contentTopic1</code> from Node D.
Node D responds with messages meeting this (and possibly other) criteria. See <ahref="/spec/13">13/WAKU2-STORE</a>.</p>
<p>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.
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.</p>
<p>See <ahref="/spec/15">15/WAKU-BRIDGE</a> for details on a bidirectional bridge mode.</p>
<h1id="appendix-b-security">
Appendix B: Security
<aclass="anchor"href="#appendix-b-security">#</a>
</h1>
<p>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.</p>
<p>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:</p>
This feature signifies the unlinkability of a publisher to its published messages in the 11/WAKU2-RELAY protocol.
The <ahref="/spec/11#security-analysis">Publisher-Message Unlinkability</a> is enforced through the <code>StrictNoSign</code> policy due to which the data fields of pubsub messages that count as PII for the publisher must be left unspecified.</p>
This feature stands for the unlinkability of the subscriber to its subscribed topics in the 11/WAKU2-RELAY protocol.
The <ahref="/spec/11/#security-analysis">Subscriber-Topic Unlinkability</a> 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 <ahref="https://www.privitar.com/blog/k-anonymity-an-introduction/">k-anonymity</a> 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.</p>
<h3id="spam-protection">
Spam protection
<aclass="anchor"href="#spam-protection">#</a>
</h3>
<p>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 <code>11/WAKU2-RELAY</code> through the <ahref="https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures">scoring mechanism</a> 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.</p>
<p>Confidentiality can be addressed through data encryption whereas integrity and authenticity are achievable through digital signatures.
These features are provided for in <ahref="/spec/14#version-1">14/WAKU2-MESSAGE (version 1)</a>` through payload encryption as well as encrypted signatures.</p>
<p><strong>Lack of anonymity/unlinkability in the protocols involving direct connections including <code>13/WAKU2-STORE</code> and <code>12/WAKU2-FILTER</code> protocols</strong>:
The anonymity/unlinkability is not guaranteed in the protocols like <code>13/WAKU2-STORE</code> and <code>12/WAKU2-FILTER</code> where peers need to have direct connections to benefit from the designated service.
This is because during the direct connections peers utilize <code>PeerID</code> to identify each other,
therefore the service obtained in the protocol is linkable to the beneficiary’s <code>PeerID</code> (which counts as PII).
For <code>13/WAKU2-STORE</code>, the queried node would be able to link the querying node’s <code>PeerID</code> to its queried topics.
Likewise, in the <code>12/WAKU2-FILTER</code>, a full node can link the light node’s <code>PeerID</code>s to its content filter.</p>
<p>The following features are currently experimental and under research and initial implementation:</p>
<p><strong>Economic Spam resistance</strong>:
We aim to enable an incentivized spam protection technique to enhance <code>11/WAKU2-RELAY</code> by using rate limiting nullifiers.
More details on this can be found in <ahref="/spec/17">17/WAKU2-RLN-RELAY</a>.
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.</p>
<p><strong>Prevention of Denial of Service (DoS) and Node Incentivization</strong>:
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 <ahref="/spec/18">18/WAKU2-SWAP</a>.
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 <code>13/WAKU2-STORE</code> and <code>12/WAKU2-FILTER</code> to protect against DoS attacks.</p>
<p>Additionally, this gives node operators who provide a useful service to the network an incentive to perform that service.
See <ahref="/spec/18">18/WAKU2-SWAP</a> for more details on this piece of work.</p>
<h2id="copyright">
Copyright
<aclass="anchor"href="#copyright">#</a>
</h2>
<p>Copyright and related rights waived via <ahref="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>.</p>
