7

Ripple supposedly incorporates transactions into the ledger using a consensus protocol. I have been looking everywhere for a clear, formal, and precise specification of the protocol and could not find one.

Several related questions, e.g.,

What are the pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work?

and

How does Ripple solve the double-spend problem?

Only provide a vague description. More specifically, I am trying to understand the essence of the consensus: what happens if the Ripple network is split in half (for example if all communication lines between Europe and the US suddenly stop working), and each half of the network approves a ledger with a conflicting transaction. What happens when the network reconnects? How are the conflicting ledgers resolved?

| improve this question | |
7

If the Ripple network splits in half, then each half will validate ledgers independently, potentially with conflicting transactions. If all servers are properly configured, they will not accept any of these ledgers as fully validated, since none of them will have sufficient validations. It's possible both sides will think they're in the minority (if the split is close to 50/50).

This reflects a basic Ripple design principle -- don't tell people they can rely on results if the results are unreliable. If conditions make reliable operation impossible, it is preferable not to operate than to give people results they cannot rely on. Ripple is designed to detect these kinds of conditions.

When the network rejoins, servers will see the other ledger chain. They will gradually avalanche to the chain with more validations until one chain or the other has a super-majority of trusted validators. At that time, the network is back in agreement and everyone can again rely on the results of transactions.

| improve this answer | |
  • Does this means that in an 80-20 split that the 20% side knows they're in the minority and will effectively stop functioning (won't claim they have reliable ledgers) until re-joined where-as the 80% side will function as normal? So is a near 50-50 split bad because either (if correctly configured) both sides think their in the minority and the whole network stops or (if incorrectly configured) both sides may think their in the majority and attempt to continue as normal causing grief when re-joined? – dchapes Sep 16 '13 at 17:13
  • 3
    @dchapes Exactly. If reliable operation is not possible, not operating is better than operating unreliably. If you don't know you're in the majority, then you cannot operate reliably. It's hard to imagine what would cause a near 50-50 split (natural disaster?) but yeah, that would certainly make reliable resolution of the double spend problem impossible. – David Schwartz Sep 16 '13 at 19:50
  • Two comments / Questions: 1. your answer suggests that things that were previously considered to be in the ledger may after some time (following a network join) be removed (similarly to what happens in Bitcoin). Am I right? Is there a point where once can say this will happen with low probability without observing the full state of the network? 2. Can't the trust graph be such that both sides think that they are in the majority, thus maintaining the inconsistency? – Aviv Zohar Sep 30 '13 at 5:44
  • 1. Yes. If one has a representative set of validators on one's UNL, a supermajority of validators on your UNL have validated that ledger, and a supermajority of validators on your UNL have stated that they too see a supermajority (of the nodes on their UNLs) confirming that same ledger. 2. Only if the trust graph is very broken. It takes very little overlap to ensure that this does not happen and even less to know when you're at risk. (You can ask a question about how we plan to avoid this and I can give more details in an answer.) – David Schwartz Sep 30 '13 at 6:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.