Inventory of PQ P2P Migrations in the Consensus Layer

Networking
, ,
1

Author: @adust09 from Nyx Foundation

Abstract

In this post, we will take stock of the challenges facing PQ P2P in the consensus layer.

Ethereum consensus-layer networking has no adopted post-quantum migration profile. Replacing validator BLS signatures with leanXMSS does not update the networking identities and handshakes used by ENRs, Discovery v5, libp2p Peer IDs, or QUIC/TLS.

The migration has three linked targets:

  1. Discovery: ENR signatures, Discovery identity proofs, and Discovery key exchange.
  2. Connection key exchange: TLS 1.3 key agreement inside QUIC.
  3. Connection authentication: libp2p TLS identity binding and TLS CertificateVerify.

The main constraints are structural: an ENR is limited to 300 bytes, a Discovery packet to 1,280 bytes, and hybrid key exchange does not provide PQ authentication.

In practice, hash-based signatures are being promoted for consensus signatures, but the size limits of the P2P layer make lattice-based schemes the de facto standard candidates for networking. This inventory maps the required changes without selecting an algorithm, encoding, or activation schedule.

This article is intended for developers working on the network layer and libp2p. Please feel free to send me your feedback.

1. Scope

This post covers Ethereum CL networking over libp2p and QUIC:

Discovery v5 + ENR
        ↓
client discovery adapter
ENR → multiaddrs + expected Peer ID
        ↓
QUIC + TLS 1.3
        ↓
libp2p streams
        ↓
gossipsub and request/response protocols

The Execution Layer and TCP/Noise fallback are outside the handshake analysis. They still need compatible migration work: the current consensus-specification development branch requires both transports and treats QUIC as primary. QUIC-only scope is therefore an analytical boundary, not a deployment proposal.

This post does not select a PQ signature, KEM, fork, or rollout date.

2. Current discovery-to-message path

First, let’s take a look at the current spec.

Discovery and libp2p use separate sessions and keys. The current CL profile derives the Discovery node ID and libp2p Peer ID from one secp256k1 networking key, but the identifiers are not interchangeable: the node ID selects records in the Discovery routing table, while the Peer ID identifies the libp2p endpoint.

image
image980×360 24.1 KB

Figure 1. The node ID is Ethereum’s. The Peer ID is libp2p’s.

A node starts from bootnode or cached ENRs. Discovery v5 performs Kademlia-style lookups with FINDNODE and NODES, then returns authenticated records. The client adapter converts a selected ENR into dialable multiaddrs and the expected Peer ID.

image
image980×620 36.7 KB

Figure 2. Discovery returns an ENR, then the client dials its QUIC endpoint and checks the Peer ID.

QUIC establishes a new TLS 1.3 session; Discovery keys and transcripts are not reused. The client checks the authenticated libp2p identity against the Peer ID derived from the ENR. The client then performs Ethereum’s Status exchange to check fork and checkpoint compatibility before normal traffic begins.

image
image1000×720 40.3 KB

Figure 3. Discovery and QUIC/libp2p are separate authenticated stages.

Lighthouse, Prysm, Teku, Nimbus, Lodestar, and Grandine bind both systems to one secp256k1 key. If future designs separate them, the node-ID-to-Peer-ID mapping must be authenticated and normative; client-local conventions would create identity-substitution and interoperability risks.

3. Cryptographic inventory

As we saw in Chapter 2, some cryptographic primitives need to be replaced.

Component Role Current scheme Quantum-relevant threat
ENR Discovery record signature secp256k1 ECDSA Forge records after quantum capability exists
Discovery v5 Session key exchange secp256k1 ECDH Record traffic now and decrypt it later
Discovery v5 Handshake identity proof secp256k1 ECDSA Impersonate nodes and forge handshakes
libp2p TLS extension Peer identity–certificate binding secp256k1 ECDSA in the CL profile Impersonate a Peer ID
QUIC/TLS 1.3 Session key exchange Negotiated DHE/ECDHE Record traffic now and decrypt it later
TLS 1.3 CertificateVerify Certificate-key signature Forge the secure-channel handshake

The threats have different timelines:

  • Key exchange: recorded ciphertext can be decrypted when the classical agreement is broken.
  • Signatures: the attacker needs quantum capability at the time of impersonation or forgery.

Hybrid key exchange can therefore precede a complete PQ identity design, but it is not a complete P2P migration.

4. Post-quantum migration for Discovery

Here, let’s review the challenges related to the replacement targets. First up is the one concerning Discv5.

4.1 ENR format and PQ size constraints

An ENR is an RLP list of at most 300 bytes:

[signature, seq, k₁, v₁, k₂, v₂, ...]

For the v4 identity scheme, the 64-byte secp256k1 signature covers:

keccak256(RLP([seq, k₁, v₁, k₂, v₂, ...]))

The signed fields include the identity key and advertised endpoints. udp and quic identify separate listening ports.

image
image980×610 47.2 KB

Figure 4. The v4 signature covers the RLP-encoded content, not the signature itself.

The size limits rule out direct substitution with common PQ signatures:

Item Size
Maximum complete ENR 300 bytes
Maximum Discovery v5 packet 1,280 bytes
Current secp256k1 ENR signature 64 bytes
Current compressed secp256k1 public key 33 bytes
ML-DSA-44 public key 1,312 bytes
ML-DSA-44 signature 2,420 bytes

