Jump to content
achuthomas

Ripple Concensus vs PBFT or any other consensus algorithm

Recommended Posts

#1: Speed & throughput. PoW approaches currently in demonstrable widespread use (Ethereum, Bitcoin etc) typically have block-times ranging from 10-15 seconds up to 10-15 minutes, and can only handle a comparatively tiny number of transactions per second versus consensus/BFT that have similar uptake.

#2: One of the reasons for the creation of the original Ripple network and XRP was specifically to come up with something less-wasteful (more environmentally-friendly) than PoW.  Whilst being terribly slow, PoW also throws away vast computing resources and electricity by comparison.

I'm not sure on the specific differences between PBFT and the consensus mechanism in use on the XRP Ledger, but AFAIK they involve similar tradeoffs in terms of agreement.

Finally, as I understand it, an upgrade to the consensus protocol, called "Cobalt" plans to address some issues regarding agreement distributions (though maybe not the one you are concerned with here).

I'm interested to know - why do you think this 20% matters?  Can you foresee a situation where this could cause a problem?  Each node has its own UNL so if problems with specific nodes keep cropping up they can simply be cut out of the consensus process and bring the network back into agreement were it to halt for a while due a malicious collusion.

Share this post


Link to post
Share on other sites

There are always tradeoffs depending on the use case. Tyour use of the word "reliable" is a bit broad. For example, in PBFT closed ledgera are final but the finality of blocks in PoW is probabalistic. The uncle rate is Etherum is 40% driving up the number of required confirmations and making a transaction in a single new block less reliable than a transaction in a new closed ledger. There are tradeoffs for each particular consensus model and the goal implement a model that you believe aligns with the purpose of the network. XRPL is a payment network so they've optimized for speed, efficiency, and finality of settlement. 

Share this post


Link to post
Share on other sites
4 hours ago, cmbartley said:

There are always tradeoffs depending on the use case.

I don't think there are always trade off. Very often some algorithms outperform others on all the fields.

8 hours ago, achuthomas said:

If Ripple only assures a consensus if less than 20% of the node are byzantine then why is it the consensus algorithm preferred by Ripple than PBFT or PoW which looks like more reliable consensus algorithm

The real question is why they didn't switch to Stellar Consensus Algorithm which seems better than Ripple Consensus?

8 hours ago, Professor Hantzen said:

I'm interested to know - why do you think this 20% matters?  Can you foresee a situation where this could cause a problem?  Each node has its own UNL so if problems with specific nodes keep cropping up they can simply be cut out of the consensus process and bring the network back into agreement were it to halt for a while due a malicious collusion.

Yeah I can see lots of situations. Now to not have problems (i.e. forks) everyone should use Ripple's preferential UNL. Now if I want to run my validator I have to use at least 90% of the validators in that UNL otherwise I can have problems. Isn't that a HUGE limitation? Basically to achieve consensus we need to achieve first consensus on the list of good validators. And to achieve that consensus everyone agreed on using Ripple's UNL, i.e. a centralized list of "good" validators.

Share this post


Link to post
Share on other sites
5 hours ago, tulo said:

real question is why they didn't switch to Stellar Consensus Algorithm which seems better than Ripple Consensus?

Stellar is slower. 2s matter for retail payments. 

Stellar seems like it handles non overlapping UNLs better but we havent seen any hard data around this... 

Edited by cmbartley

Share this post


Link to post
Share on other sites
7 hours ago, cmbartley said:

Stellar is slower.

I'm not so sure if that's because of parameters they chose or because of something inherent to their algorithm (more coordination overhead etc.).

It would be nice if XRPL and Stellar were added to a framework like https://github.com/hyperledger/caliper to get a bit more reproducible data.

Share this post


Link to post
Share on other sites
11 hours ago, cmbartley said:

Stellar is slower. 2s matter for retail payments. 

Stellar seems like it handles non overlapping UNLs better but we havent seen any hard data around this... 

We see the data...it works. I'm more afraid of the theoretical limits which weren't ever mentioned or addressed.

Share this post


Link to post
Share on other sites

×