Jump to content
Sign in to follow this  
Zerping

What's the current XRPL threat model?

Recommended Posts

What's the threat model under which XRPL operates? At what percentage of Byzantine nodes will the network stop making forward progress? At what percentage can the network be "taken over"?

 

I've read somewhere that 10% of Byzantine nodes is the max the current XRPL can handle and that would increase to 40% if Cobalt is implemented. Are these numbers correct?

Share this post


Link to post
Share on other sites

From https://ripple.com/files/ripple_consensus_whitepaper.pdf 

In order to achieve correctness, given a maximal amount of Byzantine failures, it must be shown that it is impossible for a fraudulent transaction to be confirmed during consensus, unless the number of faulty nodes exceeds that tolerance. The proof of the correctness of the RPCA then follows directly: since a transaction is only approved if 80% of the UNL of a server agrees with it, as long as 80% of the UNL is honest, no fraudulent transactions will be approved. Thus for a UNL of n nodes in the network, the consensus protocol will maintain correctness so long as: f ≤ (n−1)/5 (1) where f is the number Byzantine failures. In fact, even in the face of (n−1)/5+1 Byzantine failures, correctness is still technically maintained. The consensus process will fail, but it will still not be possible to confirm a fraudulent transaction. Indeed it would take (4n+1)/5 Byzantine failures for an incorrect transaction to be confirmed. We call this second bound the bound for weak correctness, and the former the bound for strong correctness.

Share this post


Link to post
Share on other sites
6 minutes ago, fidgetspinner said:

From https://ripple.com/files/ripple_consensus_whitepaper.pdf 

In order to achieve correctness, given a maximal amount of Byzantine failures, it must be shown that it is impossible for a fraudulent transaction to be confirmed during consensus, unless the number of faulty nodes exceeds that tolerance. The proof of the correctness of the RPCA then follows directly: since a transaction is only approved if 80% of the UNL of a server agrees with it, as long as 80% of the UNL is honest, no fraudulent transactions will be approved. Thus for a UNL of n nodes in the network, the consensus protocol will maintain correctness so long as: f ≤ (n−1)/5 (1) where f is the number Byzantine failures. In fact, even in the face of (n−1)/5+1 Byzantine failures, correctness is still technically maintained. The consensus process will fail, but it will still not be possible to confirm a fraudulent transaction. Indeed it would take (4n+1)/5 Byzantine failures for an incorrect transaction to be confirmed. We call this second bound the bound for weak correctness, and the former the bound for strong correctness.

This has been shown to be wrong: https://arxiv.org/abs/1802.07242

Share this post


Link to post
Share on other sites
8 minutes ago, Sukrim said:

This has been shown to be wrong: https://arxiv.org/abs/1802.07242

If I understand Theorem 8 correctly, 90% consensus is required for network safety? I must admit I did a very brief scan, so apologies in advance.

 XRP LCP guarantees fork safety if Oi,j > nj/2 +ni −qi +ti,j for every pair of nodes Pi ,Pj . Note that although proposition 7 is an iff statement, the overlap condition in theorem 8 is only sufficient but not necessary for XRP LCP safety. This is because lemma 6 is not an iff statement. Further, there may be some validation configurations that cannot come out of deliberation, breaking our broad assumption that anything can come out of deliberation. However, it is the weakest condition that can be expressed purely as a bound on the size of overlaps. Once again assuming 80% quorums and 20% faults, the overlap condition in theorem 8 can be summarized as requiring roughly > 90% UNL overlaps. Although quite a narrow margin (and certainly far more narrow than originally expected), this does still allow a small amount of variation, which is very important for the XRP Ledger network’s transition to a recommended UNL comprised of independent entities. Having some flexibility in the UNLs is important both for after the diversification of trusted operators (as one can never guarantee total agreement on participants when the participants are independent entities) and also during the diversification process (if tiny disagreements during changes to the UNL list could cause a fork, then diversification would always be too risky to execute).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...