rfc/content/docs/rfcs/31

slug	title	name	status	editor	contributors
31	31/WAKU2-ENR	Waku v2 usage of ENR	raw	Franck Royer <franck@status.im>

Abstract

This RFC describes the usage of the ENR (Ethereum Node Records) format for 10/WAKU2 purposes. The ENR format is defined in EIP-778 [3].

This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR.

Motivation

EIP-1459 with the usage of ENR has been implemented [1] [2] as a discovery protocol for Waku v2.

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, such as Websocket. 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.

Usage of Multiaddr Format Rationale

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. Hence, this would only provide a short term solution until another RFC would need to be added.

Moreover, secure websocket involves SSL certificates. SSL certificates are only valid for a given domain and ip, so an ENR containing the following information:

• secure websocket port
• ipv4 fqdn
• ipv4 address
• ipv6 address

Would carry some ambiguity: Is the certificate securing the websocket port valid for the ipv4 fqdn? the ipv4 address? the ipv6 address?

The 10/WAKU2 protocol family is built on the libp2p protocol stack. Hence, it uses multiaddr to format network addresses.

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: 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.

multiaddrs ENR key

We propose the definition of the multiaddrs key.

• The value MUST be a list of binary encoded multiaddr prefixed by their size.
• The size of the multiaddr MUST be encoded in a Big Endian unsigned 16-bit integer.
• The size of the multiaddr MUST be encoded in 2 bytes.
• The secp256k1 value MUST be present on the record; secp256k1 is defined in EIP-778 and contains the compressed secp256k1 public key.
• The node's peer id SHOULD be deduced from the secp256k1 value.
• The multiaddresses SHOULD NOT contain a peer id.
• For raw TCP & UDP connections details, EIP-778 pre-defined keys SHOULD be used; The keys tcp, udp, ip (and tcp6, udp6, ip6 for IPv6) are enough to convey all necessary information;
• To save space, multiaddrs key SHOULD only be used for connection details that cannot be represented using the EIP-778 pre-defined keys.
• The 300 bytes size limit as defined by 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.

Usage

Many connection types

Alice is a node operator, she runs a node that supports inbound connection for the following protocols:

• TCP 10101 on 1.2.3.4
• UDP 20202 on 1.2.3.4
• TCP 30303 on 1234:5600:101:1::142
• UDP 40404 on 1234:5600:101:1::142
• Secure Websocket on wss://example.com:443/
• QUIC on quic://quic.example.com:443/

Alice SHOULD structure the ENR for her node as follows:

key	value
tcp	10101
udp	20202
tcp6	30303
udp6	40404
ip	1.2.3.4
ip6	1234:5600:101:1::142
secp256k1	Alice's compressed secp256k1 public key, 33 bytes
multiaddrs	len1 | /dns4/example.com/tcp/443/wss | len2 | /dns4/quic.examle.com/tcp/443/quic

Where:

• | is the concatenation operator,
• len1 is the length of /dns4/example.com/tcp/443/wss byte representation,
• len2 is the length of /dns4/quic.examle.com/tcp/443/quic byte representation.

Raw TCP only

Bob is a node operator, he runs a node that supports inbound connection for the following protocols:

• TCP 10101 on 1.2.3.4

Bob SHOULD structure the ENR for her node as follows:

key	value
tcp	10101
ip	1.2.3.4
secp256k1	Bob's compressed secp256k1 public key, 33 bytes

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.

Limitations

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.

References

• [1] https://github.com/status-im/nim-waku/pull/690
• [2] https://github.com/vacp2p/rfc/issues/462#issuecomment-943869940
• [3] https://eips.ethereum.org/EIPS/eip-778