ENR (Ethereum Node Record)

An ENR is signed by a node's cryptographic key, providing verifiable proof of ownership. The signature is created using the node's private key and can be validated by any peer using the corresponding public key. This prevents spoofing and ensures the integrity of the node's advertised information.

At its core, an ENR is a flexible key-value store where keys are predefined strings and values are arbitrary data. This allows for the inclusion of diverse metadata, such as:

• IP address and TCP/UDP ports
• Node capabilities (e.g., supported Ethereum sub-protocols)
• Custom fields for future network upgrades or client-specific data.

Each ENR contains a sequence number, a monotonically increasing integer. When a node updates its metadata (e.g., changes its IP address), it increments this number and re-signs the record. Peers can compare sequence numbers to identify the most recent and valid record, ensuring they have current connection information.

ENR supersedes the older multiaddr format used in RLPx discovery v4. Unlike its predecessor, ENR is self-contained (carrying its own signature) and extensible. It is the foundation for Discv5, the current Ethereum node discovery protocol, which improves privacy and efficiency over the v4 system.

ENRs use two primary encodings for different contexts:

• Binary Encoding: The canonical form is serialized using Recursive Length Prefix (RLP) for efficient network transmission.
• Textual Encoding (enr://): For configuration and sharing, the RLP data is base64url encoded and prefixed with enr://, creating a compact, shareable URI.

The signature is the cryptographic proof of ownership, created by signing the ENR's content hash with the node's private key. The public key (or its hash) is included to allow verification. This establishes a verifiable, self-sovereign identity for the node on the network.

A monotonically increasing sequence number acts as a version counter. Each time a node updates its ENR (e.g., IP address change), it must increment this number and re-sign the record. This prevents replay attacks and ensures peers have the most current information.

The IP address and port are the primary network locators for the node, stored as key-value pairs (e.g., udp, tcp). An ENR can contain both IPv4 and IPv6 addresses. This is the essential data for other nodes to establish a direct connection.

These key-value pairs advertise the node's supported protocols and chain data. Common flags include:

• eth: The Ethereum Wire Protocol version.
• les: Light Ethereum Subprotocol support.
• snap: Support for the snap sync protocol. This allows for efficient, compatible peer discovery.

The forkid is a hash derived from the genesis block and past forks. It allows nodes to quickly identify if they are on the same chain and compatible fork history, preventing connections to nodes on a different network (e.g., a testnet).

The ENR is serialized using Recursive Length Prefix (RLP), Ethereum's standard serialization format. The structure is: [signature, sequence_number, k1, v1, k2, v2, ...]. The signature covers the RLP encoding of all subsequent elements, ensuring data integrity.

An ENR's self-signed nature makes it vulnerable to Sybil attacks, where an adversary creates many fake node identities to eclipse a target or manipulate the network. Without a robust peer discovery and reputation system, malicious nodes can flood the network. Mitigation relies on protocols like Discv5, which includes distance-based routing to limit the impact of localized malicious peers.

ENRs publicly broadcast a node's IP address, TCP/UDP ports, and supported capabilities (e.g., eth, snap). This exposes the physical location and software stack, enabling:

• DDoS targeting of specific clients or geographies.
• Fingerprinting to track node activity over time.
• Eclipse attacks by attackers who map the network to surround a victim.

The optional eth field in an ENR can contain the node's current block hash and total difficulty. This metadata leak allows passive observers to:

• Determine chain synchronization status.
• Correlate node activity with blockchain events.
• Identify nodes on minority forks. Operators may omit this field for increased privacy.

Although ENRs are cryptographically signed, the record itself is not encrypted in transit. Adversaries can:

• Intercept and replay old ENRs to present outdated network information.
• Man-in-the-Middle (MitM) attacks during the initial handshake if the connection is not secured (e.g., before TLS/Noise encryption is established in RLPx).

Vulnerabilities in ENR parsing or Discv5 implementation can lead to critical failures. Historical examples include memory exhaustion attacks via malformed packets. Client diversity is a security feature; an exploit affecting one client (e.g., Geth's ENR handling) has reduced impact if the network uses multiple clients like Nethermind, Besu, or Erigon.

To harden node security:

• Use firewalls to restrict P2P port access to known peers or trusted IP ranges.
• Regularly update client software to patch discovery protocol vulnerabilities.
• Consider using a proxy or anonymization network (like Tor) for the P2P layer, though this may impact latency.
• Monitor peer connections for sudden changes or suspicious ENR data.

A self-describing network address format used across many decentralized networks. While an ENR is a signed, structured record containing node metadata, a Multiaddr is a simple, composable string (e.g., /ip4/192.168.1.1/tcp/30303) that encodes transport protocols and addresses. ENRs often contain Multiaddr entries within their key-value pairs to specify connection endpoints.

The cryptographic identity of a node, represented by its public key. An ENR is signed by this key, binding the node's metadata (IP, ports, capabilities) to its identity. This prevents spoofing and allows other nodes to verify the authenticity of the connection information they receive. The identity is typically derived from a secp256k1 key pair.

The principle of running a variety of Ethereum client software (e.g., Geth, Nethermind, Besu, Erigon) to strengthen network resilience. ENRs facilitate client diversity by standardizing how nodes advertise their client type and supported protocols (like eth, snap). This allows nodes to discover and connect to peers running different clients, preventing a single point of failure.

The foundational network layer of Ethereum, where nodes communicate directly. The ENR is a core component of this layer, serving as the digital business card for nodes. It enables the libp2p and DevP2P networking stacks to establish authenticated connections, exchange blockchain data (blocks, transactions), and propagate gossip messages across the network.

The software implementation that runs an Ethereum node. ENRs contain fields that identify the specific client version and the network protocols it supports (e.g., eth/66, eth/67 for execution layer; beacon/2 for consensus layer). This information is crucial for ensuring compatible and efficient communication between peers in the post-Merge Ethereum architecture.