Popular Science: Network Addresses in Ethereum

Editor's Note: This article comes fromUnitimes（ID：Uni-times）Editor's Note: This article comes from

After discussing with Felix Lange, I thought it would make sense to write this article about the various types of network addresses encountered in the Ethereum ecosystem and their differences. I also have some misunderstandings in my own understanding of them, so I think it will be valuable to explain them.

secondary title

Multi-address (Multiaddr)

Let's start with the earliest multiaddr (Multiaddr[1]) that was archived, or by commit time. Multiaddress is part of Protocol Labs' multiformats project. Multi-formats are essentially various specifications of self-describing values. You've probably heard of them already, due to their widespread use in libp2p, IPFS, and other Protocol Labs projects.

/ip4/127.0.0.1/udp/1234

There are two representations of multi-address: one is the binary representation used when storing or transmitting; the other is the readable format provided to the user., }). The binary representation is also the same - there is a byte array for the keys and another for the values. Keys can be mapped from human-readable to coded form via protocol tables [2].

enode

secondary title

enode://6f8a80d6ad92a0@10.3.58.6:30303?discport=30301

The enode system is used to represent URLs. enode:// followed by a hex-encoded node ID. Next, the @ symbol indicates the host, which must be an IP address. The TCP port is listed after the host, in our case 30303. If the ports of UDP and TCP are different, the UDP port can be specified by adding the discport parameter at the end.

ENR

secondary title

Finally we come to ENR[4] (Ethereum Node Record). ENR is interesting because it uses features from both the first two types (multiple addresses and enode URLs), making it very general. The main motivation of ENR is to allow more information to be carried during the forwarding process, thus introducing node records. Node records are self-certifying, and nodes can identify themselves through signatures. These records are represented as an RLP list [5] - I won't go into the details here, but as a small mention, RLP is a serialization format used by Ethereum.

A node record contains a signature, a serial number and a field indicating the authentication mechanism used to create and verify the signature. Finally, the rest of the record contains arbitrary key-value pairs that can contain things like connection information. EIP defines some keys with predefined meanings, such as ip, which is the node IPv4 address represented by 4 bytes.

Signatures are used to verify records by ensuring that the public key passed is the one used to create the signature.

If the same identity issues 2 different records, then the serial number can be used to resolve conflicts: the record with the higher serial number is specified.

The format is future-proof, new keys can be added even if some clients cannot parse it, and new authentication mechanisms can be added to verify signatures.

Eth 2.0

secondary title

Now, let's take a look at Eth2.0. Before Eth2.0, there were never many addresses in Ethereum, but now they are very important. Why? Because Eth2.0 uses libp2p, and libp2p uses multiple addresses to identify nodes.

1. So, how do we handle this situation? The P2P specification [6] of Eth2.0 shows two solutions:

2. Multiple addresses can be exported from ENR

Since ENR can add arbitrary keys, multiple addresses can be included in ENR.