<titledata-rh="true">Capped Bandwidth in Waku | Waku Documentation</title><metadata-rh="true"name="viewport"content="width=device-width,initial-scale=1"><metadata-rh="true"name="twitter:card"content="summary_large_image"><metadata-rh="true"property="og:url"content="https://docs.waku.org/learn/research/research-and-studies/capped-bandwidth"><metadata-rh="true"property="og:locale"content="en_GB"><metadata-rh="true"name="docusaurus_locale"content="en-GB"><metadata-rh="true"name="docsearch:language"content="en-GB"><metadata-rh="true"name="keywords"content="waku, web3"><metadata-rh="true"name="image"content="https://docs.waku.org/_og/6433602de01c97d829f3a9f00274ab562df5ef08.png"><metadata-rh="true"name="docusaurus_version"content="current"><metadata-rh="true"name="docusaurus_tag"content="docs-default-current"><metadata-rh="true"name="docsearch:version"content="current"><metadata-rh="true"name="docsearch:docusaurus_tag"content="docs-default-current"><metadata-rh="true"property="og:title"content="Capped Bandwidth in Waku | Waku Documentation"><metadata-rh="true"name="description"content="This post explains i) why The Waku Network requires a capped bandwidth per shard and ii) how to achieve it by rate limiting with RLN v2."><metadata-rh="true"property="og:description"content="This post explains i) why The Waku Network requires a capped bandwidth per shard and ii) how to achieve it by rate limiting with RLN v2."><linkdata-rh="true"rel="icon"href="/theme/image/favicon.ico"><linkdata-rh="true"rel="canonical"href="https://docs.waku.org/learn/research/research-and-studies/capped-bandwidth"><linkdata-rh="true"rel="alternate"href="https://docs.waku.org/learn/research/research-and-studies/capped-bandwidth"hreflang="en-GB"><linkdata-rh="true"rel="alternate"href="https://docs.waku.org/learn/research/research-and-studies/capped-bandwidth"hreflang="x-default"><linkrel="alternate icon"type="image/png"href="/theme/image/favicon.png">
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="problem">Problem<ahref="#problem"class="hash-link"aria-label="Direct link to Problem"title="Direct link to Problem"></a></h2>
<p>First of all, let's begin with the terminology. We have talked in the past about "predictable" bandwidth, but a better name would be "capped" bandwidth. This is because it is totally fine that the waku traffic is not predictable, as long as it is capped. And it has to be capped because otherwise, no one will be able to run a node.</p>
<p>Since we aim that everyone can run a full waku node (at least subscribed to a single shard) it is of paramount importance that the bandwidth requirements (up/down) are i) reasonable to run with a residential internet connection in every country and ii) limited to an upper value, aka capped. If the required bandwidth to stay up to date with a topic is higher than what the node has available, then it will start losing messages and won't be able to stay up to date with the topic messages. And not to mention the problems this will cause to other services and applications being used by the user.</p>
<p>The main problem is that one can't just choose the bandwidth it allocates to <code>relay</code>. One could set the maximum bandwidth willing to allocate to <code>store</code> but this is not how <code>relay</code> works. The required bandwidth is not set by the node, but by the network. If a pubsub topic <code>a</code> has a traffic of 50 Mbps (which is the sum of all messages being sent multiplied by its size, times the D_out degree), then if a node wants to stay up to date in that topic, and relay traffic in it, then it will require 50 Mbps. There is no thing such as "partially contributing" to the topic (with eg 25Mbps) because then you will be losing messages, becoming an unreliable peer and potentially be disconnected. The network sets the pace.</p>
<p>So waku needs an upper boundary on the in/out bandwidth (mbps) it consumes. Just like apps have requirements on cpu and memory, we should set a requirement on bandwidth, and then guarantee that if you have that bandwidth, you will be able to run a node without any problem. And this is the tricky part. This metric is Waku's constraint, similar to the gas-per-block limit in blockchains.</p>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="previous-work">Previous Work<ahref="#previous-work"class="hash-link"aria-label="Direct link to Previous Work"title="Direct link to Previous Work"></a></h2>
<p>Quick summary of the evolution to solve this problem:</p>
<ul>
<li>Waku started with no rate-limiting mechanism. The network was subject to DoS attacks.</li>
<li>RLN v1 was introduced, which allowed to rate-limit in a privacy-preserving and anonymous way. The rate limit can be configured to 1 message every <code>y</code> seconds. However, this didn't offer much granularity. A low <code>y</code> would allow too many messages and a high <code>y</code> would make the protocol unusable (impossible to send two messages in a row).</li>
<li>RLN v2 was introduced, which allows to rate-limit each user to <code>x</code> messages every <code>y</code> seconds. This offers the granularity we need. It is the current solution deployed in The Waku Network.</li>
</ul>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="current-solution-rln-v2">Current Solution (RLN v2)<ahref="#current-solution-rln-v2"class="hash-link"aria-label="Direct link to Current Solution (RLN v2)"title="Direct link to Current Solution (RLN v2)"></a></h2>
<p>The current solution to this problem is the usage of RLN v2, which allows to rate-limit <code>x</code> messages every <code>y</code> seconds. On top of this, the introduction of <ahref="https://github.com/waku-org/specs/blob/master/standards/core/rln-contract.md"target="_blank"rel="noopener noreferrer">WAKU2-RLN-CONTRACT</a> enforces a maximum amount of messages that can be sent to the network per <code>epoch</code>. This is achieved by limiting the amount of memberships that can be registered. The current values are:</p>
<ul>
<li><code>R_{max}</code>: 160000 mgs/epoch</li>
<li><code>r_{max}</code>: 600 msgs/epoch</li>
<li><code>r_{min}</code>: 20 msgs/epoch</li>
</ul>
<p>In other words, the contract limits the amount of memberships that can be registered from <code>266</code> to <code>8000</code> depending on which rate limit users choose.</p>
<p>On the other hand <ahref="https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/64/network.md"target="_blank"rel="noopener noreferrer">64/WAKU2-NETWORK</a> states that:</p>
<ul>
<li><code>rlnEpochSizeSec</code>: 600. Meaning the epoch size is 600 seconds.</li>
<li><code>maxMessageSize</code>: 150KB. Meaning the maximum message size that is allowed. Note: recommended average of 4KB.</li>
</ul>
<p>Putting this all together and assuming:</p>
<ul>
<li>Messages are sent uniformly distributed.</li>
<li>All users totally consumes its rate-limit.</li>
</ul>
<p>We can expect the following message rate and bandwidth for the whole network:</p>
<ul>
<li>A traffic of <code>266 msg/second</code> on average (<code>160000/600</code>)</li>
<li>A traffic of <code>6 MBps</code> on average (266 * 4KB * 6), where <code>4KB</code> is the average message size and <code>6</code> is the average gossipsub D-out degree.</li>
</ul>
<p>And assuming a uniform distribution of traffic among 8 shards:</p>
