# Why does Ripple's consensus process have a 80% threshold?

A transaction is confirmed if 80% of the nodes in the UNL accept it. Where does this 80% number come from? Could it just as well have been 79% or 81%? What about 51%?

Can different nodes have different thresholds (for faster transactions, say), or must they all follow the same rule?

• The explanation video says it is "the threshold for mathematical certainty"... Commented Apr 26, 2013 at 1:31
• @StevenRoose Yeah, but is it? I mean, why not 90% or 75%? Commented Apr 26, 2013 at 2:52

If validators waited until other validators declared consensus to declare consensus themselves, no validator would ever declare consensus. So you must declare consensus and hope you turn out to be right. Most of the time you will be. If not, you will later not be mathematically certain of the results and will not pass them on to clients.

If you use a 75% threshold for mathematical certainty, many times you wouldn't be certain and would have to repeat the process. If you picked a 90% threshold for mathematical certainty, you'd be certain almost all of the time, but you'd be wasting time.

The video is a bit misleading. In fact, any threshold could be used and you would still have mathematical certainty if you actually did reach consensus. However, if you set the threshold too low, you would only rarely have certainty. 80% is the threshold we've chosen for mathematical certainty because it's a compromise that results in certainty being reached often and quickly.

Maybe that's not clear enough. Let me try it another way. When we report a transaction as fully validated, we want to be mathematically certain of that. We will not make such a report until we are. Choosing 80% as the consensus threshold allows us to reach consensus quickly, requires at least 20% of validators to be completely malicious to delay consensus, and allows us to (in a later step) be mathematically certain of the result almost all of the time.

Note that almost all of the time is not always. Sometimes, we reach 80% and later are not certain of the results. In that case, we wait until the next consensus round completes and hope we fare better in that one.

Say for some stupid reason you set your threshold to 10%. You would think you had consensus all the time. But equally obviously, a lot of the time there would be no actual consensus. If there were, you could be certain that it had happened (because you would see it). But it often wouldn't happen, and then validators would have to resynchronize and clients would be waiting patiently for the network to fix itself so their transactions can be confirmed.

Ledgers that pass the consensus process are still held up by the "validation gate". They are not reported to clients as "fully validated" until they pass this gate.

80% worked very, very well in simulation. Validators are free to change this threshold if they want. Perhaps in a future network topology, a different threshold will give better performance characteristics.

It's hard to write clearly at 3AM. Maybe I'll rewrite this when I'm more awake.

• "Sometimes, we reach 80% and later are not certain of the results." Why would you be "not certain" when 80% is the very definition of certainty? Do you mean you wouldn't be certain "in a later step" (which you allude to)? "... requires at least 20% of validators to be completely malicious to delay consensus." That's 20% + 1, right? And what is the definition of "fully validated?" (By the way, your detailed answers are much appreciated. I'm sure this will be useful to anyone taking an interest in Ripple.) Commented Apr 27, 2013 at 21:45
• Once you reach the 80% threshold, you move on to mathematical certainty. If you didn't actually have a consensus, the certainty step would fail. A transaction is "Fully validated" if a majority of validators you trust have signed off on a ledger that includes it. If there's no actual consensus, then the ledger won't fully validate. (Which is fine, it just wastes time.) Commented Apr 27, 2013 at 23:19
• So there are two steps: (1) consensus (80%); (2) validation (majority of validators). But why two steps? And how much is the "majority" in the second step? Commented Apr 27, 2013 at 23:32
• There need to be two steps because someone has to build a ledger first or nobody ever will. Think of a crowd of people walking towards two doors and they want to walk through the same door. Once 80% are closer to one door, you walk through it. Then you look back to see if everyone follows you (if so, you are mathematically certain you walked through the right door). If not, you failed and try again. The majority in the second step is currently 50+%. Commented Apr 27, 2013 at 23:36
• Why ripple needs 80% of threshold in consensus? What is the mathematical prove behind that? Why not 66% threshold? Because i think 66% threshold in consensus is enough to validate a transaction in a distributed environment. Because (2m+1)/(3m+1) equation gives a valid threshold in a Byzantine fault, where 2m+1 represents the genuine validation nodes and 3m+1 represents the entire validation nodes. Commented May 18, 2014 at 7:54