Who can I talk to?
Connectivity
Find and reach the peers that serve you. A peer you cannot discover is absent, and one you cannot dial might as well be.
Before a reader can read a single byte, they must connect to a peer that can provide it. The problem splits into two parts:
- Discoverability: learning which peers exist, and what addresses reach them.
- Dialability: turning an address into an open connection.
A peer that is discoverable but not dialable might as well not exist, and a dialable peer you can’t discover is just as absent. Today, connectivity failures at the edge of the network are mostly dialability failures, and solving discovery alone won’t fix them.
Discoverability
Nodes discover each other well. A new node starts from a hardcoded set of bootnodes and joins discv5, a Kademlia-style DHT in which every participant both consumes and serves routing information. The records it exchanges are ENRs (EIP-778): self-signed address records that anyone can relay and anyone can verify, with no registry in the middle. DNS node lists (EIP-1459) complement the DHT with signed ENR trees published in ordinary DNS, useful on networks that block UDP.
Everything else (wallets, dapps, light clients in browsers) doesn’t discover; it gets configured. The provider URL is embedded in the app, chosen from a curated list, or typed in by the user. Configuration is the only discovery mechanism a browser has. Even Helios, which verifies everything it receives, still reaches the network through provider URLs supplied at startup.
Three tracked issues, each with a plausible direction:
- Edge clients can't participate in discv5.
- No protocol enumerates serving endpoints. An on-chain registry would let readers enumerate alternatives through the chain itself, verified by the same light client that consumes them. Such a registry has a bootstrap loop: you need one endpoint to read it. But bootnodes have the same loop, and one honest endpoint is enough to find the rest.
- Discovery doesn't advertise edge-dialable transports. This needs standardized ENR fields for edge transports, with one caveat: certificate rotation makes these records churn (see below).
Dialability
The web platform can’t use any of the network’s native transports. Execution nodes speak RLPx over TCP with discovery over UDP; consensus nodes speak libp2p over TCP and, increasingly, QUIC. Browsers can open none of these. The web platform offers no raw sockets, only HTTPS, WebSocket, WebRTC, and WebTransport.
The two most used, HTTPS and WebSocket, require a certificate from a certificate authority, which requires a domain, renewal automation, and an operator willing to maintain both. That requirement determines who can serve browsers, and it favors professional operators.
Three tracked issues:
The most promising answer to the certificate barrier is WebTransport with serverCertificateHashes. A browser can dial a self-signed certificate if it knows the certificate’s hash in advance: no CA, no domain. The hash isn’t an identity or a trust claim; it’s just the data the handshake needs, carried in the same discovery record as the address. The constraint: these certificates are valid for at most 14 days, so fresh hashes must propagate through discovery continuously. Dialability and discoverability couple here, and we have to solve them together.
libp2p’s WebRTC-direct achieves the same CA-free property over WebRTC by embedding the hash in the multiaddr. Support for both transports is real but uneven across browsers, and that unevenness is itself a dependency worth tracking.
For NAT, libp2p provides AutoNAT to detect reachability, DCUtR for hole punching, and relays as a fallback. These tools can make some outbound-only nodes reachable as servers. Every node that becomes reachable this way is new permissionless supply.
In this track
- Network Privacy Network-level privacy for Ethereum: TorJS (embedded Arti) and the Abstract Access Layer, two tracks that protect who is making the request.