Networking Foundations for Post-Quantum Light Clients at Ethereum, Filecoin and IPFS

[seetadev]

Motivation

During recent Ethereum's Lean Consensus discussions, an interesting question was raised by Vitalik:

Is anyone working on Post-Quantum (PQ) Light Clients?

One accompanying idea was whether, during the rollout of Available Chain (AC), Ethereum could replace the current Sync Committee with the per-slot AC committee for light client verification. Although this increases the amount of data transferred, it substantially simplifies the protocol.

From the networking perspective, this proposal raises a broader question relevant not only Ethereum but also Filecoin.

How should libp2p evolve to support post-quantum light clients across decentralized systems?

Rather than viewing PQ migration purely as a cryptographic replacement exercise (for example replacing BLS with a PQ signature algorithm), this discussion proposes treating it as a complete networking problem involving peer discovery, transport, message dissemination, verification, observability, and protocol evolution.

Why this matters

Today, almost every blockchain ecosystem relies on lightweight clients.

Examples include:

• Ethereum Light Clients
• Celestia Light Nodes
• Filecoin retrieval clients
• IPFS delegated routing clients
• Rollup bridge clients
• Mobile wallets
• Browser-based applications

The existing assumption has largely been:

Consensus produces authenticated objects.

Networking delivers those objects.

Post-quantum systems may significantly change this assumption.

Larger signatures.

Larger proofs.

Different aggregation mechanisms.

New verification costs.

Potentially different committee structures.

Networking therefore becomes an active participant in making PQ light clients practical.

---

Why libp2p should care

libp2p has become the networking layer for numerous decentralized ecosystems.

These include:

• Ethereum
• IPFS
• Filecoin
• Celestia
• Polygon
• Optimism
• Arbitrum
• EigenLayer
• Avail
• dozens of independent research systems

If multiple ecosystems begin exploring PQ migration independently, there is significant value in identifying networking primitives that can be shared rather than repeatedly reinvented.

A Networking Perspective

Suppose a blockchain replaces:

Current model

Validators
        ↓
Sync Committee
        ↓
Light Clients

with something closer to

Validators
        ↓
Available Chain Committee
        ↓
Light Clients

Several networking questions immediately appear.

Committee dissemination

How quickly can committee information reach every light client?

What propagation latency is acceptable?

How much redundancy is required?

Can GossipSub efficiently support larger committee updates?

Verification traffic

If committee objects become larger, we may observe

• higher bandwidth consumption
• increased burst traffic
• larger verification messages
• more retransmissions

This affects every libp2p transport.

• QUIC
• TCP
• WebTransport
• WebRTC

Discovery

How should light clients discover high-quality committee providers?

Current Peer Discovery mechanisms are generally unaware of

• verification quality
• committee freshness
• historical reliability
• latency characteristics

Should future Peer Records expose additional metadata?

Caching

Can intermediate peers cache committee objects?

Could delegated routing become committee-aware?

Can IPFS content routing reduce repeated downloads?

Gossip optimization

Larger authenticated objects naturally increase pressure on GossipSub.

Questions include

• adaptive mesh sizes
• smarter scoring
• selective forwarding
• compression
• delta propagation
• priority scheduling

Post-Quantum changes networking assumptions

PQ migration introduces more than new signatures.

Possible implications include

• larger authenticated payloads
• slower verification
• higher CPU utilization
• increased bandwidth
• different aggregation strategies
• hybrid cryptographic periods
• multiple signature formats simultaneously

Networking protocols need to remain efficient throughout this transition.

Observability

One area that appears particularly underexplored is network observability.

To understand PQ networking behaviour, we likely need better measurements than simple peer counts.

Instead we should measure

• propagation delay
• committee convergence
• retransmission rate
• verification latency
• dropped committee messages
• relay dependency
• transport selection
• bandwidth overhead
• CPU verification cost

These metrics can then be compared across

• GossipSub versions
• transports
• committee sizes
• signature algorithms

Early experiments

We've begun exploring some of these questions within the Python ecosystem.

Current work includes

• py-libp2p experimentation
• lightweight rust-libp2p prototypes
• network observability tooling
• PQ attack simulations against GossipSub
• transport measurements

One internal observability stack ("Luminar") has been useful for injecting and studying various post-quantum networking scenarios. The work is still exploratory, but it has already highlighted that networking behaviour deserves independent study alongside cryptographic design.

Research questions

Some questions that could benefit from community discussion include:

1. Should PQ Light Clients become a libp2p design objective?

2. Does GossipSub require PQ-aware optimizations?

3. Should peer discovery expose committee-serving capabilities?

4. How should transports evolve for significantly larger authenticated objects?

5. Can delegated routing help distribute committee data?

6. What networking metrics should every implementation expose?

7. How should interoperability testing evolve?

Should PQ networking scenarios become part of Unified Testing?

A possible libp2p-2035 roadmap

Some ideas worth exploring include:

• PQ networking benchmark suite
• PQ interoperability test vectors
• Committee dissemination benchmarks
• GossipSub stress testing with PQ payloads
• Adaptive peer scoring for larger authenticated messages
• QUIC optimization for PQ traffic
• CBOR-42 serialization benchmarks for committee objects
• Network observability dashboards
• Standardized telemetry
• Cross-language implementation testing

Open Questions

We would love to hear thoughts from maintainers across the Go, Rust, JavaScript and Python implementations, as well as researchers working on Ethereum, Filecoin, IPFS, Celestia, and related ecosystems.

In particular:

• Are there existing efforts around PQ light clients that we should build upon?
• Which networking bottlenecks are likely to become the limiting factor?
• Should libp2p begin standardizing benchmarking and observability for PQ networking?
• Are there opportunities to develop reusable networking primitives before ecosystems independently design incompatible solutions?

Post-quantum migration will likely be one of the largest protocol transitions decentralized systems undertake over the next decade. While much of the discussion understandably focuses on cryptography, networking will play an equally important role in determining whether PQ light clients remain practical, efficient, and interoperable.

This discussion is intended as a starting point for that conversation.

Please reach to me (@seetadev) and @johannamoran in case of any suggestions, pointers and feedback.