Security Analysis of Ripple Consensus

Abstract

The Ripple network is one of the most prominent blockchain platforms and its native XRP token currently has one of the highest cryptocurrency market capitalizations. The Ripple consensus protocol powers this network and is generally considered to a Byzantine fault-tolerant agreement protocol, which can reach consensus in the presence of faulty or malicious nodes. In contrast to traditional Byzantine agreement protocols, there is no global knowledge of all participating nodes in Ripple consensus; instead, each node declares a list of other nodes that it trusts and from which it considers votes.Previous work has brought up concerns about the liveness and safety of the consensus protocol under the general assumptions stated initially by Ripple, and there is currently no appropriate understanding of its workings and its properties in the literature. This paper closes this gap and makes two contributions. It first provides a detailed, abstract description of the protocol, which has been derived from the source code. Second, the paper points out that the abstract protocol may violate safety and liveness in several simple executions under relatively benign network assumptions.

A Survey of Consortium Blockchain and Its Applications

“…Ripple [82] is a real-time gross settlement (RTGS) system aiming at fast global payments, asset exchange, and settlement [83]. Ripple maintains a ledger of transactions where participants can trade user-issued currencies along with the native cryptocurrency of Ripple, i.e., XRP.…”

Probabilistic Edge Multicast Routing for the XRP Network

“…3) Receiver Node: The node behaves as a receiver when its identifier is present in the destinations field of a message. The receiver has two tasks: (1) to unicast the message to the final destination node if it is a member of the forwarder's neighbourhood. (2) to multicast the message to the edge of its neighbourhood by executing Algorithms 2 and 1…”

“…Unlike Proof of Work protocols used in Bitcoin or Ethereum, the XRP Ledger relies on trustbased validation to advance the ledger history. As a result, it can handle up to 1,500 transactions per second [1].…”

Relaxed Reliable Broadcast for Decentralized Trust

“…In order to accept transactions, a node needs to "hear" from at least 80% of its UNL, and according to the original white paper [27], assuming that up to 20% of the nodes in an UNL might be Byzantine, the overlap between every pair of UNL's needed to prevent forks was believed to be ≥ 20%. The original protocol description appeared to be sketchy and informal, and later works detailed the functioning of the protocol and helped to clarify under which conditions its safety and liveness properties hold [2,8,23,1]. In particular, it has been spotted [2] that its safety properties can be violated (a fork can happen) with as little as 20% of UNLs overlap, even if there are no Byzantine nodes.…”

“…In a further analysis, assuming that at most 20% of nodes in the UNLs are Byzantine, [8] suggests an overlap of > 90% in order to prevent forks, but also provide an example in which the liveness of the protocol is violated even with 99% of overlap. Recently, a formalization of the algorithm was presented in [1], and a better analysis of the correctness of the protocol in the light of an atomic broadcast abstraction was given by Amores-Cesar et al [1].…”