[Paper Review] Analysis of the XRP Ledger Consensus Protocol

Brad Chase, Ethan MacBrough|arXiv (Cornell University)|Feb 20, 2018

Distributed systems and fault tolerance5 references105 citations

TL;DR

The paper analyzes the XRP Ledger Consensus Protocol, derives conditions on UNL overlap for safety and liveness, and presents a corrected overlap bound between prior estimates, noting a stricter bound (>90%) under a general fault model and introducing Cobalt as a more flexible alternative.

ABSTRACT

The XRP Ledger Consensus Protocol is a previously developed consensus protocol powering the XRP Ledger. It is a low-latency Byzantine agreement protocol, capable of reaching consensus without full agreement on which nodes are members of the network. We present a detailed explanation of the algorithm and derive conditions for its safety and liveness.

Motivation & Objective

• Clarify the XRP LCP network model and problem of consensus with partial UNL overlap.
• Derive necessary safety (consistency) and liveness (progress) conditions based on UNL overlap.
• Provide corrected bounds for overlap between UNLs under Byzantine fault models.
• Assess safety and progress of XRP LCP in the current network state and transition plans to Cobalt.

Proposed method

• Formalize XRP LCP as a Byzantine fault-tolerant consensus over per-node UNLs.
• Define quorums (q_i = ceil(0.8 n_i)) and fault limits (t_i ≤ n_i - q_i).
• Model the network as weakly asynchronous and analyze safety via overlap bounds between UNLs.
• Introduce and analyze the concepts of safety (no two honest nodes fully validate conflicting ledgers) and liveness (forward progress) under partial participation.
• Present proofs and propositions (e.g., Proposition 1, Lemma 2, Corollary 3, Proposition 4) to establish overlap-based safety criteria.
• Describe the Deliberation, Validation, and Preferred Branch components and how they interact to reach consensus.

Experimental results

Research questions

• RQ1 What UNL overlap between honest nodes guarantees safety (no conflicting ledgers with the same sequence number) and liveness (forward progress) in XRP LCP?
• RQ2 How do previous bounds (roughly 20% and ~41%) compare, and what is the corrected overlap condition under Byzantine accountability and under a more general fault model?
• RQ3 What are the implications of network asynchrony and partitioning on safety and progress, and how does XRP LCP handle them?
• RQ4 How does the XRP LCP transition plan (e.g., to Cobalt) relate to the overlap bounds and safety guarantees?
• RQ5 What practical constraints (e.g., quorum definitions, delays) affect safety and progress in real deployments?

Key findings

• A single corrected overlap bound between prior estimates is established for safety and liveness under partial UNL overlap.
• Under Byzantine accountability, two honest nodes cannot fully validate different ledgers with the same sequence number iff UNL overlap exceeds a bound related to q_i and q_j (and t_i,j).
• When moving to a fully general fault model, the minimum overlap bound rises (approximately >90% of the UNL) for safety.
• The analysis clarifies that the original 20%/41% bounds were not exact and provides precise conditions involving UNL intersections, quorum sizes, and fault bounds.
• The paper confirms XRP LCP is safe in its current state while transitioning toward the Cobalt protocol, which promises lower overlap requirements (and forward progress guarantees).
• The sibling paper on Cobalt shows a lower overlap bound (>60%) and no stagnation under maximal faults, highlighting the trade-off with XRP LCP.