Keywords

1 Introduction

Blockchain (or more generally, distributed ledger technology) platforms hold great promise to shapeshift the nature of centuries-old business models and pave the way for new, unprecedented levels of transparency for users, who, as a direct consequence, can gain more proactive control over their data. The key success of blockchains essentially stems from the idea that led to the birth of the Bitcoin protocol [28], i.e. allowing mutually mistrusting parties to perform financial payments and autonomously reach agreement on an ever-growing linearly-ordered log of transactions. The ability of blockchains to maintain the integrity of the system without relying on a trusted third party enables to move the control from the center to the edge and makes this technology an attractive option to truly concretize the promises of edge-centric computing. This and other fundamental properties such as transparency and resilience have progressively increased the interest in distributed ledger protocols, causing the flourishing of countless proposals for new features and completely new blockchain-based applications beyond the financial sector [6, 7, 33]. Over the last years, a concurrent research trend has focused towards the development of entire categories of newly designed consensus protocols [5, 9, 41] that aim at overcoming the disadvantages due to the use of the so-called Nakamoto consensus, which is the mechanism adopted by Bitcoin and similar approaches to consistently update the state of the network. The Nakamoto consensus is purposefully designed to be energy-intensive and relies on the notion of Proof-of-Work (PoW), which involves competition between participants to incentivize the creation of new blocks of transactions. The most popular alternative to the Bitcoin’s cryptographic puzzle-solving scheme is represented by Proof-of-Stake (PoS). This technique gives involved parties the chance to affect the behavior of the system on the basis of the stake they possess, instead of requiring them to invest computing power.

Despite the existence of numerous exciting lines of work investigating distributed ledger protocols, current research is predominantly addressing aspects that only target improving the performance and usability of this technology. An even more important priority for the wide adoption and acceptance of blockchain-based solutions is the rigorous analysis of their underlying consensus algorithms, which are the defining element of any distributed ledger system [21]. The reason why it is important to formalize their behavior is twofold. On one hand, it helps in gaining confidence that the protocol works exactly as expected and meets its specification. On the other hand, it serves to prove that the protocol achieves its goals in terms of a set of desirable properties. The conjunction of formal argumentation and detailed security analysis can provide the backbone for a more conscious understanding of both the potentialities and vulnerabilities of the blockchain paradigm in general [37]. Furthermore, capturing the actual functioning of consensus protocols not only makes it easier to identify their limitations, but can also be useful to study them under new perspectives that go beyond those conventionally considered.

1.1 Why the XRP Ledger Calls for a Deeper Investigation

As said, Bitcoin-like approaches employ resource-based techniques to achieve consensus. So, they represent a natural fit for settings where anyone can arbitrarily join and leave the computation. At the opposite end of the spectrum lie protocols that rely on communication-based schemes, where participating entities are known and typically achieve consensus by means of a voting mechanism that runs through several rounds of communication. Essentially, these types of consensus protocols are provided with a security layer for access control that allows only a restricted set of participants to affect the behavior of the system. An intriguing distributed ledger protocol that incorporates the above characteristics is represented by the XRP LedgerFootnote 1 payment system [34]. This protocol uses a unique consensus mechanism, known as the XRP Ledger Consensus Protocol (XRP LCP), that sets it apart from previous approaches in several ways. The fact that the XRP LCP is not based on a mining process and does not need several confirmations before transactions can be accepted as settled clearly brings many advantages, compared to Bitcoin and other cryptocurrencies [26, 40]. Indeed, while for Bitcoin-like protocols transactions are confirmed after an hour on average, in the XRP Ledger network the settlement process takes around 5 s, with a throughput of up to 1500 transactions per second. Although it exhibits several fascinating and innovative features, current research on the XRP Ledger protocol either addresses issues that do not concern the consensus protocol itself or compares it generically with other systems [12, 20, 32, 43]. By now the original white paper [38] is deprecated, and available documentation about how the XRP LCP works is restricted to the developer portal [35] and a recent analysis provided by its creators [11]. Even if the latter presents a detailed explanation of the XRP Ledger algorithm and derives conditions for its safety and liveness, there remains a degree of uncertainty around many aspects of the protocol and, in any case, not all steps have actually been described. Furthermore, to date the only existing peer-reviewed analysis of the protocol was conducted on the original white paper and showed that some specifications were flawed [2].

Therefore, what is really missing today is an in-depth study and analysis of the XRP Ledger Consensus Protocol in all its parts. The objective of this work is to narrow this gap by digging deep into the underlying technical components that contribute to the construction and proper functioning of the XRP Ledger consensus mechanism. This paper has its roots in a previous work of ours [27], and can be considered as its natural extension towards the overall goal of providing a thorough, clear and exact description of the behaviour of the XRP LCP.

Contribution. The contributions of this paper are the following:

  • In order to frame the context where some of the essential concepts incorporated by the XRP Ledger arose and developed, we first offer an overall historical perspective of the trust assumptions commonly used in the distributed systems panorama, tracing the evolution of the choices of trust in the different distributed ledger protocols.

  • Drawing from a scattered corpus of information, we identify three core technical components of the XRP Ledger protocol design - Peer-to-peer communication network, Consensus, and Transactions. This concept decomposition enables a more insightful characterization of the protocol’s behavior and can be used as a reference point for future investigation.

  • The aforementioned three main technical components are further decomposed so as to clarify the role each element/participant plays during the different phases of the protocol. Especially for the Consensus and Transactions components we present thorough technicalities which, to the best of our knowledge, have never been covered in such detail by other research papers. For example, we provide a careful characterization of the three different ledger versions that each participant has to maintain during the execution of a single round of consensus. Also, we describe in detail the conditions under which the result of a transaction is considered final in relation to the ledger version in which it has been included, as well as the way initially discarded transactions are handled.

  • Lastly, the step-by-step protocol description is preceded by a new enriched workflow showing a linear representation of the three phases of the protocol and their intermediate and final outputs for a single consensus round.

A direct benefit of our contributions is that they make the formalization and security analysis of XRP LCP provided in the subsequent sections clearer and can drive the reader towards a deeper understanding of the interactions that occur during each stage of the consensus process. This work, in conjunction with our prior effort [27], has shed light on many aspects of the XRP LCP that had remained unclear so far.

Overall, our research resulted in a comprehensive identification and characterization of the different phases governing the XRP Ledger Consensus Protocol. The careful analysis of all the available documentation and source code of the XRP LCP has allowed us to create an in-depth description of the protocol for every step and then, to conduct an accurate analysis of its security guarantees in terms of safety and liveness. Furthermore, we have proved that the correlation between some protocol parameters can be leveraged to achieve specific security goals.

