In 2012, a group of developers, David Schwartz, Jed McCaleb, and Arthur Britto, set out to create a better version of Bitcoin (BTC). They wanted faster transactions, lower energy use, and no mining. They developed what would become the XRP Ledger.
In a recent article titled “XRPL Stability and Scalability Efforts,” Bart Thomee, Senior Engineering Manager at Ripple, highlighted that approximately 80% of development work has been dedicated to non-feature tasks, concentrating on four key areas: memory usage, peering, lock contention, and test environments.
As Thomee notes, “We would like to provide transparency by highlighting what we have recently done and what we are currently working on to enhance the stability, scalability, and resiliency of the ledger.”
XRPL Memory Optimization Efforts
To support scalability and reduce hardware demands, the XRP Ledger team is working to optimize memory usage. Currently, internal structures like SHAMap and TaggedCache can consume over 20GB of memory. That much memory usage raises the bar for server demands, potentially making broader participation in the network harder.
Recent changes included replacing shared pointers with light-weight custom intrusive pointers, which resulted in 10–15% memory reduction in mainnet validators. The development team also seeks cache consolidation, faster eviction of inactive objects, and removal of unnecessary caches placed on top of modern databases to reduce the memory overhead and lower the barrier to XRPL participation. Ripple’s two-pronged objective is to reduce the memory requirement for validators and set the stage for monumental scalability in the next few years.
Stability and Communication
“As cryptocurrency has increased in popularity and consequently more transactions are being submitted than in the past, we have observed some instability in the network lately,” Thomee stated. To address this, the XRPL employs a cost-per-message system. Each message a node sends incurs a cost based on its complexity. If a node’s cost usage exceeds a certain threshold, peers may disconnect it temporarily. Despite the fixes, connectivity issues persist in some areas. Logs show that many peer disconnects are caused by missed heartbeat responses, a new and concerning pattern. To fix this, version 2.4.0 introduced smarter timeout resets when transaction sets are received. Looking forward, version 2.5.0 will feature two failsafes to prevent consensus from remaining stuck in its “establish” phase indefinitely.
Currently, XRPL uses a flooding approach to distribute messages across the network, ensuring that every node receives every message. An analysis found that with this approach, only 1.8 TB of the 14.4–43 TB of daily message traffic was actually useful for consensus.
The solution? Squelching. This technique limits how many peers forward a validator’s messages, cutting back on duplicate traffic. Early tests, with a peer limit set to 5, reduced total message volume to 8.9–16.8 TB/day, with no impact on consensus accuracy.
Tackling Lock Contention
Behind the high-speed transactions and seamless user experience of the XRP Ledger lies a complex and finely-tuned engine built for parallel execution and concurrency. A challenge in this architecture is lock contention, a performance bottleneck that arises when multiple threads try to access the same resource at the same time. “For instance, where appropriate, we may adopt lockless techniques to help mitigate or eliminate some of these problems,” he stated.
The XRPL engineering team is employing advanced profiling tools, including eBPF (Extended Berkeley Packet Filter), to trace and understand where in the code lock contention is occurring while offering precise, low-overhead insights into system behavior at runtime, essential for optimizing real-world performance.
Upgrading XRPL’s Testing
As new features are added and performance is optimized, Ripple’s engineers are redefining how they test the XRPL codebase, not just in the lab, but in real-world conditions. Testing is no longer just about ensuring that code works; it’s about proving that it keeps working reliably in a decentralized, dynamic, and often unpredictable network.
A key breakthrough is building a next-generation testbed platform that mimics actual-world conditions more accurately than typical lab tests. This approach enables the identification of bugs that only appear when there is real load and network conditions, which is impossible to model in labs.
For more elusive bugs, Ripple uses Antithesis, an autonomous testing and fuzzing platform. It aggressively mutates input data and simulates failures to uncover issues like deadlocks or crashes. Thanks to Antithesis, engineers have discovered bugs such as a missing ledger in SHAMap logic and a job queue deadlock, with several moderate-level bugs now under investigation. The upcoming 2.5.0 release should result in significantly lower memory and bandwidth use for node operators, and we will continue working on the other non-feature improvements to release as soon as they are ready,” Thomee concluded.