/ Ripple

The XRP Ledger and Consensus - For the Rest of Us!

bigbuckor

bigbuckor

I don't do "moons and Lambos." I am "cabins and Jeeps" all the way!

Read More

If you're like me, you're probably not a "techie" (no offense). The XRP Community, though, is full of intelligent people who understand everything tech and everything XRP. I am still learning, and that's okay. We should all want to learn about our favorite digital asset that is changing the way financial firms and other companies settle payments.

XRP Community blogger, Hodor, recently published a blog that explains why Consensus is better than Proof of Work (PoW) when validating transactions. If you have not read it, I encourage you to do so because the blog addresses the significant issue that blockchain purports to fix: double spending.

Now that we know consensus is better we have to ask ourselves, "what is consensus?"

Proof of Work

First, for those that do not know, PoW is achieved by "mining" using "mining rigs," or hardware designed to prove a simple but time consuming algorithm which gives the "miner" the right to to add the new block to the "chain" (and also decide which transactions go in that block). In reality, the "miner" is typically a group of mining rigs owned by individuals anywhere in the world that decide to "pool" their resources together for a better chance at solving the algorithm, or, it is a large company/conglomerate that owns hundreds, even thousands, of mining rigs with the purpose to mine for profit.

If your mining rig solves the algorithm you are rewarded for your work, typically with a number of tokens that are newly issued to you and/or with the transaction fees associated with the transactions included in the block. This "incentive" to earn additional coins/tokens is what drives individuals and companies alike to spend hundreds, thousands, and millions of dollars on mining equipment...and electricity.

In a nutshell, PoW systems require miners (validators) to compete against each other for the possibility to earn an incentive and the right to decide which transactions will be included or excluded in a particular block. Please understand that this is a very general categorization and is not intended to represent any particular coin/token and its PoW system.

Consensus

Consensus

The XRP Ledger (XRPL) uses a model that is completely different than PoW and that is much stronger than PoW: consensus. The XRPL functions for two basic purposes: first, to decide the order of the transactions for the next block, and second, whether to include a transaction in the next block or not, both of which prevent double spending. Sounds a lot like PoW, right? Wrong. Where PoW requires miners to compete against each other for the right to determine what transactions are included in a block and thus earn the incentive offered, consensus requires its validators to work together. Validators on the XRPL are not in competition with one another, rather, they work together to ensure the integrity and security of the system and that transactions are processed in a systematic manner.

If PoW requires validators to compete against each other, how does the XRPL reach consensus with all of its validators?

The Rules of Consensus

Once again, the purpose of consensus is to prevent double spending on the XRPL. Ripple provides examples on its website of potential double spends. Say I have 10 XRP in my account and want to send 10 XRP to Person A and then try to send 10 XRP to Person B. I am trying to double spend the XRP in my account by sending XRP I do not own to a second person.

Consensus is reached among the various XRPL validators by following very specific rules. Ripple says,

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:

  1. 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, consensus has no work to do.

  2. 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.

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

  4. 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.

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 to be processed). However, every honest participant’s second priority is agreement. A network with possible double spends has no utility at all. Agreement is facilitated by the fact that every honest participant values it above everything but correctness. (emphasis mine)

Therefore, as transactions are submitted for approval they are first reviewed for correctness and then they are prioritized for agreement.

Here is a video that gives a brief overview of how this process works. Notice how the threshold for consesus is raised until 80% of validators agree on the transaction set to be included in the next ledger. This process ensures that valid transactions are included in the transaction set but that excluded transactions have an opportunity to be included in the next transaction set provided the validators reach consensus on the excluded transaction(s) in the next set. This process is described below.

The Consensus Process

Ripple has published another technical article that describes how a transaction is introduced as a "candidate transaction" by a node and is ultimately included as a validated transaction in a closed block. The process is explained below:

  1. The nodes on the network share information about candidate transactions.
  2. Through the consensus process, validating nodes agree on a specific subset of the candidate transactions to be considered for the next ledger.
  3. Consensus is an iterative process in which nodes relay proposals, or sets of candidate transactions.
  4. Nodes communicate and update proposals until a supermajority of peers agree on the same set of candidate transactions.