The remainder of this paper is structured as follows. In Sect. 2 we provide an overview of the different trust assumptions underlying distributed ledger approaches. Then, we describe the flexible notion of trust introduced by the XRP Ledger. Section 3 presents the three core components at the basis of the XRP Ledger system and provides a detailed description of their utility during the protocol execution. Section 4 presents a set-theoretic formalization of the different phases of the XRP LCP. Section 5 shows the security guarantees of the protocol in terms of safety and liveness and how to increase the desired liveness/fault tolerance by changing the value of specific protocol parameters. Section 6 reviews recent work on the formalization of blockchain protocols. Finally, Sect. 7 concludes the paper and proposes directions for future research.

2 The Faces of Trust in Distributed Ledger Systems

Distributed ledger (DL) systems appear to bring forth a new form of trust where individuals who want to exchange valuable assets amongst each other are not required to trust either the interacting party or a central entity. Rather, trust seems to be placed only in a collection of components (firstly, hard code and cryptographic algorithms). The simple fact that all actors follow the same identical rules with the ultimate goal of reaching agreement on how to consistently update the state of the network causes the whole system to be perceived as trustworthy. Although blockchain approaches presuppose shifting trust to the veracity of the system and, consequently, to the overall control mechanism, it is essential to carefully consider the trust assumptions that underlie their consensus mechanisms. Indeed, trust assumptions, whether implicit or explicit, strongly influence the extent to which any distributed system maintains its stability and correctness and have a fundamental impact on how security analyses are conducted on models.

Successful blockchain platforms such as Bitcoin and Ethereum guarantee that consistency holds as long as more than half of the voting power (expressed in terms of energy consumption or wealth distribution) is controlled by participants that honestly follow the protocol. The model used in these systems is permissionless, in the sense that participants can join or leave the network at any time, without coordinating with any other party. On the contrary, the permissioned model, which is the one used traditionally in research, imposes restrictions on its nodes, in the sense that only an authorized set of known and identifiable participants is explicitly responsible for the advancement of the consensus protocol [1]. The trust assumptions underlying protocols in this setting – usually referred to as Byzantine fault tolerant (BFT) consensus – are generally stated with respect to a number of nodes behaving correctly. Typically, consensus is achievable if the maximum number of malicious nodes is less than one third of all participants in the system. Byzantine quorum (BQ) systems [25, 39] are a classic abstraction for ensuring system-wide consensus in distributed fault-tolerant computing. In a Byzantine context, a quorum can be defined as a collection of subsets of all the nodes, such that each pair of quorums intersect in a set containing sufficiently many correct nodes to guarantee consistency. Traditional BFT and BQ systems make use of a symmetric notion of trust, meaning that all the nodes involved in the system trust other network members in the same way, thereby adhering on a uniform trust view. However, this does not truly reflect the individual choices of trust taken in reality, where users may trust some participants more than others. Abandoning the idea of a global fail-prone structure, the work in [14] has laid the foundations of asymmetric trust, aiming at capturing a more subjective notion of trust for secure computation protocols. Recently, new approaches for designing BFT and BQ protocols have been proposed [8, 10, 19, 24]. This search for evolved models with more sophisticated trust assumptions is currently receiving a lot of attention because of their potential application to consensus algorithms for permissioned blockchains.

2.1 The XRP Ledger Through the Lens of Trust

The XRP Ledger was arguably the DL protocol that first introduced the idea of flexible trust structures. Influenced by the BQ approach, the XRP Ledger operates as a quorum-based system where the process for reaching agreement is driven by decisions taken by specific nodes, known as validators. The most important task of a validator is that of issuing special messages to communicate its opinion on which transactions to insert in the ledger. However, the mere act of sending messages does not automatically give the validator a say in the consensus process. In effect, the key idea is that a validator does not need to be listened to or to communicate with everyone. In the XRP Ledger, this concept is embodied in the so-called Unique Node List (UNL), which essentially resembles the classical notion of quorums, but is tailored so as to reflect the subjectiveness of trust choices. Each validator maintains its own UNL and uses it for designating which nodes it trusts. During the protocol execution, validators ignore other validators’ messages unless those validators are included into their UNL. This means that if a validator is part of a UNL, it is trusted and its messages are considered in the consensus process by the validators that trust it. A viable way to assess the trustworthiness of validators is by inspecting the Validator RegistryFootnote 2, which provides identity information and performance statistics for all network validators. Conceptually, the XRP Ledger can be sited at some intermediate level between a BFT-based protocol and a permissionless blockchain. On one hand, the protocol goes beyond the traditional form of consensus by not prescribing only one global trust assumption for all validators. On the other hand, nodes determine individually if they want to act as validators. So, in principle, anyone can participate in the consensus process. Nevertheless, this freedom in participating is in fact limited by the discretion in selecting which nodes to trust. Practically, by expressing their own trust assumptions, validators determine with which other participants they wish to stay in consensus with, thereby entailing a certain degree of permissioning.

3 Core Technical Components

3.1 Peer-to-Peer Communication Network

As in any other DL system, the XRP Ledger enables a peer-to-peer network designed around the notion of equal participation by nodes, where any node is free to join the network in order to interact with other peers.

Network Topology, Discovery and Communication. The peer-to-peer network is supported by an overlay logic that creates a virtualized network layer on top of the physical network topology. This overlay network can be thought of as a directed graph whose vertices are the nodes and whose edges define the connections allowing nodes to directly communicate with each other. In general, a node maintains multiple outgoing connections and optional incoming connections to other peers. Whenever a node joins the network, it needs a way to find out about other nodes. By default, the XRP Ledger achieves this via a gossip protocol such that once a node has connected to a peer, it asks that peer for the connection information of other peers that may also be attempting to establish peer connections. The node can then connect to such peers, and ask them for the information of some other peers to connect to, thereby triggering a cascade mechanism of contact data exchange. Inter-party interaction, which for example involves sharing information on the network connection status and consensus progress, takes the form of signed messages. Each node possesses a key pair that is generated using any of the XRP Ledger’s supported digital signature schemes, which, at present, are the ECDSA with secp256k1 (by default) and the EdDSA with Ed25519. The fact that all communications are signed guarantees the integrity of the message to the receiver as well as provides a reliable means to authenticate the identity of the sender.

3.2 Consensus

An essential part of the XRP Ledger is the consensus mechanism used to reach agreement on changes in the ledger, which is the shared state of the system. The overall consensus process, which will be thoroughly described in Sect. 4, consists of several phases that are continually repeated. The result is a chain of fully validated ledgers growing over time.

