Ethereum uses different identity objects at discovery, transport, and application boundaries. A key can be reused by an implementation, but a value from one identity scheme is not a valid value for another scheme.
Identity forms
| Form | Protocol | Encoding or derivation | What it identifies |
|---|---|---|---|
| ENR node ID | ENR and discv5 | The selected identity scheme derives a 32-byte ID. The v4 scheme hashes the uncompressed secp256k1 public-key coordinates with Keccak-256. |
A node-record identity and a discovery-table position. |
| discv4 node ID | discv4 | The secp256k1 public key in the signed packet. Routing distance is keccak256(public_key_a) XOR keccak256(public_key_b). |
A discovery-v4 node. |
| RLPx node identity | RLPx | A static secp256k1 key is saved between sessions. | The endpoint that authenticates the RLPx handshake and Hello. |
| libp2p Peer ID | libp2p | A multihash of the serialized public key. A key of at most 42 serialized bytes uses the identity multihash; a larger key uses SHA-256. | The key used by the libp2p secure channel. |
The ENR id field selects the identity scheme. The current v4 scheme uses
the compressed secp256k1 public key in the record and a 64-byte r || s
signature. The recovery value is not stored in the ENR signature.
Discovery identity
The ENR envelope checks its signature with the public key
named by the identity scheme. For v4, the signer hashes the canonical RLP
content with Keccak-256 before signing. The node ID is:
node_id = keccak256(x || y)
x and y are the uncompressed public-key coordinates, each left-padded to
32 bytes. discv4 uses the public key itself for packet signatures and hashes
that key when it computes Kademlia distance. discv5 uses the node ID derived by
the ENR identity scheme for its XOR distance.
An ENR sequence number updates a record. It does not move trust from one key to another. A record signed by a new key has a new identity and must pass discovery and transport checks again.
Transport identity
RLPx nodes keep a static secp256k1 private key between sessions. The TCP
handshake uses that key and fresh ephemeral key material to derive encrypted
session keys. The first encrypted frame carries Hello; either side can close
the connection when that frame fails authentication.
Consensus clients use a libp2p Peer ID. The ID is the multihash of the encoded
public key. Implementations must parse both the legacy raw base58btc form and
the CIDv1 form that uses the libp2p-key multicodec. The Peer ID does not
replace the ENR: discv5 provides the candidate address, and libp2p proves the
key during secure-channel setup.
Validation and rotation
Apply the identity check at the boundary that defines it:
- Check an ENR signature against the public key and identity scheme named by the record.
- Check a discv4 packet signature before using its packet type or sender.
- Check the RLPx handshake and the first encrypted frame before accepting a capability session.
- Check the libp2p secure channel's Peer ID before opening gossip or Req/Resp streams.
Treat a key rotation as a new peer until a separate protocol proves continuity. Do not compare raw public-key encodings, node IDs, or Peer IDs across these schemes.
Failure handling
- Reject an ENR with an invalid signature, identity key, or identity scheme.
- Reject a packet when its signature does not authenticate the packet bytes.
- Close a transport session when handshake authentication fails.
- Do not use a higher ENR sequence number to accept an old key.
- Do not add a candidate to a layer's peer set until that layer's transport identity check succeeds.
Separate identity forms let each protocol choose its own wire encoding and cryptographic handshake while keeping discovery records extensible.