According to the Ripple article, as the validating process begins and candidate transactions are considered for the next ledger, a minimum of 50% of nodes must be in agreement. However, before a transaction is considered "validated" and included in a "closed" ledger, a supermajority of 80% of validators must agree on the transaction set.

Reaching Consensus Through Trust

Ripple's technical article states:

During consensus, each node evaluates proposals from a specific set of peers, called chosen validators. Chosen validators represent a subset of the network which, when taken collectively, is "trusted" not to collude in an attempt to defraud the node evaluating the proposals. This definition of "trust" does not require that each individual chosen validator is trusted. Rather, validators are chosen based on the expectation they will not collude in a coordinated effort to falsify data relayed to the network.

These "trusted peers" become known as a Unique Node List (UNL) for each node operator. Node Operator A has a list of nodes they trust, Node Operator B has a list of nodes they trust, etc. Using the UNL method of trust, no one node has to trust all the nodes in the system, only those that they know are a "honest participant."

Consensus can be reached with each node trusting just a few other "honest participants" in the system. How?

Six Degrees of Kevin Bacon

Kevin-Bacon

Growing up in the 80's and 90's I played the game Six Degrees of Kevin Bacon several times. For those that don't know, Kevin Bacon was in every movie in the 80's and 90's...okay, so maybe not every movie, but it sure felt like it!

In the game, Six Degrees of Kevin Bacon, someone would throw out an actor's/actress' name and would challenge others to find the shortest path between that actor and Kevin Bacon. "It rests on the assumption that anyone involved in the Hollywood film industry can be linked through their film roles to Bacon within six steps," according to Wikipedia.

The Wikipedia site gives a couple of examples using Elvis Presley and Ian McKellen:

Elvis Presley:

Elvis Presley was in Change of Habit (1969) with Edward Asner
Edward Asner was in JFK (1991) with Kevin Bacon

Ian McKellen:

Ian McKellen was in X-Men: Days of Future Past (2014) with Michael Fassbender and James McAvoy
McAvoy and Fassbender were in X-Men: First Class (2011) with Kevin Bacon

The game could be played all night long (literally) throwing out names of new actors and finding ways from them to Kevin Bacon...there were an endless number of connections between actors and Kevin Bacon.

Six Degrees of Consensus

Consensus is much the same way...there are a seeming endless number of connections between nodes due to the trust they have with other nodes on their respective UNL. Node A can indirectly trust Node Z, because Node A trusts Node G, which trusts Node T, which trusts Node E, which trusts Node W, which trusts Node Z. Node A doesn't have to trust Node Z to reach consensus together because other nodes trusted by Node A trust Node Z.

It's like being invited to a party where you don't know many people. You know you trust the person who invited you so you go. When you get to the party you realize there are a few other people you trust. Those people introduce you to their friends. You don't have to trust them all to agree that you and they all like the party: you trust your friends, so you indirectly trust the friends of your friends when everyone agrees that the party is the best there is. This is consensus.

With the XRPL you are not far away from the other nodes in the network...probably less than six degrees. And because you know the nodes you trust are "honest participants" in the system, you trust their ability to trust other nodes and reach consensus on the transactions submitted to the network. This is exactly how a supermajority of nodes reaches consensus on which transactions to include in the next ledger, and all within 3 to 5 seconds.

Conclusion

This is not meant to be an overly technical piece. I am not an overly technical person. However, it is important that those who own XRP and/or follow XRP understand how the XRPL works and what consensus is and how it differs from PoW (and Proof of Stake, which I have not covered, but is similar to PoW except that "he who owns the most" gets the privilege of validating the block and receiving the incentive for doing so, if I can have the privilege to abbreviate its definition).

What is the incentive for running an XRPL validator? As a validator you get to introduce transactions to the Ledger (including your own if you transact with XRP), you get to help support the XRPL and ensure its stability and viability, and you get to be a part of an ecosystem that is changing the way the digital world functions around us. Also, by running a validator, you may be closer to Kevin Bacon than you think!


Did you like this post by bigbuckor?

Send some love: