ripple consensus - mathematical certainty for all unl graphs?

2

It has been stated that ripple reaches to consensus with mathematical certainty. If we analyze the consensus protocol, we can see that a specific validator can have a very narrow view of the state of the rest of the validators. At least 80% of his unl list must have proposed to include the transaction. Each of them received from 70% of their unl list such a proposal etc....

Unless all those nodes represent the 80% of the unl list of any validator, one cannot assume that the initial validator has knowledge there has been a global consensus on the new ledger.

A problematic example is a unl graph whose directed distance is more than 6 and has low connectivity.

Is this correct? if true what are the assumptions ripple makes on the unl graph so that the above happens?

Edit: wouldn't 2 disconnected networks reach to 2 different consensi, and thus have complete luck of knowledge of the second consensus? If we assume a graph and 2 subgraphs that are connected but have a core that is far away from their boundary. A validator that is inside that core, it will assume that consensus has been reached and only the validators at the boundary will know that there is no consensus. In other words, shouldn't the unl list be build by a uniform random selection of all the trustworthy validators,or there is chance to not be able to detect the absense of consensus?

Apostolis Xekoukoulotakis

Posted 2014-07-17T09:08:47.887

Reputation: 31

Answers

4

The conclusion that no consensus has been reached is a valid conclusion and can result due to poor topology or Byzantine failure. Certainty is always with respect to something that has occurred in the past. It is not possible to know with certainty the present state without observing at more points than will normally be possible.

So each server runs out ahead of what it knows for certain, applying transactions and attempting to reach consensus on them. When and if a consensus is in fact produced, the server later determines this with certainty, and thus can advance what it knows for certain.

Essentially, the consensus process produces a a stream of signed messages called "validations" from which it's possible to determine with certainty whether a consensus had actually been reached at some point in the past.

It is possible to create UNL topologies that frequently fail to reach consensus. The plan is to have Ripple servers build their UNLs using an algorithm that makes such topologies exceedingly unlikely.

Even with a perfect topology, two types of Byzantine failures are possible.

One, which is not that uncommon (one out of every 200 rounds or so), is a local failure. In order for a consensus to ever arise, someone has to declare a consensus. And for that to happen, someone must declare a consensus first. When that happens, whoever makes that declaration can't know for certain that others will declare that same consensus (or they would have already done so, and so he wouldn't be first). So it's always possible that he declares the wrong consensus.

In this case, the server that suffered the Byzantine failure quickly discovers that the other validators have built a different ledger than it did and it begins its resynchronization process. Other servers will still, from the validations, which ledger was the majority ledger.

A much less common type of failure is complete Byzantine failure. In this case, several servers declare different consensuses and there is no clear majority ledger. In this rare case, the network as a whole must reconverge before a true consensus will emerge. Ripple has an algorithm to do exactly this. Servers will see the conflicting validations and know with certainty that there was no actual consensus.

David Schwartz

Posted 2014-07-17T09:08:47.887

Reputation: 46 931

Asked: 2014-07-17T09:08:47.887

Viewed: 369 times

Active: 2014-07-18T04:13:45.597