logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-03 22:53:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update enr.md

Browse Source
This commit is contained in:
Jimmy Debe 2025-06-17 17:48:26 -04:00 committed by GitHub
parent c89d99f9cf
commit 9c6f271bae
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 16 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
standards/core/enr.md
View File

@ -8,26 +8,27 @@ contributors:
## Abstract ## Abstract
This RFC describes the usage of the ENR (Ethereum Node Records) format for [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) purposes. This specification describes the usage of the ENR (Ethereum Node Records)
format for [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) 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 specification is an extension of EIP-778, ENR used in Waku 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.
EIP-778 specifies a number of pre-defined keys. EIP-778 specifies a number of pre-defined keys.
However, the usage of these keys alone does not allow for certain transport capabilities to be encoded, However, the usage of these keys alone does not allow for certain transport capabilities to be encoded,
such as Websocket. such as Websocket.
Currently, Waku v2 nodes running in a Browser only support websocket transport protocol. Currently, Waku 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.
Hence, this would only provide a short term solution until another RFC would need to be added. Hence, this would only provide a short term solution until another specification would need to be added.
Moreover, secure websocket involves SSL certificates. Moreover, secure websocket involves SSL certificates.
SSL certificates are only valid for a given domain and ip, so an ENR containing the following information: SSL certificates are only valid for a given domain and ip, so an ENR containing the following information:
@ -47,10 +48,12 @@ Hence, it uses [multiaddr](https://github.com/multiformats/multiaddr) to format
Directly storing one or several multiaddresses in the ENR would fix the issues listed above: Directly storing one or several multiaddresses in the ENR would fix the issues listed above:
- multiaddr is self-describing and support addresses for any network protocol: - multiaddr is self-describing and support addresses for any network protocol:
No new RFC would be needed to support encoding other transport protocols in an ENR. No new specification 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 ## Wire Format
### `multiaddrs` ENR key
We define a `multiaddrs` key. We define a `multiaddrs` key.
@ -122,9 +125,9 @@ then it is not needed to use the `multiaddrs` key.
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 specification 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,17 +144,17 @@ We define a `waku2` field key:
If a protocol is not supported, the corresponding field MUST be set to `false`. If a protocol is not supported, the corresponding field MUST be set to `false`.
Indicating positive support for any specific protocol is OPTIONAL, Indicating positive support for any specific protocol is OPTIONAL,
though it MAY be required by the relevant application or discovery process. 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 node MAY choose to populate the `waku2` field for enhanced discovery capabilities,
such as indicating supported protocols. such as indicating supported protocols.
Such a node MAY indicate support for any specific protocol by setting the corresponding flag to `true`. Such a node MAY indicate support for any specific protocol by setting the corresponding flag to `true`.
- Waku v2 nodes that want to participate in [Node Discovery Protocol v5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) [[4]](#references), however, - Waku nodes that want to participate in [Node Discovery Protocol v5](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/33/discv5.md) [[4]](#references), however,
MUST implement the `waku2` key with at least one flag set to `true`. MUST implement the `waku2` key with at least one flag set to `true`.
- Waku v2 nodes that discovered other participants using Discovery v5, - Waku nodes that discovered other participants using Discovery v5,
MUST filter out participant records that do not implement this field or do not have at least one flag set to `true`. MUST filter out participant records that do not implement this field or do not have at least one flag set to `true`.
- 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.