Since 2012, Ripple has been committed to advancing the XRP Ledger as an open, decentralized system for payments. We have worked together with the community to dramatically increase the decentralization, performance, and feature set over the last seven years.
Ripple’s vision for the XRP Ledger is for it to continue to provide the best interoperability with Interledger. Key to this vision is for the XRP Ledger to remain best in class in security, performance, and settlement features.
We’ve been working on a number of possible features and design changes that could be introduced to the XRP Ledger, and we want input from the entire community about these features. How helpful are they to the use cases that the community is currently pursuing? What changes are developers and contributors to XRP Ledger interested in implementing?
Today, we are posting descriptions of many possible enhancements to the XRP Ledger. They fall broadly into three categories:
Consensus: Consensus is the heart of the XRP Ledger. It’s the way the ledger makes forward progress in a decentralized way. While PoW has provided only limited decentralization and appears to be a technological dead end, distributed agreement algorithms such as the XRP Ledger’s consensus algorithm provide real decentralization and continue to improve in their performance and reliability, year after year. Several of the suggested enhancements focus on improving the robustness of the XRP Ledger’s consensus mechanism.
Performance and Resource Consumption: Due to the nature of public ledger systems, every on-ledger transaction imposes some resource costs on every participant. This creates a trade-off where increasing the transaction rate and lowering transaction fees can increase operational costs and drive some participants out of the ecosystem. Keeping resource consumption down increases the set of participants who can run their own server nodes, improving decentralization. Some of the suggested improvements aim to increase our understanding of the software’s resource consumption, reduce the consumption of bandwidth and memory, and improve network reliability.
Features: The XRP Ledger currently has a sophisticated feature set including account management features, powerful multisigning, a decentralized exchange, and best-in-class support for off-ledger scaling. However, there are always more things it could do. The suggested improvements in this category add new capabilities such as an XRP-collateralized stablecoin and ways to ease the burden of the 20 XRP account reserve.
We would appreciate members of the XRP Ledger community looking over these suggestions and providing feedback. Suggestions for other features are welcome as well. Let’s build a roadmap to continue innovating together.
Consensus:
Play Forward Ledger: Currently, when a server loses sync with the network, it has to simultaneously try to re-synchronize with the network and fetch all the ledgers it missed. The current design requires the server to first synchronize with the network and then work backwards to fetch what it missed but then work forwards to rebuild any missing intermediary ledgers.
We propose that the design be changed to support a fetch operation that fetches a ledger’s header and all the transactions in the ledger in order. This will allow a server to play forward from the preceding ledger to the queried ledger with minimal network traffic. When a server loses synch, it can then collect validations to determine the ledgers it needs to go forward from its last-validated ledger to the current ledger.
This has three advantages. First, it provides greater protection from hostile majority attacks because the server only obtains full ledgers by building them locally. Second, it allows the server to conserve network and CPU resources by only having to play the ledgers forward, rather than backwards and then forwards. Third, it reduces the load the server places on other servers and permits it to stop being a burden and resume helping other servers more quickly.
Robustness Improvements: By deliberate design, the XRP Ledger rejects the robustness principle. Instead, when it is unclear whether safe operation is possible, the XRP Ledger does not operate. Fortunately, the circumstances under which safe operation are not possible have never happened in the production network and the greater reliability and peace of mind has proven to be at minimal cost.
However, this does mean that the number of validators that must fail for the network to stop making forward progress can be fairly low. This requires people to set a high bar for validators they choose to listen to. But keeping the bar high hinders decentralization as the set of candidate validators shrinks to those who are well-funded or committed to rapid response to failures and downtime.
We propose a design change to improve the network’s reliability in the face of failed validators and ease the trade-off of wanting diverse validators but having to insist on very high quality and response readiness to avoid the risk of a network halt. The idea is as follows:
- In the ledger would be a list of validators that are believed to be unreliable at the moment.
- That list would be maintained by the validators using the same mechanism they use to maintain the network fees and amendments.
- If a validator is in that list, it would still participate in consensus in precisely the same way. The list would have no effect on the consensus process whatsoever.
- The decision when to consider a ledger fully validated would be adjusted so that servers in the negative UNL list would not count towards the 80% threshold.
Imagine a network where everyone has the same UNL and consider what happens if validators start to fail. Without this proposal, as soon as 20% of the validators fail, the network would stop making forward progress. With this proposal, as validators fail, the remaining validators would add them to the list of validators believed unreliable. This would mean the network could keep making forward progress safely even if the number of remaining validators gets to 70% or even slightly lower.
Two-layer consensus: Today, the network uses a single consensus process to both make forward progress from ledger to ledger and to coordinate network rule and fee changes. Because the consensus process provides a high degree of decentralization, it has some trade-offs in performance, traffic levels, and the number of validators that can be tolerated.
We propose to switch to two separate consensus layers. One would exclusively advance the ledger. The other would handle fee changes, coordinate rules changes, and manage the participants in the first layer.
With this design, a small set of validators selected by the larger set of validators would ensure the network makes reliable forward progress and does not engage in censorship. The larger set of validators would police the smaller set to ensure they are in fact making progress and are not censoring. Any validators in the small set that are not behaving would be voted out by the large set.
This design has a number of advantages. The network can continue to make forward progress so long as either consensus layer is working. The set of validators preserving decentralization can be made larger without increasing the amount of work that must be done to generate each new ledger. Poorly-performing validators can continue to help keep the ledger decentralized without slowing down the advancing of the ledger. Validators engaging in censorship or poor service could not affect the advancing of the ledger as they would be voted out by the larger set.
Performance and Resource Consumption:
Memory consumption: The XRP Ledger software does use quite a bit of memory. This is especially a problem on virtual machines where memory has a significant cost premium. Reducing the memory consumption would reduce the cost to run the software and improve decentralization indirectly.
Unfortunately, we do not precisely understand how the memory is being used. An important first step would be to analyze the software’s memory consumption to see what areas of improvement would be likely to produce the most dramatic results. On the bright side, because this hasn’t been well-studied, it’s possible that there’s some low-hanging fruit where small efforts could bring large payoffs.
The software does do a lot of caching. For example, some data is cached both in raw binary form (typically as SHAMapEntry’s) and in object form (typically as STObject’s). It may be sufficient to cache only in binary form and convert to object form as needed.
In addition, the SHAMap design pegs lots of SHAMapEntry’s into memory. This design could be changed to only keep SHAMapEntry’s in the cache and fetch them from disk as needed. Code changes would be needed to prevent SHAMap’s from keeping too many strong pointers to SHAMapEntry’s.
Reduce relaying: The XRP Ledger currently uses flooding to propagate transactions, proposals, and validations. This means a typical server either receives, transmits, or both every one of these objects over every connection that it has. This has a large number of disadvantages:
- Adding additional server connections means a significant increase in bandwidth consumption.
- Lots of messages are relayed unnecessarily costing both CPU and bandwidth on both sides.
- The network diameter is larger than it needs to be.
- Link latency is higher than it needs to be, making it harder for a server that has lost sync to catch up.
We propose a system of slots and “squelches”. Each server would create a “slot” for each validator it chose to relay. Each slot would have a list of uplinks and downlinks. When a server receives a proposal or validation message, it would check the “slot” for the validator that originated it. If it had already received enough copies of that message, it would send a “squelch” to the sender of that message which would suppress further messages from that source being sent to it over this connection. When a server gets a “squelch” it would add the sender to its list of non-downlinks for the corresponding slot.
This would allow each server to maintain a set of three uplinks for each slot. If a server lost an uplink, it could send an “unsquelch” to each server to recover its uplink. Squelches would be time limited to allow for network topology changes.
This approach requires some tweaks for transaction. Every validation from the same validator comes from the same source and so can follow the same tree to spread over the network. But transactions can originate anywhere. To handle transactions, they can simply be relayed both up and down the tree. So while validations and proposals would only be sent to your downlinks, transactions would be sent to both uplinks and downlinks.
This change will allow servers to have more connections, reducing network diameter. CPU and bandwidth costs would be reduced and link latency would be significantly improved.
NetDB: Every XRP Ledger servers has a database called the “node db” that holds all the ledger entries in the current ledger and that the server has chosen to retain as history. Even if you have a cluster of servers, each one has its own node database. If a server loses sync, it cannot keep populating the node database and has to fix what it missed as and after it catches up.
We propose implementing a network protocol for access to a node database. This would permit servers to share a node database. This will conserve disk space, conserve memory, and allow a server that loses sync to obtain the data it missed locally if another server that stayed in sync populated the database for it.
This is a bit more complex than it might appear because the software is very sensitive to latency in accessing the node database. This means that sophisticated caching and prediction is needed on both sides. For example, if the software fetches an inner ledger node, the database should probably push all the direct children of that ledger node to the server’s cache to avoid an additional round trip.
XRP Ledger nodes do not need to trust their node store because they only query by hash. It is not possible for a node store to convince a server to rely on incorrect information. This means that the XRP Ledger software could be enhanced to use a variety of methods to obtain ledger data to reduce local storage requirements and improve synchronization performance.
Logging and Monitoring: The XRP Ledger has both statistics reporting and logging by category and severity. However, it has been neglected for some time. The statistics reporting could use a refresh to ensure that it is capturing parameters that are useful and valuable and to add monitoring of newer features that were added without such reporting. The logging needs a thorough audit to ensure that priorities are set appropriately and overly-chatty logging is disabled by default.
Features:
Transaction Fee Tracking: It can sometimes be difficult to choose the right fee to pay for an XRP Ledger transaction. A common approach is to pick a value known to be large enough, such as .0001 XRP, and just using that all the time.
We propose adding code to the server to keep track of when a transaction is first observed and what fee level it chose to pay. Then, when the transaction is seen in a fully-validated ledger, the server can update its statistics for transactions at that fee level. Thus the server could report, at any time, the fraction of successful transactions and the average confirmation time for various fee levels.
In addition to being useful for choosing the fees to pay for a transaction, this would also gather interesting statistical information.
XRP-collateralized stablecoin: One of the original use cases for the XRP Ledger (since 2012) was using the built-in decentralized exchange to exchange between stablecoins and to exchange stablecoins for XRP. Currently, only stablecoins that have a backer/issuer are supported.
We propose adding a collateralized stablecoin feature to the XRP Ledger. The key distinguishing property of this proposal is that the stablecoin is always redeemable for XRP on the ledger from the collateral pool. So, for example, if you hold one unit of a USD stablecoin, you can make on-ledger payments at any time just as if you held $1 worth of XRP.
We propose a scheme as follows:
- Anyone may place XRP into a position that they own.
- If the position is sufficiently collateralized, it may issue a stablecoin.
- Position owners may adjust the XRP in their positions so long as it maintains sufficient collateral.
- Position owners may issue and redeem stablecoins in their positions so long as it maintains sufficient collateral.
- Severely undercollateralized positions may be taken over by re-collateralizing them — whoever does so keeps the remaining excess collateral.
- An order book mechanism will be used to permit the stablecoin to be automatically exchanged for XRP by redeeming against the least collateralized positions first.
- This encourages over-collateralization and cleans up positions that are in danger of becoming under-collateralized
- Pathfinding will be augmented to use redemption against the collateral so payments with a stablecoin work the same as if you held the corresponding amount of XRP.
The scheme is not perfectly decentralized because some organization or federation still must supply the price the asset is pegged to on a continuous basis or the stablecoin will freeze. That organization can set a reserve ratio that they can use to tax the stablecoin system or to provide a reserve to buy out under-collateralized positions.
The most obvious application is a stablecoin pegged to a fiat asset such as the dollar. However, stablecoins can also be pegged to the value of precious metals, stocks, indexes, and so on.
DeFi Support: Some enhancements could be made to the XRP Ledger to provide better support for emerging use cases in decentralized finance. For example, validations could be augmented to include the last fully-validated ledger. This would permit validators to automatically operate as oracles and allow, for example, users to prove to Ethereum smart contracts that particular things happened on the XRP Ledger.
Checks: Most public ledgers provide no way to refuse an unwanted incoming payment. While most people would be perfectly happy to receive an unexpected, possibly misdirected, payment, it can create a real problem for some users. Regulatory requirements may make returning the payment difficult but they may also make keeping the payment difficult.
We propose adding a feature to allow recipients to actively accept payments. We dubbed the feature “checks” internally. A sender can, instead of making a payment, create a check payable to a recipient. The recipient would have to actively claim the check.
Users who do not want to receive unrequested payments could set their account to only accept checks. They could then simply not accept any unwanted payments. A whitelist of accounts permitted to send directly could be offered. Checks can also be used if the sender is not positive that the receiver still has access to the account. If the check is not cashed within some time period, the sender can cancel it and ensure the funds do not leave their account in the future.
Deletable Accounts: The 20 XRP reserve requirement has proved to be a bit of an obstacle to some use cases for the ledger. This proposal would provide a path to delete existing accounts, recovering all but one incremental reserve (currently 5 XRP). This would also allow owners of unwanted accounts to clean them up and recover approximately 15 XRP in the process.
There is a judgment call involving what to permit an account to have and still be deleted. In principle, you could allow an account to be deleted regardless of what ledger objects it owned and clean up any problems after the fact. For example, if code later encountered an order, trust line, or escrow for a non-existent account, it would simply handle it appropriately at that time. Orders, for example, would be deleted when discovered to be orphaned. However, that’s probably not optimal. It’s probably sensible to require that some amount of cleanup be done prior to allowing an account to be deleted.
In addition, all code that looks up accounts for trust lines, offers, escrows, and the like must be carefully audited to ensure it sanely handles a non-existent account. Due to the severe harm aberrant behavior could cause to those relying on the ledger, this audit is essential even if the implementation intent is that an account cannot be deleted while those objects exist.
Light Accounts: Light accounts would allow a limited account to be created without having to pay the 20 XRP reserve. Instead, a 5 XRP reserve would be paid. Light accounts would be limited in their function but they could certainly hold, receive, and send XRP.
There are some options around what features a light account would be permitted to access. Light accounts could be permitted to have a single multisigner list or they could be permitted to have a small number of payment channels or escrows. Likely they would not be permitted to have any trust lines or offers.
We’ve outlined these improvements as a starting point to engage the community and gather feedback on which ones will bring the highest value. Ripple is committed to developing the XRP Ledger in cooperation with the broader community and your feedback will determine how we build our vision and prioritize resources.
