A decentralized network, like the XRP Ledger (XRPL), has no singular authority that can make decisions for the network as a whole. Rather, it is the participants of the network who decide on matters, big and small, using whatever mechanisms and tools the network provides.
On the XRP Ledger, the primary mechanism of choice are amendments: changes to how transactions are applied, whether by introducing new features, enhancing existing functionality or fixing bugs, which are voted on by network participants. Servers independently tabulate votes and decide whether a particular amendment has enough support to become activated. If enough servers on the network vote in support for an amendment for two consecutive weeks, it is activated and the functionality that it was gating is now available.
In earlier iterations of the XRP Ledger software, servers would automatically vote in support of any amendments they understood unless server operators took additional steps to configure them to veto the amendment.
Newer versions, including the latest version 1.9.2, default to voting against new features, except for “fix” amendments that are squarely aimed at fixing bugs with existing functionality.
Whether the default vote is “yes” or “no” it is important for validator operators to independently assess the impact of individual amendments and to decide how to vote, using their own best judgement and the criteria that they deem important. With this post, we are looking to provide our own assessment of two new amendments and to explain how we decided how Ripple’s validators ought to vote.
ExpandedSignerList
The XRP Ledger has support for multi-signing, making it possible for accounts to be configured so that one or more signatures are required for transactions to be considered properly signed. The current implementations limits the number of possible signers to 8.
The ExpandedSignerList amendment, introduced by Richard Holland, increases the number of signers from 8 to 32 number and allows for some additional metadata to be attached to individual signer entries, which can be useful for signing and key management tools.
Generally, the number of accounts configured for multi-signing is a small percentage of all total accounts and fewer still are likely to need or use more than a few signers. As a result, the increase in the size of the ledger state, even when the additional metadata introduced with this amendment, is expected to be minimal.
Signature checking is expensive, and transactions which are signed by multiple signers are not only larger in size but more computationally expensive to verify, a cost shared among all servers on the network. This amendment is unlikely to directly result in more accounts using multi-signing and, as explained before, the number of accounts that will have more than few signers is expected to remain very low. As a result, the increased computational cost is expected to be minimal.
The increase in the number of signers may make it easier to support certain use cases where a large number of signers is needed; these are likely to include use cases around corporate treasures, exchanges and custodial services.
After evaluating the code and weighing the pros and cons of this amendment, Ripple has decided to configure its validators to vote in support of ExpandedSignerList. While we acknowledge a higher computational cost for a few transactions is likely, we believe it should not be a problem for the network.
NonFungibleTokensV1_1
NonFungibleTokensV1_1 is the latest amendment associated with XLS-20: Ripple’s proposal to bring native, NFT (non-fungible token) support to the XRPL. We've written about XLS-20 before and have even published our own performance test results.
Broadly, the introduction of XLS-20 will enhance the XRP Ledger's capabilities, making it possible for NFT-based use cases to be developed. The new functionality is expected to grow the state of the ledger as more items will have to be tracked and more transactions executed. While the authors of the XLS-20 specification tried to minimize the overhead of each individual NFT, the overhead is still significant. In addition, the built-in NFT DEX introduces additional overhead.
Our previously published test results show that processing NFT-based transactions is less efficient than processing direct XRP payments (not surprising, as direct XRP payments are the simplest operations by design) but our testing and experience suggests that the code is able to handle transaction rates significantly higher than those presently seen on the XRP Ledger.
Still, activation of the NonFungibleTokensV1_1 amendment will likely result in increased transaction throughput and grow the ledger state, potentially significantly. Some servers (especially those that are running on systems that don’t meet the recommended requirements) might feel the effects of activation more strongly. Generally, servers should be configured with a very fast SSD and plentiful RAM.
One additional consideration when it comes to the NonFungibleTokensV1_1 amendment is the excitement over the introduction of this functionality. Several projects, some of which have partnered with Ripple, have publicly committed to issuing NFTs on the XRP Ledger. Most are primarily targeting entertainment or collectible use cases, but others are looking to NFTs to support utility use cases such as carbon credits, item provenance, gaming and more.
After evaluating the code and weighing the pros and cons of this amendment’s potential impact on the XRP Ledger, Ripple has decided to configure its validators to vote in support of NonFungibleTokensV1_1. We are confident in the network’s readiness to XLS-20 and the potential new use cases it can inspire as a result of the work being done by much of the community, and their public commitment to XRPL-native NFTs. We do recognize that some operators may have concerns and appreciate their conservative, considered and careful approach.
Ripple will also continue to run performance tests to help refine our and the community's understanding of this amendment’s potential impact. We will also continue to devote engineering resources to develop and contribute performance enhancements aimed at offsetting the additional growth in ledger state, transaction throughput and load that is expected to accompany activation of NFT support.
Closing thoughts
While this post intends to shed light on Ripple’s voting decisions, we take no position on how other validator operators should vote when it comes to the adoption of any amendment.
But we do believe that the amendment process is important and plays a crucial role in guiding the XRP Ledger’s continued evolution. Because of that, we believe that validator operators ought to be active and engaged participants in the amendment process and urge them to evaluate, using the criteria that they believe to be important, proposed amendments.
Casting a Ballot
To vote in favor of a particular amendment, the command to execute is:
/opt/ripple/bin/rippled feature NAME accept
To vote against a particular amendment, the command to execute is:
/opt/ripple/bin/rippled feature NAME reject
Questions, comments and healthy debate are encouraged in the comments below.
Follow @RippleXDev on Twitter.
Top comments (0)