Jump to content
Sign in to follow this  
xrp123

What are the constraints for tps?

Recommended Posts

Just now, kanaas said:

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.

How would PayChans work then? You need to create them on the ledger, they just are updated off-ledger.

Share this post


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

Uber still can use them, separate from the off-ledger client accounts

So you disagree with Hodor that "Uber is actually a perfect example of processing payments via a micropayments processor. "?

Share this post


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

So you disagree with Hodor that "Uber is actually a perfect example of processing payments via a micropayments processor. "?

Yep, I really do not believe that Uber ever will have all its clients straight on the XRPLedger. Even not those like dLocal, Paypal, ... they all will handle clients off-ledger and will use the Ripplenet as an instrument for currency conversion and cross border settlement. Compare it to IP routing. I don't care (mostly don't even know) what's my address as it's handled by the ISP I'm connected to. Same for payments. The payments routing/translation will be lower in the stack and not on the users level.

Edited by kanaas

Share this post


Link to post
Share on other sites

I really hope that you are wrong then (though you are again mixing terms - "Ripplenet" does not mean RCL/XRPL). :)

In IP terms, you don't have to care about your address, but you'll have a very different experience if you aren't allowed or able to participate or have higher ups in the stack decide if your packet is worth forwarding or not.

Share this post


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

I really hope that you are wrong then 

Why would that be bad?
(BTW this confuses me indeed, if RCL is different than what is Ripplenet standing for?)

Share this post


Link to post
Share on other sites

It would be bad because it would restrict the market again only to institutions that are large and wealthy enough to afford it. The Internet got its value from connecting everyone who could connect to it somehow for free, not by first requiring a telecom company license and a few millions in down payment.

Ripplenet = Ripple Inc's Interledger implementation. The RCL connector is called "xRapid" ("X R P d"). https://ripple.com/files/ripplenet_brochure.pdf

Share this post


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

It would be bad because it would restrict the market again only to institutions that are large and wealthy enough to afford it. The Internet got its value from connecting everyone who could connect to it somehow for free, not by first requiring a telecom company license and a few millions in down payment.

As free as the internet may look, we ALL need a few centralised services to deal with.... a Yahoo, Google, MSFT, ... whatever account to email... Unless you're a geek and set up you own SMTP server but even than you got to pass by an ISP (mostly a telecom giant) to connect... or your employer...
And to manage personal wealth... for many it will be better to get some help from centralised services (banks you trust). Doing it all on your own makes you also responsible to guard it. Not saying central service will give you full protection, but at least they can force you to follow some basic rules and might even give you some assurance on theft if you follow the rules. And their vault will be much better protected and all the individual. Compare it with savings converted in bare gold.... Having 1M bullion in a vault in your house might be a worser idea than having kept in a gold-converted account on a trusted bank....

Share this post


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

Having 1M bullion in a vault in your house might be a worser idea than having kept in a gold-converted account on a trusted bank

that's why i think cryptocurrencies still need to evolve into something with pure tethered bitstrings and why central banks etc are still saying it's immature, but happy for DLT tech like ripple to go ahead and experiment

in the future we will just tie the money to the device and ID of the person (decentralised ID is a big aspect here)

then if a thief steals your "bits", they evaporate into thin air, so there's no incentive for theft in such a scenario -- the local/connected Mint Issuer just reissues the sum to the account/ID/device

but we need to evolve the tech for the next 5-10 years, but it is coming

Edited by zerpdigger

Share this post


Link to post
Share on other sites
4 hours 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.

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).

The lightning netowork is entirely off-ledger.  Paychan, from what I'm reading here is more a hybrid, and the "Paychan" actually interacts with the public ledger during the processing of the channel to make certain that the channel has enough XRP to settle:

Quote

The payee must also confirm that the channel has enough XRP available to honor the claim

https://ripple.com/build/payment-channels-tutorial/#5-the-payee-verifies-the-claims

That step is before the closing of the payment channel, which is what you are defining as "settlement."   It appears that some of the documentation does use the term "settlement" in association with the closing of the channel, as well:

Quote

After the settlement delay has passed or the channel has reached its planned expiration time, the channel is expired.

Overall, this is different than Bitcoin's lightning network, as the lightning network doesn't interact with the Bitcoin network during the processing of the lightning channel I believe -it's all off-ledger, right? 

I suppose we'd need @mDuo13 to really tell us if we're using the term settlement accurately, and if Paychan should be considered equivalent to Lightning, or more of a hybrid processing solution.  I've always thought they were equivalent, but perhaps now I should revise that understanding.

Edited by Hodor

Share this post


Link to post
Share on other sites

