vacp2p/rfc
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc.git synced 2025-01-11 15:24:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat: rendezvous discovery (#586)

Browse Source
This commit is contained in:
kaiserd 2023-03-28 10:43:02 +02:00 committed by GitHub
parent 5fef0d1a0d
commit 496233e3b5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 71 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/docs/rfcs/33/README.md
View File

@ -75,6 +75,10 @@ As part of our [discv5 roadmap](https://forum.vac.dev/t/waku-v2-discv5-roadmap-d
`33/WAKU2-DISCV5` fully inherits the [discv5 semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md). `33/WAKU2-DISCV5` fully inherits the [discv5 semantics](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md).
Before announcing their address via Waku2 discv5, nodes SHOULD check if this address is publicly reachable.
Nodes MAY use the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md) to perform that check.
Nodes SHOULD only announce publicly reachable addresses via Waku2 discv5,
to avoid cluttering peer lists with nodes that are not reachable.
# Wire Format Specification # Wire Format Specification
@ -159,6 +163,7 @@ Properly protecting against eclipse attacks is challenging and raises research q
1. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) 1. [`discv5` wire protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md)
1. [`discv5` topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement) 1. [`discv5` topic discovery](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-advertisement)
1. [Waku DNS discovery](https://rfc.vac.dev/spec/10/#discovery-domain) 1. [Waku DNS discovery](https://rfc.vac.dev/spec/10/#discovery-domain)
1. [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md)
1. [`EIP-1459`](https://eips.ethereum.org/EIPS/eip-1459) 1. [`EIP-1459`](https://eips.ethereum.org/EIPS/eip-1459)
1. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md) 1. [`GossipSub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
1. [Waku discv5 roadmap discussion](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121) 1. [Waku discv5 roadmap discussion](https://forum.vac.dev/t/waku-v2-discv5-roadmap-discussion/121)

71
content/docs/rfcs/57/README.md
View File

@ -77,7 +77,6 @@ an example for the shard with index `18` in the Status shard cluster:
In other words, the mesh network with the pubsub topic name `/waku/2/rs/16/18` carries messages associated with shard `18` in the Status shard cluster. In other words, the mesh network with the pubsub topic name `/waku/2/rs/16/18` carries messages associated with shard `18` in the Status shard cluster.
### Implementation Suggestion ### Implementation Suggestion
The Waku implementation should offer an interface that allows Status nodes to subscribe to Status specific content topics like The Waku implementation should offer an interface that allows Status nodes to subscribe to Status specific content topics like
@ -208,7 +207,6 @@ but can significantly improve scaling.
We still have k-anonymity because several chat pairs are mapped into one content topic. 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. We could improve on this in the future, and research the applicability of PIR (private information retrieval) techniques in the future.
# Infrastructure Shards # Infrastructure Shards
Waku messages are typically relayed in larger mesh networks comprised of nodes with varying resource profiles (see [30/ADAPTIVE-NODES](/spec/30/)). Waku messages are typically relayed in larger mesh networks comprised of nodes with varying resource profiles (see [30/ADAPTIVE-NODES](/spec/30/)).
@ -248,7 +246,6 @@ Strong Desktop clients MAY opt in to support the relay network.
> *Note*: This is not planned for the MVP. > *Note*: This is not planned for the MVP.
# Light Protocols # Light Protocols
Light protocols may be used to save bandwidth, Light protocols may be used to save bandwidth,
@ -263,7 +260,6 @@ Light protocols comprise
* [12/WAKU2-FILTER](/spec/12/) for requesting messages with specific attributes * [12/WAKU2-FILTER](/spec/12/) for requesting messages with specific attributes
* [34/WAKU2-PEER-EXCHANGE](/spec/34) for discovering peers * [34/WAKU2-PEER-EXCHANGE](/spec/34) for discovering peers
# Waku Archive # Waku Archive
Archive nodes are Waku nodes that offer the Waku archive service via the Waku store protocol ([13/WAKU2-STORE](/spec/13/)). Archive nodes are Waku nodes that offer the Waku archive service via the Waku store protocol ([13/WAKU2-STORE](/spec/13/)).
@ -285,6 +281,70 @@ In fact, the archive service can be offered by infrastructure nodes.
Shard discovery is covered by [51/WAKU2-RELAY-SHARDING](/spec/51/). Shard discovery is covered by [51/WAKU2-RELAY-SHARDING](/spec/51/).
This allows the Status app to abstract from the discovery process and simply address shards by their index. This allows the Status app to abstract from the discovery process and simply address shards by their index.
## Libp2p Rendezvous and Circuit-Relay
To make nodes behind restrictive NATs discoverable,
this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md).
Nodes can check whether they are behind a restrictive NAT using the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md).
> *Note:* The following will move into [51/WAKU2-RELAY-SHARDING](/spec/51/), or [33/WAKU2-DISCV5](/spec/33/):
Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address via [33/WAKU2-DISCV5](/spec/33/) discovery.
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.
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
[libp2p circuit relay](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md) functionality.
To minimize the load on circuit-relay nodes, nodes SHOULD
1) make use of the [limiting](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md#reservation)
functionality offered by the libp2p circuit relay protocols, and
2) use [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) to upgrade to a direct connection.
Nodes that do not announce themselves at all and only plan to use light protocols,
MAY use rendezvous discovery instead of or along-side [34/WAKU2-PEER-EXCHANGE](/specs/34).
For these nodes, rendezvous and [34/WAKU2-PEER-EXCHANGE](/specs/34) offer the same functionality,
but return node sets sampled in different ways.
Using both can help increasing connectivity.
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.
### Announcing Shard Participation
Registering a namespace via [lib-p2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#interaction)
is done via a register query:
```
REGISTER{my-app, {QmA, AddrA}}
```
The app name, `my-app` is used to encode a single shard in the form:
```
<rs (utf8 encoded)> | <2-byte shard cluster index> | <2-byte shard index>
```
Registering shard 2 in the Status shard cluster (with shard cluster index 16, see [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](/spec/52/h)),
the register query would look like
```
REGISTER{0x727300100002, {QmA, AddrA}}
```
Participation in further shards is registered with further queries; one register query per shard.
(0x7273 is the encoding of `rs`.)
A discovery query for nodes that are part of this shard would look like
```
DISCOVER{ns: 0x727300100002}
```
# DoS Protection # DoS Protection
> *Note* : DoS protection will be specified in a soon-to-follow update of this RFC (while in raw state). > *Note* : DoS protection will be specified in a soon-to-follow update of this RFC (while in raw state).
@ -310,7 +370,6 @@ Map 1:1 chats to community shards, if both A and B are part of the respective co
This increases k-anonymity and benefits from community DoS protection. This increases k-anonymity and benefits from community DoS protection.
It could be rate-limited with RLN. It could be rate-limited with RLN.
# Security/Privacy Considerations # Security/Privacy Considerations
This document makes several trade-offs to privacy and anonymity. This document makes several trade-offs to privacy and anonymity.
@ -332,6 +391,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
* [34/WAKU2-PEER-EXCHANGE](/spec/34/) * [34/WAKU2-PEER-EXCHANGE](/spec/34/)
* [33/WAKU2-DISCV5](/spec/33/) * [33/WAKU2-DISCV5](/spec/33/)
* [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/) * [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/)
* [libp2p circuit relay](https://github.com/libp2p/specs/blob/6634ca7abb2f955645243d48d1cd2fd02a8e8880/relay/circuit-v2.md)
* [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md)
* [31/WAKU2-ENR](/spec/31/) * [31/WAKU2-ENR](/spec/31/)
* [45/WAKU2-ADVERSARIAL-MODELS](/spec/45) * [45/WAKU2-ADVERSARIAL-MODELS](/spec/45)