While many components of utility are subjective, one that is indeed provable is convergence: that the consen-sus process will terminate in finite time.
Figure 1.Probability of a nefarious cartel being able to thwart consensus as a function of the size of the UNL, for different values of pc, the probability that any member of the UNL will decide to collude with others. Here, lower values indicate a higher probability of consensus success.
3.4.1 Convergence
We define convergence as the point in which the RPCA reaches consensus with strong correctness on the ledger, and that ledger then becomes the last-closed ledger. Note that while technically weak correctness still represents convergence of the algorithm, it is only convergence in the trivial case, as propositionC3 is violated, and no transactions will ever be confirmed. From the results above, we know that strong correctness is always achiev-able in the face of up to (n 1)/5 Byzantine failures, and that only one consensus will be achieved in the entire network so long as the UNL-connectedness con-dition is met (Equation 3). All that remains is to show that when both of these conditions are met, consensus is reached in finite time.
Since the consensus algorithm itself is deterministic, and has a preset number of rounds, t, before consensus is terminated, and the current set of transactions are de-clared approved or not-approved (even if at this point no transactions have more than the 80% required agree-ment, and the consensus is only the trivial consensus), 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. While this guarantees that consensus will terminate with an upper bound of tb, it is important to note that the bounds described for correctness and agreement above must be met by the final UNL, after all nodes that will be
dropped have been dropped. If the conditions hold for the initial UNLs for all nodes, but then some nodes are dropped from the network due to latency, the correctness and agreement guarantees do not automatically hold but must be satisfied by the new set of UNLs.
3.4.2 Heuristics and Procedures
As mentioned above, a latency bound heuristic is en-forced on all nodes in the Ripple Network to guarantee that the consensus algorithm will converge. In addi-tion, there are a few other heuristics and procedures that provide utility to the RPCA.
• There is a mandatory 2 second window for all nodes to propose their initial candidate sets in each round of consensus. While this does intro-duce a lower bound of 2 seconds to each consen-sus round, it also guarantees that all nodes with reasonable latency will have the ability to partici-pate in the consensus process.
• As the votes are recorded in the ledger for each round of consensus, nodes can be flagged and removed from the network for some common, easily-identifiable malicious behaviors. These in-clude nodes that vote “No” on every transaction, and nodes that consistently propose transactions which are not validated by consensus.
• A curated default UNL is provided to all users, which is chosen to minimize pc, described in sec-tion 3.2. While users can and should select their own UNLs, this default list of nodes guarantees that even naive users will participate in a consen-sus process that achieves correctness and agree-ment with extremely high probability.
• A network split detection algorithm is also em-ployed to avoid a fork in the network. While the consensus algorithm certifies that the transac-tions on the last-closed ledger are correct, it does not prohibit the possibility of more than one last-closed ledger existing on different subsections of the network with poor connectivity. To try and identify if such a split has occurred, each node monitors the size of the active members of its UNL. If this size suddenly drops below a preset threshold, it is possible that a split has occurred.
In order to prevent a false positive in the case where a large section of a UNL has temporary latency, nodes are allowed to publish a “partial
validation”, in which they do not process or vote on transactions, but declare that are still partic-ipating in the consensus process, as opposed to a different consensus process on a disconnected subnetwork.
• While it would be possible to apply the RPCA in just one round of consensus, utility can be gained through multiple rounds, each with an increas-ing minimum-required percentage of agreement, before the final round with an 80% requirement.
These rounds allow for detection of latent nodes in the case that a few such nodes are creating a bottleneck in the transaction rate of the network.
These nodes will be able to initially keep up dur-ing the lower-requirement rounds but fall behind and be identified as the threshold increases. In the case of one round of consensus, it may be the case that so few transactions pass the 80% threshold, that even slow nodes can keep up, lowering the transaction rate of the entire network.
4. Simulation Code
The provided simulation code demonstrates a round of RPCA, with parameterizable features (the number of nodes in the network, the number of malicious nodes, la-tency of messages, etc.). The simulator begins in perfect disagreement (half of the nodes in the network initially propose “yes”, while the other half propose “no”), then proceeds with the consensus process, showing at each stage the number of yes/no votes in the network as nodes adjust their proposals based upon the proposals of their UNL members. Once the 80% threshold is reached, consensus is achieved. We encourage the reader to ex-periment with different values of the constants defined at the beginning of “Sim.cpp”, in order to become familiar with the consensus process under different conditions.
5. Discussion
We have described the RPCA, which satisfies the con-ditions of correctness, agreement, and utility which we have outlined above. The result is that the Ripple Pro-tocol is able to process secure and reliable transactions in a matter of seconds: the length of time required for one round of consensus to complete. These transactions are provably secure up to the bounds outlined in sec-tion 3, which, while not the strongest available in the literature for Asynchronous Byzantine consensus, do
allow for rapid convergence and flexibility in network membership. When taken together, these qualities allow the Ripple Network to function as a fast and low-cost global payment network with well-understood security and reliability properties.
While we have shown that the Ripple Protocol is provably secure so long as the bounds described in equa-tions 1 and 3 are met, it is worth noting that these are maximal bounds, and in practice the network may be secure under significantly less stringent conditions. It is also important to recognize, however, that satisfying these bounds is not inherent to the RPCA itself, but rather requires management of the UNLs of all users.
The default UNL provided to all users is already suffi-cient, but should a user make changes to the UNL, it must be done with knowledge of the above bounds. In addition, some monitoring of the global network struc-ture is required in order to ensure that the bound in equation 3 is met, and that agreement will always be satisfied.
We believe the RPCA represents a significant step forward for distributed payment systems, as the low-latency allows for many types of financial transactions previously made difficult or even impossible with other, higher latency consensus methods.
6. Acknowledgments
Ripple Labs would like to acknowledge all of the peo-ple involved in the development of the Rippeo-ple Protocol consensus algorithm. Specifically, Arthur Britto, for his work on transaction sets, Jed McCaleb, for the original Ripple Protocol consensus concept, and David Schwartz, for his work on the “failure to agree is agreement to de-fer” aspect of consensus. Ripple Labs would also like to acknowledge Noah Youngs for his efforts in preparing and reviewing this paper.
References
[1] Nakamoto, Satoshi. “Bitcoin: A peer-to-peer elec-tronic cash system.” Consulted 1.2012 (2008): 28.
[2] Lamport, Leslie, Robert Shostak, and Marshall Pease. “The Byzantine generals problem.” ACM Transactions on Programming Languages and Sys-tems (TOPLAS) 4.3 (1982): 382-401.
[3] Attiya, C., D. Dolev, and J. Gill. “Asynchronous Byzantine Agreement.” Proc. 3rd. Annual ACM Symposium on Principles of Distributed Computing.
1984.
[4] Fischer, Michael J., Nancy A. Lynch, and Michael S. Paterson. “Impossibility of distributed consensus with one faulty process.” Journal of the ACM (JACM) 32.2 (1985): 374-382.
[5] Martin, J-P., and Lorenzo Alvisi. “Fast byzan-tine consensus.” Dependable and Secure Computing, IEEE Transactions on 3.3 (2006): 202-215.
[6] Alchieri, Eduardo AP, et al. “Byzantine consensus with unknown participants.” Principles of Distributed Systems. Springer Berlin Heidelberg, 2008. 22-40.