logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-07 16:43:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update network.md

Browse Source
This commit is contained in:
Jimmy Debe 2024-03-06 19:48:07 -05:00 committed by GitHub
parent cc257bb1e7
commit 60d1d7f64c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 85 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

155
standards/core/network.md
View File

@ -1,19 +1,19 @@
--- ---
title: WAKU2-NETWORK slug: 64
title: 64/WAKU2-NETWORK
name: Waku v2 Network name: Waku v2 Network
status: draft
category: Best Current Practice category: Best Current Practice
tags: waku/application
editor: Hanno Cornelius <hanno@status.im> editor: Hanno Cornelius <hanno@status.im>
contributors: contributors:
--- ---
## Abstract ## Abstract
This RFC specifies an opinionated deployment of [10/WAKU2](https://rfc.vac.dev/spec/10/) protocols This specification describes an opinionated deployment of [10/WAKU2](../10/waku2.md) protocols to form a coherent and
to form a coherent and shared decentralized messaging network shared decentralized messaging network that is open-access,
that is open-access, useful for generalized messaging, privacy-preserving, scalable and
useful for generalized messaging,
privacy-preserving,
scalable and
accessible even to resource-restricted devices. accessible even to resource-restricted devices.
We'll refer to this opinionated deployment simply as We'll refer to this opinionated deployment simply as
_the public Waku Network_, _the Waku Network_ or, if the context is clear, _the network_ _the public Waku Network_, _the Waku Network_ or, if the context is clear, _the network_
@ -23,18 +23,18 @@ in the rest of this document.
### Routing protocol ### Routing protocol
The Waku Network is built on the [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/) routing protocol, The Waku Network is built on the [17/WAKU2-RLN-RELAY](../17/rln-relay.md) routing protocol,
which in turn is an extension of [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/) with spam protection measures. which in turn is an extension of [11/WAKU2-RELAY](../11/relay.md) with spam protection measures.
### Network shards ### Network shards
Traffic in the Waku Network is sharded into eight [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/) pubsub topics. Traffic in the Waku Network is sharded into eight [17/WAKU2-RLN-RELAY](../17/rln-relay.md) pubsub topics.
Each pubsub topic is named according to the static shard naming format Each pubsub topic is named according to the static shard naming format
defined in [WAKU2-RELAY-SHARDING](../../core/relay-sharding.md) defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
with: with:
* `<cluster_id>` set to `1` * `<cluster_id>` set to `1`
* `<shard_number>` occupying the range `0` to `7`. * `<shard_number>` occupying the range `0` to `7`.
In other words, the Waku Network is a [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/) network In other words, the Waku Network is a [17/WAKU2-RLN-RELAY](../17/rln-relay.md) network
routed on the combination of the eight pubsub topics: routed on the combination of the eight pubsub topics:
``` ```
/waku/2/rs/1/0 /waku/2/rs/1/0
@ -43,11 +43,11 @@ routed on the combination of the eight pubsub topics:
/waku/2/rs/1/7 /waku/2/rs/1/7
``` ```
A node MUST use [WAKU-METADATA](./metadata.md) protocol to identify the `<cluster_id>` that every A node MUST use [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md) protocol to identify the `<cluster_id>` that every
inbound/outbound peer that attempts to connect supports. In any of the following cases, the node MUST trigger a disconnection: inbound/outbound peer that attempts to connect supports. In any of the following cases, the node MUST trigger a disconnection:
* [WAKU-METADATA](./metadata.md) dial fails. * [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md) dial fails.
* [WAKU-METADATA](./metadata.md) reports an empty `<cluster_id>`. * [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md) reports an empty `<cluster_id>`.
* [WAKU-METADATA](./metadata.md) reports a `<cluster_id>` different than `1`. * [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md) reports a `<cluster_id>` different than `1`.
## Roles ## Roles
@ -58,16 +58,17 @@ There are two distinct roles evident in the network, those of:
### Nodes ### Nodes
Nodes are the individual software units Nodes are the individual software units
using [10/WAKU2](https://rfc.vac.dev/spec/10/) protocols to form a p2p messaging network. using [10/WAKU2](../10/waku2.md) protocols to form a p2p messaging network.
Nodes, in turn, can participate in a shard as full relayers, i.e. _relay nodes_, Nodes, in turn, can participate in a shard as full relayers, i.e. _relay nodes_,
or by running a combination of protocols suitable for resource-restricted environments, i.e. _non-relay nodes_. or by running a combination of protocols suitable for resource-restricted environments,
i.e. _non-relay nodes_.
Nodes can also provide various services to the network, Nodes can also provide various services to the network,
such as storing historical messages or protecting the network against spam. such as storing historical messages or protecting the network against spam.
See the section on [default services](#default-services) for more. See the section on [default services](#default-services) for more.
#### Relay nodes #### Relay nodes
Relay nodes MUST follow [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/) Relay nodes MUST follow [17/WAKU2-RLN-RELAY](../17/rln-relay.md)
to route messages to other nodes in the network to route messages to other nodes in the network
for any of the pubsub topics [defined as the Waku Network shards](#network-shards). for any of the pubsub topics [defined as the Waku Network shards](#network-shards).
Relay nodes MAY choose to subscribe to any of these shards, Relay nodes MAY choose to subscribe to any of these shards,
@ -82,15 +83,15 @@ it MAY choose to support some shards as a non-relay node.
Nodes MAY use any method to bootstrap connection to the network, 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 [EIP-1459 DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459). but it is RECOMMENDED that each node retrieves a list of bootstrap peers to connect to using [EIP-1459 DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459).
Relay nodes SHOULD use [33/WAKU2-DISCV5](https://rfc.vac.dev/spec/33/) to continually discover other peers in the network. Relay nodes SHOULD use [33/WAKU2-DISCV5](../33/discv5.md) to continually discover other peers in the network.
Each relay node MUST encode its supported shards into its discoverable ENR Each relay node MUST encode its supported shards into its discoverable ENR,
as described in [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/#discovery). as described in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/#discovery).
The ENR MUST be updated if the set of supported shards change. 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. A node MAY choose to ignore discovered peers that do not support any of the shards in its own subscribed set.
#### Transports #### Transports
Relay nodes MUST follow [10/WAKU2](https://rfc.vac.dev/spec/10/) specifications with regards to supporting different transports. Relay nodes MUST follow [10/WAKU2](../10/waku2.md) specifications with regards to supporting different transports.
If TCP transport is available, each relay node MUST support it as transport for both dialing and listening. If TCP transport is available, each relay node MUST support it as transport for both dialing and listening.
In addition, a relay node SHOULD support secure websockets for bidirectional communication streams, In addition, a relay node SHOULD support secure websockets for bidirectional communication streams,
for example to allow connections from and to web browser-based clients. for example to allow connections from and to web browser-based clients.
@ -100,14 +101,14 @@ A relay node MAY support unsecure websockets if required by the application or r
For each supported shard, For each supported shard,
each relay node SHOULD enable and support the following protocols as a service node: each relay node SHOULD enable and support the following protocols as a service node:
1. [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/) to allow resource-restricted peers to subscribe to messages matching a specific content filter. 1. [12/WAKU2-FILTER](../12/filter.md) to allow resource-restricted peers to subscribe to messages matching a specific content filter.
2. [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) to allow other peers to request historical messages from this node. 2. [13/WAKU2-STORE](../13/store.md) to allow other peers to request historical messages from this node.
3. [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) to allow resource-restricted peers to request publishing a message to the network on their behalf. 3. [19/WAKU2-LIGHTPUSH](../19/lightpush.md) to allow resource-restricted peers to request publishing a message to the network on their behalf.
4. [34/WAKU2-PEER-EXCHANGE](../../core/peer-exchange/peer-exchange.md) to allow resource-restricted peers to discover more peers in a resource efficient way. 4. [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md) to allow resource-restricted peers to discover more peers in a resource efficient way.
#### Store service nodes #### Store service nodes
Each relay node SHOULD support [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) as a store service node, Each relay node SHOULD support [13/WAKU2-STORE](../13/store.md) as a store service node,
for each supported shard. for each supported shard.
The store SHOULD be configured to retain at least `12` hours of messages per supported shard. The store SHOULD be configured to retain at least `12` hours of messages per supported shard.
Store service nodes SHOULD only store messages with a valid [`rate_limit_proof`](#message-attributes) attribute. Store service nodes SHOULD only store messages with a valid [`rate_limit_proof`](#message-attributes) attribute.
@ -117,14 +118,14 @@ Store service nodes SHOULD only store messages with a valid [`rate_limit_proof`]
Nodes MAY opt out of relay functionality on any network shard Nodes MAY opt out of relay functionality on any network shard
and instead request services from relay nodes as clients and instead request services from relay nodes as clients
using any of the defined service protocols: using any of the defined service protocols:
1. [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/) to subscribe to messages matching a specific content filter. 1. [12/WAKU2-FILTER](../12/filter.md) to subscribe to messages matching a specific content filter.
2. [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) to request historical messages matching a specific content filter. 2. [13/WAKU2-STORE](../13/store.md) to request historical messages matching a specific content filter.
3. [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/) to request publishing a message to the network. 3. [19/WAKU2-LIGHTPUSH](../19/lightpush.md) to request publishing a message to the network.
4. [34/WAKU2-PEER-EXCHANGE](../../core/peer-exchange/peer-exchange.md) to discover more peers in a resource efficient way. 4. [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md) to discover more peers in a resource efficient way.
#### Store client nodes #### Store client nodes
Nodes MAY request historical messages from [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/) service nodes as store clients. Nodes MAY request historical messages from [13/WAKU2-STORE](../13/store.md) service nodes as store clients.
A store client SHOULD discard any messages retrieved from a store service node that do not contain a valid [`rate_limit_proof`](#message-attributes) attribute. A store client SHOULD discard any messages retrieved from a store service node that do not contain a valid [`rate_limit_proof`](#message-attributes) attribute.
The client MAY consider service nodes returning messages without a valid [`rate_limit_proof`](#message-attributes) attribute as untrustworthy. The client MAY consider service nodes returning messages without a valid [`rate_limit_proof`](#message-attributes) attribute as untrustworthy.
The mechanism by which this may happen is currently underdefined. The mechanism by which this may happen is currently underdefined.
@ -132,19 +133,21 @@ The mechanism by which this may happen is currently underdefined.
### Applications ### Applications
Applications are the higher-layer projects or platforms that make use of the generalized messaging capability of the network. 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 [10/WAKU2](https://rfc.vac.dev/spec/10/) protocols. In other words, an application defines a payload used in the various [10/WAKU2](../10/waku2.md) protocols.
Any participant in an application SHOULD make use of an underlying node in order to communicate on the network. 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 [autosharding](#autosharding) API Applications SHOULD make use of an [autosharding](#autosharding) API
to allow the underlying node to automatically select the target shard on the Waku Network. See the section on [autosharding](#autosharding) for more. to allow the underlying node to automatically select the target shard on the Waku Network.
See the section on [autosharding](#autosharding) for more.
## RLN rate-limiting ## RLN rate-limiting
The [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/) network uses [32/RLN-V1](https://rfc.vac.dev/spec/32/) proofs The [17/WAKU2-RLN-RELAY](../17/rln-relay.md) protocol uses [32/RLN-V1](../../../../vac/32/rln-v1.md) proofs
to ensure that a pre-agreed rate limit is not exceeded by any publisher. to ensure that a pre-agreed rate limit is not exceeded by any publisher.
While the network is under capacity, While the network is under capacity,
individual relayers MAY choose to freely route messages without RLN proofs 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. up to a discretionary bandwidth limit,
This bandwidth limit SHOULD be enforced using [bandwidth validation mechanism](#free-bandwidth-exceeded) separate from RLN rate-limiting. after which messages without proofs MUST be discarded by relay nodes.
This bandwidth limit SHOULD be enforced using a [bandwidth validation mechanism](#free-bandwidth-exceeded) separate from a RLN rate-limiting.
This implies that quality of service and reliability is significantly lower for messages without proofs 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. and at times of high network utilization these messages may not be relayed at all.
@ -154,61 +157,71 @@ For the Waku Network,
the `epoch` is set to `1` second the `epoch` is set to `1` second
and the maximum number of messages published per `epoch` is limited to `1` per publisher. and the maximum number of messages published per `epoch` is limited to `1` per publisher.
The `max_epoch_gap` is set to `20` seconds, The `max_epoch_gap` is set to `20` seconds,
meaning that validators MUST _reject_ messages with an `epoch` more than 20 seconds into the past or future compared to the validator's own clock. meaning that validators (relay nodes),
MUST _reject_ messages with an `epoch` more than 20 seconds into the past or
future compared to the validator's own clock.
All nodes, validators and publishers, All nodes, validators and publishers,
SHOULD use Network Time Protocol (NTP) to synchronize their own clocks, SHOULD use Network Time Protocol (NTP) to synchronize their own clocks,
thereby ensuring valid timestamps for proof generation and validation. thereby ensuring valid timestamps for proof generation and validation.
### Memberships ### Memberships
Each publisher to the Waku Network SHOULD register an RLN membership Each publisher to the Waku Network SHOULD register an RLN membership
with one of the RLN storage contracts with one of the RLN storage contracts
moderated in the Sepolia registry contract with address [0xF1935b338321013f11068abCafC548A7B0db732C](https://sepolia.etherscan.io/address/0xF1935b338321013f11068abCafC548A7B0db732C#code). moderated in the Sepolia registry contract with address [0xF1935b338321013f11068abCafC548A7B0db732C](https://sepolia.etherscan.io/address/0xF1935b338321013f11068abCafC548A7B0db732C#code).
Initial memberships are registered in the Sepolia RLN storage contract with address [0x58322513A35a8f747AF5A385bA14C2AbE602AA59](https://sepolia.etherscan.io/address/0x58322513A35a8f747AF5A385bA14C2AbE602AA59#code). Initial memberships are registered in the Sepolia RLN storage contract with address [0x58322513A35a8f747AF5A385bA14C2AbE602AA59](https://sepolia.etherscan.io/address/0x58322513A35a8f747AF5A385bA14C2AbE602AA59#code).
RLN membership setup and registration MUST follow [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/#setup-and-registration), RLN membership setup and registration MUST follow [17/WAKU2-RLN-RELAY](../17/rln-relay.md/#setup-and-registration),
with the `staked_fund` set to `0`. with the `staked_fund` set to `0`.
In other words, the Waku Network does not use RLN staking. In other words, the Waku Network does not use RLN staking.
### RLN Proofs ### RLN Proofs
Each RLN member MUST generate and attach an RLN proof to every published message Each RLN member MUST generate and attach an RLN proof to every published message
as described in [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/#publishing). as described in [17/WAKU2-RLN-RELAY](../17/rln-relay.md/#publishing).
Slashing is not implemented for the Waku Network. Slashing is not implemented for the Waku Network.
Instead, validators will penalise peers forwarding messages exceeding the rate limit Instead, validators will penalise peers forwarding messages exceeding the rate limit
as specified for [the rate-limiting validation mechanism](#rate-limit-exceeded). as specified for [the rate-limiting validation mechanism](#rate-limit-exceeded).
This incentivizes all nodes to validate RLN proofs This incentivizes all relay nodes to validate RLN proofs
and reject messages violating rate limits and reject messages violating rate limits
in order to continue participating in the network. in order to continue participating in the network.
## Network traffic ## Network traffic
All payload on the Waku Network MUST be encapsulated in a [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/) All payload on the Waku Network MUST be encapsulated in a [14/WAKU2-MESSAGE](../14/message.md)
with rate limit proof extensions defined for [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17/#payloads). with rate limit proof extensions defined for [17/WAKU2-RLN-RELAY](../17/rln-relay.md/#payloads).
Each message on the Waku Network SHOULD be validated by each relayer, Each message on the Waku Network SHOULD be validated by each relayer,
according to the rules discussed under [message validation](#message-validation). according to the rules discussed under [message validation](#message-validation).
### Message Attributes ### Message Attributes
- The mandatory `payload` attribute MUST contain the message data payload as crafted by the application. - The mandatory `payload` attribute MUST contain the message data payload as crafted by the application.
- The mandatory `content_topic` attribute MUST specify a string identifier that can be used for content-based filtering. This is also crafted by the application. See [Autosharding](#autosharding) for more on the content topic format. - The mandatory `content_topic` attribute MUST specify a string identifier that can be used for content-based filtering.
- The optional `meta` attribute MAY be omitted. If present this will form part of the message uniqueness vector described in [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/). This is also crafted by the application.
See [Autosharding](#autosharding) for more on the content topic format.
- The optional `meta` attribute MAY be omitted.
If present, will form part of the message uniqueness vector described in [14/WAKU2-MESSAGE](../14/message.md).
- The optional `version` attribute SHOULD be set to `0`. It MUST be interpreted as `0` if not present. - The optional `version` attribute SHOULD be set to `0`. It MUST be interpreted as `0` if not present.
- The mandatory `timestamp` 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. - The mandatory `timestamp` 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.
- The optional `ephemeral` attribute MUST be set to `true` if the message should not be persisted by the Waku Network. - The optional `ephemeral` attribute MUST be set to `true` if the message should not be persisted by the Waku Network.
- The optional `rate_limit_proof` attribute SHOULD be populated with the RLN proof as set out in [RLN Proofs](#rln-proofs). 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. - The optional `rate_limit_proof` attribute SHOULD be populated with the RLN proof as set out in [RLN Proofs](#rln-proofs).
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.
### Message Size ### Message Size
Any Waku Message published to the network MUST NOT exceed an absolute maximum size of `150` kilobytes. Any [14/WAKU2-MESSAGE](../14/message.md) published to the network MUST NOT exceed an absolute maximum size of `150` kilobytes.
This limit applies to the entire message after protobuf serialization, including attributes. This limit applies to the entire message after protobuf serialization, including attributes.
It is RECOMMENDED not to exceed an average size of `4` kilobytes for Waku Messages published to the network. It is RECOMMENDED not to exceed an average size of `4` kilobytes for [14/WAKU2-MESSAGE](../14/message.md) published to the network.
### Message Validation ### Message Validation
Relay nodes MUST apply [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/c96c9ec5909d64fe020d7630f3fd982bc18fd06a/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) to each relayed message and Relay nodes MUST apply [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) to each relayed message and
SHOULD apply all of the rules set out in the section below to determine the validity of a message. 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, Validation has one of three outcomes,
repeated here from the [gossipsub specification](https://github.com/libp2p/specs/blob/c96c9ec5909d64fe020d7630f3fd982bc18fd06a/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) for ease of reference: repeated here from the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) for ease of reference:
1. Accept - the message is considered valid and it MUST be delivered and forwarded to the network. 1. Accept - the message is considered valid and it MUST be delivered and forwarded to the network.
2. Reject - the message is considered invalid, MUST be rejected and SHOULD trigger a gossipsub scoring penalty against the transmitting peer. 2. Reject - the message is considered invalid, MUST be rejected and SHOULD trigger a gossipsub scoring penalty against the transmitting peer.
3. 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. 3. 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.
@ -217,7 +230,7 @@ The following validation rules are defined:
#### Decoding failure #### Decoding failure
If a message fails to decode as a valid [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14/). If a message fails to decode as a valid [14/WAKU2-MESSAGE](../14/message.md),
the relay node MUST _reject_ the message. the relay node MUST _reject_ the message.
This SHOULD trigger a penalty against the transmitting peer. This SHOULD trigger a penalty against the transmitting peer.
@ -250,14 +263,14 @@ the relay node MUST _reject_ the message.
If a message contains an RLN proof If a message contains an RLN proof
and the zero-knowledge proof is invalid and the zero-knowledge proof is invalid
according to the verification process described in [32/RLN-V1](https://rfc.vac.dev/spec/32/#verification), according to the verification process described in [32/RLN-V1](../../../../vac/32/rln-v1.md),
the relay node MUST _ignore_ the message. the relay node MUST _ignore_ the message.
#### Rate limit exceeded #### Rate limit exceeded
If a message contains an RLN proof If a message contains an RLN proof
and the relay node detects double signaling and the relay node detects double signaling
according to the verification process described in [32/RLN-V1](https://rfc.vac.dev/spec/32/#verification), according to the verification process described in [32/RLN-V1](../../../../vac/32/rln-v1.md),
the relay node MUST _reject_ the message the relay node MUST _reject_ the message
for violating the agreed rate limit of `1` message every `1` second. for violating the agreed rate limit of `1` message every `1` second.
This SHOULD trigger a penalty against the transmitting peer. This SHOULD trigger a penalty against the transmitting peer.
@ -265,13 +278,13 @@ This SHOULD trigger a penalty against the transmitting peer.
## Autosharding ## Autosharding
Nodes in the Waku Network SHOULD allow encapsulating applications to use autosharding, Nodes in the Waku Network SHOULD allow encapsulating applications to use autosharding,
as defined in [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/#automatic-sharding) as defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/#automatic-sharding)
by automatically determining the appropriate pubsub topic by automatically determining the appropriate pubsub topic
from the list [of defined Waku Network shards](#network-shards). from the list [of defined Waku Network shards](#network-shards).
This allows the application to omit the target pubsub topic This allows the application to omit the target pubsub topic
when invoking any Waku protocol function. when invoking any Waku protocol function.
Applications using autosharding MUST use content topics in the format Applications using autosharding MUST use content topics in the format
defined in [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/#content-topics-format-for-autosharding) defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/#content-topics-format-for-autosharding)
and SHOULD use the short length format: and SHOULD use the short length format:
``` ```
@ -281,8 +294,7 @@ and SHOULD use the short length format:
When an encapsulating application makes use of autosharding When an encapsulating application makes use of autosharding
the underlying node MUST determine the target pubsub topic(s) the underlying node MUST determine the target pubsub topic(s)
from the content topics provided by the application from the content topics provided by the application
using the hashing mechanism defined in [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/#automatic-sharding). using the hashing mechanism defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/#automatic-sharding).
## Copyright ## Copyright
@ -290,15 +302,18 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References ## References
* [10/WAKU2](../10/waku2.md)
* [17/WAKU2-RLN-RELAY](../17/rln-relay.md)
* [11/WAKU2-RELAY](../11/relay.md)
* [WAKU2-RELAY-SHARDING](../../core/relay-sharding.md) * [WAKU2-RELAY-SHARDING](../../core/relay-sharding.md)
* [Peer-exchange](../../core/peer-exchange/peer-exchange.md) * [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata.md)
* [EIP-1459 DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459)
* [33/WAKU2-DISCV5](../33/discv5.md)
## normative * [12/WAKU2-FILTER](../12/filter.md)
(TBD) * [13/WAKU2-STORE](../13/store.md)
A list of references that MUST be read to fully understand and/or implement this protocol. * [19/WAKU2-LIGHTPUSH](../19/lightpush.md)
See [RFC3967 Section 1.1](https://datatracker.ietf.org/doc/html/rfc3967#section-1.1). * [34/WAKU2-PEER-EXCHANGE](../../core/peer-exchange.md)
* [32/RLN-V1](../../../../vac/32/rln-v1.md)
## informative * [14/WAKU2-MESSAGE](../14/message.md)
(TBD) * [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators)
A list of additional references. * [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/)