Ripple’s protocol ensures neither safety nor liveness, according to researchers at the University of Bern

A recent report and analysis by the Cryptology and Data Security Research Group at the University of Bern concludes that the Ripple protocol doesn’t ensure safety or liveness under the stated assumptions.

Ripple’s consensus protocol aims at ensuring that the same transactions are processed and validated ledgers are consistent across the network. It should protect the system against attacks and failure modes, such as malicious actors that may be attempting to control or interrupt the system at any given time.

The analysis shows how the Ripple consensus protocol can be violated using seven nodes. The setup basically consists of six good nodes and one bad node, referred to as the Byzantine node. 

Nodes 1, 2, and 3 (white) adopt UNL1, vertically hatched, and nodes 5, 6, and 7 adopt UNL2, horizontally hatched. Node 4 (gray) is Byzantine.

Using this particular setup, researchers were able to make two correct nodes execute different transactions which basically violates the agreement condition of the consensus protocol. While this was a demonstration with only seven nodes, researchers showed the same type of violation using an arbitrarily large number of nodes too. 

The liveness of Ripple consensus protocol is also at risk

In concurrent computing, liveness refers to a set of properties of concurrent systems. The analysis report shows how the liveness of the consensus protocol can be violated even when all the nodes are the same and only one is the Byzantine (bad) node. 

Researches were able to bring the protocol into a state that made it unable to produce a correct ledger and ultimately stopped making any progress. The conclusion of the report states that Ripple might be at risk adding:

Previous work regarding the Ripple consensus protocol has already brought up some concerns about its liveness and safety. In order to better analyze the protocol, this work has presented an independent, abstract description derived directly from the implementation. Furthermore, this work has identified relatively simple cases, in which the protocol may violate safety and/or liveness and which have devastating effects on the health of the network. Our analysis illustrates the need for very close synchronization, tight interconnection, and fault-free operations among the participating validators in the Ripple network.

It’s important to note that these attacks are just theoretical and were not demonstrated with a live network. However, these hypothetical attacks have often translated into real ones eventually which means Ripple must try to fix them in time.