mirror of https://github.com/vacp2p/rfc.git
572 lines
23 KiB
HTML
572 lines
23 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html lang="en" dir="ltr">
|
||
|
|
|
||
|
|
<head>
|
||
|
|
<meta name="generator" content="Hugo 0.106.0">
|
||
|
|
<meta charset="UTF-8">
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
|
|
<meta name="description" content="Abstract # This document describes ways of sharding the Waku relay topic, 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.
|
||
|
|
Background and Motivation # Unstructured P2P networks are more robust and resilient against DoS attacks compared to structured P2P networks). However, they do not scale to large traffic loads. A single libp2p gossipsub mesh, which carries messages associated with a single pubsub topic, can be seen as a separate unstructured P2P network (gossip and control messages go beyond these boundaries, but at its core, it is a separate P2P network).">
|
||
|
|
<meta name="theme-color" content="#FFFFFF"><meta property="og:title" content="51/WAKU2-RELAY-SHARDING" />
|
||
|
|
<meta property="og:description" content="Abstract # This document describes ways of sharding the Waku relay topic, 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.
|
||
|
|
Background and Motivation # Unstructured P2P networks are more robust and resilient against DoS attacks compared to structured P2P networks). However, they do not scale to large traffic loads. A single libp2p gossipsub mesh, which carries messages associated with a single pubsub topic, can be seen as a separate unstructured P2P network (gossip and control messages go beyond these boundaries, but at its core, it is a separate P2P network)." />
|
||
|
|
<meta property="og:type" content="article" />
|
||
|
|
<meta property="og:url" content="https://rfc.vac.dev/spec/51/" /><meta property="article:section" content="docs" />
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<title>51/WAKU2-RELAY-SHARDING | Vac RFC</title>
|
||
|
|
<link rel="manifest" href="/manifest.json">
|
||
|
|
<link rel="icon" href="/favicon.png" type="image/x-icon">
|
||
|
|
<link rel="stylesheet" href="/book.min.e935e20bd0d469378cb482f0958edf258c731a4f895dccd55799c6fbc8043f23.css" integrity="sha256-6TXiC9DUaTeMtILwlY7fJYxzGk+JXczVV5nG+8gEPyM=">
|
||
|
|
<script defer src="/en.search.min.0014c66ebb4f352db3fc7d6b00c817b0a4a6b8a1b5de4e2ab4a0b776ac440f78.js" integrity="sha256-ABTGbrtPNS2z/H1rAMgXsKSmuKG13k4qtKC3dqxED3g="></script>
|
||
|
|
<!--
|
||
|
|
Made with Book Theme
|
||
|
|
https://github.com/alex-shpak/hugo-book
|
||
|
|
-->
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body dir="ltr">
|
||
|
|
<input type="checkbox" class="hidden toggle" id="menu-control" />
|
||
|
|
<input type="checkbox" class="hidden toggle" id="toc-control" />
|
||
|
|
<main class="container flex">
|
||
|
|
<aside class="book-menu">
|
||
|
|
<div class="book-menu-content">
|
||
|
|
|
||
|
|
<nav>
|
||
|
|
<h2 class="book-brand">
|
||
|
|
<a href="/"><span>Vac RFC</span>
|
||
|
|
</a>
|
||
|
|
</h2>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="book-search">
|
||
|
|
<input type="text" id="book-search-input" placeholder="Search" aria-label="Search" maxlength="64" data-hotkeys="s/" />
|
||
|
|
<div class="book-search-spinner hidden"></div>
|
||
|
|
<ul id="book-search-results"></ul>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Raw
|
||
|
|
<ul>
|
||
|
|
<li><a href="/spec/20/">20/TOY-ETH-PM</a></li>
|
||
|
|
<li><a href="/spec/24/">24/STATUS-CURATION</a></li>
|
||
|
|
<li><a href="/spec/28/">28/STATUS-FEATURING</a></li>
|
||
|
|
<li><a href="/spec/31/">31/WAKU2-ENR</a></li>
|
||
|
|
<li><a href="/spec/32/">32/RLN-SPEC</a></li>
|
||
|
|
<li><a href="/spec/34/">34/WAKU2-PEER-EXCHANGE</a></li>
|
||
|
|
<li><a href="/spec/35/">35/WAKU2-NOISE</a></li>
|
||
|
|
<li><a href="/spec/37/">37/WAKU2-NOISE-SESSIONS</a></li>
|
||
|
|
<li><a href="/spec/38/">38/CONSENSUS-CLARO</a></li>
|
||
|
|
<li><a href="/spec/43/">43/WAKU2-NOISE-PAIRING</a></li>
|
||
|
|
<li><a href="/spec/44/">44/WAKU2-DANDELION</a></li>
|
||
|
|
<li><a href="/spec/45/">45/WAKU2-ADVERSARIAL-MODELS</a></li>
|
||
|
|
<li><a href="/spec/46/">46/GOSSIPSUB-TOR-PUSH</a></li>
|
||
|
|
<li><a href="/spec/47/">47/WAKU2-TOR-PUSH</a></li>
|
||
|
|
<li><a href="/spec/48/">48/RLN-INTEREP-SPEC</a></li>
|
||
|
|
<li><a href="/spec/51/"class=active>51/WAKU2-RELAY-SHARDING</a></li>
|
||
|
|
<li><a href="/spec/52/">52/WAKU2-RELAY-STATIC-SHARD-ALLOC</a></li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>Draft
|
||
|
|
<ul>
|
||
|
|
<li><a href="/spec/1/">1/COSS</a></li>
|
||
|
|
<li><a href="/spec/3/">3/REMOTE-LOG</a></li>
|
||
|
|
<li><a href="/spec/4/">4/MVDS-META</a></li>
|
||
|
|
<li><a href="/spec/10/">10/WAKU2</a></li>
|
||
|
|
<li><a href="/spec/12/">12/WAKU2-FILTER</a></li>
|
||
|
|
<li><a href="/spec/13/">13/WAKU2-STORE</a></li>
|
||
|
|
<li><a href="/spec/14/">14/WAKU2-MESSAGE</a></li>
|
||
|
|
<li><a href="/spec/15/">15/WAKU2-BRIDGE</a></li>
|
||
|
|
<li><a href="/spec/16/">16/WAKU2-RPC</a></li>
|
||
|
|
<li><a href="/spec/17/">17/WAKU2-RLN-RELAY</a></li>
|
||
|
|
<li><a href="/spec/18/">18/WAKU2-SWAP</a></li>
|
||
|
|
<li><a href="/spec/19/">19/WAKU2-LIGHTPUSH</a></li>
|
||
|
|
<li><a href="/spec/21/">21/WAKU2-FTSTORE</a></li>
|
||
|
|
<li><a href="/spec/22/">22/TOY-CHAT</a></li>
|
||
|
|
<li><a href="/spec/23/">23/WAKU2-TOPICS</a></li>
|
||
|
|
<li><a href="/spec/26/">26/WAKU2-PAYLOAD</a></li>
|
||
|
|
<li><a href="/spec/27/">27/WAKU2-PEERS</a></li>
|
||
|
|
<li><a href="/spec/29/">29/WAKU2-CONFIG</a></li>
|
||
|
|
<li><a href="/spec/30/">30/ADAPTIVE-NODES</a></li>
|
||
|
|
<li><a href="/spec/33/">33/WAKU2-DISCV5</a></li>
|
||
|
|
<li><a href="/spec/36/">36/WAKU2-BINDINGS-API</a></li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>Stable
|
||
|
|
<ul>
|
||
|
|
<li><a href="/spec/2/">2/MVDS</a></li>
|
||
|
|
<li><a href="/spec/6/">6/WAKU1</a></li>
|
||
|
|
<li><a href="/spec/7/">7/WAKU-DATA</a></li>
|
||
|
|
<li><a href="/spec/8/">8/WAKU-MAIL</a></li>
|
||
|
|
<li><a href="/spec/9/">9/WAKU-RPC</a></li>
|
||
|
|
<li><a href="/spec/11/">11/WAKU2-RELAY</a></li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>Deprecated
|
||
|
|
<ul>
|
||
|
|
<li><a href="/spec/5/">5/WAKU0</a></li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>Retired</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</nav>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<script>(function(){var e=document.querySelector("aside.book-menu nav");addEventListener("beforeunload",function(){localStorage.setItem("menu.scrollTop",e.scrollTop)}),e.scrollTop=localStorage.getItem("menu.scrollTop")})()</script>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</aside>
|
||
|
|
|
||
|
|
<div class="book-page">
|
||
|
|
<header class="book-header">
|
||
|
|
|
||
|
|
<div class="flex align-center justify-between">
|
||
|
|
<label for="menu-control">
|
||
|
|
<img src="/svg/menu.svg" class="book-icon" alt="Menu" />
|
||
|
|
</label>
|
||
|
|
|
||
|
|
<strong>51/WAKU2-RELAY-SHARDING</strong>
|
||
|
|
|
||
|
|
<label for="toc-control">
|
||
|
|
|
||
|
|
<img src="/svg/toc.svg" class="book-icon" alt="Table of Contents" />
|
||
|
|
|
||
|
|
</label>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<aside class="hidden clearfix">
|
||
|
|
|
||
|
|
|
||
|
|
<nav id="TableOfContents">
|
||
|
|
<ul>
|
||
|
|
<li><a href="#discovery">Discovery</a>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#one-key-per-shard-cluster">One key per Shard Cluster</a></li>
|
||
|
|
<li><a href="#single-key">Single Key</a></li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#discovery-1">Discovery</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#receiver-anonymity">Receiver Anonymity</a></li>
|
||
|
|
</ul>
|
||
|
|
</nav>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</aside>
|
||
|
|
|
||
|
|
|
||
|
|
</header>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<article class="markdown">
|
||
|
|
<h1 id="51waku2-relay-sharding">
|
||
|
|
51/WAKU2-RELAY-SHARDING
|
||
|
|
<a class="anchor" href="#51waku2-relay-sharding">#</a>
|
||
|
|
</h1>
|
||
|
|
|
||
|
|
|
||
|
|
<h1 id="waku-v2-relay-sharding">
|
||
|
|
Waku v2 Relay Sharding
|
||
|
|
<a class="anchor" href="#waku-v2-relay-sharding">#</a>
|
||
|
|
</h1>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<img src="https://img.shields.io/badge/status-raw-lightgrey?style=flat-square" />
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Status: raw</li>
|
||
|
|
<li>Editor: Daniel Kaiser <a href="mailto:danielkaiser@status.im">danielkaiser@status.im</a></li>
|
||
|
|
|
||
|
|
</ul><h1 id="abstract">
|
||
|
|
Abstract
|
||
|
|
<a class="anchor" href="#abstract">#</a>
|
||
|
|
</h1>
|
||
|
|
<p>This document describes ways of sharding the <a href="/spec/11/">Waku relay</a> topic,
|
||
|
|
allowing Waku networks to scale in the number of content topics.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p><em>Note</em>: Scaling in the size of a single content topic is out of scope for this document.</p>
|
||
|
|
</blockquote>
|
||
|
|
<h1 id="background-and-motivation">
|
||
|
|
Background and Motivation
|
||
|
|
<a class="anchor" href="#background-and-motivation">#</a>
|
||
|
|
</h1>
|
||
|
|
<p><a href="https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks">Unstructured P2P networks</a>
|
||
|
|
are more robust and resilient against DoS attacks compared to
|
||
|
|
<a href="https://en.wikipedia.org/wiki/Peer-to-peer#Structured_networks">structured P2P networks</a>).
|
||
|
|
However, they do not scale to large traffic loads.
|
||
|
|
A single <a href="https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#gossipsub-the-gossiping-mesh-router">libp2p gossipsub mesh</a>,
|
||
|
|
which carries messages associated with a single pubsub topic, can be seen as a separate unstructured P2P network
|
||
|
|
(gossip and control messages go beyond these boundaries, but at its core, it is a separate P2P network).
|
||
|
|
With this, the number of <a href="/spec/11/">Waku relay</a> 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.</p>
|
||
|
|
<p>This document specifies three pubsub topic sharding methods (with varying degrees of automation),
|
||
|
|
which allow application protocols to scale in the number of content topics.
|
||
|
|
This document also covers discovery of topic shards.</p>
|
||
|
|
<h1 id="named-sharding">
|
||
|
|
Named Sharding
|
||
|
|
<a class="anchor" href="#named-sharding">#</a>
|
||
|
|
</h1>
|
||
|
|
<p><em>Named sharding</em> offers apps to freely choose pubsub topic names.
|
||
|
|
App protocols SHOULD follow the naming structure detailed in <a href="/spec/23/">23/WAKU2-TOPICS</a>.
|
||
|
|
With named sharding, managing discovery falls into the responsibility of apps.</p>
|
||
|
|
<p>The default Waku pubsub topic <code>/waku/2/default-waku/proto</code> can be seen as a named shard available to all app protocols.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p><em>Note</em>: Future versions of this document are planned to give more guidance with respect to discovery via
|
||
|
|
<a href="/spec/33/">33/WAKU2-DISCV5</a>,
|
||
|
|
<a href="https://eips.ethereum.org/EIPS/eip-1459">DNS discovery</a>,
|
||
|
|
and inter-mesh discovery via gossipsub control messages (also using circuit relay).
|
||
|
|
It might make sense to deprecate <a href="/spec/23/">23/WAKU2-TOPICS</a> as a separate spec and merge it here.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>From an app protocol point of view, a subscription to a content topic <code>waku2/xxx</code> on a shard named /mesh/v1.1.1/xxx would look like:</p>
|
||
|
|
<p><code>subscribe("/waku2/xxx", "/mesh/v1.1.1/xxx")</code></p>
|
||
|
|
<h1 id="static-sharding">
|
||
|
|
Static Sharding
|
||
|
|
<a class="anchor" href="#static-sharding">#</a>
|
||
|
|
</h1>
|
||
|
|
<p><em>Static sharding</em> offers a set of shards with fixed names.
|
||
|
|
Assigning content topics to specific shards is up to app protocols,
|
||
|
|
but the discovery of these shards is managed by Waku.</p>
|
||
|
|
<p>These shards are managed in an array of $2^16$ shard clusters.
|
||
|
|
A shard cluster, in turn, contains 64 shards.
|
||
|
|
A shard cluster is either globally available to all apps (like the default pubsub topic),
|
||
|
|
specific for an app protocol,
|
||
|
|
or reserved for automatic sharding (see next section).
|
||
|
|
In total, there are $2^16 * 64 = 4194304$ shards for which Waku manages discovery.</p>
|
||
|
|
<p>App protocols can either choose to use global shards, or app specific shards.
|
||
|
|
(In future versions of this document, automatic sharding, described in the next section, will become the default.)</p>
|
||
|
|
<p>Like the <a href="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml">IANA ports</a>,
|
||
|
|
shard clusters are divided into ranges:</p>
|
||
|
|
<table>
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>index (range)</th>
|
||
|
|
<th>usage</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td>0</td>
|
||
|
|
<td>global</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>1 - 15</td>
|
||
|
|
<td>reserved</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>16 - 1023</td>
|
||
|
|
<td>specific app protocols</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>1024 - 49125</td>
|
||
|
|
<td>all app protocols</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>49152 - 65535</td>
|
||
|
|
<td>automatic sharding</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>The informational RFC <a href="/spec/52">52/WAKU2-RELAY-STATIC-SHARD-ALLOC</a> lists the current index allocations.</p>
|
||
|
|
<p>The global shard with index 0 and the “all app protocols” range are treated in the same way,
|
||
|
|
but choosing shards in the global cluster has a higher probability of sharing the shard with other apps.
|
||
|
|
This offers k-anonymity and better connectivity, but comes at a higher bandwidth cost.</p>
|
||
|
|
<p>The name of the pubsub topic corresponding to a given static shard is specified as</p>
|
||
|
|
<p><code>/waku/2/static-rshard/<shard_cluster_index>/<shard_number></code>,</p>
|
||
|
|
<p>an example for the 2nd shard in the global shard cluster:</p>
|
||
|
|
<p><code>/waku/2/static-rshard/0/2</code>.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p><em>Note</em>: Because <em>all</em> shards distribute payload defined in <a href="spec/14/">14/WAKU2-MESSAGE</a> via <a href="https://developers.google.com/protocol-buffers/">protocol buffers</a>,
|
||
|
|
the pubsub topic name does not explicitly add <code>/proto</code> to indicate protocol buffer encoding.
|
||
|
|
We use <code>rshard</code> to indicate it is a relay shards; further shard types might follow in the future.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>From an app point of view, a subscription to a content topic <code>waku2/xxx</code> on a static shard would look like:</p>
|
||
|
|
<p><code>subscribe("/waku2/xxx", 43)</code></p>
|
||
|
|
<p>for global shard 43.
|
||
|
|
And for shard 43 of the Status app (which has allocated index 16):</p>
|
||
|
|
<p><code>subscribe("/waku2/xxx", 16, 43)</code></p>
|
||
|
|
<h2 id="discovery">
|
||
|
|
Discovery
|
||
|
|
<a class="anchor" href="#discovery">#</a>
|
||
|
|
</h2>
|
||
|
|
<p>Waku v2 supports the discovery of peers within static shards,
|
||
|
|
so app protocols do not have to implement their own discovery method.
|
||
|
|
To enable discovery of static shards,
|
||
|
|
the array of shard clusters is added to <a href="https://rfc.vac.dev/spec/31/">31/WAKU2-ENR</a>.
|
||
|
|
The representation is specified as follows.</p>
|
||
|
|
<p>The array index is a 2 bytes field.
|
||
|
|
As the array is expected to be sparse (and because ENRs do not feature an array/map type),
|
||
|
|
the ENR contains a list of occupied array slots.
|
||
|
|
Each shard cluster is represented by a bit vector,
|
||
|
|
which indicates which shards of the respective shard cluster the node is part of
|
||
|
|
(see Ethereum ENR sharding bit vector <a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata">here</a>
|
||
|
|
and <a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#sync-committee-subnet-stability">here</a>).
|
||
|
|
The right-most bit in the bit vector represents shard <code>0</code>, the left-most bit represents shard <code>63</code>.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p><em>Note</em>: We will update the <a href="https://rfc.vac.dev/spec/31/">31/WAKU2-ENR</a> accordingly, once this RFC moves forward.)</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Having a static shard participation indication as part of the ENR allows nodes
|
||
|
|
to discover peers that are part of shards via <a href="/spec/33/">33/WAKU2-DISCV5</a> as well as via DNS.</p>
|
||
|
|
<p>In its current raw version, this document proposes two representations in the ENR.
|
||
|
|
(Which one to choose is open for discussion in the raw phase of the document.
|
||
|
|
Future versions will only specify a single representation.)</p>
|
||
|
|
<h3 id="one-key-per-shard-cluster">
|
||
|
|
One key per Shard Cluster
|
||
|
|
<a class="anchor" href="#one-key-per-shard-cluster">#</a>
|
||
|
|
</h3>
|
||
|
|
<p>For each shard cluster a node is part of, the node adds a separate key to its ENR.
|
||
|
|
The representation corresponds to <a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#sync-committee-subnet-stability">Ethereum shard ENRs</a>).</p>
|
||
|
|
<p>Example</p>
|
||
|
|
<table>
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>key</th>
|
||
|
|
<th>value</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td><code>rshard-0</code></td>
|
||
|
|
<td><code>0x0000100000000000</code></td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td><code>rshard-16</code></td>
|
||
|
|
<td><code>0x0000100000003000</code></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>This example node is part of shard <code>45</code> in the global shard cluster,
|
||
|
|
and part shards <code>13</code>, <code>14</code>, and <code>45</code> in the Status main-net shard cluster.</p>
|
||
|
|
<p>This method is easier to read.
|
||
|
|
It is feasible, assuming nodes are only part of a few apps using specific shard clusters.</p>
|
||
|
|
<h3 id="single-key">
|
||
|
|
Single Key
|
||
|
|
<a class="anchor" href="#single-key">#</a>
|
||
|
|
</h3>
|
||
|
|
<p>Example</p>
|
||
|
|
<table>
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>key</th>
|
||
|
|
<th>value</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td><code>rshards</code></td>
|
||
|
|
<td><code>num_shards</code> | 0u16 | <code>0x0000100000000000</code> | 16u16 | <code>0x0000100000003000</code></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>The two-byte index uses network byte order.</p>
|
||
|
|
<h1 id="automatic-sharding">
|
||
|
|
Automatic Sharding
|
||
|
|
<a class="anchor" href="#automatic-sharding">#</a>
|
||
|
|
</h1>
|
||
|
|
<blockquote>
|
||
|
|
<p><em>Note:</em> Automatic sharding is not yet part of this specification.
|
||
|
|
This section merely serves as an outlook.
|
||
|
|
A specification of automatic sharding will be added to this document in a future version.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Automatic sharding is a method for scaling Waku relay in the number of (smaller) content topics.
|
||
|
|
It automatically maps Waku content topics to pubsub topics.
|
||
|
|
Clients and protocols building on Waku relay only see content topics, while Waku relay internally manages the mapping.
|
||
|
|
This provides both scaling as well as removes confusion about content and pubsub topics on the consumer side.</p>
|
||
|
|
<p>From an app point of view, a subscription to a content topic <code>waku2/xxx</code> using automatic sharding would look like:</p>
|
||
|
|
<p><code>subscribe("/waku2/xxx", auto=true)</code></p>
|
||
|
|
<p>The app is oblivious to the pubsub topic layer.
|
||
|
|
(Future versions could deprecate the default pubsub topic and remove the necessity for <code>auto=true</code>.)</p>
|
||
|
|
<p><em>The basic idea behind automatic sharding</em>:
|
||
|
|
Content topics are mapped using <a href="https://en.wikipedia.org/wiki/Consistent_hashing">consistent hashing</a>.
|
||
|
|
Like with DHTs, the hash space is split into parts,
|
||
|
|
each covered by a Pubsub topic (mesh network) that carries content topics which are mapped into the respective part of the hash space.</p>
|
||
|
|
<p>There are (at least) two issues that have to be solved: <em>Hot spots</em> and <em>Discovery</em> (see next subsection).</p>
|
||
|
|
<p>Hot spots occur (similar to DHTs), when a specific mesh network becomes responsible for (several) large multicast groups (content topics).
|
||
|
|
The opposite problem occurs when a mesh only carries multicast groups with very few participants: this might cause bad connectivity within the mesh.
|
||
|
|
Our research goal here is finding efficient ways of distribution.
|
||
|
|
We could get inspired by the DHT literature.
|
||
|
|
We also have to consider:
|
||
|
|
If a node is part of many content topics which are all spread over different shards,
|
||
|
|
the node will potentially be exposed to a lot of network traffic.</p>
|
||
|
|
<h2 id="discovery-1">
|
||
|
|
Discovery
|
||
|
|
<a class="anchor" href="#discovery-1">#</a>
|
||
|
|
</h2>
|
||
|
|
<p>For the discovery of automatic shards this document specifies two methods (the second method will be detailed in a future version of this document).</p>
|
||
|
|
<p>The first method uses the discovery introduced above in the context of static shards.
|
||
|
|
The index range <code>49152 - 65535</code> is reserved for automatic sharding.
|
||
|
|
Each index can be seen as a hash bucket.
|
||
|
|
Consistent hashing maps content topics in one of these buckets.</p>
|
||
|
|
<p>The second discovery method will be a successor to the first method,
|
||
|
|
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,
|
||
|
|
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.
|
||
|
|
We currently use <a href="https://rfc.vac.dev/spec/33/">33/WAKU2-DISCV5</a> for discovery,
|
||
|
|
which is based on Ethereum’s <a href="https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md">discv5</a>.
|
||
|
|
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.
|
||
|
|
Our <a href="https://vac.dev/wakuv2-apd">research log post</a> explains this in more detail.
|
||
|
|
Adding efficient (but still preserving resilience) capability discovery to discv5 is ongoing research.
|
||
|
|
<a href="https://github.com/harnen/service-discovery-paper">A paper on this</a> has been completed,
|
||
|
|
but the <a href="https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md">Ethereum discv5 specification</a>
|
||
|
|
has yet to be updated.
|
||
|
|
When the new capability discovery is available,
|
||
|
|
this document will be updated with a specification of the second discovery method.
|
||
|
|
The transition to the second method will be seamless and fully backwards compatible because nodes can still advertise and discover shard memberships in ENRs.</p>
|
||
|
|
<h1 id="securityprivacy-considerations">
|
||
|
|
Security/Privacy Considerations
|
||
|
|
<a class="anchor" href="#securityprivacy-considerations">#</a>
|
||
|
|
</h1>
|
||
|
|
<p>See <a href="/spec/45">45/WAKU2-ADVERSARIAL-MODELS</a>, especially the parts on k-anonymity.
|
||
|
|
We will add more on security considerations in future versions of this document.</p>
|
||
|
|
<h2 id="receiver-anonymity">
|
||
|
|
Receiver Anonymity
|
||
|
|
<a class="anchor" href="#receiver-anonymity">#</a>
|
||
|
|
</h2>
|
||
|
|
<p>The strength of receiver anonymity, i.e. topic receiver unlinkablity,
|
||
|
|
depends on the number of content topics (<code>k</code>) that get mapped onto a single pubsub topic (shard).
|
||
|
|
For <em>named</em> and <em>static</em> sharding this responsibility is at the app protocol layer.</p>
|
||
|
|
<h1 id="copyright">
|
||
|
|
Copyright
|
||
|
|
<a class="anchor" href="#copyright">#</a>
|
||
|
|
</h1>
|
||
|
|
<p>Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>.</p>
|
||
|
|
<h1 id="references">
|
||
|
|
References
|
||
|
|
<a class="anchor" href="#references">#</a>
|
||
|
|
</h1>
|
||
|
|
<ul>
|
||
|
|
<li><a href="/spec/11/">11/WAKU2-RELAY</a></li>
|
||
|
|
<li><a href="https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks">Unstructured P2P network</a></li>
|
||
|
|
<li><a href="/spec/33/">33/WAKU2-DISCV5</a></li>
|
||
|
|
<li><a href="https://rfc.vac.dev/spec/31/">31/WAKU2-ENR</a></li>
|
||
|
|
<li><a href="/spec/23/">23/WAKU2-TOPICS</a></li>
|
||
|
|
<li><a href="/spec/51/">51/WAKU2-RELAY-SHARDING</a></li>
|
||
|
|
<li><a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata">Ethereum ENR sharding bit vector</a></li>
|
||
|
|
<li><a href="https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md">Ethereum discv5 specification</a></li>
|
||
|
|
<li><a href="https://en.wikipedia.org/wiki/Consistent_hashing">consistent hashing</a>.</li>
|
||
|
|
<li><a href="https://vac.dev/wakuv2-apd">Research log: Waku Discovery</a></li>
|
||
|
|
<li><a href="/spec/45">45/WAKU2-ADVERSARIAL-MODELS</a></li>
|
||
|
|
</ul>
|
||
|
|
</article>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<footer class="book-footer">
|
||
|
|
|
||
|
|
<div class="flex flex-wrap justify-between">
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</footer>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<div class="book-comments">
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<label for="menu-control" class="hidden book-menu-overlay"></label>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<aside class="book-toc">
|
||
|
|
<div class="book-toc-content">
|
||
|
|
|
||
|
|
|
||
|
|
<nav id="TableOfContents">
|
||
|
|
<ul>
|
||
|
|
<li><a href="#discovery">Discovery</a>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#one-key-per-shard-cluster">One key per Shard Cluster</a></li>
|
||
|
|
<li><a href="#single-key">Single Key</a></li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#discovery-1">Discovery</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#receiver-anonymity">Receiver Anonymity</a></li>
|
||
|
|
</ul>
|
||
|
|
</nav>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</aside>
|
||
|
|
|
||
|
|
</main>
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|