Theory / Semantics # Routing protocol # The Waku Network is built on the 17/WAKU2-RLN-RELAY routing protocol, which in turn is an extension of 11/WAKU2-RELAY with spam protection measures.">
Theory / Semantics # Routing protocol # The Waku Network is built on the 17/WAKU2-RLN-RELAY routing protocol, which in turn is an extension of 11/WAKU2-RELAY with spam protection measures." />
<p>Nodes MAY use any method to bootstrap connection to the network,
but it is RECOMMENDED that each node retrieves a list of bootstrap peers to connect to using <ahref="https://eips.ethereum.org/EIPS/eip-1459">EIP-1459 DNS-based discovery</a>.
Relay nodes SHOULD use <ahref="https://rfc.vac.dev/spec/33/">33/WAKU2-DISCV5</a> to continually discover other peers in the network.
Each relay node MUST encode its supported shards into its discoverable ENR
as described in <ahref="https://rfc.vac.dev/spec/51/#discovery">51/WAKU2-RELAY-SHARDING</a>.
The ENR MUST be updated if the set of supported shards change.
A node MAY choose to ignore discovered peers that do not support any of the shards in its own subscribed set.</p>
each relay node SHOULD enable and support the following protocols as a service node:</p>
<ol>
<li><ahref="https://rfc.vac.dev/spec/12/">12/WAKU2-FILTER</a> to allow resource-restricted peers to subscribe to messages matching a specific content filter.</li>
<li><ahref="https://rfc.vac.dev/spec/19/">19/WAKU2-LIGHTPUSH</a> to allow resource-restricted peers to request publishing a message to the network on their behalf.</li>
<li><ahref="https://rfc.vac.dev/spec/34/">34/WAKU2-PEER-EXCHANGE</a> to allow resource-restricted peers to discover more peers in a resource efficient way.</li>
<p>Nodes MAY request historical messages from <ahref="https://rfc.vac.dev/spec/13/">13/WAKU2-STORE</a> service nodes as store clients.
A store client SHOULD discard any messages retrieved from a store service node that do not contain a valid <ahref="#message-attributes"><code>rate_limit_proof</code></a> attribute.
The client MAY consider service nodes returning messages without a valid <ahref="#message-attributes"><code>rate_limit_proof</code></a> attribute as untrustworthy.
The mechanism by which this may happen is currently underdefined.</p>
<p>Applications are the higher-layer projects or platforms that make use of the generalized messaging capability of the network.
In other words, an application defines a payload used in the various <ahref="https://rfc.vac.dev/spec/10/">10/WAKU2</a> protocols.
Any participant in an application SHOULD make use of an underlying node in order to communicate on the network.
Applications SHOULD make use of an <ahref="#autosharding">autosharding</a> API
to allow the underlying node to automatically select the target shard on the Waku Network. See the section on <ahref="#autosharding">autosharding</a> for more.</p>
to ensure that a pre-agreed rate limit is not exceeded by any publisher.
While the network is under capacity,
individual relayers MAY choose to freely route messages without RLN proofs
up to a discretionary bandwidth limit after which messages without proofs MUST be discarded.
This bandwidth limit SHOULD be enforced using <ahref="#free-bandwidth-exceeded">bandwidth validation mechanism</a> separate from RLN rate-limiting.
This implies that quality of service and reliability is significantly lower for messages without proofs
and at times of high network utilization these messages may not be relayed at all.</p>
<h3id="rln-parameters">
RLN Parameters
<aclass="anchor"href="#rln-parameters">#</a>
</h3>
<p>For the Waku Network,
the <code>epoch</code> is set to <code>1</code> second
and the maximum number of messages published per <code>epoch</code> is limited to <code>1</code> per publisher.
The <code>max_epoch_gap</code> is set to <code>20</code> seconds,
meaning that validators MUST <em>reject</em> messages with an <code>epoch</code> more than 20 seconds into the past or future compared to the validator’s own clock.
All nodes, validators and publishers,
SHOULD use Network Time Protocol (NTP) to synchronize their own clocks,
thereby ensuring valid timestamps for proof generation and validation.</p>
<h3id="memberships">
Memberships
<aclass="anchor"href="#memberships">#</a>
</h3>
<p>Each publisher to the Waku Network SHOULD register an RLN membership
with one of the RLN storage contracts
moderated in the Sepolia registry contract with address <ahref="https://sepolia.etherscan.io/address/0xF1935b338321013f11068abCafC548A7B0db732C#code">0xF1935b338321013f11068abCafC548A7B0db732C</a>.
Initial memberships are registered in the Sepolia RLN storage contract with address <ahref="https://sepolia.etherscan.io/address/0x58322513A35a8f747AF5A385bA14C2AbE602AA59#code">0x58322513A35a8f747AF5A385bA14C2AbE602AA59</a>.
RLN membership setup and registration MUST follow <ahref="https://rfc.vac.dev/spec/17/#setup-and-registration">17/WAKU-RLN-RELAY</a>,
with the <code>staked_fund</code> set to <code>0</code>.
In other words, the Waku Network does not use RLN staking.</p>
<h3id="rln-proofs">
RLN Proofs
<aclass="anchor"href="#rln-proofs">#</a>
</h3>
<p>Each RLN member MUST generate and attach an RLN proof to every published message
as described in <ahref="https://rfc.vac.dev/spec/17/#publishing">17/WAKU-RLN-RELAY</a>.
Slashing is not implemented for the Waku Network.
Instead, validators will penalise peers forwarding messages exceeding the rate limit
as specified for <ahref="#rate-limit-exceeded">the rate-limiting validation mechanism</a>.
This incentivizes all nodes to validate RLN proofs
and reject messages violating rate limits
in order to continue participating in the network.</p>
<h2id="network-traffic">
Network traffic
<aclass="anchor"href="#network-traffic">#</a>
</h2>
<p>All payload on the Waku Network MUST be encapsulated in a <ahref="https://rfc.vac.dev/spec/14/">14/WAKU2-MESSAGE</a>
with rate limit proof extensions defined for <ahref="https://rfc.vac.dev/spec/17/#payloads">17/WAKU2-RLN-RELAY</a>.
Each message on the Waku Network SHOULD be validated by each relayer,
according to the rules discussed under <ahref="#message-validation">message validation</a>.</p>
<h3id="message-attributes">
Message Attributes
<aclass="anchor"href="#message-attributes">#</a>
</h3>
<ul>
<li>Themandatory <code>payload</code>attribute MUST contain the message data payload as crafted by the application.</li>
<li>Themandatory <code>content_topic</code>attribute MUST specify a string identifier that can be used for content-based filtering. This is also crafted by the application. See <ahref="#autosharding">Autosharding</a> for more on the content topic format.</li>
<li>Theoptional <code>meta</code>attribute MAY be omitted. If present this will form part of the message uniqueness vector described in <ahref="https://rfc.vac.dev/spec/14/">14/WAKU2-MESSAGE</a>.</li>
<li>Theoptional <code>version</code>attribute SHOULD be set to <code>0</code>. It MUST be interpreted as <code>0</code> if not present.</li>
<li>Themandatory <code>timestamp</code>attribute MUST contain the Unix epoch time at which the message was generated by the application. The value MUST be in nanoseconds. It MAY contain a fudge factor of up to 1 seconds in either direction to improve resistance to timing attacks.</li>
<li>Theoptional <code>ephemeral</code>attribute MUST be set to <code>true</code> if the message should not be persisted by the Waku Network.</li>
<li>The optional <code>rate_limit_proof</code>attribute SHOULD be populated with the RLN proof as set out in <ahref="#rln-proofs">RLN Proofs</a>. Messages with this field unpopulated MAY be discarded from the network by relayers. This field MUST be populated if the message should be persisted by the Waku Network.</li>
<p>Relay nodes MUST apply <ahref="https://github.com/libp2p/specs/blob/c96c9ec5909d64fe020d7630f3fd982bc18fd06a/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators">gossipsub v1.1 validation</a> to each relayed message and
SHOULD apply all of the rules set out in the section below to determine the validity of a message.
Validation has one of three outcomes,
repeated here from the <ahref="https://github.com/libp2p/specs/blob/c96c9ec5909d64fe020d7630f3fd982bc18fd06a/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators">gossipsub specification</a> for ease of reference:</p>
<ol>
<li>Accept - the message is considered valid and it MUST be delivered and forwarded to the network.</li>
<li>Reject - the message is considered invalid, MUST be rejected and SHOULD trigger a gossipsub scoring penalty against the transmitting peer.</li>
<li>Ignore - the message SHOULD NOT be delivered and forwarded to the network, but this MUST NOT trigger a gossipsub scoring penalty against the transmitting peer.</li>
</ol>
<p>The following validation rules are defined:</p>
<h4id="decoding-failure">
Decoding failure
<aclass="anchor"href="#decoding-failure">#</a>
</h4>
<p>If a message fails to decode as a valid <ahref="https://rfc.vac.dev/spec/14/">14/WAKU2-MESSAGE</a>.
the relay node MUST <em>reject</em> the message.
This SHOULD trigger a penalty against the transmitting peer.</p>
<h4id="invalid-timestamp">
Invalid timestamp
<aclass="anchor"href="#invalid-timestamp">#</a>
</h4>
<p>If a message has a timestamp deviating by more than <code>20</code> seconds
either into the past or the future
when compared to the relay node’s internal clock,
