Update on the XRPL

By: Elliot Lee and Nik Bougalis, RippleX Engineering

Over the past several weeks, the XRP Ledger (XRPL) has experienced instability, a transient halt in consensus on November 3 and, over the last several hours, unusually high fees resulting in a large queue of transactions. The XRPL Foundation summarized many of these issues in a recent communication.

Essentially, the number of trust lines, tokens, and transactions on the network has increased dramatically (and the size of the ledger’s state has grown), so there is a corresponding need to scale to this growth that the community is now addressing.

Despite these challenges, the XRP Ledger is continuing to make forward progress because of the hard work of a number of dedicated ecosystem participants, such as the XRPL Foundation. In parallel, many in the XRPL community, including Ripple, are working to more thoroughly understand the issues and propose the best path forward.

Actions Toward a Solution

Since 2013, Ripple, along with others in the community, has contributed improvements to various components of the XRP Ledger and related technology—including on components such as rippled and xrpl.js.

The team has submitted proposed enhancements to the performance of the codebase that, after approval by the broader community, have already been adopted—including a set of changes that dramatically reduced the memory usage for servers. These fixes, which appeared in the 1.7.0 release, are already helping the network to cope with the increased load.

Prior to the recent instability, engineers were already working on several proposed changes that should help improve the scalability and performance of the XRP Ledger, but the events of the past few weeks have caused us to redouble our efforts. In the weeks ahead, our team will continue to work hard to identify performance bottlenecks and propose targeted improvements to fix issues.

Some of the things that we are going to propose include:

1. Making it easier to run rippled in Reporting Mode – a special mode that’s tailored to handling RPC and WebSocket client requests outside of the main rippled process and which can scale horizontally, making it possible to service more clients, more efficiently.
2. Working on “Project Clio,” which was presented at Apex, and is being designed to efficiently service RPC and WebSocket client requests.
3. Building profile-guided improvements that help eliminate lock contention, avoid resource starvation, and enhance I/O performance, all of which should make servers perform better at higher loads.
4. Proposing several protocol-level improvements, including changes to the binary representation of some objects like trustlines, which should result in significant additional memory savings, reduced overhead, lower bandwidth usage, faster sync times for servers, and less memory pressure for servers.

Call to Action

The XRP Ledger is an open-source, shared resource and no one party is responsible for it. Several participants in the community have already stepped up, with many going above and beyond. We at Ripple are also focusing engineering efforts on understanding and solving the issues, but as with everything on the ledger, it requires community effort and so we call on everyone in the XRPL community to contribute to the solution.

Numerous exchanges and other participants use the XRP Ledger. We also call on them to operate infrastructure in support of the network with the same care and diligence that they use in operating their other production environments.

We believe that the issues related to the rapid growth of the XRP Ledger are transient and, with the help of the broader community, will be solved, so that the Ledger will continue to get stronger as it grows.