Jump to content
Sign in to follow this  
xrp123

What are the constraints for tps?

Recommended Posts

The announcement this week about dLab and their high volume transaction customers (Uber for example) made me think about the Ripple quoted 1500 tps limit. 

If performance is perfect and true to that number, with no down time, that means 90,000 t/minute, 5.4 mm t/hour and 129,600,000 mm t/day.

Companies like Uber do millions of rides/transactions per day.

As more and more companies and FIs adopt the Ripplenet suite of tools, is it possible that transaction demand could exceed network capacity?

If so, what are the constraints on TPS? Is it node based?

Has this question been asked already? 

Obviously, the Ripple team has probably already thought about this, but I tried to find a discussion here and my search didn’t yield any results.

Edited by xrp123

Share this post


Link to post
Share on other sites
3 hours ago, xrp123 said:

The announcement this week about dLab and their high volume transaction customers (Uber for example) made me think about the Ripple quoted 1500 tps limit. 

If performance is perfect and true to that number, with no down time, that means 90,000 t/minute, 5.4 mm t/hour and 129,600,000 mm t/day.

Companies like Uber do millions of rides/transactions per day.

As more and more companies and FIs adopt the Ripplenet suite of tools, is it possible that transaction demand could exceed network capacity?

If so, what are the constraints on TPS? Is it node based?

Has this question been asked already? 

Obviously, the Ripple team has probably already thought about this, but I tried to find a discussion here and my search didn’t yield any results.

Uber is actually a perfect example of processing payments via a micropayments processor. 

The XRPLedger handles micropayments via its payment channels, which scale horizontally - i.e. as more computer power is added, the TPS rate increases directly.  In initial tests, Ripple reached upwards of 70,000 TPS

Link for the press release regarding 70K TPS: https://www.cryptocoinsnews.com/ripple-claims-transaction-thoroughput-now/

Link for payment channels and how they work: https://ripple.com/build/payment-channels-tutorial/

Share this post


Link to post
Share on other sites
15 minutes ago, Hodor said:

Uber is actually a perfect example of processing payments via a micropayments processor. 

The XRPLedger handles micropayments via its payment channels, which scale horizontally - i.e. as more computer power is added, the TPS rate increases directly.  In initial tests, Ripple reached upwards of 70,000 TPS

Link for the press release regarding 70K TPS: https://www.cryptocoinsnews.com/ripple-claims-transaction-thoroughput-now/

Link for payment channels and how they work: https://ripple.com/build/payment-channels-tutorial/

Thanks @Hodor! It looks like I have my reading cut out for me.

Share this post


Link to post
Share on other sites
1 hour ago, Hodor said:

The XRPLedger handles micropayments via its payment channels, which scale horizontally - i.e. as more computer power is added, the TPS rate increases directly.  In initial tests, Ripple reached upwards of 70,000 TPS

These transactions can't be settled though, so to call an update of an escrowed payment channel "transaction" is stretching the term a bit...

Share this post


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

These transactions can't be settled though, so to call an update of an escrowed payment channel "transaction" is stretching the term a bit...

Isn't the goal that payment channels will work with upfront settlement for a certain amount?

Share this post


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

These transactions can't be settled though, so to call an update of an escrowed payment channel "transaction" is stretching the term a bit...

So you're contesting what Ripple is calling a transaction then?  They are the authority that used the term "transaction" per second.  (not me). 

Share this post


Link to post
Share on other sites
8 hours ago, Hodor said:

So you're contesting what Ripple is calling a transaction then?  They are the authority that used the term "transaction" per second.  (not me). 

Bitcoin then can also do tens of thousands of "transactions" per second if you use their version of PayChan or Lightning. Also RCL did not reach 70.000 TPS, even the 1500 TPS is in a synthetic benchmark on a local network with only 1% of accounts, only the most simple transaction type and high end machines. I did not find any source on how the 70k TPS would be achieved other than maybe benchmarking how fast a modern CPU can sign stuff with secp256k1.

It was actually their CEO that used this term on Twitter and he seems to be mixing up some of his products in that tweet - PayChan transactions don't take 3.7 seconds. XRP transactions don't scale up to 70000 (yet).

13 hours ago, kanaas said:

Isn't the goal that payment channels will work with upfront settlement for a certain amount?

"Upfront settlement" is just a nicer term for "depositing money ahead of time", not much different from creating IOUs. It doesn't really matter which side has the money when you start, sooner or later you'll have to balance out or "settle". You can't do that 70000 times per second. You might be able to change the amounts you owe each other up to 70000 times per second though.

Share this post


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

Bitcoin then can also do tens of thousands of "transactions" per second if you use their version of PayChan or Lightning. Also RCL did not reach 70.000 TPS, even the 1500 TPS is in a synthetic benchmark on a local network with only 1% of accounts, only the most simple transaction type and high end machines. I did not find any source on how the 70k TPS would be achieved other than maybe benchmarking how fast a modern CPU can sign stuff with secp256k1.

well said

yeah, i always assumed that PayChans were just a way to improve net/batch settlements or ideally for use in nanopayments where you need high-volume "instant" or off-network transfers but then want settlement at the end (3.7 secs) on-ledger, which to me says... batch processing

