From 81993a9211d4b7eca9b8bf41a8ee9d243e74a261 Mon Sep 17 00:00:00 2001 From: SionoiS Date: Tue, 13 Aug 2024 10:47:55 -0400 Subject: [PATCH 1/5] rendezvous draft --- standards/core/rendezvous.md | 48 ++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 standards/core/rendezvous.md diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md new file mode 100644 index 0000000..cc0c474 --- /dev/null +++ b/standards/core/rendezvous.md @@ -0,0 +1,48 @@ +--- +title: WAKU-RENDEZVOUS +name: Waku rendez vous discovery +editor: Simon-Pierre Vivier +contributors: +--- + +## Abstract +This document describe the goal, +strategy and usage of the libp2p rendezvous protocol by Waku. + +Rendezvous is one of the discovery methods that can be used by Waku, +it supplements Discovery v5 and Waku peer exchange but fill a specific role. + +## Background +How do new nodes join the network is the question that discovery answers. +Discovery must be fast, pertinent and resilient to attacks. +Rendezvous is both fast and allow the discovery of relevant peers, +although by it's design can be easily abused. +The properties of rendezvous complements well the slower but safer methods like Discv5. +To contribute well, a Waku nodes must know a sufficient number of peers with +a wide variety of capabilities. +By using rendezvous in combination with +[Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) and +[Waku peer exchange](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md#abstract), +Waku nodes will reach a good number of meaningful peers +faster than through a single discovery method. + +## Terminology +Please refers to the [libp2p spec](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). + +## Theory +Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node will be initialized also as a rendezvous point. +Each relay node will register with a random rendezvous point every 10 seconds. +Each registration will expire after 1 minute. +Each node will roughly have 6 records of itself in the network at any given time. + +At startup, every nodes will discover peers by sending a request to a random rendezvous node. +A maximum of 12 peers will be requested. +This number is enough for good GossipSub connectivity and +minimize the load on rendezvous points. +It is assumed that other discovery methods are used in conjunction and +will continue discovering peers for the lifetime of the node. + +The namespaces used to register and request will be in the format '/waku/rs/cluster-id/shard'. +A registration consist of all the shards a nodes supports and their corresponding namespaces. + +Namespaces will not contain capabilities yet but may in the future. From ca8029dc4547e3cef426f75f0e46ca6f3d1f173f Mon Sep 17 00:00:00 2001 From: SionoiS Date: Wed, 14 Aug 2024 11:24:52 -0400 Subject: [PATCH 2/5] rephrasing --- standards/core/rendezvous.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index cc0c474..957e13b 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -30,6 +30,9 @@ faster than through a single discovery method. Please refers to the [libp2p spec](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). ## Theory +The namespaces used to register and request will be in the format 'rs/cluster-id/shard'. +A registration or request consist of all the shards a nodes supports and their corresponding namespaces. + Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node will be initialized also as a rendezvous point. Each relay node will register with a random rendezvous point every 10 seconds. Each registration will expire after 1 minute. @@ -42,7 +45,6 @@ minimize the load on rendezvous points. It is assumed that other discovery methods are used in conjunction and will continue discovering peers for the lifetime of the node. -The namespaces used to register and request will be in the format '/waku/rs/cluster-id/shard'. -A registration consist of all the shards a nodes supports and their corresponding namespaces. +## Future Work -Namespaces will not contain capabilities yet but may in the future. +Namespaces will not contain capabilities yet but may in the future. If the need arise nodes could use rendezvous to discover peers with specific capabilities. From e0aafc6ad65c90e2c942a7c27334a06855f9f0d2 Mon Sep 17 00:00:00 2001 From: SionoiS Date: Thu, 29 Aug 2024 17:14:31 -0400 Subject: [PATCH 3/5] reflect the new impl. --- standards/core/rendezvous.md | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index 957e13b..a0a8aa6 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -12,7 +12,7 @@ strategy and usage of the libp2p rendezvous protocol by Waku. Rendezvous is one of the discovery methods that can be used by Waku, it supplements Discovery v5 and Waku peer exchange but fill a specific role. -## Background +## Background and Rationale How do new nodes join the network is the question that discovery answers. Discovery must be fast, pertinent and resilient to attacks. Rendezvous is both fast and allow the discovery of relevant peers, @@ -26,23 +26,26 @@ By using rendezvous in combination with Waku nodes will reach a good number of meaningful peers faster than through a single discovery method. -## Terminology -Please refers to the [libp2p spec](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). +## Semantics +Waku rendezvous fully inherit the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). -## Theory -The namespaces used to register and request will be in the format 'rs/cluster-id/shard'. -A registration or request consist of all the shards a nodes supports and their corresponding namespaces. +## Specifications +The namespaces used to register and request will be in the format `rs/cluster-id/shard`. -Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node will be initialized also as a rendezvous point. -Each relay node will register with a random rendezvous point every 10 seconds. -Each registration will expire after 1 minute. -Each node will roughly have 6 records of itself in the network at any given time. +Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node will also be initialized as a rendezvous point. + +Each relay node will register with random rendezvous points every 10 seconds, +once for each shard it supports and register only the namespace corresponding to that shard. +Each registrations will expire after 1 minute. + +At startup, every Waku nodes will discover peers by sending requests to random rendezvous points, +once for each shard it supports. +A maximum of 12 peers will be requested each time. -At startup, every nodes will discover peers by sending a request to a random rendezvous node. -A maximum of 12 peers will be requested. This number is enough for good GossipSub connectivity and minimize the load on rendezvous points. -It is assumed that other discovery methods are used in conjunction and +It is assumed that the bootstrap node used is a rendezvous point and +that other discovery methods are used in conjunction and will continue discovering peers for the lifetime of the node. ## Future Work From 18c24ef642f536eb093680a11bdb458e6b60b644 Mon Sep 17 00:00:00 2001 From: SionoiS Date: Wed, 4 Sep 2024 11:16:29 -0400 Subject: [PATCH 4/5] refs --- standards/core/rendezvous.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index a0a8aa6..e93df43 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -51,3 +51,14 @@ will continue discovering peers for the lifetime of the node. ## Future Work Namespaces will not contain capabilities yet but may in the future. If the need arise nodes could use rendezvous to discover peers with specific capabilities. + +# Copyright + +Copyright and related rights waived via +[CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +# References + - [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) + - [Peer Exchange](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md#abstract) + - [Libp2p Rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol) + - [Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) \ No newline at end of file From 53e75df59aa4d153b287c695e00f6c62d9157a78 Mon Sep 17 00:00:00 2001 From: SionoiS Date: Tue, 22 Oct 2024 10:50:34 -0400 Subject: [PATCH 5/5] languare fixes --- standards/core/rendezvous.md | 44 ++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/standards/core/rendezvous.md b/standards/core/rendezvous.md index e93df43..e001aa6 100644 --- a/standards/core/rendezvous.md +++ b/standards/core/rendezvous.md @@ -1,24 +1,25 @@ --- title: WAKU-RENDEZVOUS -name: Waku rendez vous discovery +name: Waku Rendezvous discovery editor: Simon-Pierre Vivier contributors: --- ## Abstract -This document describe the goal, +This document describes the goal, strategy and usage of the libp2p rendezvous protocol by Waku. -Rendezvous is one of the discovery methods that can be used by Waku, -it supplements Discovery v5 and Waku peer exchange but fill a specific role. +Rendezvous is one of the discovery methods that can be used by Waku. +It supplements Discovery v5 and Waku peer exchange. ## Background and Rationale How do new nodes join the network is the question that discovery answers. Discovery must be fast, pertinent and resilient to attacks. Rendezvous is both fast and allow the discovery of relevant peers, -although by it's design can be easily abused. +although it design can be easily abused +due to it's lack of protection against denial of service atacks. The properties of rendezvous complements well the slower but safer methods like Discv5. -To contribute well, a Waku nodes must know a sufficient number of peers with +To contribute well, a Waku node must know a sufficient number of peers with a wide variety of capabilities. By using rendezvous in combination with [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) and @@ -27,26 +28,35 @@ Waku nodes will reach a good number of meaningful peers faster than through a single discovery method. ## Semantics -Waku rendezvous fully inherit the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). +Waku rendezvous fully inherits the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol). ## Specifications -The namespaces used to register and request will be in the format `rs/cluster-id/shard`. +The namespaces used to register and request MUST be in the format `rs/cluster-id/shard`. +Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) for cluster and shard information. -Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node will also be initialized as a rendezvous point. +Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point. -Each relay node will register with random rendezvous points every 10 seconds, -once for each shard it supports and register only the namespace corresponding to that shard. -Each registrations will expire after 1 minute. +Each relay node that participates in discovery +MUST register with random rendezvous points at regular intervals. -At startup, every Waku nodes will discover peers by sending requests to random rendezvous points, +We RECOMMEND a registration interval of 10 seconds. +The node SHOULD register once for every shard it supports, +registering only the namespace corresponding to that shard. + +We RECOMMEND that rendezvous points expire registrations after 1 minute, +in order to keep discovered peer records to those recentrly online. + +At startup, every Waku node SHOULD discover peers by +sending requests to random rendezvous points, once for each shard it supports. -A maximum of 12 peers will be requested each time. +We RECOMMEND a maximum of 12 peers will be requested each time. This number is enough for good GossipSub connectivity and minimize the load on rendezvous points. -It is assumed that the bootstrap node used is a rendezvous point and -that other discovery methods are used in conjunction and -will continue discovering peers for the lifetime of the node. + +We RECOMMEND that bootstrap nodes participate in rendezvous discovery and +that other discovery methods are used in conjunction and +continue discovering peers for the lifetime of the local node. ## Future Work