From 22d44969f75af3a9dfc76aeafb584c4e40599247 Mon Sep 17 00:00:00 2001 From: Age Manning Date: Tue, 16 Apr 2019 14:54:17 +1000 Subject: [PATCH 1/9] Add initial libp2p standardization --- specs/networking/libp2p-standardization.md | 131 +++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 specs/networking/libp2p-standardization.md diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md new file mode 100644 index 0000000000..ddefca02ab --- /dev/null +++ b/specs/networking/libp2p-standardization.md @@ -0,0 +1,131 @@ +ETH 2.0 Networking Spec - Libp2p standard protocols +=== + +# Abstract + +Ethereum 2.0 clients plan to use the libp2p protocol networking stack for +mainnet release. This document aims to standardize the libp2p client protocols, +configuration and messaging formats. + +# Libp2p Protocols + +## Gossipsub + +#### Protocol id: `/meshsub/1.0.0` + +*Note: Parameters listed here are subject to a large-scale network feasibility +study* + +The [Gossipsub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) +protocol will be used for block and attestation propagation across the +network. + +### Configuration Parameters + +Gossipsub has a number of internal configuration parameters which directly +effect the network performance. Clients can implement independently, however +we aim to standardize these across clients to optimize the gossip network for +propagation times and message duplication. Current network-related defaults are: + +``` +( + // The target number of peers in the overlay mesh network (D in the libp2p specs). + mesh_size: 6 + // The minimum number of peers in the mesh network before adding more (D_lo in the libp2p specs). + mesh_lo: 4 + // The maximum number of peers in the mesh network before removing some (D_high in the libp2p sepcs). + mesh_high: 12 + // The number of peers to gossip to during a heartbeat (D_lazy in the libp2p sepcs). + gossip_lazy: 6 // defaults to `mesh_size` + // Time to live for fanout peers (seconds). + fanout_ttl: 60 + // The number of heartbeats to gossip about. + gossip_history: 3 + // Time between each heartbeat (seconds). + heartbeat_interval: 1 +) +``` + +### Topics + +*The Go and Js implementations use string topics - This is likely to be +updated to topic hashes in later versions - https://github.com/libp2p/rust-libp2p/issues/473* + +For Eth2.0 clients, topics will be sent as `SHA2-256` hashes of the topic string. + +There is one dedicated topic for propagating beacon blocks and aggregated +attestations across the network. This topic will have the string +`beacon_chain`. Each shard will have it's own topic allowing relevant parties +to subscribe to in order to receive local shard attestations. The shard topics are +prefixed with `shard` followed by the number of the shard. For example, +messages relating to shard 10, will have the topic string `shard10`. + +### Messages + +Messages sent across gossipsub are fixed-size length-prefixed byte arrays. +Each message has a maximum size of 512KB (estimated from expected largest uncompressed +block size). + +The byte array is prefixed with a unsigned 64 bit length number encoded as an +`unsigned varint` (https://github.com/multiformats/unsigned-varint). Gossipsub messages therefore take the form: +``` ++--------------------------+ +| message length | ++--------------------------+ +| | +| body (<1M) | +| | ++--------------------------+ +``` + +The body of the message is an SSZ-encoded object representing either a +beacon block or attestation. The type of objected is determined via a prefixed +nibble. Currently there are two objects that are sent across the gossip +network. They are (with their corresponding nibble specification): + +- `0x1`: Beacon block +- `0x2`: Attestation + +The body therefore takes the form: +``` ++--------------------------+ +| type nibble | ++--------------------------+ +| | +| SSZ-encoded object | +| | ++--------------------------+ +``` + +## Eth-2 RPC + +#### Protocol Id: `/eth/serenity/beacon/rpc/1` + +The [RPC Interface](./rpc-interface.md) is specified in this repository. + + +## Identify + +#### Protocol Id: `/ipfs/id/1.0.0` (to be updated to `/p2p/id/1.0.0`) + +The Identify protocol (defined in go - [identify-go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/id.go) and rust [rust-identify](https://github.com/libp2p/rust-libp2p/blob/master/protocols/identify/src/lib.rs)) +allows a node A to query another node B which information B knows about A. This also includes the addresses B is listening on. + +This protocol allows nodes to discover addresses of other nodes to be added to +peer discovery. It further allows nodes to determine the capabilities of all it's connected +peers. + +### Configuration Parameters + +The protocol has two configurable parameters, which can be used to identify the +type of connecting node. Suggested format: +``` + version: `/eth/serenity/1.0.0` + user_agent: +``` + +## Discovery + +#### Protocol Id: `/eth/serenity/disc/1.0.0` + +The discovery protocol to be determined. From b83a7c4a23c8b27df64e92efcd05eb201b3244e2 Mon Sep 17 00:00:00 2001 From: Age Manning Date: Wed, 24 Apr 2019 16:44:22 +1000 Subject: [PATCH 2/9] Add @prestonvanloon and @djrtwo's comments for muliple beacon topics --- specs/networking/libp2p-standardization.md | 42 +++++++++------------- 1 file changed, 17 insertions(+), 25 deletions(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index ddefca02ab..126ed53b4a 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -53,12 +53,20 @@ updated to topic hashes in later versions - https://github.com/libp2p/rust-libp2 For Eth2.0 clients, topics will be sent as `SHA2-256` hashes of the topic string. -There is one dedicated topic for propagating beacon blocks and aggregated -attestations across the network. This topic will have the string -`beacon_chain`. Each shard will have it's own topic allowing relevant parties -to subscribe to in order to receive local shard attestations. The shard topics are -prefixed with `shard` followed by the number of the shard. For example, -messages relating to shard 10, will have the topic string `shard10`. +There are two main topics used to propagate attestations and beacon blocks to +all nodes on the network. + +- The `beacon_block` topic - This topic is used solely for propagating new + beacon blocks to all nodes on the networks. +- The `beacon_attestation` topic - This topic is used to for propagate + aggregated attestations to subscribing nodes (typically block proposers) to + be included into future blocks. Attestations will be aggregated in their + respective subnets before publishing on this topic. + +Shards will be grouped into their own subnets (defined by a shard topic). The +number of shard subnets will be defined via `SHARD_SUBNET_COUNT` and the shard +`shard_number % SHARD_SUBNET_COUNT` will be assigned to the topic: +`shard{shard_number % SHARD_SUBNET_COUNT}`. ### Messages @@ -78,24 +86,9 @@ The byte array is prefixed with a unsigned 64 bit length number encoded as an +--------------------------+ ``` -The body of the message is an SSZ-encoded object representing either a -beacon block or attestation. The type of objected is determined via a prefixed -nibble. Currently there are two objects that are sent across the gossip -network. They are (with their corresponding nibble specification): - -- `0x1`: Beacon block -- `0x2`: Attestation - -The body therefore takes the form: -``` -+--------------------------+ -| type nibble | -+--------------------------+ -| | -| SSZ-encoded object | -| | -+--------------------------+ -``` +The body of the message is an SSZ-encoded object. For the `beacon_block` topic, +this will be a `beacon_block`. For the `beacon_attestation` topic, this will be +an `attestation`. ## Eth-2 RPC @@ -103,7 +96,6 @@ The body therefore takes the form: The [RPC Interface](./rpc-interface.md) is specified in this repository. - ## Identify #### Protocol Id: `/ipfs/id/1.0.0` (to be updated to `/p2p/id/1.0.0`) From bbca108a80effe0e167132f88dd1a6899bb86c70 Mon Sep 17 00:00:00 2001 From: Age Manning Date: Thu, 2 May 2019 16:34:47 +1000 Subject: [PATCH 3/9] Add Transport and lower-level libp2p specifications --- specs/networking/libp2p-standardization.md | 79 ++++++++++++++++++++-- 1 file changed, 74 insertions(+), 5 deletions(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index 126ed53b4a..c5add549a9 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -9,6 +9,57 @@ configuration and messaging formats. # Libp2p Protocols +## Transport + +This section details the libp2p transport layer that underlies the +[protocols](#protocols) that are listed in this document. + +Libp2p allows composition of multiple transports. Eth2.0 clients should support +TCP/IP and optionally websockets. Websockets are useful for implementations +running in the browser and therefore native clients would ideally support these implementations +by supporting websockets. + +An ideal libp2p transport would therefore be TCP/IP with a fallback to +websockets. + +### Encryption + +Libp2p currently offers [Secio](https://github.com/libp2p/specs/pull/106) which +can upgrade a transport which will then encrypt all future communication. Secio +generates a symmetric ephemeral key which peers use to encrypt their +communication. It can support a range of ciphers and currently supports key +derivation for elliptic curve-based public keys. + +Current defaults are: +- Key agreement: `ECDH-P256` (also supports `ECDH-P384`) +- Cipher: `AES-128` (also supports `AES-256`, `TwofishCTR`) +- Digests: `SHA256` (also supports `SHA512`) + + +## Protocols + +This section lists the necessary libp2p protocols required by Ethereum 2.0 +running a libp2p network stack. + +## Multistream-select + +#### Protocol id: `/multistream/1.0.0` + +Clients running libp2p should support the [multistream-select](https://github.com/multiformats/multistream-select/) +protocol which allows clients to negotiate libp2p protocols establish streams +per protocol. + +## Multiplexing + +Libp2p allows clients to compose multiple multiplexing methods. Clients should +support [mplex](https://github.com/libp2p/specs/tree/master/mplex) and +optionally [yamux](https://github.com/hashicorp/yamux/blob/master/spec.md) +(these can be composed). + +**Mplex protocol id: `/mplex/6.7.0`** + +**Yamux protocol id: `/yamux/1.0.0`** + ## Gossipsub #### Protocol id: `/meshsub/1.0.0` @@ -70,11 +121,14 @@ number of shard subnets will be defined via `SHARD_SUBNET_COUNT` and the shard ### Messages -Messages sent across gossipsub are fixed-size length-prefixed byte arrays. -Each message has a maximum size of 512KB (estimated from expected largest uncompressed -block size). +#### Libp2p Specification -The byte array is prefixed with a unsigned 64 bit length number encoded as an +*This section simply outlines the data sent across the wire as specified by +libp2p - this section is aimed at gossipsub implementers to standardize their implementation of this protocol* + +Libp2p raw gossipsub messages are sent across the wire as fixed-size length-prefixed byte arrays. + +The byte array is prefixed with an unsigned 64 bit length number encoded as an `unsigned varint` (https://github.com/multiformats/unsigned-varint). Gossipsub messages therefore take the form: ``` +--------------------------+ @@ -86,7 +140,17 @@ The byte array is prefixed with a unsigned 64 bit length number encoded as an +--------------------------+ ``` -The body of the message is an SSZ-encoded object. For the `beacon_block` topic, +The body represents a protobuf-encoded [Message](https://github.com/libp2p/go-libp2p-pubsub/blob/master/pb/rpc.proto#L17-L24). + +In the following section we discuss the data being sent in the `data` field of +the protobuf gossipsub `Message`. + +#### Eth2.0 Specifics + +Each message has a maximum size of 512KB (estimated from expected largest uncompressed +block size). + +The `data` that is sent in a Gossipsub message is an SSZ-encoded object. For the `beacon_block` topic, this will be a `beacon_block`. For the `beacon_attestation` topic, this will be an `attestation`. @@ -100,6 +164,9 @@ The [RPC Interface](./rpc-interface.md) is specified in this repository. #### Protocol Id: `/ipfs/id/1.0.0` (to be updated to `/p2p/id/1.0.0`) +*To be updated to incorporate discv5* + + The Identify protocol (defined in go - [identify-go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/id.go) and rust [rust-identify](https://github.com/libp2p/rust-libp2p/blob/master/protocols/identify/src/lib.rs)) allows a node A to query another node B which information B knows about A. This also includes the addresses B is listening on. @@ -120,4 +187,6 @@ type of connecting node. Suggested format: #### Protocol Id: `/eth/serenity/disc/1.0.0` +*To be updated to incorporate discv5* + The discovery protocol to be determined. From 78181834ab6dbbfdc58a295d71d1309ba5829957 Mon Sep 17 00:00:00 2001 From: Alex Stokes Date: Thu, 2 May 2019 16:38:23 +1000 Subject: [PATCH 4/9] Update specs/networking/libp2p-standardization.md Co-Authored-By: AgeManning --- specs/networking/libp2p-standardization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index c5add549a9..5fe26f435a 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -109,7 +109,7 @@ all nodes on the network. - The `beacon_block` topic - This topic is used solely for propagating new beacon blocks to all nodes on the networks. -- The `beacon_attestation` topic - This topic is used to for propagate +- The `beacon_attestation` topic - This topic is used to propagate aggregated attestations to subscribing nodes (typically block proposers) to be included into future blocks. Attestations will be aggregated in their respective subnets before publishing on this topic. From c7fea5ff38b260fccbe9416d5e0fd769884e5343 Mon Sep 17 00:00:00 2001 From: Age Manning Date: Mon, 6 May 2019 12:28:16 +1000 Subject: [PATCH 5/9] Update libp2p-standardization based on latest comments --- specs/networking/libp2p-standardization.md | 65 ++++++++-------------- 1 file changed, 24 insertions(+), 41 deletions(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index c5add549a9..dec337f39d 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -7,7 +7,7 @@ Ethereum 2.0 clients plan to use the libp2p protocol networking stack for mainnet release. This document aims to standardize the libp2p client protocols, configuration and messaging formats. -# Libp2p Protocols +# Libp2p Components ## Transport @@ -19,8 +19,11 @@ TCP/IP and optionally websockets. Websockets are useful for implementations running in the browser and therefore native clients would ideally support these implementations by supporting websockets. -An ideal libp2p transport would therefore be TCP/IP with a fallback to -websockets. +An ideal libp2p transport would therefore support both TCP/IP and websockets. + +*Note: There is active development in libp2p to facilitate the +[QUIC](https://github.com/libp2p/go-libp2p-quic-transport) transport, which may +be adopted in the future* ### Encryption @@ -35,6 +38,11 @@ Current defaults are: - Cipher: `AES-128` (also supports `AES-256`, `TwofishCTR`) - Digests: `SHA256` (also supports `SHA512`) +*Note: Secio is being deprecated in favour of [TLS +1.3](https://github.com/libp2p/specs/blob/master/tls/tls.md). It is our +intention to transition to use TLS 1.3 for encryption between nodes, rather +than Secio.* + ## Protocols @@ -45,7 +53,8 @@ running a libp2p network stack. #### Protocol id: `/multistream/1.0.0` -Clients running libp2p should support the [multistream-select](https://github.com/multiformats/multistream-select/) +Clients running libp2p should support the +[multistream-select](https://github.com/multiformats/multistream-select/) protocol which allows clients to negotiate libp2p protocols establish streams per protocol. @@ -62,7 +71,7 @@ optionally [yamux](https://github.com/hashicorp/yamux/blob/master/spec.md) ## Gossipsub -#### Protocol id: `/meshsub/1.0.0` +#### Protocol id: `/eth/serenity/gossipsub/1.0.0` *Note: Parameters listed here are subject to a large-scale network feasibility study* @@ -121,36 +130,14 @@ number of shard subnets will be defined via `SHARD_SUBNET_COUNT` and the shard ### Messages -#### Libp2p Specification - -*This section simply outlines the data sent across the wire as specified by -libp2p - this section is aimed at gossipsub implementers to standardize their implementation of this protocol* - -Libp2p raw gossipsub messages are sent across the wire as fixed-size length-prefixed byte arrays. - -The byte array is prefixed with an unsigned 64 bit length number encoded as an -`unsigned varint` (https://github.com/multiformats/unsigned-varint). Gossipsub messages therefore take the form: -``` -+--------------------------+ -| message length | -+--------------------------+ -| | -| body (<1M) | -| | -+--------------------------+ -``` +*Note: The message format here is Eth2.0-specific* -The body represents a protobuf-encoded [Message](https://github.com/libp2p/go-libp2p-pubsub/blob/master/pb/rpc.proto#L17-L24). +Each Gossipsub +[Message](https://github.com/libp2p/go-libp2p-pubsub/blob/master/pb/rpc.proto#L17-L24) +has a maximum size of 512KB (estimated from expected largest uncompressed block +size). -In the following section we discuss the data being sent in the `data` field of -the protobuf gossipsub `Message`. - -#### Eth2.0 Specifics - -Each message has a maximum size of 512KB (estimated from expected largest uncompressed -block size). - -The `data` that is sent in a Gossipsub message is an SSZ-encoded object. For the `beacon_block` topic, +The `data` field of a Gossipsub `Message` is an SSZ-encoded object. For the `beacon_block` topic, this will be a `beacon_block`. For the `beacon_attestation` topic, this will be an `attestation`. @@ -162,10 +149,10 @@ The [RPC Interface](./rpc-interface.md) is specified in this repository. ## Identify -#### Protocol Id: `/ipfs/id/1.0.0` (to be updated to `/p2p/id/1.0.0`) - -*To be updated to incorporate discv5* +**Note: This protocol is a placeholder and will be updated once the discv5 +discovery protocol is added to this document** +#### Protocol Id: `/eth/serentiy/id/1.0.0` The Identify protocol (defined in go - [identify-go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/id.go) and rust [rust-identify](https://github.com/libp2p/rust-libp2p/blob/master/protocols/identify/src/lib.rs)) allows a node A to query another node B which information B knows about A. This also includes the addresses B is listening on. @@ -185,8 +172,4 @@ type of connecting node. Suggested format: ## Discovery -#### Protocol Id: `/eth/serenity/disc/1.0.0` - -*To be updated to incorporate discv5* - -The discovery protocol to be determined. +**To be updated to incorporate discv5** From bff71b6e90dc87a1e2e85b631ec5e3593a922722 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Tue, 7 May 2019 11:08:14 -0600 Subject: [PATCH 6/9] change some language to be more declarative rather than about the future --- specs/networking/libp2p-standardization.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index 67bf74d1df..0c65734a5b 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -77,7 +77,7 @@ optionally [yamux](https://github.com/hashicorp/yamux/blob/master/spec.md) study* The [Gossipsub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) -protocol will be used for block and attestation propagation across the +protocol is used for block and attestation propagation across the network. ### Configuration Parameters @@ -111,7 +111,7 @@ propagation times and message duplication. Current network-related defaults are: *The Go and Js implementations use string topics - This is likely to be updated to topic hashes in later versions - https://github.com/libp2p/rust-libp2p/issues/473* -For Eth2.0 clients, topics will be sent as `SHA2-256` hashes of the topic string. +For Eth2.0 clients, topics are sent as `SHA2-256` hashes of the topic string. There are two main topics used to propagate attestations and beacon blocks to all nodes on the network. @@ -120,12 +120,12 @@ all nodes on the network. beacon blocks to all nodes on the networks. - The `beacon_attestation` topic - This topic is used to propagate aggregated attestations to subscribing nodes (typically block proposers) to - be included into future blocks. Attestations will be aggregated in their + be included into future blocks. Attestations are aggregated in their respective subnets before publishing on this topic. -Shards will be grouped into their own subnets (defined by a shard topic). The -number of shard subnets will be defined via `SHARD_SUBNET_COUNT` and the shard -`shard_number % SHARD_SUBNET_COUNT` will be assigned to the topic: +Shards are grouped into their own subnets (defined by a shard topic). The +number of shard subnets is defined via `SHARD_SUBNET_COUNT` and the shard +`shard_number % SHARD_SUBNET_COUNT` is assigned to the topic: `shard{shard_number % SHARD_SUBNET_COUNT}`. ### Messages @@ -138,7 +138,7 @@ has a maximum size of 512KB (estimated from expected largest uncompressed block size). The `data` field of a Gossipsub `Message` is an SSZ-encoded object. For the `beacon_block` topic, -this will be a `beacon_block`. For the `beacon_attestation` topic, this will be +this is a `beacon_block`. For the `beacon_attestation` topic, this is an `attestation`. ## Eth-2 RPC From 3c87754deee2bd21521579c7abb90d37484c0ebc Mon Sep 17 00:00:00 2001 From: Age Manning Date: Wed, 8 May 2019 10:28:08 +1000 Subject: [PATCH 7/9] Rename shard topics to explicitly state --- specs/networking/libp2p-standardization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index 0c65734a5b..1f728fa544 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -126,7 +126,7 @@ all nodes on the network. Shards are grouped into their own subnets (defined by a shard topic). The number of shard subnets is defined via `SHARD_SUBNET_COUNT` and the shard `shard_number % SHARD_SUBNET_COUNT` is assigned to the topic: -`shard{shard_number % SHARD_SUBNET_COUNT}`. +`shard{shard_number % SHARD_SUBNET_COUNT}_attestation`. ### Messages From feb3b5ea0d021192c9b6759c20f10d2e21d6f711 Mon Sep 17 00:00:00 2001 From: Age Manning Date: Mon, 13 May 2019 10:55:08 +1000 Subject: [PATCH 8/9] Correct typo --- specs/networking/libp2p-standardization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index 1f728fa544..d9e8565866 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -152,7 +152,7 @@ The [RPC Interface](./rpc-interface.md) is specified in this repository. **Note: This protocol is a placeholder and will be updated once the discv5 discovery protocol is added to this document** -#### Protocol Id: `/eth/serentiy/id/1.0.0` +#### Protocol Id: `/eth/serenity/id/1.0.0` The Identify protocol (defined in go - [identify-go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/id.go) and rust [rust-identify](https://github.com/libp2p/rust-libp2p/blob/master/protocols/identify/src/lib.rs)) allows a node A to query another node B which information B knows about A. This also includes the addresses B is listening on. From ae6d30fd62e4c4f20086388dcbf8f100265932b1 Mon Sep 17 00:00:00 2001 From: Age Manning Date: Thu, 23 May 2019 11:48:04 +1000 Subject: [PATCH 9/9] Update with discv5 --- specs/networking/libp2p-standardization.md | 31 +++++----------------- 1 file changed, 7 insertions(+), 24 deletions(-) diff --git a/specs/networking/libp2p-standardization.md b/specs/networking/libp2p-standardization.md index d9e8565866..b6a46db1bf 100644 --- a/specs/networking/libp2p-standardization.md +++ b/specs/networking/libp2p-standardization.md @@ -147,29 +147,12 @@ an `attestation`. The [RPC Interface](./rpc-interface.md) is specified in this repository. -## Identify - -**Note: This protocol is a placeholder and will be updated once the discv5 -discovery protocol is added to this document** - -#### Protocol Id: `/eth/serenity/id/1.0.0` - -The Identify protocol (defined in go - [identify-go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/id.go) and rust [rust-identify](https://github.com/libp2p/rust-libp2p/blob/master/protocols/identify/src/lib.rs)) -allows a node A to query another node B which information B knows about A. This also includes the addresses B is listening on. - -This protocol allows nodes to discover addresses of other nodes to be added to -peer discovery. It further allows nodes to determine the capabilities of all it's connected -peers. - -### Configuration Parameters - -The protocol has two configurable parameters, which can be used to identify the -type of connecting node. Suggested format: -``` - version: `/eth/serenity/1.0.0` - user_agent: -``` - ## Discovery -**To be updated to incorporate discv5** +Discovery Version 5 +([discv5])(https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) +will be used for discovery. This protocol uses a UDP transport and specifies +its own encryption, ip-discovery and topic advertisement. Therefore, it has no +need to establish establish streams through `multistream-select`, rather, act +as a standalone implementation that feeds discovered peers/topics (ENR-records) as +`multiaddrs` into the libp2p service.