Ripple: The Most (Demonstrably) Scalable Blockchain

Blockchain technology such as Ripple’s XRP Ledger is signalling a fundamental transformation to the world’s financial systems. The XRP Ledger is suitable for real-world payment workloads, in real time. After describing the contrast in technologies between Ripple’s and legacy payments systems, this document will describe how Ripple’s capacity was tested.

In production since January 1, 2013, the XRP Ledger has been transferring value between many cryptocurrencies worldwide at next-to-no cost and within just a few seconds. Further, the technology has been tested to support 1500 per second with machines spread across the globe.

The XRP Ledger shares the fundamental attributes of traditional core payments systems—after all, the basic requirements for electronic transaction processing have been well understood for decades. All transactions exhibit ACID properties. All operations are written synchronously to multiple sites to protect against site failure. Software upgrades and all maintenance activities happen without service disruption. In fact, the network has had no downtime throughout 2016 and to date in 2017, as well as no hacks! Ripple has implemented these features to the ledger in a radically different way than other existing payments systems to make it faster, cheaper, and easier to send money worldwide, setting it apart from other blockchain networks in the market.

Legacy payment networks are powered by proprietary software running on very specialized and expensive hardware, such as mainframe systems. Processing in these legacy networks usually happens within a primary site with transaction data replicated to a secondary facility. There are a few challenges with this: site failover is error-prone; operational procedures are complex; And legacy payment networks are centralized and extremely expensive to build and operate. Moreover, there is a patchwork of closed, expensive networks built on old technologies spanning the globe, which contributes to high cost per transaction and slow delivery times  -often costing several dollars and taking many days to move funds between nations. For domestic transactions, this cost is hidden from consumers. But credit card transactions often cost merchants at least 2% per transaction, and the amount of time taken for the merchant to get their money can take days.

In contrast, rippled, the open source reference implementation of the Ripple Transaction Protocol, runs on commodity x86_64 hardware platforms. rippled nodes worldwide share all transaction data in real time and processing happens on all nodes concurrently. There are few operational requirements beyond providing sufficient hardware and network capacity. Transaction costs are paid with a digital asset called XRP and Ripple transactions usually cost the equivalent of less than one US penny. The Ripple Network does for money what the Internet does for information: makes it easy and instant to transfer. The XRP Ledger is the most scalable blockchain-based payments system and its performance rivals that of legacy providers.

Benchmark Environment

Ripple is a peer-to-peer network that implements the Ripple Protocol. Every peer independently processes transactions submitted to the network. Each node relies on a set of trusted peers, called “validators”, for determining the status of the official ledger. Funds are transferred by way of submitting transactions which are then applied to the ledger. The goal of the testing described in this document was to determine the maximum throughput of a set of validator nodes.

Not all rippled nodes are validators. Some of them expose a RESTful server interface to clients for submitting transactions to the network (client handlers) and for retrieving historical data. The benchmark environment was comprised of both validating nodes and client handlers as are present in the live network. In addition, a dedicated host was used to generate test load.

Two separate environments were used to measure the XRP Ledger’s throughput. These environments were both distinct from the live network. One environment tested geographically decentralized validators, and the other environment used validators within a single datacenter. These environments were both based on bare metal x86_64 servers running Centos7 Linux. All nodes ran rippled version 0.80.0-b1. These environments used faster hardware than the current production network. There is a project to migrate the production network to upgrade the hardware and to match the quantity and geographic distribution of the former test environment. Once this project completes, the performance capabilities described of the live network will be equivalent to those described in this document.

Each server in the test environment had the following specifications:

• 1 x Intel Xeon E3-1270 v3 3.5GHz CPU. 4 cores and hyperthreading enabled.

• 32GB RAM

• 2 x Gigabit Ethernet adapters. One adaptor used for public traffic and one adaptor used for private traffic.

• 1GB mirrored internal SSD storage.

For the geographically decentralized environment, there were 16 validators comprised of four hosts in each of four continents: North America, South America, Europe, and Asia. All 4 client handlers and the test driver were located in North America.

Two different topologies were tested:

1. Geographically decentralized: All 20 rippled hosts were configured with the same set of 16 trusted validators. The client handlers and test driver host were in a separate location in North America from the 4 sets of validators.

2. Single location: There were 5 trusted validators in the same location as the 4 client handlers and test driver.

Workload and Criteria

The workload consisted of sending payments of XRP between 5,000 accounts. Each second, a fixed number of transactions were submitted with a random sender giving 5 millionths of one XRP to a random receiver. This rate was sustained for twenty minutes. This workload was generated with a custom benchmark harness tool developed by Ripple. XRP is the native currency of the XRP Ledger: each transaction consumes a small amount of XRP as an anti-spam measure. Further, XRP can be used as a bridge currency to facilitate trades between any other asset types represented on the network.

Each test run was aborted by the benchmark software once either of 2 criteria failed:

1. Ledger stability: The Ripple ledger updates roughly every 4 seconds. The amount of latency for a specific transaction is measured by the time from submission to the time of its inclusion in a new version of the ledger. Success criteria for this testing was such that the ledger would never take more than 30 seconds for an update.

2. Transaction completion: If over 50% of transactions submitted within just over a minute had failed to complete, then the test aborted.

Transaction volume was ramped up iteratively until these criteria failed. There was a ramp-up period of 10 minutes where transaction volume increased linearly from 0 to 800 transactions to second. Then, each phase ran for 20 minutes before stepping up an additional 100 per second. This continued until failure of one of the above criteria.

Results

The following table describes average latency for transactions at varying input rates and according to the two tested topologies. Input rate is in transactions per second. Latency is measured in seconds.

Rate (/s)

Decentralized Latency (s)

Single Site Latency (s)

800

7.022

6.991

900

7.638

7.305

1000

7.847

7.529

1100

8.384

7.981

1200

8.842

8.057

1300

9.847

8.708

1400

14.005

1500

10.719

The decentralized topology was stable for 20 minutes with up until and including 1300 transactions per second. The network ceased supporting the workload with 1400/s. Average latency from during ramp-up all the way to 1300/s varied from 7 seconds to just under 10. The single-site network had slightly better maximum throughput with 1500/s sustained for 20 minutes, but could not sustain 1600/s. Transaction latencies were very similar with both topologies for rates up until and including 1300/s. However, for the single site, transaction latencies increased noticeably beyond that point. In both cases, the network sustained well over 1000 transactions per second while remaining stable.

These results are based on a network comprised of the hardware type listed above. Nodes with slower hardware will likely sustain less traffic.

Summary

Ripple’s tested throughput is in the range of capability of SWIFT, the legacy international payments provider. They recently had a peak traffic day of just over 30,000,000 messages. That averages about 347 per second. Neither their peak seconds nor tested throughput have been reported publicly. But the Ripple Consensus Ledger’s 1000+ transactions per second capability puts it squarely in the running for the ability to handle the biggest international payment workloads.