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

Merge ed5605cb1bb907b1f6aa9840701624eab74efc3a into f5e7f23fa89808adce36608cc1929a9a8e79cb7e

Browse Source
This commit is contained in:
Jimmy Debe 2024-09-03 09:06:26 +01:00 committed by GitHub
commit a399786173
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
standards/core/peer-exchange.md
View File

@ -42,12 +42,14 @@ The responder SHOULD provide a set of peers that has been retrieved using ambien
This both protects the responder's anonymity as well as helps distributing load.
To allow for fast responses, responders SHOULD retrieve peers unsolicited (before receiving a query)
and maintain a queue of peers for the purpose of providing them in peer exchange responses.
and maintain a queue of peers by their `cluster_id`/`shard` for the purpose of providing them in peer exchange responses.
To get the best anonymity properties with respect to response peer sets, responders SHOULD use each of these peers only once.
To save bandwidth, and as a trade off to anonymity,
responders MAY maintain a larger cache of exchange peers and randomly sample response sets from this local cache.
The size of the cache SHOULD be large enough to allow randomly sampling peer sets that (on average) do not overlap too much.
This local cache SHOULD store peers by `cluster_id`/`shard` for faster retrieval.
For peers without shard info, the cache can maintain a separate set of peers.
The size of the cache for each `cluster_id`/`shard` pair SHOULD be large enough to allow randomly sampling peer sets that (on average) do not overlap too much.
The responder SHOULD periodically replace the oldest peers in the cache.
This document provides recommended choices for the cache size in the [Implementation Suggestions Section](#implementation-suggestions).
@ -68,6 +70,8 @@ message PeerInfo {
message PeerExchangeQuery {
uint64 num_peers = 1;
optional uint32 cluster_id = 2;
repeated uint32 shards = 3;
}
message PeerExchangeResponse {
@ -84,6 +88,8 @@ message PeerExchangeRPC {
The `enr` field contains a Waku ENR as specified in [WAKU2-ENR](./enr.md).
Requesters send a `PeerExchangeQuery` to a peer.
When `cluster_id` is set and `shards` are specified, responders SHOULD provide peers belonging to the specified cluster_id/shards pair.
When no `shards` are specified, responders SHOULD provide a mixed list of peers from any shard and non-shard specific peers.
Responders SHOULD include a maximum of `num_peers` `PeerInfo` instances into a response.
Responders send a `PeerExchangeResponse` to requesters containing a list of `PeerInfo` instances, which in turn hold an ENR.
@ -99,7 +105,8 @@ The size of the (optional) exchange peer cache discussed in [Theory and Protocol
depends on the average number of requested peers, which is expected to be the outbound degree of the underlying
[libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) mesh network.
The recommended value for this outbound degree is 6 (see parameter `D` in [29/WAKU2-CONFIG](https://rfc.vac.dev/spec/29/)).
It is recommended for the cache to hold at least 10 times as many peers (60).
It is recommended for the cache to hold at least 10 times as many peers (60) for each `cluster_id`/`shard` pair.
The size of the whole cache is bounded by `No. of cluster_id/shard pair` * `D` * 10.
The recommended cache size also depends on the number of requesters a responder is expected to serve within a _refresh cycle_.
A refresh cycle is the time interval in which all peers in the cache are expected to be replaced.