Open Access

ARTICLE

Ripple+: An Improved Scheme of Ripple Consensus Protocol in Deployability, Liveness and Timing Assumption

Chuanwang Ma^1,*, Yu Zhang^1,2, Binxing Fang^1,2, Hongli Zhang¹, Yidong Jin³, Dasheng Zhou³

1 School of Cyberspace Science, Harbin Institute of Technology, Harbin, 150001, China
2 Peng Cheng Laboratory, Shenzhen, 518055, China
3 Beijing Jingning Data Technology Co., Ltd., Beijing, 100007, China

* Corresponding Author: Chuanwang Ma. Email:

(This article belongs to the Special Issue: Blockchain Security)

Computer Modeling in Engineering & Sciences 2022, 130(1), 463-481. https://doi.org/10.32604/cmes.2022.016838

Received 31 March 2021; Accepted 13 July 2021; Issue published 29 November 2021

Abstract

Ripple acts as a real-time settlement and payment system to connect banks and payment providers. As the consensus support of the Ripple network to ensure network consistency, Ripple consensus protocol has been widely concerned in recent years. Compared with those Byzantine fault tolerant protocols, Ripple has a significant difference that the system can reach an agreement under decentralized trust model. However, Ripple has many problems both in theory and practice, which are mentioned in the previous researches. This paper presents Ripple+, an improved scheme of Ripple consensus protocol, which improves Ripple from three aspects: (1) Ripple+ employs a specific trust model and a corresponding guideline for Unique Node List selection, which makes it easy to deploy in practice to meet the safety and liveness condition; (2) the primary and view change mechanism are joined to solve the problem discussed by the previous research that Ripple may lose liveness in some extreme scenarios; (3) we remove the strong synchrony clock and timeout during consensus periods to make it suitable for weak synchrony assumption. We implemented a prototype of Ripple+ and conducted experiments to show that Ripple+ can achieve the throughput of tens of thousands of transactions per second with no more than half a minute latency, and the view change mechanism hardly incurs additional cost.

---

Keywords

---