Open, (Last) Closed and Fully Validated Ledgers. In the XRP Ledger, the actual ledger destined to become part of the immutable history of transactions is nothing more than what results from successive refinements of individual versions of the ledger itself. In fact, during the consensus process, the content of the initial (parent) ledger taken as a basis is subject to continuous updates until a final ledger is validated by the whole network. We can roughly distinguish three different ledger versions, namely open, last closed and fully validated. In a sense, this series of individual ledgers is part of an evolutionary line expressed in terms of content validity and finality that leads from an initial provisional ledger version reflecting only the view of the single validator to a permanent and authoritative one that is globally accepted. Table 1 outlines the main differences between the ledger versions. Getting into details, each validator maintains a single open ledger that represents its own current working version of the next ledger and is used as a temporary workspace to group all incoming transactions in the order they arrive. At a certain point in time, the ledger is closedFootnote 3, and no new transaction can be considered as candidate for inclusion in the next ledger (but it may be considered for inclusion in a later ledger version). The set of transactions it contains forms the reference point for the start of the actual consensus phase. The closed ledger does not constitute another version of the ledger, rather a particular state associated with the open ledger, which simply serves to indicate that, for the current consensus round, all possible transactions to be considered as candidates are known (as such, we have not included it in the summarising table). The last closed ledger is the most recent ledger that the validator believes the network reached agreement on. The process for calculating a new last closed ledger involves taking the previous last closed ledger and applying the transaction set resulting from consensusFootnote 4. In the last closed ledger, transactions are applied according to deterministic protocol rules (canonical order), instead of the order in which they are received, as is the case with the open ledger. This make sure that validators process the same sequence of transactions in the same way. However, the last closed ledger only reflects the personal belief by each validator on which transactions should be permanently included in the ledger. Thus, the content of a last closed ledger cannot yet be considered as neither final nor reliable. Only the transactions appearing in a fully validated ledger are final and hence truly irrevocable. This can be easily clarified by considering two basic parameters specified in the ledger header: the ledger index (or sequence number) and the ledger hash. The ledger index is a progressive number used to identify the ledger so as to keep all the ledgers in order. The ledger hash serves as a unique identifier of the exact contents of the ledger. As said, the contents of the open ledger change over time, reflecting the arrival of new submitted transactions (that is obviously affected by network delays). Since it is very likely that validators have very different ledgers at the early phase of the process, the ledger hash is calculated only for last closed ledgers. Nevertheless, due to Byzantine failures, different validators can come to a different conclusion about the last closed ledger. This means that there may be multiple last closed ledgers with the same ledger index but different ledger hash competing to be fully validated. As a result, unless the last closed ledger is fully validated, it might be replaced by a completely different last closed ledger having a differing set of transactions.

Table 1. Differences between ledger versions.
Full size table

Proposal, Dispute and Validation. Most of the consensus process is devoted to the exchange of so-called proposals between validators. A proposal is a signed message containing the position taken by the validator with regard to which set of transactions it believes should be included in the next ledger. Throughout the process, each validator broadcasts several proposals in an attempt to achieve consensus, but it is up to the receiving validators to decide whether or not to consider those proposals as part of their local decision-making process. As mentioned in Sect. 2.1, the UNLs give structure to the XRP Ledger network and can be thought of as the convincing set that each validator listens to. Thus, proposals are evaluated only if submitted by trusted validators. This exchange of proposals logically implies the occurrence of divergences between the various positions taken by the validators. This concept is expressed by the term dispute, which denotes an individual transaction that is either not included in a validator’s proposal or not included in a trusted validator’s proposal. The purpose of validations is to let trusted validators know which particular ledger has been built by the other validators and to come to a common conclusion about which ledger version should be declared as fully validated. In essence, a validation is a signed message containing the hash of the last closed ledger.

3.3 Transactions

Transactions represent the means by which making changes to the state of the world in the XRP Ledger. Every transaction has an identifying hash that serves as a globally distinguishing ID and has to be authorized through digital signatures before submission.

Transaction Finality. Every validator processes transactions independently and then verifies that its outcome corresponds to that of the rest of the network. When a validator receives a transaction, it provisionally applies it to its current open ledger and returns the corresponding tentative result. As mentioned earlier, the set (and the order) of transactions is not final until a ledger is approved by the consensus process. Depending on circumstances, this can cause a transaction that succeeded initially to eventually fail or a transaction that failed initially to eventually succeed. Furthermore, as long as a transaction is not incorporated in a fully validated ledger, it is also possible to cancel it. In addition to the hash, each transaction has a sequence number that starts at 1 and increments for each transaction that an XRP Ledger account submits. The purpose of this sequence number is analogous to that of the ledger index, that is keeping transactions in order. By signing a transaction, the owner of an account effectively authorizes it to take place. However, if the same account sends another transaction with the same sequence number, that transaction can be theoretically deleted. Whether or not the cancellation process is successful depends on a number of factors, including the network topology and workloads, but generally it is more likely to succeed when the transaction has not yet been proposed as a candidate transaction in a validator’s proposal.

Queuing. In order to protect the network from excessive load (for instance due to denial-of-service attacks), each transaction must destroy a small amount of XRP, the native cryptocurrency of the XRP Ledger. Each validator maintains a cost threshold based on its local load, so if the transaction fee specified by a transaction is lower than the validator’s load-based transaction cost, the validator simply discards the transaction without relaying it to the other peers. Also, a transaction can be included in an open ledger only if it meets the open ledger cost requirement, which serves to set a target number of transactions in any given ledger. When that is not the case, the validator may add the unsuitable transactions to its local queue after having estimated whether they are likely to be included in a later ledger version. This queuing structure is useful for selecting candidate transactions for the creation of the next ledger. If the queue is full, transactions drop out from it, starting with those with the lowest transaction cost. At each consensus round, transactions with the highest transaction cost are given priority.

4 Digging into the XRP Ledger Consensus Protocol

4.1 Protocol Overview

The ultimate goal of the XRP LCP is to advance the chain of ledgers by agreeing on a new set of transactions to apply to the prior fully validated ledger. At a high level, a ledger can be represented as a quintuple of the form \(L = \langle sn, h, h_{-1}, ts, T \rangle \) where sn is the sequence number (or ledger index) of the ledger, h is the unique identifying hash of the ledger’s contents, \(h_{-1}\) is the h value of the previous ledger version this ledger was derived from, ts is a timestamp, and T is a set of transactions. Of the many last closed ledgers independently built by validators, only one can become fully validated. Hence, there exists always only one fully validated ledger hash for each ledger index in history; all the other candidate ledger versions are destined to be discarded. A tuple \(L = \langle sn, h, h_{-1}, ts, T \rangle \) is valid with respect to a predecessor (fully validated) ledger \(L' = \langle sn', h', h'_{-1}, ts', T'\rangle \) if and only if the following holds:

  1. 1.

    \(h_{-1} = h'\);

  2. 2.

    \(sn = sn' + 1\);

  3. 3.

    \(|\varSigma _L| \ge q_v\), where \(|\varSigma _L|\) is the support of the ledger L and \(q_v\) is the minimum percentage of participation required to reach network agreement.

Note that the above third condition essentially says that a ledger is only validated by the consensus process as soon as a quorum \(q_v\) of trusted validators votes for the same exact ledger version L. Specifically, the threshold \(q_v\), which we refer to as validation quorum, is a parameter that roughly specifies the minimum number of agreeing trusted validators each validator needs to hear from to commit to a decision. The distinguishing characteristic of the XRP LCP is that it makes use of two different thresholds serving two different purposes. In addition to the validation quorum, which is utilized at the very end of the entire consensus process, the XRP Ledger specifies another quorum, which we refer to as consensus quorum. This additional threshold is utilized at the intermediate phase of the consensus protocol to determine when a validator can build its own last closed ledger. Even though both quorums are subject to changes and do not necessarily need to be equal, in the current implementation they are exactly the same, as we will see later. By default, the two quorums are automatically set to a safe number of trusted validators based on how many there are. However, in principle it is possible to manually set their value.

Fig. 1.
figure 1

Workflow of the protocol phases for a single round of consensus.

Full size image

The overall consensus process, which can be viewed as a progression through three phases – collection, deliberation and validation – involves multiple rounds of vetting where validators continually propose and revise their candidate sets of transactions in order to determine the final, authoritative version of the ledger. Figure 1 shows the flow of the primary operations that each of the three phases involves for a single ledger round, while a brief description of each phase is provided below:

  • \(\diamond \) Collection: Validators collect all received new transactions and apply the well-formed ones to their open ledger before relaying them to the other members of the network. When certain conditions are met, validators close their ledger and propose their initial candidate transaction set to their trusted validators.

  • \(\diamond \) Deliberation: Validators begin an iterative process during which they try to establish consensus by exchanging proposals with their trusted validators. Starting from their own position, they continuously change their view of the candidate transaction set by adding or removing disputed transactions from their proposal. After each update, validators check the percentage of trusted validators agreeing with them and declare that consensus has been reached only when there is a supermajority agreement. Then, they create a new last closed ledger by applying the consensus transaction set to the last fully validated ledger and issue a validation.

  • \(\diamond \) Validation: Validators determine whether to consider the contents of their last closed ledger as final by comparing the results received from their trusted validators. The decision is taken on the basis of the percentage of agreement on the newly-created ledger. Only when a quorum of validations for the same ledger is reached, that ledger is deemed fully validated.

4.2 Preliminaries

Synchrony and Timing Assumptions. An important aspect that must be considered when designing any consensus protocol is the ability of parties to reach a certain degree of synchronization during the protocol execution. In the XRP Ledger network, the protocol execution is driven by a heartbeat timer which allows nodes to advance the consensus process. In practice, at regular intervals each validator checks whether the necessary conditions to move to the next phase of the consensus protocol are met. Although each validator can begin a new round of consensus at arbitrary times based on when the initial round started and the time taken to apply the transactions, the transition to both deliberation and validation phases can only occur at the end of the heartbeat timer. Furthermore, each node maintains an internal clock that it uses when calculating its own close time, i.e. the time at which the ledger has been closed. In practice, at the closure of the ledger (which reflects the end of collection phase) each validator uses its own current time as the initial close time estimate and includes this value in its initial position. Later, this approximate time is rounded based on a dynamic resolution. As a result, each validator uses the consensus process not only to reach agreement with its trusted nodes about the set of transactions, but also to attempt to agree on a common time for the closure of the ledger. Validators update their close time positions in response to the effective close time included in their trusted nodes’ positions, and in this way, they can derive a common close time for the ledger without the need to synchronize their clocks. When there is no clear majority of trusted validators agreeing on a close time, nodes agree to disagree on an actual close time. Even though in this case the network has no official close time, the effective close time of the ledger is set to 1 s past the close time of the previous ledger.

The XRP LCP as a whole reaches agreement on both the effective close time and the final ledger version. Nevertheless, here the focus is on the ledger content aspect, thus our formalization includes only the fundamental protocol timing parameters.

Notation. We denote by N the universe of nodes of the peer-to-peer XRP Ledger network. Nodes play different roles: client applications submit transactions to server nodes, which are differentiated in tracking nodes and validators. The consensus process is exclusively driven by the latter. Since only validators actively participate, check and validate all transactions taking place in the system, we believe that for the purposes of formalization it is meaningful to consider only the subset \(N_v \subset N\) of participants, where \(N_v\) denotes exactly the nodes acting as validators. As already mentioned, during the consensus process, validators only evaluate proposals and validations issued by their trusted nodes, discarding those received from validators not belonging to their UNL. For any node \(i \in N_v\), \(UNL_i= \{u:\ u \in N_v,\ F(u)\}\) denotes the set of all nodes u for which F(u) is true, where F(u) means that validator i trusts u. Also, we use \(n_i= |UNL_i|\) to denote the size of node i’s UNL. Giving as a fact that the individual choice to include (or omit) a given transaction in the next ledger is influenced only by the trusted nodes’ messages, we decide not to directly specify UNL membership every time (in our formalization, we will specify this dependency only in the context of the last phase). Deliberation and validation phases are parameterized by \(q_c\) and \(q_v\), respectively. In particular, \(q_c\) specifies the consensus quorum (i.e. the minimum number of validators having issued the same proposal needed to declare consensus), whereas \(q_v\) represents the validation quorum (i.e. the minimum number of validations needed to fully validate a ledger) – see Sect. 4.1. Both these parameters are a function of a constant k and \(n_i\), where \(n_i\) is the previously defined size of \(UNL_i\). We let \(\tilde{L_i}\), \(\tilde{L_i^c}\) and \(L_i'\) denote the open ledger, the closed ledger and the last closed ledger of node i, respectively. Moreover, we use \(\hat{L}\) to denote the last fully validated ledger. tx is used to represent a single transaction under consideration by consensus. Any transactions excluded from a node’s proposal are added to its local queue we denote by \(T_Q\). For notational simplicity, we suppose the existence of another set \(T_I\) which contains all received new transactions. Also, we use \(P_i\) to denote the node i’s proposal of candidate transactions and the symbol \(\theta \) to indicate the threshold for including a given transaction in the proposal \(P_i\). Lastly, \(D_i\) denotes the node i’s set of disputed transactions, whereas \(\sigma _i\) denotes a validation issued by i. Table 2 provides a summary of the notation (over the course of the presentation, some elements will be slightly modified to better suit the context).

Table 2. Summary of notation [27].
Full size table

4.3 The XRP LCP Step-by-Step

We are now ready to proceed with the formalization of the three main phases of the XRP LCP. In order to formalize the behaviour of the protocol, we referred to the current implementation of the server software at the heart of the XRP Ledger (known as rippled), whose source code is available at [36]. Each rippled server running in a validator mode actively participates in the consensus process and contributes to the advancement of the ledger chain structure and to the overall health of the system. The XRP Ledger chain of ledgers starts with the genesis ledgerFootnote 5 (the first ledger ever created) and ends with the last fully validated ledger. Generally, given the prior fully validated ledger \(\hat{L}\) and a set T of new candidate transactions, the execution of the XRP Ledger Consensus Protocol determines an output ledger \(\hat{L}'\) which, together with the previous validated ledgers, forms the ledger history. Note that in our formalization we have considered the perspective of a single validator \(i \in N_v\), which makes decisions only by listening to its unique node list \(UNL_i\). Bearing the above in mind, the outcomes produced by each validator i for each of the three phases are as follows:

  • \(\diamond \) The output expected from collection is i’s initial proposal \(P_i^0\), which contains the starting position taken by the validator i before considering any trusted validator’s position;

  • \(\diamond \) At the end of deliberation, i builds a new last closed ledger \(L_i'\);

  • \(\diamond \) Validation establishes which last closed ledger, amongst those proposed by all participants, must be considered the authoritative one (\(\hat{L}'\)).

Collection. The first stage of the process is a quiescent period allowing the validator i to create an individual perception of the state of the network. This perception is created thanks to the use of the open ledger that the validator fills with the candidate transactions that failed to be included in the last round (i.e. those queued in \(T_Q\)), as well as with newly submitted ones. i’s open ledger \(\tilde{L_i}\) contains the set of transactions T:

$$\begin{aligned} T = T_Q \cup T_I,\ \ T \in \tilde{L_i} \end{aligned}$$
(1)

Under normal circumstances, the closure of the ledger occurs after a predetermined minimum time \(t_{minclose}\) has elapsed and only if the open ledger contains at least one transaction. Thus, i closes its open ledger if the following holds:

$$\begin{aligned} T \ne \emptyset \ \wedge \ (t_{open} \ge t_{minclose}), \ \ T \in \tilde{L_i} \end{aligned}$$
(2)

where \(t_{open}\) is used to denote how long the ledger has been open. We let \(\tilde{L_i^c}\) indicate that i’s open ledger has been closed (superscript letter c). In other cases, the protocol either (1) closes the ledger if more than half of the proposers have closed the ledger or validated the last closed ledger, or (2) postpones the closure to the end of a certain idle interval so that it is more likely to include some transactions in the next ledger. Regardless of the condition which led to the closure of the ledger, once the pre-close phase is completed, i establishes its initial position on the basis of the transactions included in the newly closed ledger. Then, i proposes it to its trusted validators in the form of a proposal, i.e. a signed message containing the transactions it believes should be included in the next ledger:

$$\begin{aligned} P_i^0 = \{tx:\ tx \in T, \ \ T \in \tilde{L_i^c}\} \end{aligned}$$
(3)

Here the notation used for the proposal slightly differs from that given in Sect. 4.2; we introduced the superscript 0 to denote that \(P_i\) is the initial proposal shared by i. Like ledgers, also proposals have a sequence number that is incremented each time a validator updates the transaction set contained therein. As easy to guess, different nodes may receive different unconfirmed transactions due to network delays. As this variation in arrival time allows for each potential new ledger version to be different for each node, immediately after sharing its initial position, i considers all the proposals received from its trusted validators and creates a dispute for each transaction discovered not to be in common with the peer’s position under consideration. We define the validator i’s dispute set \(D_i\) as:

$$\begin{aligned} D_i = \{tx:\ (tx \in P_i^r \ \wedge \ tx \notin P_{j \ne i}^r)\ \vee \ (tx \notin P_i^r \ \wedge \ tx \in P_{j\ne i}^r)\} \end{aligned}$$
(4)

where r refers to one of the subsequent proposals issued by i during deliberation (at this time, \(r = 0\)). Also, the validator keeps track of each peer’s vote on each disputed transaction (voting in favour of a disputed transaction simply means believing that such transaction should be included in the next ledger). For each \(tx \in D_i\), we use v(tx) to denote the support given to tx by i’s trusted validators:

$$\begin{aligned} v(tx) = |{j \ne i:\ tx \in P_j^r}| \end{aligned}$$
(5)

where, as before, r at this time is 0 (in a more advanced stage of the process, i.e. during deliberation, \(P_j^r\) will refer to the most recent proposal issued by j). Unless they are part of a peer’s proposal, transactions received after the closure of the ledger are not considered until the next round.

Deliberation. In order to achieve consensus on the specific set of transactions to be processed next, i begins an iterative process during which it issues updated proposals (i.e. updates of its initial position), which are modified based on the support each individual transaction receives. The heartbeat timer is the key ingredient that drives the consensus process forward (see Sect. 4.2). In fact, it is only on timer calls that i adjusts and issues new proposals. Going into detail, the mechanism allowing differences between peers’ proposals to converge is based on a majority voting scheme. The evaluation of the achieved convergence degree is performed taking the value of a certain threshold \(\theta \) as a reference. In turn, the value \(\theta \) depends on a parameter d which expresses the percentage of time that consensus is expected to take to converge. Specifically, d is a function of the previous round duration, which corresponds to the duration of the last deliberation phase (measured from closing the open ledger to accepting the consensus result) and the duration of the deliberation phase for the current consensus round:

$$\begin{aligned} d = f(t_{(deliberation-1)}, \ t_{deliberation}) = \frac{t_{deliberation}\cdot 100 }{max(t_{(deliberation-1)},\ t_{minconsensus})} \end{aligned}$$
(6)

where \(t_{minconsensus}\) (currently, 5 s) expresses the minimum amount of time to consider that consensus was reached in the previous round. As deliberation proceeds, i changes its candidate transaction set in response to what its trusted validators propose. As a result, i may either add a disputed transaction to its current set if the percentage of trusted validators that have proposed the same transaction in their most recent proposal exceeds the aforementioned threshold \(\theta \) or, otherwise, remove it. New proposals are formalized as follows:

$$\begin{aligned} P_{i}' = \{tx:\ (tx \in P_i^r \ \wedge \ tx \notin D_i)\ \vee \ (tx \in D_i \ \wedge \ (v(tx) \ge \theta ))\}. \end{aligned}$$
(7)

The current implementation uses an initial threshold for inclusion of 0.5. This means that if a particular disputed transaction is supported by half of the validators or more, i agrees to include it in its set. On the contrary, a transaction that, at this early stage, does not have the support of at least \(50\%\) of the trusted nodes, is removed from i’s position. Omitted transactions are added to the transaction queue \(T_Q\) and considered again for inclusion in the next ledger version. Therefore, the queue is updated whenever a transaction is removed from a proposal:

$$\begin{aligned} T_Q' = T_Q \cup \{tx:\ tx \in D_i \ \wedge \ (v(tx) < \theta )\}. \end{aligned}$$
(8)

The specific values of \(\theta \) are subject to change, in accordance to the XRP Ledger implementation. Depending on the value of the function d (defined in Eq. 6), \(\theta \) can currently assume one of the following values:

$$\begin{aligned} \left\{ \begin{array}{lc} 0.5 &{} d< 50 \\ 0.65 &{} \ 50 \le d< 85 \\ 0.7 &{} \ 85 \le d < 200\\ 0.95 &{} otherwise \end{array} \right. \end{aligned}$$
(9)

After changing its transaction view, i broadcasts its new proposal (increasing the related sequence number) and determines whether consensus has been reached – in case i has not changed its set of transactions, no new proposal needs to be issued. Consensus can be declared only if there is a supermajority support for each of the transactions the candidate set contains. Formally, the support of a proposal \(P_i^r\) is expressed as follows:

$$\begin{aligned} v(P_i^r) = |\{j \ne i: \ P_j^r = P_i^r\}|. \end{aligned}$$
(10)

Actually, consensus is reached when the following three conditions are met: (a) a certain minimum amount of time has elapsed since deliberation began, (b) at least 3/4 of the previous round proposers are participating or the current deliberation phase is longer (of a given minimum amount of time) than the deliberation phase of the previous round, (c) i, together with its trusted peers, has reached the percentage threshold \(q_c\) above which consensus can be declared. However, for the purpose of formalization, the really meaningful condition is the third. Hence, we assume i declares consensus reached when the following holds:

$$\begin{aligned} v(P_i^r) \ge q_c, \ \ q_c = k \cdot n_i \end{aligned}$$
(11)

where \(n_i\) is the number of trusted nodes belonging to \(UNL_i\) (see Sect. 4.2) and \(k = 0.8\) in the current implementation. Once consensus is reached, i builds a new last closed ledger \(L_i'\) by adding the agreed-upon set of transactions to the prior fully validated ledger \(\hat{L}\):

$$\begin{aligned} L_i' = \hat{L} \cup \{tx\in P_i^r: \ v(P_i^r) \ge q_c\} \end{aligned}$$
(12)

and then, it broadcasts its resulting ledger in the form of a signed message \(\sigma _i\) containing the identifying hash of this ledger. At this point, the round is completed and i now builds a new open ledger on top of the last closed ledger. As previously said, the open ledger represents the basis of any validator’s initial proposal and hence, the first transactions to be added to the new open ledger are those pending from the previous consensus round. Next, all valid transactions that in the previous round were received after the ledger was closed are applied. In practice, the protocol starts a new round of consensus before the third phase, i.e. validation, ends. Each participant begins a new collection phase concurrently, preparing its proposal for the next ledger version meanwhile the consensus process related to the prior ledger version progresses. Accordingly, at any given time, the process is characterized by a series of in-progress open ledgers, individual participants’ last closed ledgers that have not been fully validated and historical ledgers that have been fully validated (see Sect. 3.2).

Validation. At the end of deliberation, as seen above, validators independently build what they believe the next state of the ledger should be. Due to latency in propagating transactions throughout the network, different validators may compute different last closed ledgers. These ledger versions have the same sequence number, but different hash values that uniquely identify their contents (see Sect. 3.2). It is important to note that the sequence number and the hash correlate 1:1 only for fully validated ledgers. Thus, for a given sequence number, only one ledger version can ever be fully validated. In order to converge on a universal status of the ledger and, consequently, resolve the above differences, i checks how many trusted validators have built a last closed ledger identical to its own by comparing its validation, i.e. the hash of the ledger it computed, with the hashes received from its peers; amongst all the most recent validations, i considers only those with the greatest sequence number. We denote by \(\varSigma _{L_i'}\) the set of trusted validators that published the same validation hash as the validator i:

$$\begin{aligned} \varSigma _{L_i'} = \{j \in UNL_i: \ \sigma _j = \sigma _i\}. \end{aligned}$$
(13)

Based on these validations, i recognizes whether the previous consensus round succeeded or not. In particular, the node declares its last closed ledger \(L_i'\) fully validated in the event that a supermajority agreement on the calculated hash is reached. Therefore, if i detects that it is in the majority, having built a ledger that received enough matching validations to meet the validation quorum \(q_v\), it considers the ledger fully validated. Formally, \(L_i'\) is declared fully validated iff:

$$\begin{aligned} |\varSigma _{L_i'}|\ge q_v, \ \ q_v = k \cdot n_i \end{aligned}$$
(14)

where, as for the consensus quorum \(q_c\) (cf. Eq. 11), the constant k is 0.8. Conversely, if i is in the minority, it cannot consider its ledger instance fully validated. Instead, it has to find the supermajority ledger, i.e. the one with the sufficient number of validations (and highest sequence number), and accept it as the new fully validated ledger:

$$\begin{aligned} \hat{L}' = L_x': \ (x = i \ \vee \ x \in UNL_i) \ \wedge \ (|\varSigma _{L_x'}| \ge q_v). \end{aligned}$$
(15)

Lastly, in case for a given sequence number no last closed ledger meets \(q_v\), no ledger is declared fully validated and i switches to a strategy allowing it to determine the preferred last closed ledger for the next consensus round (we refer the reader to [11] for an overview on this strategy).

5 Security Analysis

5.1 Desiderata and Adversary Model

Consensus protocols typically have some desired properties they wish to obtain. For example, one of the fundamental problems they have to face is to ensure that all the correct processes operating in a system with dynamic participation make decisions and eventually share a single common view of the state of the system even in the presence of corruptions and network failures. However, understanding under which conditions do these protocols achieve their desiderata is often not so trivial. Even though there exist several nuances of the Byzantine agreement protocol [31], all variants are subject to conditions similar to the following:

  • \(\diamond \) Validity: If every process begins with the same initial value v, then the final decision of a non-faulty process must be v;

  • \(\diamond \) Agreement: Final decisions by non-faulty processes must be identical;

  • \(\diamond \) Termination: Every non-faulty process must eventually decide.

These conditions are intended to capture two crucial properties, namely safety and liveness. The former, which derives from the conjunction of validity and agreement, traditionally guarantees that something bad will never happen. The latter guarantees that something good will happen eventually, and derives from the termination condition. In the XRP Ledger context, the above definitions can be reformulated as follows:

  • \(\diamond \) Safety: If an honest validator fully validates a ledger L, then all honest validators cannot fully validate a contradictory ledger \(L' \ne L\);

  • \(\diamond \) Liveness: If an honest validator broadcasts a valid proposal P, then P will eventually be accepted by all validators and included in a fully validated ledger.

As previously mentioned, the XRP Ledger features a layered notion of trust. The network is divided into subsets of nodes that are collectively trusted to not collude in an attempt to defraud the other peers, and each node has complete discretion in selecting its own UNL. Since validators only have influence over nodes configured to trust them, the presence of an honest validator in more UNLs directly implies a greater influence by that validator on the process of determining the next ledger state. Intuitively, the majority voting scheme on its own is not sufficient to guarantee network safety. Rather, it is essential to ensure that the majority of the validators act honestly and that the UNLs maintain a minimal degree of intersection between each other, in the sense that each validator chooses its own set of trusted validators so that it is reasonably similar to the set chosen by all the others. These two factors have a significant impact on the ability of systems to prevent the occurrence of a fork and to produce reliable results. Ledger forks constitute a major threat to the correct operations of every distributed system, and in the XRP Ledger ecosystem, this phenomenon corresponds to the situation in which two honest validators fully validate conflicting ledgers, i.e. ledgers having the same sequence number, but different identifying hash value. The original Ripple (XRP Ledger) whitepaper [38] provided an initial analysis of the overlap condition required to ensure consistency, coming to the conclusion that the needed minimum overlap was roughly 1/5 of the UNL size. Later, an independent analysis [2] proved that the above condition was insufficient and suggested that the correct bound was \({>}2/5\) of the UNL size. To be precise, they showed that in order to ensure the absence of any fork, the intersection set size between the UNL of any two validators needs to be \({>}40\%\) of the maximum UNL size. A recent work by Chase and MacBrough [11] provided a further analysis of the XRP LCP and derived new conditions for its safety and liveness, changing the expectation for the overlap requirement. Below, we report some of their major findings, which will be useful in the subsequent section. Prior to this, we introduce the adversary model used to analyze the safety and liveness of the protocol.

In the traditional distributed computing literature, the most common model employed to capture the role of attackers and their capabilities is the Threshold Adversary Model, where the threshold helps in easy characterization of an upper bound on the number of corrupted nodes. By adopting this approach, we can model the XRP Ledger network as if an adversary is in full control of at most \(t_i\) nodes in \(UNL_i\) for any validator i. The nodes controlled by the adversary are called Byzantine and can deviate from the protocol by performing at least one of the following actions: (i) not responding to messages; (ii) sending incorrect messages; (iii) sending differentiated messages to different nodes. In contrast, we consider as honest any node that follows exactly the prescribed XRP LCP. The honest proportion is equal to \(n_i - t_i\). Due to the FLP impossibility result [15], safety and liveness cannot be simultaneously guaranteed by any consensus algorithm in the presence of arbitrary asynchrony and Byzantine nodes. In [11], the authors assumed a weak form of asynchrony in order to prove that the system is able to not fall in a state where some honest nodes can never fully validate a new ledger. This last assumption, however, does not seem to be sufficient to guarantee that the system cannot get stuck even in networks where two UNLs disagree only by few nodes. In this regard, the paper showed an example where even with 99% UNL overlap and no Byzantine faults, the system failed to successfully apply the preferred branch strategy, consequently maintaining a ledger chain with two distinct branches (in other words, the nodes were unable to determine a preferred chain of ledgers to converge on). It follows that the XRP LCP cannot get stuck only in the restricted case where the network consists of a single agreed-upon UNL with an arbitrary number of extra nodes.

The most relevant contribution by Chase and MacBrough was the re-analysis of the overlap condition required to ensure safety. According to them, the XRP LCP guarantees fork safety if for every pair of nodes i, j the following holds:

$$\begin{aligned} O_{i,j} > \frac{n_j}{2} + n_i - q_v + t_{i,j} \end{aligned}$$
(16)

where \(O_{i,j}\) = \(|UNL_i \cap UNL_j|\), \(q_v\) = \(k \cdot n_i\) (cf. Eq. 14) and \(t_{i,j}\) = min{\(t_i, t_j, O_{i,j}\)} is the maximum number of allowed Byzantine faults in \(UNL_i \cap UNL_j\) – here we have slightly changed the original notation in order to adapt it to the one used in our formalization. Assuming 80% validation quorum (\(q_v\)) (as prescribed in the actual implementation) and 20% faults (\(t_{i,j}\)), the condition in essence requires roughly \({>}90\%\) UNL agreement.

5.2 Achieving Safety and Liveness in the XRP Ledger

In order to provide a more accurate view of the security provisions of the XRP LCP in terms of safety and liveness, here we make some observations about the three key parameters of the protocol, i.e. UNL overlap, validation quorum and tolerated Byzantine nodes, considering also the discussion recently appeared on the XRP Ledger GitHub repository [42]. We investigate the values \(O_{i,j}\), \(q_v\) and \(t_{i,j}\) displayed in Eq. 16 and in the following we show how safety and liveness tolerances are related to each other and vary according to the assumptions made on the above parameters. To this end, we find it convenient to introduce two additional parameters, namely \(\mu _i\) and \(\mu _j\), which denote the size of the set of surplus nodes for \(UNL_i\) and \(UNL_j\), respectively, that is the nodes in \(UNL_i\) that are not in common with \(UNL_j\) and viceversa: \(\mu _i = n_i-O_{i,j}\), \(\mu _j = n_j-O_{i,j}\) (Fig. 2). Moreover, we denote by \(t_s\) the safety fault tolerance and by \(t_l\) the liveness tolerance of the system, i.e. the maximum number of Byzantine nodes the XRP LCP tolerates in order to guarantee safety and liveness, respectively.

Fig. 2.
figure 2

\(\mu _i\) and \(\mu _j\) are the set sizes of surplus nodes in \(UNL_i\) and \(UNL_j\) [27].

Full size image

Given a pair of nodes i, j with their respective UNLs, and assuming that \(n_i < n_j\) and both UNLs have the same percentage of faulty nodes, \(t_{i,j}\) = min{\(t_i, t_j, O_{i,j}\)} = \(t_i\). By substituting \(O_{i,j}\) with \(n_i - \mu _i\) in Eq. 16, we get the following inequality:

$$\begin{aligned} t_s < - \frac{n_i}{2} - \frac{\mu _i}{2} - \frac{\mu _j}{2} + q_v. \end{aligned}$$
(17)

On the other hand, the liveness tolerance \(t_l\) is given by:

$$\begin{aligned} t_l < n_i - q_v. \end{aligned}$$
(18)

In general, a consensus protocol providing results that can be relied upon is preferable, rather than one that is able to progress in the presence of faulty nodes but, at the same time, reports impaired results that could undermine consistency. As a result, in order to obtain a validation quorum \(q_v\) whose safety fault tolerance \(t_s\) meets or exceeds the liveness tolerance \(t_l\), we can use \(t_s \ge n_i - q_v\) and get the following:

$$\begin{aligned} n_i - q_v < - \frac{n_i}{2} - \frac{\mu _i}{2} - \frac{\mu _j}{2} + q_v \end{aligned}$$
$$\begin{aligned} q_v > \frac{3n_i}{4} + \frac{\mu _i}{4} + \frac{\mu _j}{4}. \end{aligned}$$
(19)

Unique UNL. Let us now consider the simplest case where the XRP Ledger network consists of a single agreed-upon UNL. In this case, \(n_i = n_j = n\), and, consequently, \(\mu _i = \mu _j = 0\). By Eq. 19, we obtain \(q_v > (3/4)n\), meaning that when there is 100% agreement on participants, reaching a 75% validation quorum is sufficient to fully validate a ledger. Therefore, in Eq. 16 we have \(n > n/2 + n - (3/4)n + t_i\), from which we obtain \(t_s (= t_i) < (1/4)n\), whereas from Eq. 18 we obtain \(t_l < n - (3/4) n = (1/4) n\). As a result, in case \(UNL_i = UNL_j\) and \(q_v = 0.75 n\), both the tolerances are 0.25n. This means that when less than 25% of trusted nodes are Byzantine, the protocol functions properly.

Keeping valid the assumption \(UNL_i=UNL_j\), now we show how \(t_s\) and \(t_l\) vary when \(q_v\) is equal to 0.8n, as required by the current XRP LCP specification. In this case, the value of the two tolerances are no longer equal: \(t_s < (3/10) n\), and \(t_l < (1/5) n\). Compared to the previous case in which \(q_v = 0.75 n\), here the liveness tolerance is lower than the safety fault tolerance, and this implies that the system ability to not get stuck is slightly weakened.

Overlapping UNLs. So far the analysis has focused on the circumstance where the network is composed of a unique UNL. However, the validation quorum increase takes on greater significance in the context in which the UNLs of any two nodes i, j do not completely overlap, i.e. when at least one of the two parameters \(\mu _i\) and \(\mu _j\) is \(>0\). In this regard, we now turn our attention to the total non-overlapping component resulting from the sum of the two individual surpluses \(\mu _i\) and \(\mu _j\) of Eq. 17:

$$\begin{aligned} \mu _i + \mu _j < -n + 2q_v - 2t_s. \end{aligned}$$
(20)

Let us now consider two cases in which we set the validation quorum first to \(80\%\) and then to \(90\%\) of the nodes. In the former case, \(q_v=0.8n\) and assuming \(t_s=0.2n\), we can safely allow up to a non-overlap of 0.2n. In the latter case, \(q_v=0.9n\) and assuming \(t_s=0.1n\), the maximum non-overlap we can safely allow is 0.6n. Thus, as the above bounds show, as \(q_v\) increases, the degree of freedom of any node in the choice of validators to trust, in turn, increases.

To conclude, if we want the system to have a little more liveness, we can increase the sizes of the surplus node sets \(\mu _i\) and \(\mu _j\). Recalling that \(t_l\) depends on the quantity \(n_i - q_v\), as the values \(\mu _i\) and \(\mu _j\) increase, we obtain a higher validation quorum (cf. Eq. 19), and hence the maximum number of allowed Byzantine nodes to guarantee liveness increases. Let us consider an overlap of 90%, i.e. a non-overlap of 10%. If the safety fault tolerance is \(0.2 n_i\), from Eq. 16 we obtain \(q_v > 0.75 n_i\), and \(t_l < 0.25 n_i\). In contrast, if the safety fault tolerance is \(0.25 n_i\), we obtain \(q_v > 0.8 n_i\), and hence, \(t_l < 0.2 n_i\). From this analysis, it emerges that safety and liveness tolerances, validation quorum, and UNLs overlapping set size are strictly correlated, and it is possible to tune these parameters according to the desired properties the system needs to satisfy.

Currently, if no configuration changes are made, each node adopts the default and recommended UNL provided by Ripple. This essentially implies that no disagreement on the participants in the network is allowed, since all the nodes listen to a single list of validators. Accordingly, the XRP LCP is really able to guarantee that the network cannot get stuck as long as the number of Byzantine nodes within the system is limited.

6 Related Work

Research on blockchain platforms has only recently focused on the problem of assessing their underlying consensus protocols on the basis of non-functional properties (with special emphasis on security and privacy). In literature, the work in [16] has been the first to formalize and analyze the fundamental principles behind the Nakamoto consensus, presenting an abstraction of the Bitcoin protocol in synchronous networks (referred to as the Bitcoin backbone) and proving that it satisfies certain security properties. This analysis was later extended in [29], where the authors proved that the protocol satisfies a strong form of consistency and liveness in an asynchronous network with a model allowing for dynamic participation and adaptive corruption (assuming a-priori bounded adversarial delays). Further refinements of the above original model of computation were subsequently presented in [17, 18]. Recently, the analysis conducted in [3] focused on the study of the economic forces governing the tension between honest participants and deviating ones, and showed that these forces affect participants’ behavior in a way that rational participants end up behaving honestly because this strategy gives them the best utility. A number of other papers have studied the security of several Bitcoin-like consensus mechanisms in a rigorous manner [4, 13, 22, 30]. Although the majority of current research is dealing with blockchains in the permissionless setting, work begins to appear that explores the theoretical foundation and feasibility of reaching consensus in the permissioned setting. For example, the study in [23] formulated an abstraction of the Stellar network by introducing the notion of Personal Byzantine Quorum Systems, whereas the work in [19] established a correspondence between the federated voting protocol of Stellar and another protocol for reliable Byzantine broadcast with the aim at putting the basis for their rigorous formalization and proof of correctness.

7 Concluding Remarks

Blockchain technology is widely envisioned as a game-changer for facilitating the transfer of units of value and for securing data. The most important component that all existing DL approaches have in common is a consensus protocol allowing participants to agree on the exact series of events and their outcome at any point in time. The interest in consensus protocols has recently triggered a stimulating line of work aiming at in-depth analysis and rigorous formalization of the security properties holding for the blockchain-based protocols. As a result, in some cases, it has been possible to discover weaknesses or attacks against commonly used blockchain platforms resulting from unforeseen scenarios or weak assumptions that did not hold up during the execution of the protocol [29]. In other cases, the formalization effort has been directed to answer some fundamental questions about the required properties that a DL protocol and its implementation must satisfy [16].

In this paper, we presented a formalization of the XRP Ledger Consensus Protocol, analyzing in detail the process, the interactions amongst the participants, and the timing assumptions necessary for its correct functioning. We gave also a definition for two key security properties for the XRP LCP, that are safety and liveness, and the conditions under which they can be guaranteed, analyzing the correlation amongst some protocol parameters and showing how they can be leveraged to meet some desired liveness/fault tolerance.

Our work can serve as the basis for a further precise description of the XRP Ledger platform relying on some formal language that can be used as input to (semi-)automatic verification tools, in order to prove and verify the correct implementation of the consensus process. In this direction, we plan to provide a complete formalization of the XRP LCP, extending its coverage, and proving additional security properties, in relation also to other blockchain based protocols. The goal is to achieve a deep understanding of the underlying consensus mechanisms, and to foster a comparative analysis, considering both security and performance aspects.