Source-linked AI summary
Analysis of the XRP Ledger Consensus Protocol
Brad Chase, Ethan MacBrough
TL;DR
Because XRP LCP permits partial agreement about network participants, determining the UNL overlap needed for safety and liveness is important. The paper explains the protocol and derives those conditions; it finds a roughly >90% safety bound in the general fault model, with forward progress guaranteed only in a restricted setting.
Problem
XRP LCP allows partial agreement on participants, leaving the necessary UNL overlap for safety and liveness to be clarified.
Source: §1 · p. 2Method
The paper gives a detailed explanation of XRP LCP and derives conditions for consistency and liveness.
Source: §1 · p. 2, §5 · p. 20Results
Roughly >90% participant agreement is needed for safety, while forward progress is guaranteed only for a single expanding UNL with leaves when no nodes are faulty and message delays are bounded.
Source: §5 · p. 20Takeaways & Limitations
During the current diversification of trusted network operators, the paper says the XRP network is safe and cannot get stuck making no forward progress.
Source: §1 · p. 2XRP LCP is only weakly asynchronous, and its performance depends on protocol delay parameters.
Source: §2 · p. 5
Abstract
from arXiv · showhide
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.
1 Introduction
The paper explains how XRP LCP reaches agreement on transaction sets without full agreement about network membership, then derives conditions for safety and liveness. It revisits conflicting UNL-overlap analyses and frames the protocol’s strict requirements as an interim concern during a planned transition.
1 Introduction
- XRP LCP’s role is to make nodes agree on transaction sets; deterministic transaction processing then produces a consistent ledger.The protocol does not determine transaction content or outcomes.Source: §1 · p. 1
- Most Byzantine fault-tolerant protocols require prior agreement on participants, whereas XRP LCP allows partial agreement and an open network.Users choose unique node lists (UNLs), whose pairwise overlap determines safety.Source: §1 · pp. 1–2
- The paper re-evaluates prior overlap results, gives a corrected bound between them, and reports a roughly >90% minimum under a more general fault model.It also states that, during current trusted-operator diversification, the XRP network is safe and cannot get stuck.Source: §1 · p. 2
- The paper treats XRP LCP as a general consensus protocol and excludes discussion of ledger transaction semantics and XRP’s benefits as a digital currency.Its stated structure covers the network model, algorithm, correctness conditions, and concluding discussion.Source: §1 · p. 2
- XRP LCP is presented as an interim protocol during a planned transition to Cobalt, whose stated general-fault-model overlap bound is >60%.The paper says XRP LCP’s relatively strict UNL requirements should be viewed in light of that transition.Source: §1 · p. 2
2 Network Model and Problem Definition
This section defines the network and ledger model used to assess XRP LCP, including how nodes choose trusted participants and what safety and progress mean. It states the adversarial and timing assumptions, along with practical implementation considerations that affect liveness.
Network model
- Each node chooses its own UNL, the nodes whose messages it listens to; trust need not be symmetric, and sufficient overlap is required for consistency and liveness.A node’s presence in more UNLs implicitly gives it more influence; Figure 1 highlights one node’s UNL.Source: §2 · p. 3, Figure 1 · p. 4
- The adversary may control message delivery and Byzantine nodes, while Byzantine accountability is a tenuous restriction used only where explicitly stated.Each node’s quorum is 80% of its UNL size, and at most n_i − q_i nodes in that UNL may be Byzantine faulty.Source: §2 · pp. 3, 5
Consensus problem
- The ledger is the shared ordered transaction history, and fork safety means tolerated Byzantine configurations cannot make honest nodes validate contradictory ledgers.The protocol can be viewed as atomic broadcast with batched transactions; its properties include agreement, linearizability, and censorship resilience.Source: §2 · pp. 3–5
Network model
- The network has no prescribed relation to UNL structure, but each listed peer is assumed to provide a reliable authenticated channel.Messages are signed and verified, and broadcast sends the same message to nodes that include the sender in their UNL.Source: §2 · pp. 3–4
Consensus problem
- Censorship resilience formalizes forward progress; in practice, nodes echo transactions, so clients need not submit them to every correct node.The peer-to-peer network floods submitted transactions until every node receives them.Source: §2 · p. 5
Network assumptions
- Safety must hold under arbitrary asynchrony, but forward progress is guaranteed only under weak asynchrony: bounded message delays and no faulty nodes.The paper cites FLP as preventing guaranteed progress with arbitrary asynchrony and faulty nodes.Source: §2 · p. 5
Practical considerations
- XRP LCP’s weak asynchrony and parameter-dependent performance are limitations; implementation heuristics help enforce bounded delays.Heuristics identify lagging nodes, limit excessive flooding, and route traffic through the network.Source: §2 · p. 5
3 The XRP Ledger Consensus Protocol
XRP LCP combines deliberation, validation, and preferred-branch selection to agree on transaction sets and advance ledger history. Deliberation builds transaction-set agreement, validation makes ledgers authoritative, and preferred-branch selection supports progress when validations conflict.
3 The XRP Ledger Consensus Protocol
- Deliberation proposes transaction sets, validation makes a ledger authoritative after a quorum, and preferred-branch selection guides work when validations conflict.The protocol's outcome is agreement on transaction sets, not on their content or processing outcome.Source: §3 · pp. 5–6
3.1 Deliberation
- Each node updates its proposed set from recent same-parent UNL proposals, raising the inclusion threshold by round until a quorum triggers validation.Implementation thresholds rise from 0.5 to 0.65, 0.70, and 0.95; timing parameters balance throughput, latency, and network overhead, while safety and liveness do not depend on these deliberation details.Source: §3.1 · pp. 8–9
3.2 Validation
- A node fully validates a ledger when it sees a quorum of trusted-node validations for that ledger.Fully validated ledgers and their ancestors are authoritative and irrevocable.Source: §3 · p. 6, §3.2 · p. 9
3.3 Preferred Branch
- Preferred-branch selection walks ledger ancestry and chooses a child whose branch support remains greatest even if uncommitted support backs a conflicting sibling.Nodes switch branches conservatively; under extreme asynchrony, a branch may initially have support from only one node, so others must verify its protocol invariants before switching.Source: §3.3 · pp. 9–10
4 Analysis
This analysis examines XRP LCP safety and liveness under different UNL configurations, Byzantine assumptions, and network conditions, deriving overlap conditions for safety and considering deliberation’s effects. It establishes when a single sufficiently large agreed-upon UNL prevents the protocol from getting stuck, while showing that progress is not guaranteed in a fully asynchronous network and that split UNLs can get stuck even with high overlap and no Byzantine faults.
4.1 Safety
- Assuming Byzantine accountability, preventing two honest nodes from fully validating different ledgers with the same sequence number requires every pair to have UNL overlap of 41% of the average size of their respective UNLs.The accountability assumption may fail in a fully asynchronous network, where a network partition could segregate contradictory messages long enough for damage to occur.Source: §4.1 · pp. 11, 13
- Without Byzantine accountability, same-sequence contradictory-ledger safety requires Oi,j > (ni − qi) + (nj − qj) + ti,j, or roughly 61% UNL overlap under 80% quorums and 20% faults.This same-sequence condition alone does not establish full safety, because deliberation can terminate with an arbitrary result.Source: §4.1 · p. 14
- Deliberation can end with different node groups validating contradictory ledgers, while neither group is large enough for full validation; safety analysis therefore treats deliberation’s result as arbitrary.In the example, if both validating groups contain more than two nodes, none fully validates a ledger during that consensus round.Source: §4.1 · p. 16
- Fork safety is guaranteed when every pair satisfies Oi,j > nj/2 + ni − qi + ti,j; with 80% quorums and 20% faults, this requires roughly >90% UNL overlap.The condition is sufficient but not necessary, and is the weakest safety condition expressible purely as a bound on overlap. The proof route is to ensure more than half of each UNL's honest nodes validate the ledger, so later validations remain on its descendant branch.Source: §4.1 · pp. 16, 18
4.2 Liveness
- Forward progress cannot be guaranteed in a fully asynchronous network, and XRP LCP can get stuck even with 99% UNL overlap and no Byzantine faults.The analysis seeks conditions preventing honest nodes from becoming unable to fully validate a new ledger, rather than guaranteeing forward progress in all cases.Source: §4.2 · p. 18
- A 102-peer network with two UNLs overlapping by 99% can remain stuck without Byzantine faults when each group validates a different ledger branch.The example says the network cannot rejoin without manual intervention.Source: Figure 6 · p. 19, §4.2 · p. 19
- If a closed subset N cannot get stuck or fork, adding a node whose UNL includes at least its quorum-sized subset of N cannot make the expanded network get stuck.Source: §4.2 · p. 19
- With quorum n − ⌊(n − 1)/k⌋, XRP LCP cannot get stuck with a single agreed-upon UNL X of size at least k and any number of leaf validators.Source: §4.2 · p. 20
- In a complete network, quick delivery of validations lets preferred-branch selection align nodes; synchronous deliberation then leads all nodes to validate the same ledger.If a transaction set is shared with 80% of X, nodes exit deliberation with the same ledger in round 1; otherwise, they deterministically propose the same transaction set in round 2.Source: §4.2 · p. 20
5 Conclusion
The analysis finds that XRP LCP needs roughly >90% participant agreement for safety, while its forward-progress guarantee is limited to a restricted single-expanding-UNL setting. It identifies open questions about tighter topology-aware bounds and deliberation failures, and presents Cobalt as an alternative with a lower overlap bound.
5 Conclusion
- Roughly >90% agreement on participants is needed for XRP LCP safety, while the stated progress guarantee is limited to a single expanding UNL with leaves, no faulty nodes, and bounded message delay.With even minor participant disagreement in the general case, forward progress cannot be guaranteed.Source: §5 · p. 20
- Whether trust-topology analysis can improve the sufficient safety-overlap bound remains open, including whether indirect message flow can yield a more precise condition.A better account of when deliberation fails might also refine understanding of forward progress.Source: §5 · pp. 20–21
- Cobalt is presented as a possible replacement that needs only >60% overlap in the general fault model and cannot get stuck when the overlap bound is met.The paper describes it as a direction for greater future decentralization.Source: §5 · p. 21
A Algorithms
The appendix supplies pseudocode for deliberation, validation, and preferred-branch selection, including proposal updates, ledger selection, and branch traversal.
A Algorithms
- Nodes update stored proposals from trusted peers only when the received proposal matches their preferred ledger and has a newer round.The regular update step either starts deliberation on a changed preferred ledger or updates the current position.Source: A Algorithms · p. 23
- Deliberation filters proposed transactions by support threshold, advances the round, and broadcasts the updated proposal and ledger.The appendix identifies this as the UpdatePosition function.Source: A Algorithms · p. 24
- Validation records which nodes validated each ledger and advances the preferred ledger when its validation count reaches q_i and its sequence is newer.Preferred-branch selection sorts child ledgers by branch support and returns the selected ledger.Source: A Algorithms · pp. 24–25