Agreeing without mining

A bank keeps one book of who owns what. One bank, one book, one boss. The XRP Ledger has no boss. Many servers around the world each keep a copy of the book. They need a way to agree on every new page.

The hard part is order. Say you have 10 XRP and you try to send all of it to two people at the same moment. Only one payment can count. Everyone has to agree on which one. That is the double-spend problem.

The XRP Ledger solves it with a conversation.

1. Some servers, called validators, each suggest a list of new transactions.
2. They compare lists with the validators they trust and adjust. This repeats for a few rounds.
3. When enough of them hold the same list, they apply it and each works out the resulting page.
4. Each one announces a fingerprint of its result. If enough fingerprints match, the page is validated.

A validated page is final. It never changes. Then the next page begins. A new one closes about every 3 to 5 seconds.

A transaction that misses one page is not lost. It usually lands in the next one.

Nothing here is a race. Bitcoin pays mining rewards. The XRP Ledger has no mining and no reward. Validators are not paid by the protocol. People run them because they rely on the network and want it to stay healthy.

The protocol is the XRP Ledger Consensus Protocol. Its design priorities, in order: correctness, agreement, forward progress.

Ledger versions. Each ledger version has three parts:

• The full current state.
• The set of transactions applied to the previous version.
• A header with the ledger index, a hash of the contents and the parent's hash.

Because every version holds the whole state, a server does not need all history to know current balances.

Stage 1: consensus on a transaction set. Validators relay proposals, which are sets of candidate transactions. Each server weighs only proposals from its trusted validators, its Unique Node List. Over successive rounds validators change their proposals to match the validators they trust. xrpl.org describes the thresholds this way: at least 50% agreement at the start of the first round, rising to 80% for the final round. It adds that the values can change. Transactions left out stay as candidates for the next ledger.

Stage 2: validation. Each server then:

1. Takes the agreed set and puts it in canonical order. This order is not arrival order and is hard to manipulate.
2. Applies the transactions to the previous validated ledger.
3. Computes the hash of the new ledger.

Validators sign that hash and broadcast it as a validation. A server declares the ledger validated when a supermajority of its trusted validators sent the same hash. The stated threshold is at least 80%. If a server's own result differs, it fetches the correct ledger from its peers.

If a round fails. Without supermajority agreement, servers repeat the process for a new ledger version. Each round reduces disagreement.

No mining. xrpl.org states the network is not open to a 51% attack because consensus does not use mining. The FAQ says rewards such as Bitcoin's mining rewards are not needed, since validating adds little cost to running a server.

Watch it live. server_info returns last_close.converge_time_s, the time the last ledger took to reach consensus, and last_close.proposers, the number of trusted validators that took part.

Related: Validators and the UNL.