DEV Community: Nik Bougalis

XRPL Amendments: To Vote or Not to Vote?

Nik Bougalis — Wed, 17 Aug 2022 05:26:04 +0000

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.

rippled 1.9.2: Bug Fixes & XLS-20 Amendment Voting

Nik Bougalis — Tue, 26 Jul 2022 03:03:00 +0000

Greetings 🖖

Version 1.9.2 of rippled (the reference implementation of
the XRPL protocol) was just released with several key changes, including fixes for bugs identified with the initial implementation of the XLS-20 spec that introduces support for Non Fungible Tokens (NFTs).

The XRPL validator community can now confidently vote on
XLS-20—Ripple's proposed standard to bring native NFTs to the XRP Ledger (XRPL).

New in 1.9.2

The 1.9.2 release aims to correct or rectify issues that developers and server operators identified with earlier releases, such as:

A race condition in the shard code that could result in a server crash. This issue would only affect servers configured with sharding enabled, which is currently experimental and not recommended for production.
A race condition while handling an operator-requested shutdown request could result in the server stalling and hanging instead of shutting down.
In rare cases, an exception would be thrown from a code path that did not install an exception handler, abruptly shutting down and potentially resulting in database corruption.
An incorrect SQL query during startup could result in an apparent failure to persist amendment votes across restarts, even though the vote was properly persisted.
A failure to properly sanitize certain JSON inputs early could result in unexpected errors in code that made assumptions about the data contained in the JSON object.
Although extremely unlikely to manifest in practice, a bug in the low-level spinlock code could cause the same SHAMapInnerNode child list to lock under some circumstances repeatedly.
Improper error checking could allow for the creation of an offer to acquire an NFT that would see the user offering the NFT for sale to pay the user accepting the offer; this fix introduces a fix amendment, fixNFTokenNegOffer.
Improper range checking during parsing of HTTP and HTTPS URLs could fail to properly detect invalid port numbers.
Failure to honor the network_id configuration parameter.

XLS-20 Voting

The XRP Ledger uses an on-ledger voting mechanism to allow network
participants to vote on amendments to the protocol.

One such amendment is NonFungibleTokensV1 which is being actively voted on. Unfortunately, the discovery of bugs in that amendment
has necessitated the introduction of two fix amendments: fixNFTokenDirV1 and fixNFTokenNegOffer, complicating the path toward activation of the XLS-20 standard as the fixes need to activate before the NonFungibleTokensV1 amendment.

While the maintainers of the software take no position on how operators should vote when it comes to the adoption of the XLS-20 standard, the 1.9.2 release introduces a new amendment, NonFungibleTokensV1_1, which combines and supersedes the existing NonFungibleTokensV1, fixNFTokenDirV1 and fixNFTokenNegOffer amendments, simplifying voting and reducing the possibility of accidentally activating amendments out of order. The NonFungibleTokensV1, fixNFTokenDirV1 and fixNFTokenNegOffer amendments continue to be available and open for voting but should be considered deprecated.

Building for the XLS-20 Community

As we previously shared, Ripple has conducted testing and configured its validators to vote in support of activation of XLS-20. Ripple's validators will begin
voting for NonFungibleTokensV1_1 and against the NonFungibleTokensV1, fixNFTokenDirV1 and fixNFTokenNegOffer once upgraded to the 1.9.2 release.

We are confident in the potential XLS-20 can bring to several projects and businesses in the XRPL community. Some of the many projects dependent on native NFT support include:

If activated, XLS-20 would bring native NFT support to the XRPL, providing developers and community projects access to NFT minting, trading and burning functionality. XLS-20 also supports advanced features like automatic royalties.

XRP Ledger server operators are encouraged to upgrade to version 1.9.2 within two weeks to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.