would love to hear your thoughts, obv this "settlement" type is via xrp (most likely), so would then have to go through to a real FI's ledger, although i heard it said on this forum a while back by some devs that you could in theory use issuances with PayChans (could be wrong)... although then again, Ripple issuances are NOT final settlements, you'd still need real ledgers (ILP?)

Edited by zerpdigger

Share this post


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

"Upfront settlement" is just a nicer term for "depositing money ahead of time", not much different from creating IOUs. It doesn't really matter which side has the money when you start, sooner or later you'll have to balance out or "settle". You can't do that 70000 times per second. You might be able to change the amounts you owe each other up to 70000 times per second though.

Settlement actually in most case is a final cleanup of risk. Do you really have to do that instantly and 70000 times a second for small to micro payments? I doubt it. Having on average by lets say once a minute a pre-funding on a "run out of fund" channel seems in most cases way more than good enough I guess. The combination of high capacity pre-funded payments channels with instant settlement for the bigger to very large funds gives the best possible solution in the full range of payments, from micro to mega, instant and on a very, very large scale....

Edited by kanaas

Share this post


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

Bitcoin then can also do tens of thousands of "transactions" per second if you use their version of PayChan or Lightning.

Of course they can, but do you see a transaction of lets say 10000 BTC go by PayChan? Bet it will go by the "slow" blockchain....

Share this post


Link to post
Share on other sites
7 minutes ago, kanaas said:

Settlement actually in most case is a final cleanup of risk. Do you really have to do that instantly and 70000 times a second for small to micro payments? I doubt it. Having on average by lets say once a minute a pre-funding on a "run out of fund" channel seems in most cases way more than good enough I guess.

You won't be able to settle faster than once per minute anyways if the limits for updating the amount you need to settle is ~60 times higher than the capacity to actually settle. I agree that it makes more sense to drop a few coins in a phone box than to demand the user to throw in a single cent every second and cut the call if the user can't keep up.

1 minute ago, kanaas said:

Of course they can, but do you see a transaction of lets say 10000 BTC go by PayChan? Bet it will go by the "slow" blockchain....

Show me a creation and settlement of a 230 million XRP (which is the price of 10k BTC at the moment) PayChan then... ;) I also don't really get what you mean: If you need to change the balance between two or more known parties a few thousand times per second while allowing all participants to settle immediately unilaterally, this is possible in both currencies. The amount on the table does not really matter, in practice it would be more likely to work similar to what credit card companies do when you rent a car: freeze a certain amount on your card until you hand back the car. In cryptocurrency terms, you'd commit a certain amount to a PayChan with a service provider and settle the remainder automatically after a while or after you signify that you are done (depending on the service). You can change the amount a few 10k times per second and it doesn't even depend on others, so that's where the "virtually unlimited" claims come from - you updating the balance with Uber does not influence me updating my balance with McDonald's. It is however NOT possible (but also often not necessary) to settle at this rate.

This thread is about something different though - would it be possible to have all Uber rides on the ledger for example and when would we reach which limit? The answer to that is largely unknown. Currently it would maybe even be possible to settle each ride, maybe in the future you'll have to "run a tab" with Uber for a week or so and only settle rarely. There might also be a chance to trade your Uber balance for some other things you might need, so you'd lock in 100 USD with Uber, but after using 10 of these for a cab ride, you trade the remaining 90 for 90 Walmart USD. I'm not so sure if/how this exactly would work off-chain, but I suspect it could be done. We're still a far way off from that though, in the near term a community created and funded blockchain benchmarking project would be the best bet to actually get some hard data on this stuff.

Share this post


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

Show me a creation and settlement of a 230 million XRP (which is the price of 10k BTC at the moment) 

I don't have that much, but I'm pretty sure that some like Jed have moved this sort of amounts from one account to another and being instant settled in less than 10 seconds.
Do you really want proof of lage amount payments being possible with XRP? And of the fact that they do not go slower that any other payment? :o

Share this post


Link to post
Share on other sites
Just now, kanaas said:

I don't have that much, but I'm pretty sure that some like Jed have moved this sort of amounts from one account to another and being instant settled in less than 10 seconds.
Do you really want proof of lage amount payments being possible with XRP? And of the fact that they do not go slower that any other payment? :o

I guess you are confused. There are several transactions out there that move billions of XRP at once. They however are not PayChan, they are settlements. Hodor said that in the Uber case, PayChan would be the better model, and I agree. Exactly because it keeps settlement transaction volume (the one that actually matters) lower. Non-settling fast micropayments are possible in both BTC and XRP though, so the reson why Uber would use XRP to settle would be because they need the money in seconds, not hours. as they can currently manage just fie with the legacy systems, I am not so sure where the benefits would exactly be. Probably smaller fees, network effects and regulatory environment in a few years would play a bigger role than capacity or speed.

For now still, the initial question is not really answerable without getting very deep into rippled.

Share this post


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

This thread is about something different though - would it be possible to have all Uber rides on the ledger for example and when would we reach which limit? The answer to that is largely unknown. Currently it would maybe even be possible to settle each ride, maybe in the future you'll have to "run a tab" with Uber for a week or so and only settle rarely. 

Or Uber has an off and on ledger mixed payments platform where the on ledger part just is used for cheap and instant FX transferts? Personally I do NOT believe Ripple wallets to be used in a form that every user is on ledger. The on ledger services eventually only makes sense for forex transactions, no need to have the straight linked to clients.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×