Inventory of PQ P2P Migrations in the Consensus Layer

Inventory of Post‑Quantum P2P Migrations in the Consensus Layer

Ethereum’s consensus‑layer (CL) networking currently relies on secp256k1‑based signatures and key exchanges across three tightly coupled components: Discovery v5/ENR, QUIC/TLS 1.3, and libp2p. A migration to post‑quantum (PQ) cryptography cannot be a simple drop‑in replacement because of strict byte‑size constraints (ENR ≤ 300 B, Discovery packet ≤ 1 280 B) and because each component carries distinct identity and authentication responsibilities. This inventory maps the required changes without prescribing algorithms, encodings, or rollout dates, aiming to give developers a clear picture of the problem space.

---

1. Why the Existing Stack Is Vulnerable

| Component | Current Primitive | Quantum‑Relevant Threat | |-----------|-------------------|------------------------| | ENR signature | secp256k1 ECDSA (64 B) | Forged records once a quantum adversary can solve ECDLP | | Discovery key exchange | secp256k1 ECDH (32 B) | Recorded ciphertext can be decrypted after ECDH is broken | | libp2p TLS identity binding | secp256k1 ECDSA | Peer‑ID impersonation | | QUIC/TLS 1.3 key exchange | DHE/ECDHE (X25519) | Same as Discovery – future decryption of captured traffic | | TLS CertificateVerify | secp256k1 ECDSA | Handshake forgery |

The threats differ in timing: key‑exchange compromises affect past traffic, while signature attacks require quantum capability at the moment of impersonation. Consequently, a hybrid approach (classical + PQ) can be introduced for key exchange before a full PQ identity design is ready.

---

2. Discovery v5 & ENR – Size is the Hard Constraint

2.1 ENR format limits

An ENR is an RLP list limited to 300 bytes: ``` [signature, seq, k1, v1, k2, v2, …] ``` The 64‑byte secp256k1 signature and 33‑byte compressed public key comfortably fit, but candidate PQ schemes quickly exceed the budget. For example, ML‑DSA‑44 public keys are ~1.3 KB and signatures >2 KB—far beyond the ENR limit. Hash‑based signatures (XMSS, SLH‑DSA) are even larger, making them unsuitable for the ENR payload.

2.2 Implications

• New record format – PQ keys and signatures must be stored outside the existing ENR fields, perhaps via a separate credential blob referenced by a hash.
• Credential distribution – Clients need a reliable way to fetch and cache large PQ credentials without inflating discovery traffic.
• Downgrade protection – Both the legacy v4 scheme and the future PQ scheme must coexist safely; attackers must not force a node to fall back to the insecure format.
• DoS considerations – Verification of large PQ signatures is CPU‑intensive; rate‑limiting and packet‑size caps are essential.

---

3. QUIC/TLS 1.3 – Hybrid Key Exchange First

QUIC’s transport security is built on TLS 1.3. The current profile uses X25519 (32 B) for forward secrecy. A hybrid group (e.g., X25519 + ML‑KEM‑768) adds a ~1 KB public key, raising the TLS handshake size but preserving compatibility with existing clients.

Migration checklist

1. Define a common TLS profile that lists supported hybrid groups and mandates downgrade‑safe negotiation.
2. Measure impact on latency, CPU, and memory for each hybrid group across major client implementations.
3. Provide test vectors and cross‑client telemetry to ensure consistent handling of hybrid handshakes.
4. Maintain fallback to pure classical groups for nodes that have not yet upgraded, while preventing forced downgrades.

Hybrid key exchange protects future confidentiality without altering the signature‑based authentication steps that follow.

---

4. libp2p Authentication – Two Signature Roles

Within the libp2p TLS handshake, two distinct signatures are used:

• Peer‑identity binding – The long‑term libp2p key signs the TLS certificate’s public key, linking the TLS channel to the expected Peer ID.
• TLS CertificateVerify – The certificate key signs the transcript, proving possession of the private key.

Both must transition to PQ or hybrid schemes. The challenges are:

• Key‑size compatibility – PQ public keys (e.g., ML‑DSA) are larger than the current 33‑byte secp256k1 keys, affecting the size of TLS certificates and the libp2p identity payload.
• Encoding standards – libp2p currently expects PKIX/PKCS#8 encodings; PQ keys will need standardized encodings that all clients understand.
• Rotation & revocation – Mechanisms for rotating large PQ keys and revoking compromised identities must be defined.
• Interoperability – Clients must agree on whether to accept hybrid signatures (classical + PQ) or pure PQ signatures, and how to negotiate this during the handshake.

---

5. Putting It All Together – A Coordinated Migration Path

| Migration Target | Immediate Action | Longer‑Term Goal | |------------------|------------------|------------------| | Discovery ENR | Draft a new ENR schema that references external PQ credentials; prototype a bootstrap mechanism for fetching them. | Standardize a compact PQ credential format (e.g., compressed ML‑DSA public key + short hash) and integrate it into the ENR ecosystem. | | Discovery session | Implement hybrid KEM (ML‑KEM) for the initial key exchange, keeping ECDSA for identity proof until PQ signatures are ready. | Replace ECDSA identity proof with a PQ‑compatible proof that fits within the 1 280‑byte packet budget. | | QUIC/TLS | Agree on a set of hybrid groups (X25519 + ML‑KEM‑768) and update client libraries accordingly. | Phase in pure PQ groups once library support and performance are proven. | | libp2p TLS | Add support for hybrid CertificateVerify (classical + PQ) and test cross‑client compatibility. | Transition to pure PQ signatures for both peer‑identity binding and CertificateVerify, with a clear revocation path. |

Successful migration will require tight coordination between the Ethereum consensus‑spec team, the libp2p maintainers, and each client implementation. A shared interoperability test suite, along with clear versioning of the CL P2P profile, will be essential to avoid network fragmentation.

---

6. Practical Takeaway

Developers working on the CL networking stack should start by experimenting with hybrid key exchange in QUIC/TLS and designing a lightweight external credential reference for ENRs. Early prototypes can be validated against existing clients to surface compatibility issues before committing to a full PQ signature rollout. By tackling the three boundaries—Discovery, QUIC/TLS, and libp2p—in parallel but with clearly defined hand‑off points, the Ethereum ecosystem can evolve toward a quantum‑safe peer‑to‑peer layer without jeopardizing current network stability.