^{As with all proposed amendments, Ripple recommends that XRPL validators do their due diligence before voting. Visit my previous blog to learn more about the XRP Ledger's amendment process.}

Ensuring Stable, Performant NFTs on the XRP Ledger

Nik Bougalis — Wed, 06 Jul 2022 00:43:11 +0000

In May, Ripple configured its validators to vote in favor of activating the XLS-20 amendment on the XRP Ledger (XRPL). In reaching that decision—and building on our ongoing commitment to the XRPL’s health and performance—we conducted extensive testing to determine the XRPL’s capacity to support the extra transaction load brought about by native, on-ledger NFTs at scale.

This post outlines the results of that performance testing supporting the 1.9.1 release of rippled, the reference server implementation for the XRP Ledger. Performed in a distinct environment completely separate from any other XRP Ledger network, our testing sought to determine the peak throughput sustainable by the XRPL against particular workloads, such as native NFT transactions.

The Test Environment

The test environment consisted of 9 servers in a single Amazon Web Services region. Five of these servers were configured as validators, and the remaining 4 were configured to receive traffic from a load-generating benchmarking program located on a separate host. The hardware type for each host was EC2 type z1d.2xlarge, which has specifications roughly in line with those recommended for production: 8 CPU cores, 64GB RAM, an 8GB root volume and 300GB of ephemeral storage. The only significant deviation is the network interface, which is 10Gbps instead of the recommend 1Gbps.

The rippled configuration on each host had the following baseline characteristics (except where noted for specific tests):

Data and logs stored on ephemeral storage
The [node_size] is set to huge
The primary database type is NuDB
The NonFungibleTokensV1 feature, which is the amendment that adds XLS-20 support is enabled.
Fee escalation is minimized by using the following configuration file stanza:

[transaction_queue]:
minimum_txn_in_ledger = 4294967295
target_txn_in_ledger = 4294967295
normal_consensus_increase_percent = 4294967295

The test framework is a custom set of tools able to submit transactions of various types at configurable rates. Each test begins with an initial ramp-up period which settles at a fixed initial rate of submission. That fixed rate is maintained for a configurable period of time and then increased by a configurable amount—this cycle continues until a maximum configurable rate is reached. When the test finishes, a report is generated which measures the peak sustained transaction commit rate. This is the peak per-minute value that was sustained for at least 20 minutes during the test. This value can then be divided by 60 for a per-second rate.

The ledger data for each test is based upon a snapshot of the livenet ledger number 70,637,016. This ledger was created on March 29, 2022. The reason for basing tests on this ledger is to simulate the workload on a data set that is similar to the live environment. For each type of workload, additional accounts are created. The test framework randomly chooses sender and receivers among these additional accounts. The types of workload tested were:

XRP payments
NFT minting
NFT offer + buy or sell
Mixed XRP payments and NFT offer + buy or sell

Test Results

The following tests were based on rippled version 1.9.1-b1, with the initial test measuring sustained throughput for XRP payments. Doing this required 20,000 accounts be created—in addition to those already existing from the snapshot of ledger 70,637,016. A random sender and receiver were chosen from these 20,000 accounts for each transaction submitted during the test. The peak sustained throughput was 2,199 transactions per second.

The next test was configured identically except for the node_database type—which was RocksDB contrasted with NuDB in the previous test. Peak sustained throughput was 1,940 transactions per second. All remaining tests used NuDB.

The next test measured NFT throughput. One million accounts were created in addition to those in the snapshot of ledger 70,637,016. Each account minted 20 NFTs, meaning a total of 20,000,000 NFTs on the XRP Ledger. The test randomly selected an NFT and created an offer against it. The offer was then accepted, with each offer and acceptance constituting a single transaction. To clarify, each NFT offer and acceptance resulted in a pair of transactions. The maximum sustained throughput rate for this workload was 751 per second.

The next test measured a mixture of XRP payments as well as NFT offers and acceptances. The precise mixture was 2 XRP payments for each NFT offer and accept transaction pair. The throughput for this test was 1,064 per second.

The final test—around NFT minting—was based on the livenet ledger 70,637,016 snapshot for which 20,000 additional test accounts were created. Each transaction randomly selected a test account and minted an NFT on it. The maximum sustained throughput of NFTs minted this was 384 per second.

Test Description	Transaction Throughput
XRP Payments (20,000 accounts, with NuDB)	2,199 TPS
XRP Payments (20,000 accounts, with RocksDB)	1,940 TPS
NFT Minting & Trading (1,000,000 accounts, 20,000,000 NFTs, with NuDB)	751 TPS
XRP Payments & NFT Trading (NuDB)	1,064 TPS
NFT Minting (20,000 accounts, with NuDB)	384 TPS

Conclusions

The aforementioned tests are based on synthetic workloads in an ideal environment. Factors that likely affect performance, but which were not tested this way, arise from the live network having hundreds of nodes distributed across the world running different types of hardware. By comparison, the test only had 9 rippled nodes (5 validators) operating in a single site. In addition, there is a continuous flow of existing transactions not tested above—particularly trustline creation and order book manipulation.

Despite the effort to minimize the overhead of XLS-20 based NFTs, NFT transactions are more computationally intensive to process compared to simple XRP payments. This was expected, primarily because more ledger objects are manipulated when processing NFT transactions as opposed to payments, which only manipulate two objects: the accounts of the sender and the recipient.

Database Backend Recommendations

The test results emphasize a need for high-performance disk I/O and strongly suggest that node operators should consider switching away from RocksDB in favor of NuDB.

While previous testing suggested that RocksDB performed better in nodes configured to maintain small amounts of ledger history, that performance advantage is no longer present. The data suggests that NuDB—coupled with a high-performance solid-state storage—is the better solution for all node types, whether full-history or not. In particular, during these NFT tests, NuDB exhibited not only better performance but a lower memory footprint than RocksDB did.

To learn more about XLS-20, follow RippleX on Dev.To or Twitter.

Ripple Validators Vote in Favor of XLS-20 Amendment

Nik Bougalis — Mon, 23 May 2022 21:28:15 +0000

Today, Ripple is upgrading its servers to the recently released version 1.9.1 of rippled, the reference implementation of the XRP Ledger (XRPL) protocol, and configuring its validators to vote in favor of activating the XLS-20 amendment on XRPL Mainnet.

Ripple proposed XLS-20 last May to bring native NFT support to the XRPL and provide developers access to NFT minting, trading and burning functionality. XLS-20 also includes advanced features like automatic royalties, co-ownership of assets and more without the need for smart contracts.

What’s New

In line with Ripple's previous commitment, we conducted extensive testing to ensure that the NFT code is stable, scalable and performant in the face of the additional transaction volume anticipated by native, on-ledger support for NFTs. As a result of that testing, we feel confident that the XRPL can support the extra transaction load at scale.

We plan to share the results of our testing in the coming weeks so server operators can better understand the performance characteristics and resource requirements of the server software in a world where XLS-20 is activated.

Included in the 1.9.1 release are fixes to address syncing difficulties, as well as several improvements, including:

The fixNFTokenDirV1 amendment, to fix a corner case that could result in a potential off-by-one error when determining which page an NFT object belongs on.
The ExpandedSignerList amendment that would expand the maximum number of signers on an account from 8 to 32 to enable more advanced use cases. Additionally, this amendment allows each signer to have an arbitrary 256-bit data field that can be used by external code.
Improved Memory Efficiency of Pathfinding: Code improvements that reduce the memory footprint of pathfinding operations by discarding trust line results that cannot be used before those results are fully loaded or cached.

XRPL Amendments: The road to XLS-20

Activating an amendment to the XRPL Mainnet is not up to a single entity, operator or server. The amendment process requires broad network agreement for an extended period. The default for proposed new feature amendments—including the XLS-20 standard—is set to vote “No.”

By design, this allows validators time to review proposed amendments before deciding whether to vote in favor of enabling them. If either of the two amendments introduced in the 1.9.1 release reaches and maintains the requisite 80% support, servers running on previous versions will find themselves amendment blocked. To ensure service continuity, server operators should be prepared to upgrade to a version of the software that includes support for amendments that have gained majority support.

As with all proposed amendments that introduce new features, Ripple recommends that XRPL validators do their own due diligence before moving forward and voting to enable XLS-20.

To further address the scalability and performance of the network, Ripple continues to work on the open-source Clio project as part of our ongoing commitment to developing best-in-class tools and building on top of open protocols.

For anyone interested in experimenting with XLS-20 and exploring the NFT capabilities it introduces, Ripple is operating an NFT-Devnet. All are welcome to explore NFT-Devnet, which demonstrates the performance characteristics and implications of the proposed XLS-20 standard without compromising the performance of the XRPL Mainnet.

To learn more about improvements and new functionality in 1.9.1, visit www.xrpl.org.

Announcing the Latest XLS-20 Release to Enhance NFT Functionality on the XRPL

Nik Bougalis — Fri, 29 Apr 2022 20:41:28 +0000

Earlier this month, version 1.9.0 of rippled was released with key contributions from RippleX, including XLS-20 and performance improvements to enhance network stability.

XRPL’s Built-In NFT Functionality
First publicly put forward last May, XLS-20 is a standard proposed to enhance NFT support on the XRP Ledger (XRPL). XLS-20 provides developers access to essential NFT functionality, such as minting, trading, and burning. Along with operations to enumerate, transfer and hold these tokens, other advanced features like automatic royalties (which enable more sophisticated royalty structures for creators) and co-ownership of assets are also built into the proposal.

Enhancing NFT functionality on the XRPL will likely bring a significant increase in transaction volume. As a responsible participant in the XRPL community, Ripple validators have been configured to vote “no” on the XLS-20 amendment until we feel confident in understanding the impact of NFTs on XRP Ledger Mainnet. In the meantime, we are conducting rigorous performance testing to assess the implications of additional transaction load on the XRPL and eliminate potential bottlenecks. Our team will share our results with the broader community once completed.

The XRPL is a public decentralized blockchain, and proposed amendments to the network require 80% of validators to vote in favor of the amendment before new code can be implemented on the mainnet. Though Ripple validators will vote “no” for now on the XLS-20 amendment, RippleX engineers have proposed it in the meantime to present it to the community, enabling developers to test NFT functionality and ensure a seamless user experience long-term by reducing the probability of merge conflicts later on.

Release Highlights: Performance and Stability Improvements

As part of our ongoing commitment to helping maintain the health of the XRPL, a number of performance improvements were included in XRPL 1.9 including: reduced memory usage for pathfinding, optimized trust line caching, and increased network efficiency and stability.

Also introduced were improvements to ledger-fetching logic, lock decongestion, and limited lock-free programming capabilities.

The Road Ahead

The features in this latest release are proposed and operated by XRPL server operators which demonstrates a shared commitment to improving the XRPL’s performance and innovation.

We remain committed to developing best-in-class functionalities, tools and open protocols that help developers scale and build utility on the XRP Ledger.

To learn more about improvements and new functionality in XRPL 1.9, visit www.xrpl.org.

RippleX releases XLS-20 dev network: NFT-Devnet

Nik Bougalis — Tue, 11 Jan 2022 03:23:48 +0000

In May, RippleX invited the developer community to provide feedback on our proposal to enhance NFT support on the XRP Ledger (XRPL).

We believe crypto and blockchain are powerful levelers in unlocking access and equity for everyone. The rapid rise and growth of non-fungible tokens – or NFTs – is key to that vision. On track to surpass $17B in global sales by the end of this year, it’s clear that NFTs are here to stay with many in the industry already building toward a tokenized future that allows new business models to prosper and people to engage more deeply with the communities and things they care most about.

Today the NFT-Devnet is available, making it possible for all developers to learn about and experiment with the native NFT capabilities introduced with XLS-20d. Developers are welcome to start building apps and tokenization use cases, as well as visit the Technical Tutorial page to get started.

The NFT-Devnet: Getting Started with NFTs on XRPL

Non-fungible tokens serve to encode ownership of physical, non-physical or purely digital goods, such as works of art and in-game items.

The XLS-20d proposal introduces extensions to the XRP Ledger that would support a native NFT type, along with operations to enumerate, transfer and hold such tokens. With XLS-20d live on XLS-20 Sandbox today, developers can access all essential NFT functionality including minting, trading, and burning. Moreover, advanced features like automatic royalties, which enable more sophisticated royalty structures for creators, and co-ownership, which expands access possibilities to assets, are also built into the proposal.

The NFT-Devnet is a beta environment where developers can preview, test and experiment with XLS-20d on XRPL before it is enabled on the Mainnet.

As this is the first time developers can mint native NFTs on the XRP Ledger, an interactive Technical Tutorial in the documentation on xrpl.org can help them get started. We also encourage developers building NFT projects – or wanting to get started with NFTs – to apply to the XRPL Grants program.

Community Spotlight: Carbonland Trust

RippleX is just one contributor to the XRPL – there’s a whole community of independent developers building on it today for its inherent performance advantages and tokenization capabilities. One such project is Carbonland Trust, which is pushing the boundaries for potential NFT uses.

Earlier this year, Ripple launched the XRPL Grants program – an initiative to engage, fund and support the independent developer community and their technical projects built on the XRP Ledger. Carbonland Trust is one of more than 20 projects to receive funding through the program, focused on protecting forest land with their CO2 Removal Bonded NFTs and Conservation Certificates. The project centers on creating the first CO2 Removal Credit Yielding NFT, a carbon credit producing digital asset and forest conservation DeFi protocol. In addition, the project includes CO2 Bonds which offer businesses and individuals a better way to remove CO2, hedge against rising carbon credit prices, and lock in a stable, long-term supply of high-quality offsets.

Carbonland Trust is one of many projects funded through the XRPL Grants program that will build on the XRPL XLS-20 Sandbox environment.

Experimenting on the NFT-Devnet

We’re excited to bring our proposal for NFT capabilities to life on the NFT-Devnet, a test network with feature-functionality that will look exactly like the primary Devnet. This is a first step toward our vision of enabling developers to build apps that leverage the XRP Ledger’s native tokenization capabilities.

While the RippleX team is excited to contribute to NFT technology on the XRP Ledger, our engineers–along with others in the community–are also contributing to its stability and scalability. As such, XLS-20d will initially be released on the NFT-Devnet in order to allow developers to test NFT capabilities, and server operators to understand the performance characteristics and implications of the proposed changes without compromising the performance of the XRPL.

Following today’s release, we invite the XRPL developer community to visit the Technical Tutorial page. Feel free to comment and/or ask your questions below.