vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
rfc/spec/51/index.html

742 lines
28 KiB
HTML
Raw Blame History

<!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 (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 (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&#43;JXczVV5nG&#43;8gEPyM=">
<script defer src="/en.search.min.5ae14046c81918d2a9c50127aabc329f4f345e6c256f04e9ae05f6d48759463d.js" integrity="sha256-WuFARsgZGNKpxQEnqrwyn080XmwlbwTprgX21IdZRj0="></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-V1</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>
<li><a href="/spec/57/">57/STATUS-Simple-Scaling</a></li>
<li><a href="/spec/58/">58/RLN-V2</a></li>
<li><a href="/spec/61/">61/STATUS-Community-History-Archives</a></li>
<li><a href="/spec/63/">63/STATUS-Keycard-Usage</a></li>
<li><a href="/spec/64/">64/WAKU2-NETWORK</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>
<li><a href="/spec/53/">53/WAKU2-X3DH</a></li>
<li><a href="/spec/54/">54/WAKU2-X3DH-SESSIONS</a></li>
<li><a href="/spec/55/">55/STATUS-1TO1-CHAT</a></li>
<li><a href="/spec/56/">56/STATUS-COMMUNITIES</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="#abstract">Abstract</a></li>
<li><a href="#background-and-motivation">Background and Motivation</a></li>
<li><a href="#named-sharding">Named Sharding</a></li>
<li><a href="#static-sharding">Static Sharding</a>
<ul>
<li><a href="#discovery">Discovery</a>
<ul>
<li><a href="#index-list">Index List</a></li>
<li><a href="#bit-vector">Bit Vector</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#automatic-sharding">Automatic Sharding</a>
<ul>
<li>
<ul>
<li><a href="#algorithm">Algorithm</a></li>
<li><a href="#example">Example</a></li>
</ul>
</li>
<li><a href="#content-topics-format-for-autosharding">Content Topics Format for Autosharding</a>
<ul>
<li><a href="#example-1">Example</a></li>
<li><a href="#generation">Generation</a></li>
<li><a href="#topic-design">Topic Design</a></li>
</ul>
</li>
<li><a href="#problems">Problems</a>
<ul>
<li><a href="#hot-spots">Hot Spots</a></li>
<li><a href="#discovery-1">Discovery</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#securityprivacy-considerations">Security/Privacy Considerations</a>
<ul>
<li><a href="#receiver-anonymity">Receiver Anonymity</a></li>
</ul>
</li>
<li><a href="#copyright">Copyright</a></li>
<li><a href="#references">References</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>
<li>Contributors:
Simon-Pierre Vivier <a href="mailto:simvivier@status.im">simvivier@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
(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.
It is RECOMMENDED for App protocols to 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>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(&quot;/waku2/xxx&quot;, &quot;/mesh/v1.1.1/xxx&quot;)</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>Static shards are managed in shard clusters of 1024 shards per cluster.
Waku static sharding can manage $2^16$ shard clusters.
Each shard cluster is identified by its index (between $0$ and $2^16-1$).</p>
<p>A specific shard cluster is either globally available to all apps,
specific for an app protocol,
or reserved for automatic sharding (see next section).</p>
<blockquote>
<p><em>Note:</em> This leads to $2^16 * 1024 = 2^26$ shards for which Waku manages discovery.</p>
</blockquote>
<p>App protocols can either choose to use global shards, or app specific shards.</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 - 49152</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 &ldquo;all app protocols&rdquo; 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/rs/&lt;shard_cluster_index&gt;/&lt;shard_number&gt;</code>,</p>
<p>an example for the 2nd shard in the global shard cluster:</p>
<p><code>/waku/2/rs/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>rs</code> to indicate these are <em>relay shard</em> clusters; 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(&quot;/waku2/xxx&quot;, 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(&quot;/waku2/xxx&quot;, 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.</p>
<p>Nodes add information about their shard participation in their <a href="https://rfc.vac.dev/spec/31/">31/WAKU2-ENR</a>.
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>
<blockquote>
<p><em>Note:</em> In the current version of this document,
sharding information is directly added to the ENR.
(see Ethereum ENR sharding bit vector <a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata">here</a>
Static relay sharding supports 1024 shards per cluster, leading to a flag field of 128 bytes.
This already takes half (including index and key) of the ENR space of 300 bytes.
For this reason, the current specification only supports a single shard cluster per node.
In future versions, we will add further (hierarchical) discovery methods.
We will update <a href="https://rfc.vac.dev/spec/31/">31/WAKU2-ENR</a> accordingly, once this RFC moves forward.</p>
</blockquote>
<p>This document specifies two ways of indicating shard cluster participation.
The index list SHOULD be used for nodes that participante in fewer than 64 shards,
the bit vector representation SHOULD be used for nodes participating in 64 or more shards.
Nodes MUST NOT use both index list (<code>rs</code>) and bit vector (<code>rsv</code>) in a single ENR.
ENRs with both <code>rs</code> and <code>rsv</code> keys SHOULD be ignored.
Nodes MAY interpret <code>rs</code> in such ENRs, but MUST ignore <code>rsv</code>.</p>
<h3 id="index-list">
Index List
<a class="anchor" href="#index-list">#</a>
</h3>
<table>
<thead>
<tr>
<th>key</th>
<th>value</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>rs</code></td>
<td>&lt;2-byte shard cluster index&gt; | &lt;1-byte length&gt; | &lt;2-byte shard index&gt; | &hellip; | &lt;2-byte shard index&gt;</td>
</tr>
</tbody>
</table>
<p>The ENR key is <code>rs</code>.
The value is comprised of</p>
<ul>
<li>a two-byte shard cluster index in network byte order, concatenated with</li>
<li>a one-byte length field holding the number of shards in the given shard cluster, concatenated with</li>
<li>two-byte shard indices in network byte order</li>
</ul>
<p>Example:</p>
<table>
<thead>
<tr>
<th>key</th>
<th>value</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>rs</code></td>
<td>16u16 | 3u8 | 13u16 | 14u16 | 45u16</td>
</tr>
</tbody>
</table>
<p>This example node is part of shards <code>13</code>, <code>14</code>, and <code>45</code> in the Status main-net shard cluster (index 16).</p>
<h3 id="bit-vector">
Bit Vector
<a class="anchor" href="#bit-vector">#</a>
</h3>
<table>
<thead>
<tr>
<th>key</th>
<th>value</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>rsv</code></td>
<td>&lt;2-byte shard cluster index&gt; | &lt;128-byte flag field&gt;</td>
</tr>
</tbody>
</table>
<p>The ENR key is <code>rsv</code>.
The value is comprised of a two-byte shard cluster index in network byte order concatenated with a 128-byte wide bit vector.
The bit vector indicates which shards of the respective shard cluster the node is part of.
The right-most bit in the bit vector represents shard <code>0</code>, the left-most bit represents shard <code>1023</code>.
The representation in the ENR is inspired by <a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#sync-committee-subnet-stability">Ethereum shard ENRs</a>),
and <a href="https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#sync-committee-subnet-stability">this</a>).</p>
<p>Example:</p>
<table>
<thead>
<tr>
<th>key</th>
<th>value</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>rsv</code></td>
<td>16u16 | <code>0x[...]0000100000003000</code></td>
</tr>
</tbody>
</table>
<p>The <code>[...]</code> in the example indicates 120 <code>0</code> bytes.
This example node is part of shards <code>13</code>, <code>14</code>, and <code>45</code> in the Status main-net shard cluster (index 16).
(This is just for illustration purposes, a node that is only part of three shards should use the index list method specified above.)</p>
<h1 id="automatic-sharding">
Automatic Sharding
<a class="anchor" href="#automatic-sharding">#</a>
</h1>
<p>Autosharding selects shards automatically and is the default behavior for shard choice.
The other choices being static and named sharding as seen in previous sections.
Shards (pubsub topics) SHOULD be computed from content topics with the procedure below.</p>
<h3 id="algorithm">
Algorithm
<a class="anchor" href="#algorithm">#</a>
</h3>
<p>Hash using Sha2-256 the concatenation of
the content topic <code>application</code> field (UTF-8 string of N bytes) and
the <code>version</code> (UTF-8 string of N bytes).
The shard to use is the modulo of the hash by the number of shards in the network.</p>
<h3 id="example">
Example
<a class="anchor" href="#example">#</a>
</h3>
<table>
<thead>
<tr>
<th>Field</th>
<th>Value</th>
<th>Hex</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>application</code></td>
<td>&ldquo;myapp&rdquo;</td>
<td>0x6d79617070</td>
</tr>
<tr>
<td><code>version</code></td>
<td>&ldquo;1&rdquo;</td>
<td>0x31</td>
</tr>
<tr>
<td><code>network shards</code></td>
<td>8</td>
<td>0x8</td>
</tr>
</tbody>
</table>
<ul>
<li>SHA2-256 of <code>0x6d7961707031</code> is <code>0x8e541178adbd8126068c47be6a221d77d64837221893a8e4e53139fb802d4928</code></li>
<li><code>0x8e541178adbd8126068c47be6a221d77d64837221893a8e4e53139fb802d4928</code> MOD <code>8</code> equals <code>0</code></li>
<li>The shard to use has index 0</li>
</ul>
<h2 id="content-topics-format-for-autosharding">
Content Topics Format for Autosharding
<a class="anchor" href="#content-topics-format-for-autosharding">#</a>
</h2>
<p>Content topics MUST follow the format in <a href="https://rfc.vac.dev/spec/23/#content-topic-format">23/WAKU2-TOPICS</a>.
In addition, a generation prefix MAY be added to content topics.
When omitted default values are used.
Generation default value is <code>0</code>.</p>
<ul>
<li>The full length format is <code>/{generation}/{application-name}/{version-of-the-application}/{content-topic-name}/{encoding}</code></li>
<li>The short length format is <code>/{application-name}/{version-of-the-application}/{content-topic-name}/{encoding}</code></li>
</ul>
<h3 id="example-1">
Example
<a class="anchor" href="#example-1">#</a>
</h3>
<ul>
<li>Full length <code>/0/myapp/1/mytopic/cbor</code></li>
<li>Short length <code>/myapp/1/mytopic/cbor</code></li>
</ul>
<h3 id="generation">
Generation
<a class="anchor" href="#generation">#</a>
</h3>
<p>The generation number monotonously increases and indirectly refers to the total number of shards of the Waku Network.</p>
<!-- raw HTML omitted -->
<h3 id="topic-design">
Topic Design
<a class="anchor" href="#topic-design">#</a>
</h3>
<p>Content topics have 2 purposes: filtering and routing.
Filtering is done by changing the <code>{content-topic-name}</code> field.
As this part is not hashed, it will not affect routing (shard selection).
The <code>{application-name}</code> and <code>{version-of-the-application}</code> fields do affect routing.
Using multiple content topics with different <code>{application-name}</code> field has advantages and disadvantages.
It increases the traffic a relay node is subjected to when subscribed to all topics.
It also allows relay and light nodes to subscribe to a subset of all topics.</p>
<h2 id="problems">
Problems
<a class="anchor" href="#problems">#</a>
</h2>
<h3 id="hot-spots">
Hot Spots
<a class="anchor" href="#hot-spots">#</a>
</h3>
<p>Hot spots occur (similar to DHTs), when a specific mesh network (shard) 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.</p>
<p>The current autosharding method does not solve this problem.</p>
<blockquote>
<p><em>Note:</em> Automatic sharding based on network traffic measurements to avoid hot spots in not part of this specification.</p>
</blockquote>
<h3 id="discovery-1">
Discovery
<a class="anchor" href="#discovery-1">#</a>
</h3>
<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.</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&rsquo;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>), as a proxy for the number of peers and messages, 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://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="#abstract">Abstract</a></li>
<li><a href="#background-and-motivation">Background and Motivation</a></li>
<li><a href="#named-sharding">Named Sharding</a></li>
<li><a href="#static-sharding">Static Sharding</a>
<ul>
<li><a href="#discovery">Discovery</a>
<ul>
<li><a href="#index-list">Index List</a></li>
<li><a href="#bit-vector">Bit Vector</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#automatic-sharding">Automatic Sharding</a>
<ul>
<li>
<ul>
<li><a href="#algorithm">Algorithm</a></li>
<li><a href="#example">Example</a></li>
</ul>
</li>
<li><a href="#content-topics-format-for-autosharding">Content Topics Format for Autosharding</a>
<ul>
<li><a href="#example-1">Example</a></li>
<li><a href="#generation">Generation</a></li>
<li><a href="#topic-design">Topic Design</a></li>
</ul>
</li>
<li><a href="#problems">Problems</a>
<ul>
<li><a href="#hot-spots">Hot Spots</a></li>
<li><a href="#discovery-1">Discovery</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#securityprivacy-considerations">Security/Privacy Considerations</a>
<ul>
<li><a href="#receiver-anonymity">Receiver Anonymity</a></li>
</ul>
</li>
<li><a href="#copyright">Copyright</a></li>
<li><a href="#references">References</a></li>
</ul>
</nav>
</div>
</aside>
</main>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink