Introduction to Consensus

Consensus is the most important property of any decentralized payment system. In traditional centralized payment systems, one authoritative administrator gets the final say in how and when payments occur. Decentralized systems, by definition, don't have an administrator to do that. Instead, decentralized systems like the XAG Ledger define a set of rules all participants follow, so every participant can agree on the exact same series of events and their outcome at any point in time. We call this set of rules a consensus protocol.

Consensus Protocol Properties

The XAG Ledger uses a consensus protocol unlike any digital asset that came before it. This protocol, known as the XAG Ledger Consensus Protocol, is designed to have the following important properties:

  • Everyone who uses the XAG Ledger can agree on the latest state, and which transactions have occurred in which order.
  • All valid transactions are processed without needing a central operator or having a single point of failure.
  • The ledger can make progress even if some participants join, leave, or behave inappropriately.
  • If too many participants are unreachable or misbehaving, the network fails to make progress rather than diverging or confirming invalid transactions.
  • Confirming transactions does not require wasteful or competitive use of resources, unlike most other blockchain systems.

These properties are sometimes summarized as the following principles, in order of priority: Correctness, Agreement, Forward Progress.

This protocol is still evolving, as is our knowledge of its limits and possible failure cases. For academic research on the protocol itself, see Consensus Research.

Background

Consensus protocols are a solution to the double-spend problem: the challenge of preventing someone from successfully spending the same digital money twice. The hardest part about this problem is putting transactions in order: without a central authority, it can be difficult to resolve disputes about which transaction comes first when you have two or more mutually-exclusive transactions sent around the same time. For a detailed analysis of the double-spend problem, how the XAG Ledger Consensus Protocol solves this problem, and the tradeoffs and limitations involved, see Consensus Principles and Rules.

Ledger History

The XAG Ledger processes transactions in blocks called "ledger versions", or "ledgers" for short. Each ledger version contains three pieces:

  • The current state of all balances and objects stored in the ledger.
  • The set of transactions that have been applied to the previous ledger to result in this one.
  • Metadata about the current ledger version, such as its ledger index, a cryptographic hash that uniquely identifies its contents, and information about the parent ledger that was used as a basis for building this one.

Figure 1: Anatomy of a ledger version, which includes transactions, state, and metadata

Each ledger version is numbered with a ledger index and builds on a previous ledger version whose index is one less, going all the way back to a starting point called the genesis ledger with ledger index 1.¹ Like Bitcoin and other blockchain technologies, this forms a public history of all transactions and their results. Unlike many blockchain technologies, each new "block" in the XAG Ledger contains the entirety of the current state, so you don't need to collect the entire history to know what's happening now.²

The main job of the XAG Ledger Consensus Protocol is to agree on a set of transactions to apply to the previous ledger, apply them in a well-defined order, then confirm that everyone got the same results. When this happens successfully, a ledger version is considered validated, and final. From there, the process continues by building the next ledger version.

Trust-Based Validation

The core principle behind the XAG Ledger's consensus mechanism is that a little trust goes a long way. Each participant in the network chooses a set of validators, servers specifically configured to participate actively in consensus, run by different parties who are expected to behave honestly most of the time. More importantly, the set of chosen validators should not be likely to collude with one another to break the rules in the exact same way. This list is sometimes called a Unique Node List, or UNL.

As the network progresses, each server listens to its trusted validators³; as long as a large enough percentage of them agree that a set of transactions should occur and that a given ledger is the result, the server declares a consensus. If they don't agree, validators modify their proposals to more closely match the other validators they trust, repeating the process in several rounds until they reach a consensus.

Figure 2: Consensus rounds. Validators revise their proposals to match other validators they trust

It's OK if a small proportion of validators don't operate properly all the time. As long as fewer than 20% of trusted validators are faulty, consensus can continue unimpeded; and confirming an invalid transaction would require over 80% of trusted validators to collude. If more than 20% but less than 80% of trusted validators are faulty, the network simply stops making progress.

For a longer exploration of how the XAG Ledger Consensus Protocol responds to various challenges, attacks, and failure cases, see Consensus Protections Against Attacks and Failure Modes.