waku-org/specs
1
0
Fork 0
mirror of https://github.com/waku-org/specs.git synced 2025-02-23 18:28:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update enr.md

Browse Source
This commit is contained in:
Jimmy Debe 2024-01-30 01:39:26 -05:00 committed by GitHub
parent 71278a8444
commit 12436232ba
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 14 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
standards/core/enr.md
View File

@ -1,21 +1,19 @@
--- ---
slug: 31 title: WAKU2-ENR
title: 31/WAKU2-ENR
name: Waku v2 usage of ENR name: Waku v2 usage of ENR
status: tags: waku/core-protocol
tags: waku/core
editor: Franck Royer <franck@status.im> editor: Franck Royer <franck@status.im>
contributors: contributors:
--- ---
# Abstract ## Abstract
This RFC describes the usage of the ENR (Ethereum Node Records) format for [10/WAKU2](/specs/10) purposes. This RFC describes the usage of the ENR (Ethereum Node Records) format for [10/WAKU2](/specs/10) purposes.
The ENR format is defined in [EIP-778](https://eips.ethereum.org/EIPS/eip-778) [[3]](#references). The ENR format is defined in [EIP-778](https://eips.ethereum.org/EIPS/eip-778) [[3]](#references).
This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR. This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR.
# Motivation ## Motivation
EIP-1459 with the usage of ENR has been implemented [[1]](#references) [[2]](#references) as a discovery protocol for Waku v2. EIP-1459 with the usage of ENR has been implemented [[1]](#references) [[2]](#references) as a discovery protocol for Waku v2.
@ -25,7 +23,7 @@ such as Websocket.
Currently, Waku v2 nodes running in a Browser only support websocket transport protocol. Currently, Waku v2 nodes running in a Browser only support websocket transport protocol.
Hence, new ENR keys need to be defined to allow for the encoding of transport protocol other than raw TCP. Hence, new ENR keys need to be defined to allow for the encoding of transport protocol other than raw TCP.
## Usage of Multiaddr Format Rationale ### Usage of Multiaddr Format Rationale
One solution would be to define new keys such as `ws` to encode the websocket port of a node. One solution would be to define new keys such as `ws` to encode the websocket port of a node.
However, we expect new transport protocols to be added overtime such as quic. However, we expect new transport protocols to be added overtime such as quic.
@ -50,7 +48,7 @@ Directly storing one or several multiaddresses in the ENR would fix the issues l
No new RFC would be needed to support encoding other transport protocols in an ENR. No new RFC would be needed to support encoding other transport protocols in an ENR.
- multiaddr contains both the host and port information, allowing the ambiguity previously described to be resolved. - multiaddr contains both the host and port information, allowing the ambiguity previously described to be resolved.
# `multiaddrs` ENR key ## `multiaddrs` ENR key
We define a `multiaddrs` key. We define a `multiaddrs` key.
@ -67,9 +65,9 @@ We define a `multiaddrs` key.
- The 300 bytes size limit as defined by [EIP-778](https://eips.ethereum.org/EIPS/eip-778) still applies; - The 300 bytes size limit as defined by [EIP-778](https://eips.ethereum.org/EIPS/eip-778) still applies;
In practice, it is possible to encode 3 multiaddresses in ENR, more or less could be encoded depending on the size of each multiaddress. In practice, it is possible to encode 3 multiaddresses in ENR, more or less could be encoded depending on the size of each multiaddress.
## Usage ### Usage
### Many connection types #### Many connection types
Alice is a node operator, she runs a node that supports inbound connection for the following protocols: Alice is a node operator, she runs a node that supports inbound connection for the following protocols:
- TCP 10101 on `1.2.3.4` - TCP 10101 on `1.2.3.4`
@ -99,7 +97,7 @@ Where:
- `len2` is the length of `/dns4/quic.examle.com/tcp/443/quic` byte representation. - `len2` is the length of `/dns4/quic.examle.com/tcp/443/quic` byte representation.
- `len3` is the length of `/ip4/1.2.3.4/tcp/55555/p2p/QmRelay` byte representation. Notice that the `/p2p-circuit` component is not stored, but, since circuit relay addresses are the only one containing a `p2p` component, it's safe to assume that any address containing this component is a circuit relay address. Decoding this type of multiaddresses would require appending the `/p2p-circuit` component. - `len3` is the length of `/ip4/1.2.3.4/tcp/55555/p2p/QmRelay` byte representation. Notice that the `/p2p-circuit` component is not stored, but, since circuit relay addresses are the only one containing a `p2p` component, it's safe to assume that any address containing this component is a circuit relay address. Decoding this type of multiaddresses would require appending the `/p2p-circuit` component.
### Raw TCP only #### Raw TCP only
Bob is a node operator, he runs a node that supports inbound connection for the following protocols: Bob is a node operator, he runs a node that supports inbound connection for the following protocols:
- TCP 10101 on `1.2.3.4` - TCP 10101 on `1.2.3.4`
@ -115,13 +113,13 @@ Bob SHOULD structure the ENR for her node as follows:
Indeed, as Bob's node's connection details can be represented with EIP-778's pre-defined keys only Indeed, as Bob's node's connection details can be represented with EIP-778's pre-defined keys only
then it is not needed to use the `multiaddrs` key. then it is not needed to use the `multiaddrs` key.
## Limitations ### Limitations
Supported key type is `secp256k1` only. Supported key type is `secp256k1` only.
In the future, an extension of this RFC could be made to support other elliptic curve cryptography such as `ed25519`. In the future, an extension of this RFC could be made to support other elliptic curve cryptography such as `ed25519`.
# `waku2` ENR key ## `waku2` ENR key
We define a `waku2` field key: We define a `waku2` field key:
@ -141,7 +139,7 @@ though it MAY be required by the relevant application or discovery process.
- Flags marked as `undef` is not yet defined. - Flags marked as `undef` is not yet defined.
These SHOULD be set to `false` by default. These SHOULD be set to `false` by default.
## Usage ### Usage
- A Waku v2 node MAY choose to populate the `waku2` field for enhanced discovery capabilities, - A Waku v2 node MAY choose to populate the `waku2` field for enhanced discovery capabilities,
such as indicating supported protocols. such as indicating supported protocols.
@ -153,11 +151,11 @@ MUST filter out participant records that do not implement this field or do not h
- In addition, such nodes MAY choose to filter participants on specific flags (such as supported protocols), - In addition, such nodes MAY choose to filter participants on specific flags (such as supported protocols),
or further interpret the `waku2` field as required by the application. or further interpret the `waku2` field as required by the application.
# Copyright ## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
# References ## References
- [1] https://github.com/status-im/nim-waku/pull/690 - [1] https://github.com/status-im/nim-waku/pull/690
- [2] https://github.com/vacp2p/rfc/issues/462#issuecomment-943869940 - [2] https://github.com/vacp2p/rfc/issues/462#issuecomment-943869940