We are excited to announce a significant upgrade to our network backend: the stabilization of LiteP2P.
This lightweight and efficient alternative to libp2p is now production-ready and is the default network backend in the 2503-7 release.
Over the past year, our team has been dedicated to refining litep2p, resolving critical issues, and transitioning it from an experimental project to a robust, stable solution.
This move promises substantial performance improvements, most notably in CPU efficiency, without compromising the core performance of the project.
For a detailed look at the changes, please see the stabilization PR #8461 on GitHub.
Polkadot Node Operators
Following six months of rigorous testing on Kusama and local testnets, the data confirms that LiteP2P is stable and ready for Polkadot.
Kusama validators are already running smoothly on LiteP2P, demonstrating its reliability.
We ask all Polkadot node operators to be especially attentive. While we have high confidence based on our data, we have a fallback plan ready for any unforeseen issues.
Your vigilant monitoring of dashboards will be invaluable in helping us respond swiftly if needed.
Let’s work together to ensure a seamless transition.
Performance Comparison: LiteP2P vs Libp2p
CPU Usage
LiteP2P consumes approximately half the CPU resources of libp2p.
This frees up significant processing power for other subsystems and enables nodes to run on more cost-effective hardware.
The graph below, taken from a live Kusama validator, illustrates the CPU time spent on the networking task. LiteP2P (left) uses about 1.3 CPUs, while libp2p (right) requires 2.9-3 CPUs.
Faster Authority Discovery and Stable Connections
LiteP2P’s implementation of the Kademlia DHT protocol enables significantly faster peer discovery.
For instance, LiteP2P discovers 1000 authority records in just 2 minutes, compared to the 10 minutes required by libp2p.
This leads to faster sync times and a more stable set of connected peers.
In one experiment, a node using LiteP2P synced to the tip of the chain in 526 seconds, while a libp2p node took 803 seconds.
We expect this to positively impact many outstanding issues with the current Libp2p Kademlia implementation, as inconsistent era points
For more details, see this forum post on backend updates.
Protocol Performance
Artificial benchmarks consistently show LiteP2P outperforming libp2p in data transfer speeds. Using the litep2p-perf benchmarking tool, we observed:
- Upload Speeds: LiteP2P is ~24% faster, reaching up to 608.78 Mbit/s.
- Download Speeds: LiteP2P is ~26% faster, with a top speed of 615.73 Mbit/s.
In comparison, libp2p’s top speeds were approximately 100 Mbit/s slower in both categories.
Further optimizations to our notifications protocol, such as integrating an upstream yamux implementation with dynamic stream window auto-tuning, have yielded an additional ~3% performance improvement over libp2p.
You can see the impact in this GitHub issue #7183.
The request-response protocol also shows LiteP2P’s superior performance across various packet scenarios, as detailed in our benchmarks.
A Note for Kusama Validators
I would like to extend my thanks to all Kusama validators who participated in the gradual rollout of LiteP2P. Your involvement was crucial in achieving a smooth transition.
Action Required: If you are a validator still running an older, experimental version of LiteP2P, please upgrade to the 2503-7 release immediately.
The new version includes significant improvements, such as compatibility with older light clients, enhanced WebSocket connection stability, a more robust Kademlia address store, and fixes for high CPU usage on minimal-relay chains.
Thanks!
A special thanks to Aaro who started the project and to @dmitry-markin for his outstanding work on implementing the content provider advertisement, discovery feature and continuous contributions towards litep2p!
Thanks everyone for your continued support and collaboration as we take this important step forward, and to all others who have contributed!