I've tried wrapping my head around the Ripple "consensus process". From my understanding, Ripple creates a new ledger version every 4 seconds, computed by a set of "validating nodes".

But herein lies my question, how will the validating nodes push a new ledger version at the scale of their advertised capacity[1]? How would validating nodes with slower connections keep up?

[1]: https://ripple.com/xrp/


There's a self-regulating mechanism that keeps the network running so that it's not as fast as the fastest validator (as that would make attacks too easy) nor as slow as the slowest validator (as that would provide poor performance). But Ripple has never claimed on ledger transactions rates that high. To get to 50,000 TPS, you need to use off-chain scaling schemes like payment channels.

This is a fundamental scaling limit with all public ledgers that try to create fungible tokens. Every full node must process every transaction and thus if you try to get the number of on chain transactions very high, you impose high bandwidth, CPU, and storage costs on everyone. (You can trade off some fungibility, as IOTA does and as some sharding schemes do.)

  • Is there a limit to the number of transactions that can be processed in any single round? Jun 16 '18 at 15:55
  • There is no hard limit. There is a heuristic that admits transactions into the round based on how large a fee they pay and the performance of recent rounds. If a large backlog of transactions accumulate, each round will include more and more of them until either the backlog clears or consensus starts to degrade. If consensus degrades, fees will go up and the number of txns allowed per ledger will go down. Jun 19 '18 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.