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.
As one of the most famous blockchain projects, Ripple plays the role of the bridge among different currencies. It is an Internet transaction protocol which allows people to pay in any currency. Its XRP token was ranked seventh in market capitalization in March 2021. The Ripple network adopts the Ripple consensus protocol as its underlying consensus support to prevent double-spending and ensure the consistency of the network. Unlike proof-of-series consensus adopted in other digital cryptocurrency (such as PoW in Bitcoin [
However, the safety and the liveness of the Ripple consensus protocol is still controversial, because it's more complicated to reach an agreement in decentralized trust model with Byzantine faults. As described in the original whitepaper [
The liveness of the Ripple consensus protocol is another controversial point, which was first analyzed in [
Another disadvantage of the Ripple consensus protocol is that it relies on the synchrony timing assumption. It needs a global heartbeat timer to proceed and enter the next phase during consensus, which is shown in their open source code. This contrasts with other BFT protocols, like weak synchrony assumption in PBFT [
This paper proposes Ripple+, an improved scheme of the Ripple consensus protocol in three aspects:
Our trust model, in addition to solving the problem of deployability, is also reasonable. Node diversity is common in reality. Similar to other permissionless blockchain projects, in which some super nodes take more responsibilities for the blockchain network, these nodes may have higher power in the role of reality, or they may have more computing power and bandwidth in the network. Thus, they are more suitable to be the core node of the network to take on more tasks in terms of power, resources and reliability. For example, among the banks that access current Ripple to realize a high-performance global payments business, a few strong banks should be selected as the core nodes and others play the role of the leaf nodes.
We implemented a prototype of Ripple+ with Go language and conducted simulation experiments on a single server to evaluate its performance, in terms of latency, throughput and cost of view change mechanism. On the basis of the experimental results, Ripple+ can achieve a peak throughput of over 10,000 tx/s with about two seconds latency when the core set size is set to 10. While the peak throughput decreases to 2,500 tx/s and the latency increases to 5 s when the core set size increases to 20. As the core set size continues to grow, the latency increases rapidly. Compared with 20 core set size, the latency is approximately six times that of the original when the core set size is doubled. In addition, the cost of view change is only about one hundredth of the consensus latency, which implies that the view change mechanism will not affect the efficiency of Ripple+ seriously. The above experimental results indicate that Ripple+ is suitable to be the consensus support of permissionless blockchain in terms of both latency and throughput.
Researches on the Byzantine fault tolerant (BFT) protocol have been going on for nearly 40 years since Lamport et al. [
For specific consensus protocol under the decentralized trust model other than Ripple, Stellar [
The Ripple consensus protocol runs in a permissionless blockchain. Each node in the Ripple network maintains the same ledger and connects with each other via the gossip network. A set of clients update the ledger by submitting transactions to the gossip network. Decentralized trust is a distinctive feature of Ripple. For a node
Roughly speaking, the protocol consists of three phases:
Open phase: The clients submit transactions to all nodes via the gossip network, then all nodes get the submission and update their candidate set. The open phase ends after a certain period. Establish phase: The nodes attempt to agree on a set of transactions based on the prior ledger at a regular interval. Each node proposes the transactions in the candidate set as well as their current ledger state as their initial proposal. The nodes only consider the messages received from their UNL that update based on the identical ledger. All nodes propose to each other iteratively in several synchronous rounds, and the transactions whose support rate reaches the threshold in this round will be proposed in the next round, until a quorum of the UNL has the same proposals with its own. In the current Ripple implementation, the threshold goes Accepted phase: The nodes validate the last closed ledger by gossiping the last closed ledger state via a validation message. Once a node finds that there is a quorum of its UNL with an identical last closed ledger state, the ledger will become a fully validated ledger.
Before starting the establish phase, the nodes will perform the preferred branch algorithm in advance to ensure that there are enough correct nodes working on the identical ledger, otherwise the system may get stuck. The nodes maintain the ledger states of all nodes in its UNL, and update the states according to the validation messages. The nodes construct an ancestor tree according to the ledger sequence and the dependency relationship, and calculate the support count of each ledger in the tree (i.e., the number of the ledgers in the same branch with it, including itself). Then, starting from the root
In [
The liveness of the Ripple consensus protocol is analyzed in [
Some other related researches elaborate and improve Ripple in different aspects. Mauri et al. [
Most of our assumptions are based on Ripple. Specifically, Ripple+ runs in an open system with Byzantine faults. Each node in the network maintains a UNL, which is a set of nodes that it trusts. The node makes decisions only depending on the proposals of its UNL. The network contains a relatively reliable set of nodes, which we call the core set, and the nodes in the core set are called core nodes. All core nodes trust each other and select the core set itself as its UNL. The core set is the basis to ensure safety and liveness. One of the core nodes is chosen to be the primary at any time, which is responsible for receiving the transactions submitted by the clients and gossiping them to all nodes. The primary will be changed to the node in the next position in the core set when a timeout occurs. It can help us to ensure liveness even if the scenario described in [
Two kinds of ledgers are maintained by all nodes in the system. The last closed ledger is the most recent ledger that records the latest ratified transactions by a consensus period, while the fully validated ledger is the validation result of the updated last closed ledger. The fully validated ledger represents the state of the current work. In normal cases, two correct nodes will commit the same totally ordered transactions to the ledgers with an identical ledger state, thus generating the identical new ledger. The ledger may be forked due to possible faults and network delays. When it occurs, the node will check and switch to the preferred ledger.
We assume that all core nodes and their addresses are public to the whole network, which means that each pair of correct core nodes is connected by a reliable authenticated point-to-point channel to ensure that the messages can be delivered correctly. Therefore, we use “broadcast” when the messages are propagated only in the core set (this only occurs in the view change mechanism in Ripple+). By contrast, the leaf nodes are unknown to the whole network, thus the core nodes communicate with the leaf nodes via a gossip network. We use “gossip” in this case to differ from “broadcast” in the following paper. The leaf node can join the gossip network by informing several core nodes of its address.
Compared with the strong synchronous clocks in Ripple, Ripple+ only relies on the weak synchrony assumption, which implies that the delay bound is time varying, but does not grow faster than a polynomial function of time indefinitely. We consider it as a timing assumption which is more suitable for the real Internet environment. However, the timeout is adopted in Ripple+ when view change is carried out, as we cannot violate the FLP impossibility [
As shown in
A consensus period begins when the clients submit the transactions and ends when the transactions are committed to the fully validated ledger. In normal cases, a consensus period composes of four phases:
Submit phase: The clients submit their transactions to the primary, which then receives, checks, wraps and sends these transactions via the gossip network to start a new consensus period. Open phase: When a node receives the transactions from the primary, it generates its initial proposal and gossips it to start iterations. Establish phase: The transactions are proposed iteratively among all nodes in several rounds, until there is a transaction set that a quorum of the UNL agrees on. Then the transaction set will be committed to the last closed ledger, and a validation message of the updated last closed ledger state will be gossiped. Accepted phase: When there is a quorum of the UNL that agrees on the identical last closed ledger, the update will be applied to the fully validated ledger.
When a timeout occurs, which means that there are some valid transactions that have not been committed for a period of time, a view change will be carried out and the primary will be changed to the node in the next position in the core set. Assuming that at most 20% of the core nodes are Byzantine nodes, the scenario in [
In this section, we elaborate each phase of Ripple+ in normal cases, the pseudocode is presented in
In the original Ripple, the clients send transactions to all nodes via the gossip network to let as many nodes as possible receive these transactions. The clients do not know exactly who will propose for the transactions they submit, and the nodes do not know exactly how many transactions are submitted. The nodes enter the next phase only after a duration, which is related to the duration of the previous consensus period. Ripple+ introduces a primary to receive the clients’ submissions and determine when to enter the next phase. The primary is chosen from the core set in turn according to the current view number, and its identity is public to all clients and nodes for verification. In the submit phase, the clients only submit their transactions to the primary. The submissions will be forwarded to the primary if other nodes receive them. When the primary considers that it has received enough transactions, it wraps the transactions into a batch and sends them via the gossip network.
When the node receives a gossip message including a list of transactions from the primary, it will start a new consensus period. Firstly, the node initializes its state, including the round number and the proposals of its UNL maintained by its own. Then it checks whether it works on the preferred ledger according to the recent validation messages of the nodes in UNL stored locally. If not, it will switch to it. After that, it generates its initial proposal based on the transactions received from the primary as well as its current last closed ledger state, then gossips it.
The establish phase can be divided into several rounds. In each round, the node receives the proposals from its UNL continuously and maintains their proposal states. When the node has received proposals from a quorum of its UNL in this round, it counts votes for all transactions based on the latest proposal of all nodes in the UNL. The transactions whose support rate exceeds the threshold in this round will be proposed in the next round. This differs from the original Ripple that the latter carries out a vote count only after a predetermined time interval, which means that the process in this phase is synchronous. After the node gossips the new proposal, it will check whether it has reached an agreement with the nodes in its UNL. If there is a quorum of UNL who proposes the identical transaction list with the node and they all state that they are working on an identical ledger, then the node considers that the agreement has been reached and it will commit these transactions to the last closed ledger. After updating the ledger, the node will gossip a validation message containing the state of the updated last closed ledger and enter the accepted phase.
The node maintains the validation states of all nodes in its UNL locally based on the latest validation messages it receives. When a ledger is supported by a quorum of the UNL, the fully validated ledger will be updated to this ledger. Note that even if there is not an agreed-upon ledger, the consensus will not get stuck. The reason is that the accepted phase is parallel to other phases. When the preferred ledger check is carried out in the open phase of the next consensus period, all correct nodes will switch to the same branch based on the validation states maintained locally and reach an agreement in the next consensus period.
As described above, we introduce the primary to avoid the possible scenarios occurred in [
View change is led by the core set, while the new view will apply to the whole network. We set a timer at each core node and catch timeout exception to determine when to start a view change with the help of the clients. Under normal conditions, only the primary can receive requests from clients. When other core nodes receive a message from a client containing some valid transactions which have not been committed, it starts a timer and forwards the message to the primary. The core node stops the timer when these valid transactions are committed, but restarts it when other valid transactions are received from the clients. If the timer expires, view change will be executed.
The process of the view change is shown in
When the core node in the next position of the core set receives the
Assuming that the system contains
According to Proposition 4 in [
Apparently,
In [
In [
According to Lemma 10 in [
We implemented a prototype of Ripple+ with Go and simulated several nodes on a single server, in which each node runs in an isolated goroutine. The nodes communicate with each other in HTTP POST manner and the communication delay is negligible. We use SHA256 as hash algorithm and ECDSA as digital signature algorithm for message authentication. Public/private key pairs are generated for each node in advance. All global parameters, such as the member of the core set, the quorum size and the threshold of each round, are pre-configured. In addition, we also simulate clients to submit transactions to the primary repeatedly, which then wraps the transactions into a batch and gossips it to all nodes to start a new consensus period. The batch size and the core set size are controlled to analyze the performance of Ripple+ under different conditions.
We take the ledger state of the core set to represent the whole network state. A consensus period finishes when a quorum of the core set updates their fully validated ledgers, while leaf nodes are omitted in our experiments as the messages from the leaf nodes will be ignored by all core nodes in our trust model. In our experiment, the number of the Byzantine nodes does not exceed 20% of each node's UNL size.
We analyze the performance of Ripple+ both in the ideal case and in the common case. Ideally, all nodes will take all the transactions received from the primary as the initial proposal in the establish phase, thus only one iteration is required to reach an agreement on the condition that the primary does not send inconsistent messages in the open phase. While in the common case, the initial proposal may only contain a subset of all transactions received from the primary in the open phase, causing the nodes to have different initial proposals. Thus, the establish phase will last several rounds. This is similar to the original Ripple, because multiple clients submit transactions via the gossip network and each node is not guaranteed to receive all transactions. We will compare the performance of Ripple+ in both cases.
Two metrics are employed to analyze the performance of Ripple+: (1)
We set the batch size to 100, then measured the average latency of a single consensus period.
The average latency of the establish phase and the validate phase per consensus period are further analyzed in
The cost of view change under different core set sizes is shown in
We present Ripple+, improving Ripple from deployability, liveness and timing assumption. It makes Ripple+ easy to deploy that Ripple+ introduces the core set and the guidelines for specifying the UNL choice. It has been proved that our guidelines meet the safety condition. Ripple+ evades the scenario that the system may get stuck by introducing a primary and view change mechanism. The method has been proved to be effective both theoretically and experimentally. In addition, the synchronous clocks and the timeouts are removed in the open phase and the establish phase to make Ripple+ fit for a weak synchrony network. Our experimental results show that Ripple+ is suitable to be consensus support of permissionless blockchain, in terms of both latency and throughput.
The authors would like to thank the undergraduate student Junye Zheng from the School of Cyberspace Science and Technology of Harbin Institute of Technology, who provided the experimental data.
In this appendix, we provide pseudocode for both normal cases and view change in Ripple+ described in
In [
Thus, we can obtain the range of
Now we discuss the range of their UNL overlap
Again, given the range of n shown in