Jump to content
melushell

How scalable is Ripple's TPS???

Recommended Posts

There have been comments from Ripple team members in the past that they are working on allowing it to scale to an even higher TPS, which will probably be needed in the future if XRP ends up fulfilling its purpose.

Share this post


Link to post
Share on other sites
On 1/15/2018 at 7:11 PM, nikb said:

Payment channels are NOT limited in any way.

When you create a payment channel you pay a small fee (currently, 10 drops or 0.00001 XRP is sufficient). When you close a payment channel and settle it, you pay another small fee (again, , 10 drops or 0.00001 XRP is sufficient).

Once the channel is setup you can operate the payment channel off the ledger, limited only by your CPU and the connectivity of the two endpoints. This part happens off the ledger, so it's not bound in any way by the 1,500 tx/sec figure and there are NO fees associated with these off the ledger messages. 

As for speed, according to https://ed25519.cr.yp.to/ed25519-20110926.pdf,  an average quad-core CPU should be able to do over 100,000 Ed25519 signature operations per second. This figure will, obviously, only get better as CPUs get faster. Obviously, at 100,000 sigs/sec, the bottleneck isn't the signing, but the networking between the two endpoints.

 

 

This might help

Share this post


Link to post
Share on other sites

They tested up to 70k txs a second with an average settlement of 3.7s using the Payment Channel feature.  Payment Channels is the currently implemented  "Visa" solution to provide high volume transactions asynchronously off-ledger with a single settlement when the channel is closed.  Can a payment channel be used at a tx rate higher than 70k/sec?  I'm sure it can be, but as of right now such a test hasn't been publicly disclosed.  Ripple tested the 70k boundary specifically because Visa today has that kind of tx volume and the credit card case is currently one of the "worst case" scenarios for performance around high transaction volume.

If you'd like more reading (in addition to what others above have kindly provided).  Check out the following...

@Hodor's blog post from last year: https://xrphodor.wordpress.com/2017/09/17/ripple-xrp-and-micropayments/

The original article (which is referenced by the blog post above): https://www.cryptocoinsnews.com/ripple-claims-transaction-thoroughput-now/

The Payment Channel tutorial guide straight from Ripple: https://ripple.com/build/payment-channels-tutorial/

 

Share this post


Link to post
Share on other sites
20 minutes ago, Zedy44 said:

They tested up to 70k txs a second with an average settlement of 3.7s using the Payment Channel feature.

You can't settle 70k transactions within a few seconds on XRPL, according to Ripple it is limited to 1500 settlements per second in their load tests which seem already to assume a best case scenario of all validators being in the same datacenter with gigabit connectivity between each other.

Share this post


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

You can't settle 70k transactions within a few seconds on XRPL, according to Ripple it is limited to 1500 settlements per second in their load tests which seem already to assume a best case scenario of all validators being in the same datacenter with gigabit connectivity between each other.

well, maybe it's a sleight of word... :D

i guess there's some metric that limits the amount of paychans opening/closing per ledger close time, so there's a max "extra" transactions you can "tack on" to the 1500 theoretical txps -- assuming i'm vaguely understanding how this works...

the way i imagine it is you have to fold paychan transactions into the 1500 txps to give the full max tx per second inc. paychans

you can take 1 xrp, put it in channel and ping back and forth 5000 micro-transactions, but it still needs to settle on-ledger, which is still limited to the alleged ~1500

70,000 / 1,500 = ~47 tx per channel if that's how they get the figure, assuming every one of the 1,500 is a paychan closure?

*confused dot com*

Edited by zerpdigger

Share this post


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

You can't settle 70k transactions within a few seconds on XRPL, according to Ripple it is limited to 1500 settlements per second in their load tests which seem already to assume a best case scenario of all validators being in the same datacenter with gigabit connectivity between each other.

The very next sentence I wrote states these are off-ledger transactions, which are ultimately settled when the channel is closed on ledger (or multiple settlements if claims are made periodically).  I suppose I could have tried to clarify this distinction even further, but I thought my response was pretty accurate given the question.

Share this post


Link to post
Share on other sites
12 minutes ago, zerpdigger said:

why there is a paychan limit at all

Because the recipient on the PayChan has to submit their most recent "receipt" to the XRPLedger to trigger the "Settlement" transaction against the payment channel.

The "settlement transaction" of the receipt however could represent an infinite number of offline transactions up to the amount of value in the payment channel.

The "settlement transactions" is subject to the 1500 TPS transaction limit of XRPLedger.

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites
23 minutes ago, KarmaCoverage said:

Because the recipient on the PayChan has to submit their most recent "receipt" to the XRPLedger to trigger the "Settlement" transaction against the payment channel.

The "settlement transaction" of the receipt however could represent an infinite number of offline transactions up to the amount of value in the payment channel.

The "settlement transactions" is subject to the 1500 TPS transaction limit of XRPLedger.

so how is e.g. that 70k figure (per sec, prusamably?) calculated? where are the bottlenecks? how many "receipts" per settlement tx? or can there be e.g. a max of 1500 paychan receipts (assuming ZERO other transactions! which is ridiculous but for the sake of understanding)

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

×
×
  • Create New...