7
3
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?
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 – 2013-09-16T17:13:32.627
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 – 2013-09-16T19:50:16.813
Two comments / Questions:
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?
Can't the trust graph be such that both sides think that they are in the majority, thus maintaining the inconsistency?
>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 – 2013-09-30T06:25:20.450