vacp2p/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-09 22:08:07 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
e7d3de896642f16de25843e63cc72dc131d11419
rfc-index/status/raw/simple-scaling.html
status-im-auto e7d3de8966 Update documentation
2025-12-22 13:04:47 +00:00

781 lines
62 KiB
HTML
Raw Blame History

<!DOCTYPE HTML>
<html lang="en" class="ayu" dir="ltr">
<head>
<!-- Book generated using mdBook -->
<meta charset="UTF-8">
<title>Simple Scaling - Vac RFC</title>
<!-- Custom HTML head -->
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#ffffff">
<link rel="icon" href="../../favicon.svg">
<link rel="shortcut icon" href="../../favicon.png">
<link rel="stylesheet" href="../../css/variables.css">
<link rel="stylesheet" href="../../css/general.css">
<link rel="stylesheet" href="../../css/chrome.css">
<link rel="stylesheet" href="../../css/print.css" media="print">
<!-- Fonts -->
<link rel="stylesheet" href="../../FontAwesome/css/font-awesome.css">
<link rel="stylesheet" href="../../fonts/fonts.css">
<!-- Highlight.js Stylesheets -->
<link rel="stylesheet" href="../../highlight.css">
<link rel="stylesheet" href="../../tomorrow-night.css">
<link rel="stylesheet" href="../../ayu-highlight.css">
<!-- Custom theme stylesheets -->
<link rel="stylesheet" href="../../custom.css">
</head>
<body class="sidebar-visible no-js">
<div id="body-container">
<!-- Provide site root to javascript -->
<script>
var path_to_root = "../../";
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "navy" : "ayu";
</script>
<!-- Work around some values being stored in localStorage wrapped in quotes -->
<script>
try {
var theme = localStorage.getItem('mdbook-theme');
var sidebar = localStorage.getItem('mdbook-sidebar');
if (theme.startsWith('"') && theme.endsWith('"')) {
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
}
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
}
} catch (e) { }
</script>
<!-- Set the theme before any content is loaded, prevents flash -->
<script>
var theme;
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
if (theme === null || theme === undefined) { theme = default_theme; }
var html = document.querySelector('html');
html.classList.remove('ayu')
html.classList.add(theme);
var body = document.querySelector('body');
body.classList.remove('no-js')
body.classList.add('js');
</script>
<input type="checkbox" id="sidebar-toggle-anchor" class="hidden">
<!-- Hide / unhide sidebar before it is displayed -->
<script>
var body = document.querySelector('body');
var sidebar = null;
var sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
if (document.body.clientWidth >= 1080) {
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
sidebar = sidebar || 'visible';
} else {
sidebar = 'hidden';
}
sidebar_toggle.checked = sidebar === 'visible';
body.classList.remove('sidebar-visible');
body.classList.add("sidebar-" + sidebar);
</script>
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
<div class="sidebar-scrollbox">
<ol class="chapter"><li class="chapter-item expanded affix "><a href="../../index.html">Introduction</a></li><li class="chapter-item expanded "><a href="../../vac/index.html"><strong aria-hidden="true">1.</strong> Vac</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../vac/1/coss.html"><strong aria-hidden="true">1.1.</strong> 1/COSS</a></li><li class="chapter-item expanded "><a href="../../vac/2/mvds.html"><strong aria-hidden="true">1.2.</strong> 2/MVDS</a></li><li class="chapter-item expanded "><a href="../../vac/3/remote-log.html"><strong aria-hidden="true">1.3.</strong> 3/Remote Log</a></li><li class="chapter-item expanded "><a href="../../vac/4/mvds-meta.html"><strong aria-hidden="true">1.4.</strong> 4/MVDS Meta</a></li><li class="chapter-item expanded "><a href="../../vac/25/libp2p-dns-discovery.html"><strong aria-hidden="true">1.5.</strong> 25/Libp2p DNS Discovery</a></li><li class="chapter-item expanded "><a href="../../vac/32/rln-v1.html"><strong aria-hidden="true">1.6.</strong> 32/RLN-V1</a></li><li class="chapter-item expanded "><a href="../../vac/raw/index.html"><strong aria-hidden="true">1.7.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../vac/raw/consensus-hashgraphlike.html"><strong aria-hidden="true">1.7.1.</strong> Consensus Hashgraphlike</a></li><li class="chapter-item expanded "><a href="../../vac/raw/decentralized-messaging-ethereum.html"><strong aria-hidden="true">1.7.2.</strong> Decentralized Messaging Ethereum</a></li><li class="chapter-item expanded "><a href="../../vac/raw/eth-mls-offchain.html"><strong aria-hidden="true">1.7.3.</strong> ETH MLS Offchain</a></li><li class="chapter-item expanded "><a href="../../vac/raw/eth-mls-onchain.html"><strong aria-hidden="true">1.7.4.</strong> ETH MLS Onchain</a></li><li class="chapter-item expanded "><a href="../../vac/raw/deleted/eth-secpm.html"><strong aria-hidden="true">1.7.5.</strong> ETH SecPM</a></li><li class="chapter-item expanded "><a href="../../vac/raw/gossipsub-tor-push.html"><strong aria-hidden="true">1.7.6.</strong> Gossipsub Tor Push</a></li><li class="chapter-item expanded "><a href="../../vac/raw/logos-capability-discovery.html"><strong aria-hidden="true">1.7.7.</strong> Logos Capability Discovery</a></li><li class="chapter-item expanded "><a href="../../vac/raw/mix.html"><strong aria-hidden="true">1.7.8.</strong> Mix</a></li><li class="chapter-item expanded "><a href="../../vac/raw/noise-x3dh-double-ratchet.html"><strong aria-hidden="true">1.7.9.</strong> Noise X3DH Double Ratchet</a></li><li class="chapter-item expanded "><a href="../../vac/raw/rln-interep-spec.html"><strong aria-hidden="true">1.7.10.</strong> RLN Interep Spec</a></li><li class="chapter-item expanded "><a href="../../vac/raw/rln-stealth-commitments.html"><strong aria-hidden="true">1.7.11.</strong> RLN Stealth Commitments</a></li><li class="chapter-item expanded "><a href="../../vac/raw/rln-v2.html"><strong aria-hidden="true">1.7.12.</strong> RLN-V2</a></li><li class="chapter-item expanded "><a href="../../vac/raw/sds.html"><strong aria-hidden="true">1.7.13.</strong> SDS</a></li></ol></li><li class="chapter-item expanded "><a href="../../vac/template.html"><strong aria-hidden="true">1.8.</strong> Template</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/index.html"><strong aria-hidden="true">2.</strong> Waku</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/core/index.html"><strong aria-hidden="true">2.1.</strong> Standards - Core</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/core/10/waku2.html"><strong aria-hidden="true">2.1.1.</strong> 10/Waku2</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/11/relay.html"><strong aria-hidden="true">2.1.2.</strong> 11/Relay</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/12/filter.html"><strong aria-hidden="true">2.1.3.</strong> 12/Filter</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/13/store.html"><strong aria-hidden="true">2.1.4.</strong> 13/Store</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/14/message.html"><strong aria-hidden="true">2.1.5.</strong> 14/Message</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/15/bridge.html"><strong aria-hidden="true">2.1.6.</strong> 15/Bridge</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/17/rln-relay.html"><strong aria-hidden="true">2.1.7.</strong> 17/RLN Relay</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/19/lightpush.html"><strong aria-hidden="true">2.1.8.</strong> 19/Lightpush</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/31/enr.html"><strong aria-hidden="true">2.1.9.</strong> 31/ENR</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/33/discv5.html"><strong aria-hidden="true">2.1.10.</strong> 33/Discv5</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/34/peer-exchange.html"><strong aria-hidden="true">2.1.11.</strong> 34/Peer Exchange</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/36/bindings-api.html"><strong aria-hidden="true">2.1.12.</strong> 36/Bindings API</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/64/network.html"><strong aria-hidden="true">2.1.13.</strong> 64/Network</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/66/metadata.html"><strong aria-hidden="true">2.1.14.</strong> 66/Metadata</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/standards/application/index.html"><strong aria-hidden="true">2.2.</strong> Standards - Application</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/application/20/toy-eth-pm.html"><strong aria-hidden="true">2.2.1.</strong> 20/Toy ETH PM</a></li><li class="chapter-item expanded "><a href="../../waku/standards/application/26/payload.html"><strong aria-hidden="true">2.2.2.</strong> 26/Payload</a></li><li class="chapter-item expanded "><a href="../../waku/standards/application/53/x3dh.html"><strong aria-hidden="true">2.2.3.</strong> 53/X3DH</a></li><li class="chapter-item expanded "><a href="../../waku/standards/application/54/x3dh-sessions.html"><strong aria-hidden="true">2.2.4.</strong> 54/X3DH Sessions</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/index.html"><strong aria-hidden="true">2.3.</strong> Standards - Legacy</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/legacy/6/waku1.html"><strong aria-hidden="true">2.3.1.</strong> 6/Waku1</a></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/7/data.html"><strong aria-hidden="true">2.3.2.</strong> 7/Data</a></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/8/mail.html"><strong aria-hidden="true">2.3.3.</strong> 8/Mail</a></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/9/rpc.html"><strong aria-hidden="true">2.3.4.</strong> 9/RPC</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/informational/index.html"><strong aria-hidden="true">2.4.</strong> Informational</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/informational/22/toy-chat.html"><strong aria-hidden="true">2.4.1.</strong> 22/Toy Chat</a></li><li class="chapter-item expanded "><a href="../../waku/informational/23/topics.html"><strong aria-hidden="true">2.4.2.</strong> 23/Topics</a></li><li class="chapter-item expanded "><a href="../../waku/informational/27/peers.html"><strong aria-hidden="true">2.4.3.</strong> 27/Peers</a></li><li class="chapter-item expanded "><a href="../../waku/informational/29/config.html"><strong aria-hidden="true">2.4.4.</strong> 29/Config</a></li><li class="chapter-item expanded "><a href="../../waku/informational/30/adaptive-nodes.html"><strong aria-hidden="true">2.4.5.</strong> 30/Adaptive Nodes</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/deprecated/index.html"><strong aria-hidden="true">2.5.</strong> Deprecated</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/deprecated/5/waku0.html"><strong aria-hidden="true">2.5.1.</strong> 5/Waku0</a></li><li class="chapter-item expanded "><a href="../../waku/deprecated/16/rpc.html"><strong aria-hidden="true">2.5.2.</strong> 16/RPC</a></li><li class="chapter-item expanded "><a href="../../waku/deprecated/18/swap.html"><strong aria-hidden="true">2.5.3.</strong> 18/Swap</a></li><li class="chapter-item expanded "><a href="../../waku/deprecated/fault-tolerant-store.html"><strong aria-hidden="true">2.5.4.</strong> Fault Tolerant Store</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="../../nomos/index.html"><strong aria-hidden="true">3.</strong> Nomos</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../nomos/raw/index.html"><strong aria-hidden="true">3.1.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../nomos/raw/nomosda-encoding.html"><strong aria-hidden="true">3.1.1.</strong> NomosDA Encoding</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/nomosda-network.html"><strong aria-hidden="true">3.1.2.</strong> NomosDA Network</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-hardware-requirements.html"><strong aria-hidden="true">3.1.3.</strong> P2P Hardware Requirements</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-nat-solution.html"><strong aria-hidden="true">3.1.4.</strong> P2P NAT Solution</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-network-bootstrapping.html"><strong aria-hidden="true">3.1.5.</strong> P2P Network Bootstrapping</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-network.html"><strong aria-hidden="true">3.1.6.</strong> P2P Network</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/sdp.html"><strong aria-hidden="true">3.1.7.</strong> SDP</a></li></ol></li><li class="chapter-item expanded "><a href="../../nomos/deprecated/index.html"><strong aria-hidden="true">3.2.</strong> Deprecated</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../nomos/deprecated/claro.html"><strong aria-hidden="true">3.2.1.</strong> Claro</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="../../codex/index.html"><strong aria-hidden="true">4.</strong> Codex</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../codex/raw/index.html"><strong aria-hidden="true">4.1.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../codex/raw/codex-block-exchange.html"><strong aria-hidden="true">4.1.1.</strong> Block Exchange</a></li><li class="chapter-item expanded "><a href="../../codex/raw/codex-marketplace.html"><strong aria-hidden="true">4.1.2.</strong> Marketplace</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="../../status/index.html"><strong aria-hidden="true">5.</strong> Status</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../status/24/curation.html"><strong aria-hidden="true">5.1.</strong> 24/Curation</a></li><li class="chapter-item expanded "><a href="../../status/28/featuring.html"><strong aria-hidden="true">5.2.</strong> 28/Featuring</a></li><li class="chapter-item expanded "><a href="../../status/55/1to1-chat.html"><strong aria-hidden="true">5.3.</strong> 55/1-to-1 Chat</a></li><li class="chapter-item expanded "><a href="../../status/56/communities.html"><strong aria-hidden="true">5.4.</strong> 56/Communities</a></li><li class="chapter-item expanded "><a href="../../status/61/community-history-service.html"><strong aria-hidden="true">5.5.</strong> 61/Community History Service</a></li><li class="chapter-item expanded "><a href="../../status/62/payloads.html"><strong aria-hidden="true">5.6.</strong> 62/Payloads</a></li><li class="chapter-item expanded "><a href="../../status/63/keycard-usage.html"><strong aria-hidden="true">5.7.</strong> 63/Keycard Usage</a></li><li class="chapter-item expanded "><a href="../../status/65/account-address.html"><strong aria-hidden="true">5.8.</strong> 65/Account Address</a></li><li class="chapter-item expanded "><a href="../../status/71/push-notification-server.html"><strong aria-hidden="true">5.9.</strong> 71/Push Notification Server</a></li><li class="chapter-item expanded "><a href="../../status/raw/index.html"><strong aria-hidden="true">5.10.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../status/raw/simple-scaling.html" class="active"><strong aria-hidden="true">5.10.1.</strong> Simple Scaling</a></li><li class="chapter-item expanded "><a href="../../status/raw/status-app-protocols.html"><strong aria-hidden="true">5.10.2.</strong> Status App Protocols</a></li><li class="chapter-item expanded "><a href="../../status/raw/status-mvds.html"><strong aria-hidden="true">5.10.3.</strong> Status MVDS</a></li><li class="chapter-item expanded "><a href="../../status/raw/url-data.html"><strong aria-hidden="true">5.10.4.</strong> URL Data</a></li><li class="chapter-item expanded "><a href="../../status/raw/url-scheme.html"><strong aria-hidden="true">5.10.5.</strong> URL Scheme</a></li></ol></li><li class="chapter-item expanded "><a href="../../status/deprecated/index.html"><strong aria-hidden="true">5.11.</strong> Deprecated</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../status/deprecated/3rd-party.html"><strong aria-hidden="true">5.11.1.</strong> 3rd Party</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/account.html"><strong aria-hidden="true">5.11.2.</strong> Account</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/client.html"><strong aria-hidden="true">5.11.3.</strong> Client</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/dapp-browser-API-usage.html"><strong aria-hidden="true">5.11.4.</strong> Dapp Browser API Usage</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/eips.html"><strong aria-hidden="true">5.11.5.</strong> EIPs</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/ethereum-usage.html"><strong aria-hidden="true">5.11.6.</strong> Ethereum Usage</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/group-chat.html"><strong aria-hidden="true">5.11.7.</strong> Group Chat</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/IPFS-gateway-for-sticker-Pack.html"><strong aria-hidden="true">5.11.8.</strong> IPFS Gateway for Sticker Pack</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/keycard-usage-for-wallet-and-chat-keys.html"><strong aria-hidden="true">5.11.9.</strong> Keycard Usage for Wallet and Chat Keys</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/notifications.html"><strong aria-hidden="true">5.11.10.</strong> Notifications</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/payloads.html"><strong aria-hidden="true">5.11.11.</strong> Payloads</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/push-notification-server.html"><strong aria-hidden="true">5.11.12.</strong> Push Notification Server</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/secure-transport.html"><strong aria-hidden="true">5.11.13.</strong> Secure Transport</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/waku-mailserver.html"><strong aria-hidden="true">5.11.14.</strong> Waku Mailserver</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/waku-usage.html"><strong aria-hidden="true">5.11.15.</strong> Waku Usage</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/whisper-mailserver.html"><strong aria-hidden="true">5.11.16.</strong> Whisper Mailserver</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/whisper-usage.html"><strong aria-hidden="true">5.11.17.</strong> Whisper Usage</a></li></ol></li></ol></li></ol>
</div>
<div id="sidebar-resize-handle" class="sidebar-resize-handle">
<div class="sidebar-resize-indicator"></div>
</div>
</nav>
<!-- Track and set sidebar scroll position -->
<script>
var sidebarScrollbox = document.querySelector('#sidebar .sidebar-scrollbox');
sidebarScrollbox.addEventListener('click', function(e) {
if (e.target.tagName === 'A') {
sessionStorage.setItem('sidebar-scroll', sidebarScrollbox.scrollTop);
}
}, { passive: true });
var sidebarScrollTop = sessionStorage.getItem('sidebar-scroll');
sessionStorage.removeItem('sidebar-scroll');
if (sidebarScrollTop) {
// preserve sidebar scroll position when navigating via links within sidebar
sidebarScrollbox.scrollTop = sidebarScrollTop;
} else {
// scroll sidebar to current active section when navigating via "next/previous chapter" buttons
var activeSection = document.querySelector('#sidebar .active');
if (activeSection) {
activeSection.scrollIntoView({ block: 'center' });
}
}
</script>
<div id="page-wrapper" class="page-wrapper">
<div class="page">
<div id="menu-bar-hover-placeholder"></div>
<div id="menu-bar" class="menu-bar sticky">
<div class="left-buttons">
<label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
<i class="fa fa-bars"></i>
</label>
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
<i class="fa fa-paint-brush"></i>
</button>
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
<li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
</ul>
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
<i class="fa fa-search"></i>
</button>
</div>
<h1 class="menu-title">Vac RFC</h1>
<div class="right-buttons">
<a href="../../print.html" title="Print this book" aria-label="Print this book">
<i id="print-button" class="fa fa-print"></i>
</a>
<a href="https://github.com/vacp2p/rfc-index" title="Git repository" aria-label="Git repository">
<i id="git-repository-button" class="fa fa-github"></i>
</a>
</div>
</div>
<div id="search-wrapper" class="hidden">
<form id="searchbar-outer" class="searchbar-outer">
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
</form>
<div id="searchresults-outer" class="searchresults-outer hidden">
<div id="searchresults-header" class="searchresults-header"></div>
<ul id="searchresults">
</ul>
</div>
</div>
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
<script>
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
});
</script>
<div id="content" class="content">
<main>
<h1 id="status-simple-scaling"><a class="header" href="#status-simple-scaling">STATUS-SIMPLE-SCALING</a></h1>
<div class="rfc-meta">
<table>
<tr><th>Name</th><td>Status Simple Scaling</td></tr>
<tr><th>Status</th><td>raw</td></tr>
<tr><th>Category</th><td>Informational</td></tr>
<tr><th>Editor</th><td>Daniel Kaiser &lt;danielkaiser@status.im&gt;</td></tr>
<tr><th>Contributors</th><td>Alvaro Revuelta &lt;alrevuelta@status.im&gt;</td></tr>
</table>
</div>
<!-- timeline:start -->
<h2 id="timeline"><a class="header" href="#timeline">Timeline</a></h2>
<ul>
<li><strong>2025-12-22</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/b1a578393edf8487ccc97a5f25b25af9bf41efb3/docs/status/raw/simple-scaling.md"><code>b1a5783</code></a> — Chore/mdbook updates (#237)</li>
<li><strong>2025-12-18</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/d03e699084774ebecef9c6d4662498907c5e2080/docs/status/raw/simple-scaling.md"><code>d03e699</code></a> — ci: add mdBook configuration (#233)</li>
<li><strong>2024-11-20</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/ff87c84dc71d4f933bab188993914069fea12baa/status/raw/simple-scaling.md"><code>ff87c84</code></a> — Update Waku Links (#104)</li>
<li><strong>2024-09-17</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/9b5e2194cf2a2464740de6798fddd21a24b2dc7e/status/raw/simple-scaling.md"><code>9b5e219</code></a> — Update simple-scaling (#93)</li>
<li><strong>2024-09-13</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/3ab314d87d4525ff1296bf3d9ec634d570777b91/status/raw/simple-scaling.md"><code>3ab314d</code></a> — Fix Files for Linting (#94)</li>
<li><strong>2024-06-14</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/a189a72146978307ede84708d89c580dab5bc142/status/raw/simple-scaling.md"><code>a189a72</code></a> — fix: messageHash in 57 (#22)</li>
<li><strong>2024-03-01</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/61a39e26d7b8a1ced4c9e56b971a20c72679556d/status/raw/simple-scaling.md"><code>61a39e2</code></a> — Update and rename vac/raw/57/simple-scaling.md to status/raw/simple-scaling.md</li>
<li><strong>2024-02-28</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/18a16ae6954f49fba0046d8e418f7bc55ae4c7aa/vac/raw/57/simple-scaling.md"><code>18a16ae</code></a> — Update and rename simple-scaling.md to simple-scaling.md</li>
<li><strong>2024-02-12</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/f19a136ea6c0ae18c4a8afaed88a81b0aaa30262/status/raw/57/simple-scaling.md"><code>f19a136</code></a> — Update and rename status/57/simple-scaling.md to status/raw/57/simple-scaling.md</li>
<li><strong>2024-02-07</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/27fae4fe9168cb2318f54ee94852150019be5652/status/57/simple-scaling.md"><code>27fae4f</code></a> — Update simple-scaling.md</li>
<li><strong>2024-02-05</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/fa8c750dd762ccef1cc6c8d775f57a57a6f9bd21/status/57/simple-scaling.md"><code>fa8c750</code></a> — Update simple-scaling.md</li>
<li><strong>2024-02-01</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/59190400c67b7a2d9b7bfa1ab5504eabb3637317/status/57/simple-scaling.md"><code>5919040</code></a> — Update simple-scaling.md</li>
<li><strong>2024-01-27</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/f7a51b9fdfc3155fa09795cf6902f5d4d82f83b7/status/57/simple-scaling.md"><code>f7a51b9</code></a> — Create simple-scaling.md</li>
</ul>
<!-- timeline:end -->
<h2 id="abstract"><a class="header" href="#abstract">Abstract</a></h2>
<p>This document describes how to scale
<a href="../56/communities.html">56/STATUS-COMMUNITIES</a> as well as <a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a>
using Waku v2 protocol and components.
It also adds a few new aspects,
where more sophisticated components are not yet researched and evaluated.</p>
<blockquote>
<p><em>Note:</em> (Parts of) this RFC will be deprecated in the future
as we continue research to scale specific components
in a way that aligns better with our principles of decentralization and
protecting anonymity.
This document informs about scaling at the current stage of research and
shows it is practically possible.
Practical feasibility is also a core goal for us.
We believe in incremental improvement, i.e.
having a working decentralized scaling solution with trade-offs
is better than a fully centralized solution.</p>
</blockquote>
<h2 id="background-and-motivation"><a class="header" href="#background-and-motivation">Background and Motivation</a></h2>
<p><a href="../56/communities.html">56/STATUS-COMMUNITIES</a> as well as
<a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a> use Waku v2 protocols.
Both use Waku content topics
(see <a href="../../waku/informational/23/topics.html">23/WAKU2-TOPICS</a>)
for content based filtering.</p>
<p>Waku v2 currently has scaling limitations in two dimensions:</p>
<ol>
<li>
<p>Messages that are part of a specific content topic
have to be disseminated in a single mesh network (i.e. pubsub topic).
This limits scaling the number of messages disseminated in a specific content topic,
and by extension, the number of active nodes that are part of this content topic.</p>
</li>
<li>
<p>Scaling a large set of content topics requires distributing these over several
mesh networks (which this document refers to as pubsub topic shards).</p>
</li>
</ol>
<p>This document focuses on the second scaling dimension.
With the scaling solutions discussed in this document,
each content topics can have a large set of active users,
but still has to fit in a single pubsub mesh.</p>
<blockquote>
<p><em>Note:</em> While it is possible to use the same content topic name on several shards,
each node that is interested in this content topic
has to be subscribed to all respective shards, which does not scale.
Splitting content topics in a more sophisticated and
efficient way will be part of a future document.</p>
</blockquote>
<h2 id="relay-shards"><a class="header" href="#relay-shards">Relay Shards</a></h2>
<p>Sharding the <a href="../../waku/standards/core/11/relay.html">11/WAKU2-RELAY</a>
network is an integral part of scaling the Status app.</p>
<p><a href="https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md">WAKU2-RELAY-SHARDING</a>
specifies shards clusters, which are sets of <code>1024</code> shards
(separate pubsub mesh networks).
Content topics specified by application protocols can be distributed over these shards.
The Status app protocols are assigned to shard cluster <code>16</code>,
as defined in <a href="https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md">WAKU2-RELAY-STATIC-SHARD-ALLOC</a>.</p>
<p><a href="https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md">WAKU2-RELAY-SHARDING</a>
specifies three sharding methods.
This document uses <em>static sharding</em>,
which leaves the distribution of content topics to application protocols,
but takes care of shard discovery.</p>
<p>The 1024 shards within the main Status shard cluster are allocated as follows.</p>
<h3 id="shard-allocation"><a class="header" href="#shard-allocation">Shard Allocation</a></h3>
<div class="table-wrapper"><table><thead><tr><th>shard index</th><th>usage</th></tr></thead><tbody>
<tr><td>0 - 15</td><td>reserved</td></tr>
<tr><td>16 - 127</td><td>specific (large) communities</td></tr>
<tr><td>128 - 767</td><td>communities</td></tr>
<tr><td>768 - 895</td><td>1:1 chat</td></tr>
<tr><td>896 - 1023</td><td>media and control msgs</td></tr>
</tbody></table>
</div>
<p>Shard indices are mapped to pubsub topic names as follows (specified in <a href="https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md">WAKU2-RELAY-SHARDING</a>).</p>
<p><code>/waku/2/rs/&lt;cluster_id&gt;/&lt;shard_number&gt;</code></p>
<p>an example for the shard with index <code>18</code> in the Status shard cluster:</p>
<p><code>/waku/2/rs/16/18</code></p>
<p>In other words, the mesh network with the pubsub topic name <code>/waku/2/rs/16/18</code>,
carries messages associated with shard <code>18</code> in the Status shard cluster.</p>
<h4 id="implementation-suggestion"><a class="header" href="#implementation-suggestion">Implementation Suggestion</a></h4>
<p>The Waku implementation should offer an interface that
allows Status nodes to subscribe to Status specific content topics like</p>
<pre><code class="language-yaml">subscribe("/status/xyz", 16, 18)
</code></pre>
<p>The shard cluster index <code>16</code> can be kept in the Status app configuration,
so that Status nodes can simply use</p>
<pre><code class="language-yaml">subscribe("/status/xyz", 18)
</code></pre>
<p>which means: connect to the <code>"status/xyz"</code> content topic on shard <code>18</code>
within the Status shard cluster.</p>
<h3 id="status-communities"><a class="header" href="#status-communities">Status Communities</a></h3>
<p>In order to associate a community with a shard,
the community description protobuf is extended by the field
<code>uint16 relay_shard_index = 15</code>:</p>
<pre><code class="language-protobuf">
syntax = "proto3";
message CommunityDescription {
// The Lamport timestamp of the message
uint64 clock = 1;
// A mapping of members in the community to their roles
map&lt;string,CommunityMember&gt; members = 2;
// The permissions of the Community
CommunityPermissions permissions = 3;
// The metadata of the Community
ChatIdentity identity = 5;
// A mapping of chats to their details
map&lt;string,CommunityChat&gt; chats = 6;
// A list of banned members
repeated string ban_list = 7;
// A mapping of categories to their details
map&lt;string,CommunityCategory&gt; categories = 8;
// The admin settings of the Community
CommunityAdminSettings admin_settings = 10;
// If the community is encrypted
bool encrypted = 13;
// The list of tags
repeated string tags = 14;
// index of the community's shard within the Status shard cluster
uint16 relay_shard_index = 15
}
</code></pre>
<blockquote>
<p><em>Note</em>: Currently, Status app has allocated shared cluster <code>16</code> in <a href="https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md">WAKU2-RELAY-STATIC-SHARD-ALLOC</a>.
Status app could allocate more shard clusters, for instance to establish a test net.
We could add the shard cluster index to the community description as well.
The recommendation for now,
is to keep it as a configuration option of the Status app.
<em>Note</em>: Once this RFC moves forward,
the new community description protobuf fields should be mentioned in <a href="../56/communities.html">56/STATUS-COMMUNITIES</a>.</p>
</blockquote>
<p>Status communities can be mapped to shards in two ways: static, and owner-based.</p>
<h4 id="static-mapping"><a class="header" href="#static-mapping">Static Mapping</a></h4>
<p>With static mapping,
communities are assigned a specific shard index within the Status shard cluster.
This mapping is similar in nature to the shard cluster allocation in <a href="https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md">WAKU2-RELAY-STATIC-SHARD-ALLOC</a>.
Shard indices allocated in that way are in the range <code>16 - 127</code>.
The Status CC community uses index <code>16</code>
(not to confuse with shard cluster index <code>16</code>, which is the Status shard cluster).</p>
<h4 id="owner-mapping"><a class="header" href="#owner-mapping">Owner Mapping</a></h4>
<blockquote>
<p><em>Note</em>: This way of mapping will be specified post-MVP.</p>
</blockquote>
<p>Community owners can choose to map their communities to any shard within
the index range <code>128 - 767</code>.</p>
<h3 id="11-chat"><a class="header" href="#11-chat">1:1 Chat</a></h3>
<p><a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a>
uses partitioned topics to map 1:1 chats to a set of 5000 content topics.
This document extends this mapping to 8192 content topics that are, in turn,
mapped to 128 shards in the index range of <code>768 - 895</code>.</p>
<pre><code class="language-js">contentPartitionsNum = 8192
contentPartition = mod(publicKey, contentPartitionsNum)
partitionContentTopic = "contact-discovery-" + contentPartition
partitionContentTopic = keccak256(partitionContentTopic)
shardNum = 128
shardIndex = 768 + mod(publicKey, shardNum)
</code></pre>
<h2 id="infrastructure-nodes"><a class="header" href="#infrastructure-nodes">Infrastructure Nodes</a></h2>
<p>As described in <a href="../../waku/informational/30/adaptive-nodes.html">30/ADAPTIVE-NODES</a>,
Waku supports a continuum of node types with respect to available resources.
Infrastructure nodes are powerful nodes that have a high bandwidth connection and
a high up-time.</p>
<p>This document, which informs about simple ways of scaling Status over Waku,
assumes the presence of a set of such infrastructure nodes in each shard.
Infrastructure nodes are especially important for
providing connectivity in the roll-out phase.</p>
<p>Infrastructure nodes are not limited to Status fleets, or
nodes run by community owners.
Anybody can run infrastructure nodes.</p>
<h3 id="statically-mapped-communities"><a class="header" href="#statically-mapped-communities">Statically-Mapped Communities</a></h3>
<p>Infrastructure nodes are provided by the community owner,
or by members of the respective community.</p>
<h3 id="owner-mapped-communities"><a class="header" href="#owner-mapped-communities">Owner-Mapped Communities</a></h3>
<p>Infrastructure nodes are part of a subset of the shards in the range <code>128 - 767</code>.
Recommendations on choosing this subset will be added
in a future version of this document.</p>
<p>Status fleet nodes make up a part of these infrastructure nodes.</p>
<h3 id="11-chat-1"><a class="header" href="#11-chat-1">1:1 chat</a></h3>
<p>Infrastructure nodes are part of a subset of the shards in the range <code>768 - 985</code>
(similar to owner-mapped communities).
Recommendations on choosing this subset will be added
in a future version of this document.</p>
<p>Desktop clients can choose to only use filter and lightpush.</p>
<blockquote>
<p><em>Note</em>: Discussion: I'd suggest to set this as the default for the MVP.
The load on infrastructure nodes would not be higher, because
they have to receive and relay each message anyways.
This comes as a trade-off to anonymity and decentralization,
but can significantly improve scaling.
We still have k-anonymity because
several chat pairs are mapped into one content topic.
We could improve on this in the future, and research the applicability of PIR
(private information retrieval) techniques in the future.</p>
</blockquote>
<h2 id="infrastructure-shards"><a class="header" href="#infrastructure-shards">Infrastructure Shards</a></h2>
<p>Waku messages are typically relayed in larger mesh networks
comprised of nodes with varying resource profiles
(see <a href="../../waku/informational/30/adaptive-nodes.html">30/ADAPTIVE-NODES</a>).
To maximise scaling, relaying of specific message types can be dedicated to shards
where only infrastructure nodes with very strong resource profiles relay messages.
This comes as a trade-off to decentralization.</p>
<h2 id="control-message-shards"><a class="header" href="#control-message-shards">Control Message Shards</a></h2>
<p>To get the maximum scaling for select large communities for the Status scaling MVP,
specific control messages that cause significant load
(at a high user number) SHOULD be moved to a separate control message shard.
These control messages comprise:</p>
<ul>
<li>community description</li>
<li>membership update</li>
<li>backup</li>
<li>community request to join response</li>
<li>sync profile picture</li>
</ul>
<p>The relay functionality of control messages shards SHOULD
be provided by infrastructure nodes.
Desktop clients should use light protocols as the default for control message shards.
Strong Desktop clients MAY opt in to support the relay network.</p>
<p>Each large community (in the index range of <code>16 - 127</code>)
can get its dedicated control message shard
(in the index range <code>896 - 1023</code>) if deemed necessary.
The Status CC community uses shard <code>896</code> as its control message shard.
This comes with trade-offs to decentralization and anonymity
(see <em>Security Considerations</em> section).</p>
<h2 id="media-shards"><a class="header" href="#media-shards">Media Shards</a></h2>
<p>Similar to control messages, media-heavy communities should use separate media shards
(in the index range <code>896 - 1023</code>) for disseminating messages with large media data.
The Status CC community uses shard <code>897</code> as its media shard.</p>
<h2 id="infrastructure-focused-community"><a class="header" href="#infrastructure-focused-community">Infrastructure-focused Community</a></h2>
<p>Large communities MAY choose to mainly rely on infrastructure nodes
for <em>all</em> message transfers (not limited to control, and media messages).
Desktop clients of such communities should use light protocols as the default.
Strong Desktop clients MAY opt in to support the relay network.</p>
<blockquote>
<p><em>Note</em>: This is not planned for the MVP.</p>
</blockquote>
<h2 id="light-protocols"><a class="header" href="#light-protocols">Light Protocols</a></h2>
<p>Light protocols may be used to save bandwidth,
at the (global) cost of not contributing to the network.
Using light protocols is RECOMMENDED for resource restricted nodes,
e.g. browsers,
and devices that (temporarily)
have a low bandwidth connection or a connection with usage-based billing.</p>
<p>Light protocols comprise</p>
<ul>
<li><a href="../../waku/standards/core/19/lightpush.html">19/WAKU2-LIGHTPUSH</a> for sending messages</li>
<li><a href="../../waku/standards/core/12/filter.html">12/WAKU2-FILTER</a>
for requesting messages with specific attributes</li>
<li><a href="https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md">WAKU2-PEER-EXCHANGE</a>
for discovering peers</li>
</ul>
<h2 id="waku-archive"><a class="header" href="#waku-archive">Waku Archive</a></h2>
<p>Archive nodes are Waku nodes that offer the Waku archive service via
the Waku store protocol (<a href="../../waku/standards/core/13/store.html">13/WAKU2-STORE</a>).
They are part of a set of shards and store all messages disseminated in these shards.
Nodes can request history messages via the <a href="../../waku/standards/core/13/store.html">13/WAKU2-STORE</a>.</p>
<p>The store service is not limited to a Status fleet.
Anybody can run a Waku Archive node in the Status shards.</p>
<blockquote>
<p><em>Note</em>: There is no specification for discovering archive nodes
associated with specific shards yet.
Nodes expect archive nodes to store all messages, regardless of shard association.</p>
</blockquote>
<p>The recommendation for the allocation of archive nodes to shards is similar to the
allocation of infrastructure nodes to shards described above.
In fact, the archive service can be offered by infrastructure nodes.</p>
<h2 id="discovery"><a class="header" href="#discovery">Discovery</a></h2>
<p>Shard discovery is covered by <a href="https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md">WAKU2-RELAY-SHARDING</a>.
This allows the Status app to abstract from the discovery process and
simply address shards by their index.</p>
<h3 id="libp2p-rendezvous-and-circuit-relay"><a class="header" href="#libp2p-rendezvous-and-circuit-relay">Libp2p Rendezvous and Circuit-Relay</a></h3>
<p>To make nodes behind restrictive NATs discoverable,
this document suggests using <a href="https://github.com/libp2p/specs/blob/master/rendezvous/README.md">libp2p rendezvous</a>.
Nodes can check whether they are behind a restrictive NAT using the
<a href="https://github.com/libp2p/specs/blob/master/autonat/README.md">libp2p AutoNAT protocol</a>.</p>
<blockquote>
<p><em>Note:</em> The following will move into <a href="https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md">WAKU2-RELAY-SHARDING</a>,
or <a href="../../waku/standards/core/33/discv5.html">33/WAKU2-DISCV5</a>:
Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address
via <a href="../../waku/standards/core/33/discv5.html">33/WAKU2-DISCV5</a> discovery.</p>
</blockquote>
<p>It is RECOMMENDED that nodes that are part of the relay network also
act as rendezvous points.
This includes accepting register queries from peers,
as well as answering rendezvous discover queries.
Nodes MAY opt-out of the rendezvous functionality.</p>
<p>To allow nodes to initiate connections to peers behind restrictive NATs
(after discovery via rendezvous),
it is RECOMMENDED that nodes that are part of the Waku relay network also offer
<a href="https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md">libp2p circuit relay</a>
functionality.</p>
<p>To minimize the load on circuit-relay nodes, nodes SHOULD</p>
<ol>
<li>make use of the <a href="https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md#reservation">limiting</a>
functionality offered by the libp2p circuit relay protocols, and</li>
<li>use <a href="https://github.com/libp2p/specs/blob/master/relay/DCUtR.md">DCUtR</a>
to upgrade to a direct connection.</li>
</ol>
<p>Nodes that do not announce themselves at all and only plan to use light protocols,
MAY use rendezvous discovery instead of or along-side <a href="https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md">WAKU2-PEER-EXCHANGE</a>.
For these nodes, rendezvous and
<a href="https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md">WAKU2-PEER-EXCHANGE</a>
offer the same functionality,
but return node sets sampled in different ways.
Using both can help increasing connectivity.</p>
<p>Nodes that are not behind restrictive NATs MAY register at rendezvous points, too;
this helps increasing discoverability, and by extension connectivity.
Such nodes SHOULD, however, not register at circuit relays.</p>
<h3 id="announcing-shard-participation"><a class="header" href="#announcing-shard-participation">Announcing Shard Participation</a></h3>
<p>Registering a namespace via <a href="https://github.com/libp2p/specs/blob/master/rendezvous/README.md#interaction">lib-p2p rendezvous</a>
is done via a register query:</p>
<pre><code class="language-rs">REGISTER{my-app, {QmA, AddrA}}
</code></pre>
<p>The app name, <code>my-app</code> contains the encoding of a single shard in string form:</p>
<pre><code class="language-rs">"rs/"| to_string(&lt;2-byte shard cluster index&gt;) | "/" | to_string(&lt;2-byte shard index&gt;)
</code></pre>
<p>The string conversion SHOULD remove leading zeros.</p>
<blockquote>
<p><em>Note:</em> Since the <a href="https://github.com/libp2p/specs/blob/master/rendezvous/README.md#protobuf">ns</a>
field is of type string, a more efficient byte encoding is not utilized.</p>
</blockquote>
<p>Registering shard 2 in the Status shard cluster (with shard cluster index 16,
see <a href="https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md">WAKU2-RELAY-STATIC-SHARD-ALLOC</a>,
the register query would look like</p>
<pre><code class="language-rs">REGISTER{"rs/16/2", {QmA, AddrA}}
</code></pre>
<p>Participation in further shards is registered with further queries;
one register query per shard.</p>
<p>A discovery query for nodes that are part of this shard would look like</p>
<pre><code class="language-rs">DISCOVER{ns: "rs/16/2"}
</code></pre>
<h2 id="dos-protection"><a class="header" href="#dos-protection">DoS Protection</a></h2>
<p>Hereunder we describe the "opt-in message signing for DoS prevention" solution,
designed <em>ad hoc</em> for Status MVP.</p>
<p>Since publishing messages to pubsub topics has no limits,
anyone can publish messages at a very high rate and DoS the network.
This would elevate the bandwidth consumption of all nodes subscribed
to said pubsub topic, making it prohibitive (in terms of bandwidth)
to be subscribed to it.
In order to scale, we need some mechanism to prevent this from happening,
otherwise all scaling efforts will be in vain.
Since RLN is not ready yet,
hereunder we describe a simpler approach designed <em>ad hoc</em> for Status use case,
feasible to implement for the MVP and
that validates some of the ideas that will evolve to solutions such as RLN.</p>
<p>With this approach, certain pubsub topics can be optionally configured
to only accept messages signed with a given key,
that only trusted entities know.
This key can be pre-shared among a set of participants,
that are trusted to make fair usage of the network,
publishing messages at a reasonable rate/size.
Note that this key can be shared/reused among multiple participants, and
only one key is whitelisted per pubsub topic.
This is an opt-in solution that operators can choose to deploy in their shards
(i.e. pubsub topics), but it's not enforced in the default one.
Operators can freely choose how they want to generate, and
distribute the public keys.
It's also their responsibility to handle the private key,
sharing it with only trusted parties and keeping proper custody of it.</p>
<p>The following concepts are introduced:</p>
<ul>
<li><code>private-key-topic</code>: A private key of 32 bytes,
that allows the holder to sign messages and it's mapped to a <code>protected-pubsub-topic</code>.</li>
<li><code>app-message-hash</code>: Application <code>WakuMessage</code> hash,
calculated as <code>sha256(concat(pubsubTopic, payload, contentTopic, timestamp, ephemeral))</code>
with all elements in bytes.</li>
<li><code>message-signature</code>: ECDSA signature of <code>application-message-hash</code>
using a given <code>private-key-topic</code>, 64 bytes.</li>
<li><code>public-key-topic</code>: The equivalent public key of <code>private-key-topic</code>.</li>
<li><code>protected-pubsub-topic</code>: Pubsub topic that only accepts messages
that were signed with <code>private-key-topic</code>,
where <code>verify(message-signature, app-message-hash, public-key-topic)</code>
is only correct if the <code>message-signature</code> was produced by <code>private-key-topic</code>.
See ECDSA signature verification algorithm.</li>
</ul>
<p>This solution introduces two roles:</p>
<ul>
<li>Publisher: A node that knows the <code>private-key-topic</code> associated to <code>public-key-topic</code>,
that can publish messages with a valid <code>message-signature</code> that are accepted and
relayed by the nodes implementing this feature.</li>
<li>Relayer: A node that knows the <code>public-key-topic</code>,
which can be used to verify if the messages were signed with the equivalent <code>private-key-topic</code>.
It allows distinguishing valid from invalid messages
which protect the node against DoS attacks,
assuming that the users of the key send messages of a reasonable size and rate.
Note that a node can validate messages and
relay them or not without knowing the private key.</li>
</ul>
<h3 id="design-requirements-publisher"><a class="header" href="#design-requirements-publisher">Design requirements (publisher)</a></h3>
<p>A publisher that wants to send messages
that are relayed in the network for a given <code>protected-pubsub-topic</code> shall:</p>
<ul>
<li>be able to sign messages with the <code>private-key-topic</code> configured for that topic,
producing a ECDSA signature of 64 bytes using
deterministic signing complying with RFC 6979.</li>
<li>include the signature of the <code>app-message-hash</code> (<code>message-signature</code>)
that wishes to send in the <code>WakuMessage</code> <code>meta</code> field.</li>
</ul>
<p>The <code>app-message-hash</code> of the message shall be calculated as the <code>sha256</code> hash
of the following fields of the message:</p>
<pre><code class="language-rs">sha256(concat(pubsubTopic, payload, contentTopic, timestamp, ephemeral))
</code></pre>
<p>Where fields are serialized into bytes using little-endian.
Note that <code>ephemeral</code> is a boolean that is serialized to <code>0</code> if <code>false</code> and
<code>1</code> if <code>true</code>.</p>
<h3 id="design-requirements-relay"><a class="header" href="#design-requirements-relay">Design requirements (relay)</a></h3>
<p>Requirements for the relay are listed below:</p>
<ul>
<li>A valid <code>protected-pubsub-topic</code> shall be configured with a <code>public-key-topic</code>,
(derived from a <code>private-key-topic</code>).
Note that the relay does not need to know the private key.
For simplicity, there is just one key per topic.
Since this approach has clear privacy implications,
this configuration is not part of the waku protocol, but of the application.</li>
</ul>
<p>Requirements on the gossipsub validator:</p>
<ul>
<li>Relay nodes should use the existing gossipsub validators that allow to <code>Accept</code>
or <code>Reject</code> messages, according to the following criteria:</li>
<li>If <code>timestamp</code> is not set (equals to 0) then <code>Reject</code> the message.</li>
<li>If the <code>timestamp</code> is <code>abs(current_timestamp-timestamp) &gt; MessageWindowInSec</code>
then <code>Reject</code> the message.</li>
<li>If <code>meta</code> is empty, <code>Reject</code> the message.</li>
<li>If <code>meta</code> exists but its size is different than 64 bytes, <code>Reject</code> the message.</li>
<li>If <code>meta</code> does not successfully verifies according to the ECDSA signature
verification algorithm using <code>public-key-topic</code> and <code>app-message-hash</code>,
then <code>Reject</code> the message.</li>
<li>If and only if all above conditions are met then <code>Accept</code> the message.</li>
</ul>
<p>Other requirements:</p>
<ul>
<li>The node shall keep metrics on the messages validation output,
<code>Accept</code> or <code>Reject</code>.</li>
<li>(Optional). To further strengthen DoS protection,
gossipsub <a href="https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators">scoring</a>
can be used to trigger disconnections from peers sending multiple invalid messages.
See <code>P4</code> penalty.
This protects each peer from DoS,
since this score is used to trigger disconnections from nodes attempting to DoS them.</li>
</ul>
<h3 id="required-changes"><a class="header" href="#required-changes">Required changes</a></h3>
<p>This solution is designed to be backward compatible so
that nodes validating messages can coexist in the same topic
with other nodes that don't perform validation.
But note that only nodes that perform message validation
will be protected against DoS.
Nodes wishing to opt-in this DoS protection feature shall:</p>
<ul>
<li>Generate a <code>private-key-topic</code> and distribute it to a curated list of users,
that are trusted to send messages at a reasonable rate.</li>
<li>Redeploy the nodes, adding a new configuration
where a <code>protected-pubsub-topic</code> is configured with a <code>public-key-topic</code>,
used to verify the messages being relayed.</li>
</ul>
<h3 id="test-vectors"><a class="header" href="#test-vectors">Test vectors</a></h3>
<p>Relay nodes complying with this specification
shall accept the following message in the configured pubsub topic.</p>
<p>Given the following key pair:</p>
<pre><code class="language-js">private-key-topic = 5526a8990317c9b7b58d07843d270f9cd1d9aaee129294c1c478abf7261dd9e6
public-key-topic = 049c5fac802da41e07e6cdf51c3b9a6351ad5e65921527f2df5b7d59fd9b56ab02bab736cdcfc37f25095e78127500da371947217a8cd5186ab890ea866211c3f6
</code></pre>
<p>And the following message to send:</p>
<pre><code class="language-js">protected-pubsub-topic = pubsub-topic
contentTopic = content-topic
payload = 1A12E077D0E89F9CAC11FBBB6A676C86120B5AD3E248B1F180E98F15EE43D2DFCF62F00C92737B2FF6F59B3ABA02773314B991C41DC19ADB0AD8C17C8E26757B
timestamp = 1683208172339052800
ephemeral = true
</code></pre>
<p>The message hash and meta (aka signature) are calculated as follows.</p>
<pre><code class="language-js">app-message-hash = 662F8C20A335F170BD60ABC1F02AD66F0C6A6EE285DA2A53C95259E7937C0AE9
message.meta = 127FA211B2514F0E974A055392946DC1A14052182A6ABEFB8A6CD7C51DA1BF2E40595D28EF1A9488797C297EED3AAC45430005FB3A7F037BDD9FC4BD99F59E63
</code></pre>
<p>Using <code>message.meta</code>, the relay node shall calculate the <code>app-message-hash</code>
of the received message using <code>public-key-topic</code>,
and with the values above, the signature should be verified,
making the node <code>Accept</code> the message and relaying it to other nodes in the network.</p>
<h2 id="owner-mapped-communities-1"><a class="header" href="#owner-mapped-communities-1">Owner Mapped Communities</a></h2>
<p>Basic idea:
Tokenized load.</p>
<h3 id="1-to-1-chat"><a class="header" href="#1-to-1-chat">1 to 1 Chat</a></h3>
<p>An idea we plan to explore in the future:
Map 1:1 chats to community shards, if both A and B are part of the respective community.
This increases k-anonymity and benefits from community DoS protection.
It could be rate-limited with RLN.</p>
<h2 id="securityprivacy-considerations"><a class="header" href="#securityprivacy-considerations">Security/Privacy Considerations</a></h2>
<p>This document makes several trade-offs to privacy and anonymity.
Todo: elaborate.
See <a href="https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md">WAKU2-ADVERSARIAL-MODELS</a>
for information on Waku Anonymity.</p>
<h2 id="copyright"><a class="header" href="#copyright">Copyright</a></h2>
<p>Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>.</p>
<h2 id="references"><a class="header" href="#references">References</a></h2>
<ul>
<li><a href="../56/communities.html">56/STATUS-COMMUNITIES</a></li>
<li><a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a></li>
<li><a href="../../waku/informational/23/topics.html">23/WAKU2-TOPICS</a></li>
<li><a href="../../waku/standards/core/11/relay.html">11/WAKU2-RELAY</a></li>
<li><a href="https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md">WAKU2-RELAY-SHARDING</a></li>
<li><a href="https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md">WAKU2-RELAY-STATIC-SHARD-ALLOC</a></li>
<li><a href="../../waku/informational/30/adaptive-nodes.html">30/ADAPTIVE-NODES</a></li>
<li><a href="../../waku/standards/core/19/lightpush.html">19/WAKU2-LIGHTPUSH</a></li>
<li><a href="../../waku/standards/core/12/filter.html">12/WAKU2-FILTER</a></li>
<li><a href="https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md">WAKU2-PEER-EXCHANGE</a></li>
<li><a href="../../waku/standards/core/13/store.html">13/WAKU2-STORE</a></li>
<li><a href="https://github.com/libp2p/specs/blob/master/rendezvous/README.md">libp2p rendezvous</a></li>
<li><a href="https://github.com/libp2p/specs/blob/master/autonat/README.md">libp2p AutoNAT protocol</a></li>
<li><a href="../../waku/standards/core/33/discv5.html">33/WAKU2-DISCV5</a></li>
<li><a href="https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md">libp2p circuit relay</a></li>
<li><a href="https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md#reservation">limiting</a></li>
<li><a href="https://github.com/libp2p/specs/blob/master/relay/DCUtR.md">DCUtR</a></li>
<li><a href="https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators">scoring</a></li>
<li><a href="https://docs.libp2p.io/concepts/nat/circuit-relay/">Circuit Relay</a></li>
<li><a href="https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md">WAKU2-ADVERSARIAL-MODELS</a></li>
</ul>
<h2 id="informative"><a class="header" href="#informative">Informative</a></h2>
<ul>
<li><a href="https://docs.libp2p.io/concepts/nat/circuit-relay/">Circuit Relay</a></li>
<li><a href="https://github.com/waku-org/specs/blob/master/standards/core/enr.md">WAKU2-ENR</a></li>
</ul>
</main>
<nav class="nav-wrapper" aria-label="Page navigation">
<!-- Mobile navigation buttons -->
<a rel="prev" href="../../status/raw/index.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next prefetch" href="../../status/raw/status-app-protocols.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
<div style="clear: both"></div>
</nav>
</div>
</div>
<nav class="nav-wide-wrapper" aria-label="Page navigation">
<a rel="prev" href="../../status/raw/index.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next prefetch" href="../../status/raw/status-app-protocols.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
</nav>
</div>
<script>
window.playground_copyable = true;
</script>
<script src="../../elasticlunr.min.js"></script>
<script src="../../mark.min.js"></script>
<script src="../../searcher.js"></script>
<script src="../../clipboard.min.js"></script>
<script src="../../highlight.js"></script>
<script src="../../book.js"></script>
<!-- Custom JS scripts -->
<script src="../../scripts/rfc-index.js"></script>
</div>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink