EIP-1459/EIP-778 in a Browser environment

fryorcraken · September 28, 2021, 2:46am

Context

nim-waku has recently implemented EIP-1459 for peer discovery.

In short, EIP-1459 proposes a method to store and traverse a tree of peer records stored in DNS TXT entries for bootstraping purposes. Given a single enrtree url, one can retrieve connection information for a large list of nodes.
All entries are signed by a public key, which is provided as part of the enrtree url.
Link entries allows pointing to other domain name allowing discovery of further peers listed by different authorities.

EIP-1459 uses EIP-778 to encode peer information.

EIP-778 enables the encoding of arbitrary key/value peers, with the following keys having predefined meanings:

id
secp256k1
ip
tcp
udp
ip6
tcp6
udp6

In a browser environment, it is not possible to directly connect to TCP or UDP ports.
Currently, js-waku only support websocket (ws) connections. Other methods such as QUIC are being considered but not yet available.

Moreover, modern browsers only allow connections to a secure websocket (wss) within a secure context (https). For waku nodes to be reachable via wss they need to provide an SSL connection and hence setup a SSL certificate.
Modern browser accept both self-signed ip certificates and domain certificates signed by pre-defined root CA.
Also, websocket connections run over TCP as they initiate with an HTTP Upgrade.

This means that it is not possible to define peers reachable by a web app only using the keys predefined by EIP-778.

Proposal

I propose to define the following keys to be used in EIP-778 entry for Waku EIP-1459 usage:

Key	Value Type	Value Length	Value Description
`fqdn`	`utf-8 string`	Max 253 Bytes [1]	Fully Qualified Domain Name of the node, SHOULD be used in favor of `ip` when the node is reachable via a FQDN.
`wss`	`Big Endian Integer`	-	secure websocket port
`wss6`	`Big Endian Integer`	-	IPv6 specific secure websocket port

Notes

ws is not proposed as it has little practical value, https and hence wss should be preferred for all http content.
EIP-778 defines that The maximum encoded size of a node record is 300 bytes. . This should be kept in mind when encoding long FQDN.
See [1] regarding FQDN length, note that the max length is noted in characters which is not equivalent to Bytes since the introduction of utf-8 domains.
I could not find if any other application already use such keys (or similar) with EIP-778. I will do further investigation and update this post.

References

[1] https://groups.google.com/g/comp.protocols.dns.bind/c/Y26Luh7Gyg0/m/15U_tvTmY8YJ

The maximum number of octets is a label is 63. RFC1035.
The maximum number of octets in a domain name is 255 octets. RFC1035
The maximum length of a fqdn, not a hostname, is 1004 characters. RFC1035
The maximum length of a full qualified hostname is 253 characters. Imputed from RFC952, RFC1123 and RFC1035.

fryorcraken · September 28, 2021, 2:52am

Nimbus team reached out: Discord
Ethereum Magicians: EIP-1459/EIP-778 in a Browser environment - EIPs - Fellowship of Ethereum Magicians
Lodestar reached out, but does not seem to use any additional keys

fryorcraken · September 30, 2021, 6:24am

Few ongoing discussions:

Vac Discord: Discord
ChainSafe Discord: Discord
Nimbus Discord: Discord

fryorcraken · September 30, 2021, 6:45am

Regarding the discussions so far, it seems that it would be more future proof to simply add a single mutliaddr key that contains one or several multiaddrs for the node.

This would actually could be used by the ecosystem overall as eth2 also uses libp2p/mutladdrs.

Not sure how one would encode an array in RLP/ENR just yet.

fryorcraken · October 1, 2021, 12:04am

ChainSafe does use a multiaddr entry in ENR: Discord so this is a promising direction.

fryorcraken · October 1, 2021, 12:10am

ChainSafe is also using themultiaddr field. As libp2p is used in both eth2 and waku, it seems natural to slowly migrated towards the usage of multiaddr. The only remaining question is whether we could store several multiaddr in the ENR field. Indeed, AFAIK (will check), a multiaddr only contains one transport protocol stack info. ie, either TCP or UDP or WSS. you cannot express 2 in the same multaddr. Hence, ideally you’d want to store multiple multiaddr in on ENR and then select what multiaddr to dial depending on what protocol you support. Also, all multiaddr should have the same peer id. I wonder if we can deduce a peer id from secp256k1 field. If so, then the multiaddr could be peer-id-less.

fryorcraken · October 1, 2021, 5:48am

Discussion taken to the spec repository:

github.com/vacp2p/rfc

25/LIBP2P-DNS-DISCOVERY: Leafe entry format to allow for multiple mutliaddrs and self signature

opened 05:47AM - 01 Oct 21 UTC

D4nte

# Problem During the implementation of [EIP-1459 in nim-waku](https://github.…com/status-im/nim-waku/issues/616), the ENR encoding format was preferred over encoding a multiaddr due to the fact that [multiaddr format cannot include a self signed signature](https://github.com/status-im/nim-waku/issues/616#issuecomment-867873420) and that multiaddresses bring little benefits over ENR. During the implementation of [EIP-1459 in js-waku](https://github.com/status-im/js-waku/pull/305) it was discovered that the following information MUST be present in the ENR tree for EIP-1459 to be useful for Waku nodes in the browser: - Secure websocket port - FQDN for the host, when websocket transport is secured by a dns certificate [EIP-778](https://eips.ethereum.org/EIPS/eip-778) ENR currently does not pre-define keys to store such values. However, it is possible to extend the ENR format with arbitrary keys. # Considered solutions Several solutions [were proposed](https://forum.vac.dev/t/eip-1459-eip-778-in-a-browser-environment/101/3) for the extension of the ENR format. For example, new fields `fqdn` and `wss` to respectively encode the peer domain name and websocket port. It was concluded that the most future proof solution would be to introduce a new key value `multiaddr` that could contain one (or several) multiaddresse(s). This would not only allow wss and fqdn information to be encoded in the ENR (thanks to the `dns4`, `dns6`, and `wss` keys of the multiaddr format) but it would also future proof the format (e.g. support of quic protocol) thanks to the self-describing characteristics of multiaddr. However, adding a `multiaddr` key to ENR lead to handling 2 layers of encoding (ENR and then multiaddr) for no to little benefits. This could be justifiable for backward compatibility reasons (e.g. we had several implementation of Waku v2 in the wild using ENR format) but DNS discovery in Waku v2 is brand new and not yet deployed in the prod fleet. Also, it is not certain how multiple multiaddr would be encoded. Indeed, EIP-788 states that a key can only be present once. Meaning that within the `multiaddr` value, additional information such as number of multiaddresses encoded would need to be catered for, adding another layer of codec logic. # Proposed solution Libp2p's [RFC 0003 - Peer Routing Records](https://github.com/libp2p/specs/blob/master/RFC/0003-routing-records.md) defines a format that satisfy all sought characteristics: - It enables the encoding of peer information, one peer id for several multiaddr. Allowing TCP, UDP, fqdn, wss, quic information to be represented. - It proposes records entries to be self-signed using [RFC 0002 - Signed Envelopes](https://github.com/libp2p/specs/blob/master/RFC/0002-signed-envelopes.md), allowing a similar level of security to ENR. - It directly uses multiaddrs, allowing future proofing of the format when support of new transport protocol is added to Waku implementations, withing having to handle multiple layer of codec. - It proposes the usage of protobuf (EIP-778 uses RLP), wire codec already commonly used in the Waku v2 protocol family. ## Size consideration One question remains unanswered: Can RFC 003/RFC 002 records fit in TXT DNS records? Let's review EIP-778 space usage. EIP-778 uses [URL-safe base64 alphabet](https://datatracker.ietf.org/doc/html/rfc4648#section-5) omitting padding characters for text encoding. Using a similar text encoding seems appropriate. ## Maximum size DNS TXT records MUST have a maximum length of 255 bytes ([rfc6763](https://datatracker.ietf.org/doc/html/rfc6763#section-6.1)). However, it is possible to register several TXT entrioes against the same fqdn and concatenate the entries to extract a string longer than 255 characters. EIP-778 defines a maximum encoded size of 300 bytes. [Base 64 Encoding](https://datatracker.ietf.org/doc/html/rfc4648#section-4) enables [..] 6 bits to be represented per printable character. 300 bytes = 300 octet = 2400 bits = 400 characters. Which means that, at most, ENR records may take 2 TXT DNS entry (255 * 2 = 510) to be stored. ## Typical size EIP-778 states: > A record containing a IPv4 address, when signed using the “v4” scheme occupies roughly 120 bytes, leaving plenty of room for additional metadata. # Definition of done ## Size consideration Calculation of the typical size of RFC-003 data (wrapped in an RFC 002 signed envelope) should be done to know whether it would fit in a single TXT DNS entry when encoded in base 64. Currently, a typical RFC 003 record would contain: - a peer id - a swq number - 3 or 6 multiaddrs (1 tcp, 1 upd, 1 wss, ip4 or ip4 and ip6) Also, review of a practical maximum size for the record should be done to ensure that there is enough space to add further multi addr entries within a reasonable byte space (EIP-778 usage of 2 DNS TXT record could be used as reference). ## Spec update If appropriate (see size consideration), propose a spec change to replace [multiaddr entries](https://github.com/vacp2p/rfc/blob/7992c7aaede2a655eb1b4eaeeb030ff4ca09d5f2/content/docs/rfcs/25/README.md#L102) with RFC 002/RFC 003 entry.

Indeed, it now seem more appropriate to use 25/LIBP2P-DNS-DISCOVERY and direct deal with mutliaddresses for Waku v2 then extending ENR to fit multiaddr.