Decoding Ripple (XRP) Whitepaper

Read Time:3 Minute
xrp logo Decoding Ripple (XRP) Whitepaper
Decoding Ripple (XRP) Whitepaper 2

Introduction

  • The Ripple Protocol is a distributed payment system that uses collectively-trusted sub-networks to achieve low-latency consensus.
  • The trust required of these sub-networks is minimal, and can be further reduced with principled choice of member nodes.
  • The Ripple Protocol is correct, in agreement, and useful in the face of Byzantine failures.

Definitions – Previous Work and Formalization

  • The Ripple Protocol consensus algorithm (RPCA) is applied every few seconds by all nodes, in order to maintain the correctness and agreement of the network.
  • The RPCA proceeds in rounds. In each round, each server takes all valid transactions it has seen prior to the beginning of the consensus round that have not already been applied, and makes them public in the form of a list known as the “candidate set”.
  • Each server then amalgamates the candidate sets of all servers on its UNL, and votes on the veracity of all transactions.
  • Transactions that receive more than a minimum percentage of “yes” votes are passed on to the next round, if there is one, while transactions that do not receive enough votes will either be discarded, or included in the candidate set for the beginning of the consensus process on the next ledger.
  • The final round of consensus requires a minimum percentage of 80% of a server’s UNL agreeing on a transaction. All transactions that meet this requirement are applied to the ledger, and that ledger is closed, becoming the new last-closed ledger.

Ripple Consensus Algorithm

  • The Ripple consensus algorithm (RPCA) proceeds in rounds, with each server taking all valid transactions it has seen prior to the beginning of the consensus round that have not already been applied, and making them public in the form of a list known as the “candidate set”.
  • Each server then amalgamates the candidate sets of all servers on its UNL, and votes on the veracity of all transactions.
  • Transactions that receive more than a minimum percentage of “yes” votes are passed on to the next round, if there is one, while transactions that do not receive enough votes will either be discarded, or included in the candidate set for the beginning of the consensus process on the next ledger.
  • The final round of consensus requires a minimum percentage of 80% of a server’s UNL agreeing on a transaction. All transactions that meet this requirement are applied to the ledger, and that ledger is closed, becoming the new last-closed ledger.
  • In order to achieve correctness, given a maximal amount of Byzantine failures, it must be shown that it is impossible for a fraudulent transaction to be confirmed during consensus, unless the number of faulty nodes exceeds that tolerance.
  • Agreement is not inherently guaranteed by the correctness proof, since the UNLs for each server can be different.
  • To satisfy the agreement requirement, it must be shown that all non faulty nodes reach consensus on the same set of transactions, regardless of their UNLs.
  • The limiting factor for the termination of the algorithm is the communication latency between nodes. In order to bound this quantity, the response-time of nodes is monitored, and nodes who’s latency grows larger than a preset bound b are removed from all UNLs.
  • A latency bound heuristic is enforced on all nodes in the Ripple Network to guarantee that the consensus algorithm will converge. In addition, there are a few other heuristics and procedures that provide utility to the RPCA, including a mandatory 2 second window for all nodes to propose their initial candidate sets in each round of consensus, and a network split detection algorithm.

Simulation Code

  • The Ripple Protocol consensus algorithm (RPCA) is a method for achieving consensus in a distributed system.
  • The RPCA satisfies the conditions of correctness, agreement, and utility, which allows the Ripple network to function as a fast and low-cost global payment network with well-understood security and reliability properties.
  • The RPCA is provably secure up to the bounds outlined in section 3, which, while not the strongest available in the literature for Asynchronous Byzantine consensus, do allow for rapid convergence and flexibility in network membership.

Leave a Reply

%d bloggers like this: