Inventory of PQ P2P Migrations in the Consensus Layer

What it is

An inventory by adust09 (Nyx Foundation) of what must change to make Ethereum consensus-layer (CL) networking post-quantum. It covers Discovery v5 with ENRs, libp2p and QUIC with TLS 1.3. It selects no algorithm, encoding or fork. The author says no specific plans exist yet and that a Discv5-focused migration plan will follow.

How it works

Replacing validator BLS signatures with leanXMSS does not touch networking identity. All six clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine) bind the Discovery node ID and the libp2p Peer ID to one secp256k1 key. The two are not interchangeable: the node ID selects routing-table records, and the Peer ID identifies the libp2p endpoint. The client checks the Peer ID derived from the ENR against the identity authenticated in the QUIC handshake.

The post splits the work into three layers:

• Discovery. The Discv5 handshake uses an ECDSA identity proof plus secp256k1 ECDH, with HKDF-SHA-256 and AES-128-GCM. Both must be replaced. The ENR v4 signature covers keccak256(RLP([seq, k₁, v₁, ...])).
• Connection key exchange. TLS 1.3 inside QUIC can add an ML-KEM secret through a hybrid group. RFC 10024 standardizes this.
• Connection authentication. libp2p TLS has two signatures: the long-term key signs the certificate key (Peer ID binding), and the certificate key signs the transcript (CertificateVerify). Hybrid key exchange changes neither.

Key exchange and signatures have different threat timelines. Recorded ciphertext can be decrypted later, so key exchange is urgent. Signature forgery needs quantum capability at the time of the attack. Hybrid key exchange can therefore ship before a full PQ identity design.

What to do

The post lists work for client and library teams.

For Discovery, define common rules for:

• binding the ENR, node ID, Peer ID and endpoints together;
• storing, fetching, caching and refreshing large PQ keys outside the 300-byte ENR;
• running v4 alongside its successor without downgrade;
• capping oversized packets and costly decapsulation or signature verification, to resist DoS;
• one encoding, error behavior and set of test vectors.

For QUIC/TLS, the post asks for:

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

The author proposes that the Ethereum team lead Discv5 planning and the libp2p team lead the rest.

Caveats

• ML-DSA-44 is only an example. Its public key alone exceeds both the 300-byte ENR and 1,280-byte packet limits, so a new record format or credential distribution model is needed.
• The author says lattice schemes are the likely networking candidates because hash-based signatures (XMSS, SLH-DSA) are several kilobytes or more. They describe this as a tendency, not a selection.
• Scope is QUIC only. The current consensus-spec development branch requires both transports and treats QUIC as primary, so TCP/Noise still needs migration work.
• In libp2p, ML-DSA peer identities and PKIX/PKCS#8 key encodings are still open proposals. FN-DSA (FIPS 206) is still a draft.
• Prior work cited: the post-quantum task list, "Towards a Quantum-Safe P2P for Ethereum", and a signature-free PQ RLPx handshake study. The last covers the Execution Layer Discv4/RLPx path, not CL Discovery v5 or libp2p.