How Does XRP Consensus Work?

Key Takeaways

• The XRP Ledger allows multiple conflicting transactions to be in the agreed group. The group of transactions is executed according to deterministic rules, so whichever transaction comes first according to the sorting rules succeeds, and whichever conflicting transaction comes second fails.

• Deterministic rules can be used even to form the groupings, leading to disagreement only in edge cases. For example, if there are two conflicting transactions in a round, deterministic rules can be used to determine which is included in the next round.

• It is extremely rare for a participant to particularly care about how the transactions were grouped. The agreement is easiest when everyone’s priority is reaching an agreement and only challenging when there are diverging interests.

How Ripple Consensus Work

Simplifying the Problem

Much of the double-spend problem can be solved by well-known rules such as prohibiting an account from spending funds it does not have. The double-spend problem can be reduced to putting transactions in order.

Consider the example of Alice trying to send the same $10 to both Bob and Charlie. If the payment to Bob is known to be first, then everyone can agree that she has the funds to pay Bob.

If the payment to Charlie is known to be second, then everyone can agree that she cannot send those funds to Charlie because the money has already been sent to Bob.

We can also order transactions by deterministic rules. Because transactions are collections of digital information, it’s trivial for a computer to sort them.

This would be enough to solve the double-spend problem without a central authority, but it would require us to have every transaction that would ever occur (so that we could sort them) before we could be certain of the results of any transaction. Obviously, this is impractical.

If we could collect transactions into groups and agree on those groupings, we could sort the transactions within that group. As long as every participant agrees on which transactions are to be processed as a unit, they can use deterministic rules to solve the double-spend problem without any need for a central authority.

The participants each sort the transactions and apply them in a deterministic way following the known rules. The XRP Ledger solves the double-spend problem in exactly this way.

The XRP Ledger allows multiple conflicting transactions to be in the agreed group. The group of transactions is executed according to deterministic rules, so whichever transaction comes first according to the sorting rules succeeds, and whichever conflicting transaction comes second fails.

SEE ALSO: How Does Proof-of-Stake Improve Proof-of-Work?

Consensus Rules

The primary role of consensus is for participants in the process to agree on which transactions are to be processed as a group to resolve the double-spend problem. There are four reasons this agreement is easier to achieve than might be expected.

If there is no reason a transaction should not be included in such a group of transactions, all honest participants agree to include it. If all participants already agree, a consensus has no work to do.

If there is any reason at all a transaction should not be included in such a group of transactions, all honest participants are willing to exclude it. If the transaction is still valid, there is no reason not to include it in the next round, and they should all agree to include it then.

It is extremely rare for a participant to particularly care how the transactions were grouped. The agreement is easiest when everyone’s priority is reaching an agreement and only challenging when there are diverging interests.

Deterministic rules can be used even to form the groupings, leading to disagreement only in edge cases. For example, if there are two conflicting transactions in round, deterministic rules can be used to determine which is included in the next round.

Every participant’s top priority is correctness. They must first enforce the rules to be sure nothing violates the integrity of the shared ledger. For example, a transaction that is not properly signed must never be processed (even if other participants want it to be processed). However, every honest participant’s second priority is agreement. A network with possible double spends has no utility at all, so every honest participant values agreement above everything but correctness.

Can Consensus Fail?

It is not practical to develop a consensus algorithm that never fails to achieve perfect consensus. To understand why consider how the consensus process finishes.

At some point, each participant must declare that a consensus has been reached and that some set of transactions is known to be the result of the process. This declaration commits that participant irrevocably to some particular set of transactions as the result of the consensus process.

Some participants must do this first or no participant will ever do it, and they will never reach a consensus. Now, consider the participant that does this first. When this participant decides that consensus is finished, other participants have not yet made that decision.

If they were incapable of changing the agreed set from their point of view, they would have already decided consensus was finished. So they must be still capable of changing their agreed set.

In other words, for the consensus process to ever finish, some participants must declare that consensus has been reached on a set of transactions even though every other participant is theoretically still capable of changing the agreed-upon set of transactions.

Imagine a group of people in a room trying to agree which door they should use to exit. No matter how much the participants discuss, at some point, someone has to be the first one to walk out of a door, even though the people behind that person could still change their minds and leave through the other door.

The probability of this kind of failure can be made very low, but it cannot be reduced to zero. The engineering tradeoffs are such that driving this probability down below about one in a thousand makes consensus significantly slower, and less able to tolerate network and endpoint failures.

SEE ALSO: How Much Ripple XRP Is Burned Per Transaction?

How the XRP Ledger Handles Consensus Failure

After a consensus round completes, each participant applies the set of transactions that they believe were agreed to. This results in constructing what they believe the next state of the ledger should be.

Participants that are also validators then publish a cryptographic fingerprint of this next ledger. We call this fingerprint a “validation vote”. If the consensus round succeeded, the vast majority of honest validators should be publishing the same fingerprint.

Participants then collect these validation votes. From the validation votes, they can determine whether the previous consensus round resulted in a supermajority of participants agreeing on a set of transactions or not.

They built the same ledger a supermajority agreed to. In this case, they can consider that ledger fully validated and rely on its contents.

They built a different ledger than a supermajority agreed on. In this case, they must build and accept the supermajority ledger. This typically indicates that they declared a consensus early and many other participants changed after that. They must “jump” to the super-majority ledger to resume operation.

No supermajority is clear from the received validations. In this case, the previous consensus round was wasted and a new round must occur before any ledger can be validated.

Of course, case 1 is the most common. Case 2 does not harm the network whatsoever. A small percentage of the participants could even fall into case 2 every round, and the network would work with no issues.

Even those participants can recognize that they did not build the same ledger as the supermajority, so they know not to report their results as final until they agree with the supermajority.

Case 3 results in the network losing a few seconds in which it could have made forward progress, but is extremely rare.

In this case, the next consensus round is much less likely to fail because disagreements are resolved in the consensus process and only remaining disagreements can cause a failure.

On rare occasions, the network as a whole fails to make forward progress for a few seconds. In exchange, average transaction confirmation times are low.

SEE ALSO: Bitcoin vs Ripple – What are the Differences and Flaws

Frequently Asked Questions (FAQ)

1. How are XRP transactions verified?

The servers that receive, relay, and process transactions may be either tracking servers or validators. To account for this, the XRP Ledger uses a process called consensus to ensure that the same transactions are processed and validated ledgers are consistent across the peer-to-peer XRP Ledger network.

2. What algorithm does XRP use?

The XRP Ledger (XRPL) does not employ a proof-of-work (PoW) algorithm, as seen with Bitcoin’s blockchain, or a proof-of-stake (PoS) algorithm, as with the Ethereum 2.0 blockchain. Instead, the XRP Ledger relies on a setup called the XRP Ledger Consensus Protocol to validate account balances and perform transactions.

3. Is XRP a Protocol?

The XRP Ledger uses a consensus protocol, unlike any digital asset that came before it. This protocol, known as the XRP Ledger Consensus Protocol, is designed to have the following important properties. Everyone who uses the XRP Ledger can agree on the latest state, and which transactions have occurred in which order.

4. Will Ripple ever Hit $5?

While CoinPriceForecast expects the value to hit $2 by the end of 2021 and $3 by the end of 2022. If you’re waiting for XRP to hit $5, you’ll have to wait until 2025, according to the site.

Final Thoughts

With the XRP Census protocol, Individuals are allowed to agree on the same series of events and their outcomes giving that the set rules made by Ripple are followed by them to the latter.  Much of this helps in solving the double end problem effectively.