This picture will be mintable soon
Koen van Schaijk
Koen van Schaijk

The Federated Byzantine Agreement (FBA) & The XRP Ledger Consensus Protocol

Peer-to-peer computing architecture has given way to many new developments such as distributed ledger and, subsequently, blockchain technology. Its inception has played a crucial role in creating various consensus algorithms and protocols – the backbone of decentralized networks such as the XRPL and Bitcoin Network. 

Today we dive into the intricacies of one of these protocols – the XRP Ledger Consensus Protocol. More specifically, how the protocol ties in with the fictitious yet foundational Byzantine General Problem and how the concept of quorums pertains to the XRPL Consensus Protocol.

What Is The FBA?

The FBA, more commonly known as the Byzantine Generals Problem, is an example of a thought experiment in which knowledge and the communication of that knowledge play an integral part. The main goal of this problem is to determine whether unanimity (or consensus) can be achieved in a distributed or decentralized system. The problem was theorised in the late 1970s by Robert Shostak, a computer scientist known for his influential role in the development of distributed computing. To better explain the challenges of this decentralized architecture, Shostak came up with this interesting analogy involving a group of generals preparing to invade a town. 

A Classical Analogy

The Three Challenges of Distributed Payment Systems

Before jumping into the analogy, it is essential to understand the basic premise and problems of distributed computing and, therefore, distributed payment systems. Computer networks process much conflicting information before making a decision. However, different requests from and to a server or node can cause different conflicts in the entire distributed system’s processes which can devalue the validity of transactions occurring throughout the network. As such, a decentralised network must ensure it can handle the following three challenges: (1) correctness, (2) agreement, and (3) utility. 

  1. Correctness is the principle that a system should be able to distinguish between a correct and a fraudulent transaction.   
  2. Agreement relates to the foundational truth beneath the network. It refers to the double-spend problem and suggests that there should be but one set of globally valid transactions.
  3. Utility can be discerned between the computing costs required to participate in the network and the throughput speed experienced on the distributed payment system.

For a decentralized network and its constituents to operate efficiently, the consensus algorithm must achieve positive outcomes in all three categories. 

The Byzantine General Problem

The problem of receiving various conflicting requests from various dispersed nodes can be tricky. It is best described using Shostak’s analogy of the Byzantine Generals Problem. The classic version of this problem is what served as a foundation for the creation of XRPL’s consensus protocol.

The classical version of the Byzantine Generals Problem goes as follows:

  • Several units of the Byzantine army are stationed outside an enemy city. 
  • Each unit is commanded by a separate general. 
  • The generals have the order to attack the city with a majority of the units simultaneously because the chance of an attack succeeding with a limited number of units is too small. 
  • The generals must agree on whether to attack or retreat and can only communicate using messengers.

In this situation, there are two uncertainties: (1) the communication between the generals can be distorted or halted by messengers travelling through hostile territories, and (2) some generals may be traitors acting in bad faith.

To draw parallels with a distributed system, a failing messenger would represent a failing node while a traitor general, would represent a malicious actor within the network.

Although we look at this situation from a simplified perspective where only two different plans are possible per general (to attack or to retreat), a successful outcome is determined based on which plan has received the most votes (yay or nay). Even though there are only two options in this scenario, failure may originate from multiple entities (or sources) within the system. This is known as a ‘Byzantine’ failure. In other words, a small yet unknown number of traitors and messenger miscommunications could result in a significant failure to attack.

Deriving from this analogy is the fact that distributed payment systems need to be rigorous enough to withstand both standard and ‘Byzantine’ failures. Such a system must be proven to solve the three aforementioned challenges allowing for only marginal errors.

The FBA & The XRPL Consensus Protocol

In essence, the Byzantine Generals Problem has laid much of the foundation for the development of the XRPL Consensus Protocol. It has allowed the network to conceptualise a consensus mechanism sustaining an undetermined number of unaffiliated participants or nodes. 

Although reaching an agreement in a system is only possible if enough participants or nodes (known as a quorum) conform with one another, the FBA behaves differently. To achieve consensus in an FBA, each participant or node must extend its trust to a smaller group of other participants or nodes (known as a quorum slice). A quorum slice can be seen as the subset of a quorum, and it facilitates trust between a node and its appointed validator nodes. If this action is conducted throughout the ledger, quorum slices stimulate a state of agreement throughout the distributed ledger. They can be seen as the (d)UNL validators on the XRPL.

Quorum slice picture

The ‘trust’ concept – visualized by the grey square in the image above – is set up in the configuration file of a node. Since nodes each have configuration files, they may differ in terms of which validators, and therefore UNLs, they wish to trust. This can cause quorum slices and quorums to form dynamically and independently within a network. However, for a valid quorum to form, it should share connecting nodes, resulting in overlapping transmissions and, therefore, agreements. This overlap is called a ‘quorum intersection,’ which is essential for a sustainable peer-to-peer consensus mechanism as it allows transactions to be proposed, accepted, and recognized throughout the network. 

Quorum intersection

When these quorums do not intersect, nodes can be left out, causing the system to become ‘disjoint’. ‘Disjoint’ quorums are undesirable outcomes within a system because they can all simultaneously and independently agree on contradictory transactions, therefore undermining the overall consensus of the entire network. 

Thankfully, the XRPL Consensus Protocol has a maximum fault tolerance of approximately 20%. As long as this percentage is not exceeded within the quorums, the validators within the (d)UNLs will continue to approve new transaction proposals from the network participants and nodes.

Disjoint

The Consensus Algorithm

The strength of a consensus algorithm is usually measured in terms of percentages. More specifically, how many faulty processes can be tolerated on the network before it begins to fail? To achieve ‘correctness’, given a maximum amount of Byzantine node failures, a transaction is only approved if more than 80% of the (d)UNL validators agree. As long as 80% of the (d)UNL is honest, no fraudulent transactions will be approved (Schwartz, 2018). 

Over the years, several algorithms – with greater complexity – have been proposed for the Byzantine Generals problem, with some algorithms even allowing up to 33% fault tolerance before a fork is formed. Some of the protocol’s characteristics are mentioned hereunder:

  • A mandatory 2-second window for all nodes to propose their initial candidate sets in each round of consensus (nodes with more significant latency can then participate in the consensus process).
  • As the votes are recorded in the ledger for each consensus round, nodes can be flagged and removed from the network for some common, easily-identifiable malicious behaviors. These include nodes that vote “Nay” on every transaction and nodes that consistently propose transactions that are not validated by consensus.
  • A network split detection algorithm is employed to prevent the network from forking.
  • A default UNL is provided to all users (dUNL) to reduce the probability that any node colludes and joins a nefarious cartel on the network. This default list of nodes guarantees that even naive users will participate in a consensus process that achieves agreement, correctness, and utility with extremely high probability (Schwartz, 2018).

How Does The XRPL Consensus Protocol Fair Against Other Consensus Mechanisms?

Making comparisons between blockchain systems and consensus algorithms is often a bad idea. Why? Because they are different solutions to different problems. All systems operate based on the consensus/security model they think is the most applicable for their networks/system’s use case. 

In the case of the XRPL, it is optimized and made scalable as a global payments gateway, which is an entirely different use case than Bitcoin (designed to be a decentralised store of value) or Avalanche (designed for low-cost smart contract capability).

Conclusion

The XRPL Consensus Protocol is a highly scalable, fast, and low-cost global payment system with well-understood security and reliability properties. The XRPL can be accurate and up-to-date without requiring all of its nodes to agree. Instead, quorum slices emerge from the choices of each node.

This quorum slice convinces an individual node of agreement, while a quorum convinces the entire system of agreement. This is what makes the XRPL so flexible.

There are many other consensus algorithms out there, but the XRPL Consensus Protocol offers a very suitable and scalable solution that will prove its worth in the years to come.

Koen van Schaijk
Koen van Schaijk