ML-DSA-44 is an example, not a selection. Its public key already exceeds both limits, and its signature is larger still. Since the identity key, signature, endpoints, and metadata share the ENR budget, PQ migration requires a new record format or credential-distribution model. Other schemes make different size trade-offs, but none should be assumed to be a drop-in replacement.

Scheme families diverge by layer. Ethereum’s consensus-signature work promotes hash-based schemes such as XMSS and SLH-DSA, which offer high confidence but carry signatures of several kilobytes or more. The P2P layer cannot afford that overhead inside a 300-byte ENR, so standardized lattice-based schemes such as ML-DSA dominate practical candidates for networking. This describes the community’s current tendency, not a selection.

4.2 Discovery v5 session authentication and migration challenges

On first contact, the initiator knows the recipient’s ENR but has no session keys:

  1. The initiator sends an ordinary packet with random message content.
  2. The recipient replies with a WHOAREYOU challenge containing an identity nonce and ENR sequence.
  3. The initiator sends an identity signature, ephemeral key, optional ENR, and an encrypted request such as FINDNODE.
  4. The recipient verifies the proof, derives keys, and returns an encrypted response such as NODES.
  5. Both sides reuse the session keys until expiry.

Discovery derives AES-128-GCM keys from secp256k1 ECDH and HKDF-SHA-256. ECDSA authenticates the handshake; ECDH alone does not.

image
image980×300 17.5 KB

Figure 5. Discovery and libp2p perform separate key exchanges.

PQ migration must replace both the ECDSA identity proof and ECDH while preserving the binding among the ENR, node ID, endpoints, and Peer ID. A hybrid KEM protects the session secret but does not authenticate the peer. PQ authentication must either fit within the 1,280-byte packet budget or use separately authenticated credentials.
Post-quantum Discovery therefore needs common rules for:

  • proving that the ENR, node ID, Peer ID, and advertised endpoints belong to the same node;
  • deciding where large PQ public keys and signatures are stored and how they are retrieved, cached, and refreshed;
  • operating the current v4 scheme alongside its successor without allowing downgrade attacks;
  • limiting oversized Discovery packets and expensive Discovery-side cryptography (decapsulation and signature verification) to resist denial-of-service attacks;
  • defining one encoding, error behavior, and set of test vectors that every client implements.

5. Post-quantum migration for connection key exchange

Let’s look at key exchange. From this point on, support for libp2p is required.

QUIC uses TLS 1.3. A classical ECDHE secret feeds the TLS key schedule; a hybrid group adds an ML-KEM secret.

TLS 1.3 key share Client share Server share Property added
X25519 32 bytes 32 bytes Classical forward secrecy
X25519MLKEM768 1,216 bytes 1,120 bytes Classical + ML-KEM hybrid secrecy

RFC 10024 standardizes hybrid TLS 1.3 groups. Ethereum clients still need:

  • a common TLS profile and compatible libraries;
  • QUIC handshake-size, latency, CPU, and memory measurements;
  • deterministic negotiation and downgrade-safe fallback rules;
  • cross-client tests and telemetry for configured, negotiated, and failed hybrid sessions.

Hybrid secrecy protects key establishment; it does not replace the signatures used for connection authentication.

6. Post-quantum migration for connection authentication

Next up is authentication. The libp2p TLS handshake has two signing roles:

  1. Peer-identity binding: the long-term libp2p key signs the TLS certificate public key, binding the channel to the expected Peer ID.
  2. TLS CertificateVerify: the certificate key signs the TLS transcript, proving possession of that key.

PQ key exchange changes neither signature. Both need a PQ or hybrid plan.

Signature role Open algorithm question Required continuity and tests
Peer-identity binding PQ-only or hybrid? Peer ID derivation, identity binding, rotation, revocation, expected-peer checks
TLS CertificateVerify PQ-only or hybrid? TLS library support, encoding, transcript compatibility, cross-client negotiation

7. Prior work and unresolved areas

Several studies have already been conducted.

  1. The post-quantum task list separates node identity, ENRs, discovery, handshakes, encryption, and bootnodes, but does not define a CL interoperability profile.
  2. Towards a Quantum-Safe P2P for Ethereum quantifies PQ size growth and shows why discovery needs redesign rather than a field-for-field algorithm swap.
  3. The signature-free post-quantum RLPx handshake studies static KEM identity and delayed authentication for the Execution Layer Discv4/RLPx path, not CL Discovery v5/libp2p.

On the standards side, NIST has finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), with FN-DSA still in draft (FIPS 206). The IETF has standardized TLS 1.3 (RFC 8446) and hybrid PQ/T key exchange for TLS 1.3 (RFC 10024); hash-based XMSS (RFC 8391) and LMS (RFC 8554) are standardized separately.

In libp2p, ML-DSA peer identities and PKIX/PKCS#8 key encodings remain open proposals. No standard defines the Ethereum CL P2P profile this document calls for.

Migration challenge summary

Ethereum CL P2P migration requires coordinated changes to three boundaries:

  • Discovery needs new identity, record, and handshake formats.
  • QUIC/TLS needs downgrade-safe hybrid key exchange.
  • libp2p/TLS needs PQ plans for both identity binding and CertificateVerify.

At this point, there are no specific plans in place. It would be preferable for the Ethereum team to take the lead on planning Discv5, while the libp2p team takes the lead on everything else.

The overall migration cannot be completed without cooperation from the client teams.
Next, I plan to post a specific migration plan focused on Discv5.