You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Devcon 8 Community Hub Workshop Proposal]: Post-Quantum Light Clients: Rethinking the Networking Layer
#6
Post-Quantum Light Clients: Rethinking the Networking Layer
Format
1.5 hours Workshop Proposal
Abstract
Post-quantum light clients are more than a cryptographic upgrade. This talk explores how larger proofs, new committee models, verification costs, and hybrid PQ transitions affect peer discovery, GossipSub, transports, caching, observability, and interoperability, and how libp2p can evolve to support practical, efficient PQ light clients.
Workshop Overview
Post-quantum migration is often framed as a cryptographic problem: replace vulnerable signature schemes with post-quantum alternatives.
For decentralized systems, that is only part of the challenge.
Light clients depend on a complete stack of mechanisms to discover peers, retrieve authenticated data, propagate messages, verify proofs, and remain synchronized with the network. Post-quantum cryptography can substantially change the characteristics of those messages through larger signatures, proofs, certificates, and potentially different aggregation and committee mechanisms.
This creates a fundamental networking question:
How should decentralized networking evolve when authenticated objects become significantly larger and more expensive to verify?
The talk will examine this question through the lens of Ethereum's emerging post-quantum light-client discussions and the broader libp2p ecosystem, including Filecoin, IPFS, Celestia, rollups, and other decentralized systems.
Motivation
Recent Ethereum Lean Consensus discussions raised an important question around post-quantum light clients.
One possible direction is to reconsider the current Sync Committee model and explore whether per-slot committees associated with an Available Chain could provide the information required for light-client verification. Such a design could simplify parts of the protocol while potentially increasing the amount of data that light clients need to receive and verify.
This illustrates an important point:
Changing the consensus or cryptographic model changes the networking requirements.
Instead of asking only:
Can we replace BLS with a post-quantum signature scheme?
we should also ask:
Can the decentralized network efficiently deliver, discover, cache, propagate, and verify the resulting objects?
That is the perspective of this talk.
The Core Thesis
The talk proposes treating post-quantum light clients as a networking problem as well as a cryptographic problem.
A PQ transition could affect:
Message sizes
Bandwidth requirements
CPU verification costs
Propagation latency
Gossip behavior
Peer selection
Discovery mechanisms
Caching
Transport performance
Committee dissemination
Network observability
Interoperability
These effects need to be evaluated before large-scale PQ deployment.
Why This Matters Beyond Ethereum
Light clients are fundamental to decentralized systems.
They enable:
Mobile wallets
Browser applications
Ethereum light clients
Filecoin clients
IPFS delegated-routing clients
Celestia light nodes
Rollup bridges
Cross-chain applications
Resource-constrained devices
The common architectural assumption is often:
Consensus authenticates the data; networking delivers it.
Post-quantum migration challenges this separation.
If authenticated objects become larger, verification becomes more expensive, or committee structures change, the networking layer becomes part of the practical security and scalability model.
What Changes with Post-Quantum Cryptography?
The transition can introduce several new characteristics.
Larger authenticated objects
Many PQ signatures and proofs are substantially larger than current elliptic-curve signatures.
Higher verification costs
Verification may have different CPU and memory characteristics from today's cryptography.
New aggregation mechanisms
Existing aggregation assumptions may not translate directly to PQ schemes.
Hybrid transition periods
Networks may need to support classical and PQ authentication simultaneously.
Increased bandwidth pressure
Larger objects can create significantly more network traffic, especially during committee updates and synchronization.
Different failure modes
Dropped, delayed, or partially propagated large messages may have different consequences than today's smaller authenticated messages.
The result is a need to evaluate cryptography and networking together.
Each stage introduces questions that should be evaluated during PQ migration.
1. Committee Dissemination
If light clients depend on larger or more frequently changing committee information:
How quickly can committee information propagate?
What redundancy is necessary?
How much bandwidth does dissemination require?
Can GossipSub efficiently handle the resulting traffic?
Should committee information receive higher priority?
We need to understand whether existing gossip assumptions continue to hold.
2. Peer Discovery
Light clients need reliable sources of authenticated information.
Today, peer discovery generally does not encode rich information about:
Committee-serving capability
Data freshness
Historical reliability
Verification performance
Latency
Bandwidth capacity
A PQ environment may make these properties more important.
This raises the question:
Should peer discovery become aware of the capabilities required to serve PQ light clients?
3. GossipSub
Larger messages create new pressure on gossip protocols.
Potential areas for investigation include:
Adaptive mesh parameters
Message prioritization
Selective forwarding
Smarter peer scoring
Compression
Delta propagation
Batching
Duplicate suppression
The goal is not necessarily to create a separate PQ gossip protocol.
Instead, we should determine which existing libp2p primitives can evolve to efficiently support PQ workloads.
4. Transport Performance
PQ authenticated messages could significantly change traffic characteristics across:
QUIC
TCP
WebTransport
WebRTC
We need measurements across:
Throughput
Latency
Packetization
Retransmission
Connection establishment
CPU overhead
Memory usage
This is particularly important for mobile, browser, and resource-constrained light clients.
5. Caching and Retrieval
Not every light client necessarily needs to retrieve the same authenticated object independently.
This creates opportunities for:
Intermediate caching
Content-addressed storage
Delegated retrieval
IPFS content routing
Peer-assisted distribution
Committee-aware retrieval
The talk will explore whether decentralized storage and routing mechanisms can reduce the network cost of PQ light clients.
6. Observability
One of the biggest gaps is the lack of standardized observability for PQ networking.
Instead of measuring only peer counts and connection health, we should measure:
Committee propagation latency
Message convergence
Verification latency
Retransmission rates
Message drop rates
Bandwidth overhead
CPU cost
Relay dependency
Transport selection
Peer reliability
Committee freshness
These measurements can provide a common basis for comparing implementations.
From Cryptographic Benchmarks to Network Benchmarks
A cryptographic algorithm can be benchmarked in isolation.
But that does not tell us whether a decentralized system can efficiently use it.
For example:
PQ Signature
↓
Larger Object
↓
More Network Traffic
↓
Higher Propagation Latency
↓
More Retransmissions
↓
Higher CPU + Bandwidth Cost
↓
Potentially Worse Light-Client UX
The talk argues that PQ readiness should therefore include network-level benchmarks, not only cryptographic benchmarks.
Early Research Direction
We have begun exploring these questions through experimentation across the Python and Rust libp2p ecosystems.
Current areas include:
py-libp2p experimentation
Lightweight rust-libp2p prototypes
Network observability
PQ traffic and attack simulations
GossipSub experimentation
Transport measurements
Cross-language interoperability
An internal observability stack, Luminar, is being explored for injecting and studying different networking scenarios and measuring their effects across the stack.
The work is exploratory, but the early direction suggests that PQ migration deserves independent network-level evaluation alongside cryptographic research.
Proposed Research Framework
The talk proposes a simple framework:
Measure
Establish common PQ networking benchmarks.
Stress
Test GossipSub, transports, discovery, and retrieval under realistic PQ workloads.
Observe
Measure propagation, verification, bandwidth, CPU, and reliability.
Compare
Evaluate different committee sizes, payload sizes, transports, and cryptographic configurations.
Optimize
Identify protocol and implementation improvements.
Interoperate
Add PQ scenarios to cross-language interoperability testing.
Potential libp2p Roadmap
This work could eventually lead to reusable infrastructure across decentralized ecosystems.
Potential areas include:
PQ networking benchmark suites
PQ interoperability test vectors
Committee dissemination benchmarks
GossipSub PQ stress tests
Adaptive peer scoring
PQ-aware peer discovery
QUIC optimization for larger authenticated objects
Committee-aware retrieval
Standardized network telemetry
Cross-language PQ testing
Network observability dashboards
The objective is not to prescribe a single PQ architecture.
It is to develop networking primitives and measurements that allow different ecosystems to evaluate their choices consistently.
Ethereum and the Broader Ecosystem
Although Ethereum provides the primary motivation, the problem is ecosystem-wide.
The same networking challenges may emerge in:
Ethereum
Filecoin
IPFS
Celestia
Rollups
Cross-chain bridges
Decentralized storage networks
Mobile wallets
Browser clients
This makes libp2p particularly relevant.
Rather than every ecosystem independently solving the networking implications of PQ migration, common primitives and benchmarks could be developed collaboratively.
30-Minute Structure
0–3 min — The Question
Introduce Vitalik's PQ light-client question and explain why it should be considered a networking problem.
Highlight the networking challenges at each layer.
13–18 min — What Should We Measure?
Introduce the proposed observability and benchmarking framework.
18–23 min — Early Experiments
Discuss py-libp2p, rust-libp2p, GossipSub experiments, transport measurements, and network observability.
23–27 min — Toward a libp2p PQ Roadmap
Present potential benchmarks, interoperability testing, peer discovery improvements, transport work, and telemetry.
27–30 min — Open Questions
Close with the broader ecosystem questions and invite collaboration.
Key Takeaways
The audience should leave with three key ideas.
1. PQ migration is not only cryptographic
Changing signatures and proofs changes the network characteristics of decentralized systems.
2. Light clients need networking designed around the new reality
Peer discovery, gossip, retrieval, transports, caching, and observability must be evaluated under PQ workloads.
3. We should measure before we standardize
Common benchmarks and interoperability tests can help Ethereum and other decentralized ecosystems make evidence-based design decisions rather than independently rediscovering the same problems.
CROPS Alignment
This talk directly supports Devcon's CROPS priorities.
Security
Post-quantum migration is fundamentally a long-term security requirement. The talk focuses on ensuring that light clients remain securely verifiable and connected even as cryptographic assumptions change.
Open Source
The proposed research is centered on open-source libp2p implementations, reusable benchmarks, interoperability tests, observability tooling, and community-driven protocol development.
Censorship Resistance
Robust decentralized peer discovery, gossip, retrieval, and transport mechanisms are essential to preventing PQ light clients from becoming dependent on centralized providers or trusted data sources.
Privacy
Peer discovery, propagation patterns, transport behavior, and observability can expose metadata. PQ migration should therefore preserve privacy properties rather than optimizing only for cryptographic correctness.
Open Questions for the Community
The talk will conclude with several questions:
Should PQ light clients become an explicit libp2p design objective?
Does GossipSub require PQ-aware optimizations?
Should peer discovery expose committee-serving capabilities?
How should transports evolve for significantly larger authenticated objects?
Can IPFS and delegated routing reduce repeated committee-data retrieval?
What networking metrics should every PQ implementation expose?
Should PQ scenarios become part of libp2p Unified Testing?
What can Ethereum, Filecoin, IPFS, Celestia, and other ecosystems standardize together?
Closing Thesis
Post-quantum migration will likely be one of the largest protocol transitions decentralized systems undertake over the coming decade.
It is tempting to think of that transition as:
BLS → PQ signatures
But for a decentralized network, the real transition is much larger:
Cryptography → Consensus → Data → Networking → Verification → User Experience
If we want PQ light clients to remain practical, secure, permissionless, and interoperable, we need to start measuring the networking consequences now.
The question is not simply whether a light client can verify a post-quantum proof.
The question is whether the decentralized network can deliver and verify that proof efficiently, securely, and without introducing new dependencies.
This talk also proposes that libp2p providing a modular networking stack and a testbed should be part of that conversation from the beginning.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Devcon 8 Workshop Proposal
Title
Post-Quantum Light Clients: Rethinking the Networking Layer
Format
1.5 hours Workshop Proposal
Abstract
Post-quantum light clients are more than a cryptographic upgrade. This talk explores how larger proofs, new committee models, verification costs, and hybrid PQ transitions affect peer discovery, GossipSub, transports, caching, observability, and interoperability, and how libp2p can evolve to support practical, efficient PQ light clients.
Workshop Overview
Post-quantum migration is often framed as a cryptographic problem: replace vulnerable signature schemes with post-quantum alternatives.
For decentralized systems, that is only part of the challenge.
Light clients depend on a complete stack of mechanisms to discover peers, retrieve authenticated data, propagate messages, verify proofs, and remain synchronized with the network. Post-quantum cryptography can substantially change the characteristics of those messages through larger signatures, proofs, certificates, and potentially different aggregation and committee mechanisms.
This creates a fundamental networking question:
The talk will examine this question through the lens of Ethereum's emerging post-quantum light-client discussions and the broader libp2p ecosystem, including Filecoin, IPFS, Celestia, rollups, and other decentralized systems.
Motivation
Recent Ethereum Lean Consensus discussions raised an important question around post-quantum light clients.
One possible direction is to reconsider the current Sync Committee model and explore whether per-slot committees associated with an Available Chain could provide the information required for light-client verification. Such a design could simplify parts of the protocol while potentially increasing the amount of data that light clients need to receive and verify.
This illustrates an important point:
Changing the consensus or cryptographic model changes the networking requirements.
Instead of asking only:
we should also ask:
That is the perspective of this talk.
The Core Thesis
The talk proposes treating post-quantum light clients as a networking problem as well as a cryptographic problem.
A PQ transition could affect:
These effects need to be evaluated before large-scale PQ deployment.
Why This Matters Beyond Ethereum
Light clients are fundamental to decentralized systems.
They enable:
The common architectural assumption is often:
Post-quantum migration challenges this separation.
If authenticated objects become larger, verification becomes more expensive, or committee structures change, the networking layer becomes part of the practical security and scalability model.
What Changes with Post-Quantum Cryptography?
The transition can introduce several new characteristics.
Larger authenticated objects
Many PQ signatures and proofs are substantially larger than current elliptic-curve signatures.
Higher verification costs
Verification may have different CPU and memory characteristics from today's cryptography.
New aggregation mechanisms
Existing aggregation assumptions may not translate directly to PQ schemes.
Hybrid transition periods
Networks may need to support classical and PQ authentication simultaneously.
Increased bandwidth pressure
Larger objects can create significantly more network traffic, especially during committee updates and synchronization.
Different failure modes
Dropped, delayed, or partially propagated large messages may have different consequences than today's smaller authenticated messages.
The result is a need to evaluate cryptography and networking together.
A Networking Model for PQ Light Clients
The talk will examine the complete path:
Each stage introduces questions that should be evaluated during PQ migration.
1. Committee Dissemination
If light clients depend on larger or more frequently changing committee information:
We need to understand whether existing gossip assumptions continue to hold.
2. Peer Discovery
Light clients need reliable sources of authenticated information.
Today, peer discovery generally does not encode rich information about:
A PQ environment may make these properties more important.
This raises the question:
3. GossipSub
Larger messages create new pressure on gossip protocols.
Potential areas for investigation include:
The goal is not necessarily to create a separate PQ gossip protocol.
Instead, we should determine which existing libp2p primitives can evolve to efficiently support PQ workloads.
4. Transport Performance
PQ authenticated messages could significantly change traffic characteristics across:
We need measurements across:
This is particularly important for mobile, browser, and resource-constrained light clients.
5. Caching and Retrieval
Not every light client necessarily needs to retrieve the same authenticated object independently.
This creates opportunities for:
The talk will explore whether decentralized storage and routing mechanisms can reduce the network cost of PQ light clients.
6. Observability
One of the biggest gaps is the lack of standardized observability for PQ networking.
Instead of measuring only peer counts and connection health, we should measure:
These measurements can provide a common basis for comparing implementations.
From Cryptographic Benchmarks to Network Benchmarks
A cryptographic algorithm can be benchmarked in isolation.
But that does not tell us whether a decentralized system can efficiently use it.
For example:
The talk argues that PQ readiness should therefore include network-level benchmarks, not only cryptographic benchmarks.
Early Research Direction
We have begun exploring these questions through experimentation across the Python and Rust libp2p ecosystems.
Current areas include:
An internal observability stack, Luminar, is being explored for injecting and studying different networking scenarios and measuring their effects across the stack.
The work is exploratory, but the early direction suggests that PQ migration deserves independent network-level evaluation alongside cryptographic research.
Proposed Research Framework
The talk proposes a simple framework:
Measure
Establish common PQ networking benchmarks.
Stress
Test GossipSub, transports, discovery, and retrieval under realistic PQ workloads.
Observe
Measure propagation, verification, bandwidth, CPU, and reliability.
Compare
Evaluate different committee sizes, payload sizes, transports, and cryptographic configurations.
Optimize
Identify protocol and implementation improvements.
Interoperate
Add PQ scenarios to cross-language interoperability testing.
Potential libp2p Roadmap
This work could eventually lead to reusable infrastructure across decentralized ecosystems.
Potential areas include:
The objective is not to prescribe a single PQ architecture.
It is to develop networking primitives and measurements that allow different ecosystems to evaluate their choices consistently.
Ethereum and the Broader Ecosystem
Although Ethereum provides the primary motivation, the problem is ecosystem-wide.
The same networking challenges may emerge in:
This makes libp2p particularly relevant.
Rather than every ecosystem independently solving the networking implications of PQ migration, common primitives and benchmarks could be developed collaboratively.
30-Minute Structure
0–3 min — The Question
Introduce Vitalik's PQ light-client question and explain why it should be considered a networking problem.
3–7 min — Why PQ Changes the Network
Explain larger authenticated objects, verification costs, hybrid transitions, and committee changes.
7–13 min — The PQ Light-Client Stack
Walk through:
Committee → Discovery → Gossip → Transport → Retrieval → Verification
Highlight the networking challenges at each layer.
13–18 min — What Should We Measure?
Introduce the proposed observability and benchmarking framework.
18–23 min — Early Experiments
Discuss py-libp2p, rust-libp2p, GossipSub experiments, transport measurements, and network observability.
23–27 min — Toward a libp2p PQ Roadmap
Present potential benchmarks, interoperability testing, peer discovery improvements, transport work, and telemetry.
27–30 min — Open Questions
Close with the broader ecosystem questions and invite collaboration.
Key Takeaways
The audience should leave with three key ideas.
1. PQ migration is not only cryptographic
Changing signatures and proofs changes the network characteristics of decentralized systems.
2. Light clients need networking designed around the new reality
Peer discovery, gossip, retrieval, transports, caching, and observability must be evaluated under PQ workloads.
3. We should measure before we standardize
Common benchmarks and interoperability tests can help Ethereum and other decentralized ecosystems make evidence-based design decisions rather than independently rediscovering the same problems.
CROPS Alignment
This talk directly supports Devcon's CROPS priorities.
Security
Post-quantum migration is fundamentally a long-term security requirement. The talk focuses on ensuring that light clients remain securely verifiable and connected even as cryptographic assumptions change.
Open Source
The proposed research is centered on open-source libp2p implementations, reusable benchmarks, interoperability tests, observability tooling, and community-driven protocol development.
Censorship Resistance
Robust decentralized peer discovery, gossip, retrieval, and transport mechanisms are essential to preventing PQ light clients from becoming dependent on centralized providers or trusted data sources.
Privacy
Peer discovery, propagation patterns, transport behavior, and observability can expose metadata. PQ migration should therefore preserve privacy properties rather than optimizing only for cryptographic correctness.
Open Questions for the Community
The talk will conclude with several questions:
Should PQ light clients become an explicit libp2p design objective?
Does GossipSub require PQ-aware optimizations?
Should peer discovery expose committee-serving capabilities?
How should transports evolve for significantly larger authenticated objects?
Can IPFS and delegated routing reduce repeated committee-data retrieval?
What networking metrics should every PQ implementation expose?
Should PQ scenarios become part of libp2p Unified Testing?
What can Ethereum, Filecoin, IPFS, Celestia, and other ecosystems standardize together?
Closing Thesis
Post-quantum migration will likely be one of the largest protocol transitions decentralized systems undertake over the coming decade.
It is tempting to think of that transition as:
BLS → PQ signatures
But for a decentralized network, the real transition is much larger:
Cryptography → Consensus → Data → Networking → Verification → User Experience
If we want PQ light clients to remain practical, secure, permissionless, and interoperable, we need to start measuring the networking consequences now.
This talk also proposes that libp2p providing a modular networking stack and a testbed should be part of that conversation from the beginning.
All reactions