## 3 Byzantine Fault Tolerance for Distributed-Ledger Systems
### Permissioned
#### 3.2.1 Ripple Consensus Protocol  
A notable example of a _semi-permissioned_ network is Ripple [11] and the consensus protocol that it is embodied in the XRP Ledger. The consensus mechanism implemented by Ripple (known as the Ripple Consensus Algorithm (RPCA)) is influenced by the idea of a Byzantine quorum system [26] where a minimum set of nodes (i.e., a quorum) collaborates to attain the agreement process. Specifically, for Ripple, the quorum is defined as a list of trusted nodes called the UNL. Each node that is trusted as a validating server to the XRP Ledger maintains its own UNL list and votes on transactions they support. Validating servers collaborate under a binding relationship and only trust the votes cast by other servers included in their UNL. Transactions that are broadcasted to the network are collected by the validating servers that are the ones that participate in the consensus. These transactions are then exchanged with the other validating servers for the creation of a candidate set of transactions. In brief, the process for advancing the ledger is done periodically in rounds and with voting from the nodes that are part of each validating server's UNL list [27]. For RPCA, each node defines a minimum number of agreeing nodes, denoted by \(q\), in the UNL list before committing to a decision. This is set to \(q_{i}=0.8\), which means that 80% of the UNL list must agree. According to [PERSON] al. [27], the network can tolerate \(f<n/5\), where, \(n\) is the number of nodes and \(f\) is the number of byzantine (faulty) nodes. Typically, a classical BFT protocol can tolerate \(f<(n-1)/3\). It is argued that Ripple is trading fault tolerance capabilities of the network in an attempt to increase performance. In addition, the high level of synchrony assumed by the nodes participating in Ripple's UNL list might be restrictive in environments of low trust [20; 24]. In addition, this impacts on the decentralization of the Ripple's network.  
In terms of network participation, anyone can deploy an instance of the Ripple network ([[https://github.com/ripple/rippled](https://github.com/ripple/rippled)]([https://github.com/ripple/rippled](https://github.com/ripple/rippled))), as well as act as a validator, contributing on that private instance. For example, the XRP Ledger is the ledger maintained by Ripple Labs, Inc. ([[https://ripple.com/](https://ripple.com/)]([https://ripple.com/](https://ripple.com/))).  
On another note, Stellar [28], which is a protocol initially forked from Ripple, further expands on the idea of a quorum by introducing quorum slices and federated byzantine fault tolerance. Thus, the Stellar Consensus Protocol (SCP) allows for a loose synchrony of participants and achieves a bound of \(1/3\) Byzantine fault tolerance compared to the \(1/5\) fault tolerant bound achieved by Ripple. Stellar allows more flexibility in terms of which participants to trust and thus for more decentralization when compared to RPCA, but it is less decentralized than the classical PoW [29]. For Stellar, safety is compromised when a user node trusts a quorum slice that is inefficient [28].