There's two scaling technologies I'm aware of: Off-ledger (batch processor of IOU's, and probably needs to be trusted to a larger degree (I may be wrong)), and sharding (many sub-blockchains acting as one).  I believe sharding is an upcoming feature of Ethereum and will allow nearly infinite scaling of on-ledger transactions.  This is difficult to implement because the coordination required between the sub-blockchains is slow and difficult to decentralize.  That being said, Ripple is much better situated to implement sharding given its distributed model as opposed to decentralized, which gives them more control over validator delegation.  In other words, they can somewhat better allocate disparate sub-blockchains in a manner that's balanced, and facilitates the necessary inter-sub-blockchain communications to settle quickly.  This sharded on-ledger transaction volume capacity scales nearly infinitely as an unlimited number of sub-blockchains can be created to match demand, as long as the necessary hardware is involved.

Edited by galgitron

Share this post


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

Overall, this is different than Bitcoin's lightning network, as the lightning network doesn't interact with the Bitcoin network during the processing of the lightning channel I believe -it's all off-ledger, right? 

Nope, the lightning network is more like a network of PayChans, its so called "hubs" still need to be funded on-chain and if you want to join or leave the network, it still requires actual on-chain transactions. You can imagine it a bit like PayChans optionally settling into another PayChan instead of only the predefined accounts. I'd still love to see mduo's explanation though. :-)

Share this post


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

The lightning netowork is entirely off-ledger.  Paychan, from what I'm reading here is more a hybrid, and the "Paychan" actually interacts with the public ledger during the processing of the channel to make certain that the channel has enough XRP to settle:

https://ripple.com/build/payment-channels-tutorial/#5-the-payee-verifies-the-claims

That step is before the closing of the payment channel, which is what you are defining as "settlement."   It appears that some of the documentation does use the term "settlement" in association with the closing of the channel, as well:

Overall, this is different than Bitcoin's lightning network, as the lightning network doesn't interact with the Bitcoin network during the processing of the lightning channel I believe -it's all off-ledger, right? 

I suppose we'd need @mDuo13 to really tell us if we're using the term settlement accurately, and if Paychan should be considered equivalent to Lightning, or more of a hybrid processing solution.  I've always thought they were equivalent, but perhaps now I should revise that understanding.

I think @Sukrim knows more about Lightning than I do, so I can't really talk about that.

As for whether you're using the term "settlement" accurately, I've found that different people use it to mean different things even within the industry. The way I tend to view it is, "settlement" happens when the balances are declared current and the outcome of transactions is final so the money is unlocked for you to use elsewhere. If the money is on hold or pending, then settlement (of those transactions) hasn't happened yet.

By that definition, sending claims in an XRP payment channel isn't settlement; settlement happens two ways:

  1. The receiver redeems a claim to actually get some more XRP into their account, or
  2. The sender requests to close the channel, then actually closes the channel after the SettleDelay (waiting period) has elapsed.

In both cases, you have to settle using "traditional" XRP Ledger transactions, so you can't settle faster than there's a new ledger version (i.e. every 4-7 seconds). And in the case of #2, the amount of time you have to wait to declare the channel settled is actually defined in the channel itself by the SettleDelay—since you have to give the receiver a chance to redeem any outstanding claims before taking the XRP back. So it's variable, but not faster than every 4-7 seconds.

However, the settlement that occurs when you redeem or close a payment channel can encompass an unlimited number of off-ledger payments that are guaranteed by the signed claims. So in a sense this is like the analogy of editing your running total of how much you owe the car-rental company, but there's a big difference: signed claims have a much stronger guarantee, and can be claimed at any time the channel is open. So imagine (for the sake of argument) that you went to a car company for a 10-day car rental at $50/day plus a $500 deposit on a car and a $1/mile usage charge. The car company putting a $1500 hold on your credit card is like opening a $1500 payment channel, except that you (or more accurately, an app acting on your behalf) can update the car company multiple times per second with your mileage and other sundry charges. Then the car company could decide to settle the $50/day charge each morning, and also settle the usage charge every 20 miles or so. You're still out the same amount in the end, but the rental car company can get portions of their eventual bill in between, which means they need less working capital to "tide them over" until they receive payments for the car.

In reality, rental cars are unlikely to work this way, but online services are a different story. A lot of Ripple employees are hoping that online content can move beyond an advertising-driven revenue model to a micropayments model, where you could actually pay fractions of a cent per pageload or something more closely tied to the actual cost and value of the media and its delivery method.

Share this post


Link to post
Share on other sites
14 hours ago, mDuo13 said:

So it's variable, but not faster than every 4-7 seconds

Got it... basically the ledger close is the absolute minimum, but then add the settlement delay number on top of that. 

14 hours ago, mDuo13 said:

In reality, rental cars are unlikely to work this way, but online services are a different story. A lot of Ripple employees are hoping that online content can move beyond an advertising-driven revenue model to a micropayments model, where you could actually pay fractions of a cent per pageload or something more closely tied to the actual cost and value of the media and its delivery method.

This confirms my understanding of the business intention for payment channels - micropayment processing.  This is why I think it's perfect for businesses that process payments falling into this range. 

@mDuo13 thanks for stopping by to add your clarification! 

Share this post


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

×