[1/π§΅] I've been reading a lot about #XRPL #scalability recently.
Let me quickly go through how #XRPL performs and #scales on these metrics:
βΆοΈ Scale up "vertically"
βΆοΈ Scale out "horizontally"
βΆοΈ High volume & High value TX
βΆοΈ High value & Low speed
Let me quickly go through how #XRPL performs and #scales on these metrics:
βΆοΈ Scale up "vertically"
βΆοΈ Scale out "horizontally"
βΆοΈ High volume & High value TX
βΆοΈ High value & Low speed
[2/17] π Asynchronous TX speedβScale up "vertically"
In contrast to #DAG-based systems, which operate in "chaotic order" and execute transactions in parallel, the #XRPL validates transactions in canonical transaction orderβone Ledger at a time.
π bitcoin.stackexchange.com/questions/7857β¦
. . .
In contrast to #DAG-based systems, which operate in "chaotic order" and execute transactions in parallel, the #XRPL validates transactions in canonical transaction orderβone Ledger at a time.
π bitcoin.stackexchange.com/questions/7857β¦
. . .
[3/17] . . .
β The approach for #DLT/#Blockchain-based systems such as #XRPL:
βοΈ "Payment Channels"
π§ It's a sophisticated feature for transmitting "asynchronous" #XRP #payments that may be broken into extremely small amounts and paid in total order afterwards.
. . .
β The approach for #DLT/#Blockchain-based systems such as #XRPL:
βοΈ "Payment Channels"
π§ It's a sophisticated feature for transmitting "asynchronous" #XRP #payments that may be broken into extremely small amounts and paid in total order afterwards.
. . .
[4/17] . . .
Because it's #Christmas, consider the following #analogy: π π
1β£ Without "#PaymentChannels":
Alice sends a package (Ledger) to @bob_way every ~3 seconds, each containing a few toys (#transactions)
. . .
Because it's #Christmas, consider the following #analogy: π π
1β£ Without "#PaymentChannels":
Alice sends a package (Ledger) to @bob_way every ~3 seconds, each containing a few toys (#transactions)
. . .
[5/17] . . .
2β£ With "#PaymentChannels":
Alice is continually wrapping up new toys (#TX) and NOT delivering them over to @bob_way (async. authorized claim with a single validated #TX), while also reminding him:
"They are yours whenever you want them π" (redeem a claim)
. . .
2β£ With "#PaymentChannels":
Alice is continually wrapping up new toys (#TX) and NOT delivering them over to @bob_way (async. authorized claim with a single validated #TX), while also reminding him:
"They are yours whenever you want them π" (redeem a claim)
. . .
[6/17] . . .
π€¨ What are the constraints of the solution?
#PaymentChannels enable #transactions to be carried out at a rate that is only limited by the participants' capacity to produce and validate #digital #signatures for those Claims.
. . .
π€¨ What are the constraints of the solution?
#PaymentChannels enable #transactions to be carried out at a rate that is only limited by the participants' capacity to produce and validate #digital #signatures for those Claims.
. . .
[7/17] . . .
This restriction is mostly determined by the speed of the participants' #hardware and the complexity of the #signature #algorithms.
. . .
This restriction is mostly determined by the speed of the participants' #hardware and the complexity of the #signature #algorithms.
. . .
[8/17] . . .
In 2011, research proved the capacity to produce over #Ed25519 100,000 #signatures per second and verify over 70,000 per second on commodity #hardware.
π ed25519.cr.yp.to/ed25519-201109β¦
. . .
In 2011, research proved the capacity to produce over #Ed25519 100,000 #signatures per second and verify over 70,000 per second on commodity #hardware.
π ed25519.cr.yp.to/ed25519-201109β¦
. . .
[9/17] . . .
The most recent numbers are always available here:
π bench.cr.yp.to/results-sign.hβ¦
The most recent paper I could find was as follows:
π eprint.iacr.org/2021/471.pdf
Numbers interpretation (4 years ago):
π crypto.stackexchange.com/questions/6025β¦
The most recent numbers are always available here:
π bench.cr.yp.to/results-sign.hβ¦
The most recent paper I could find was as follows:
π eprint.iacr.org/2021/471.pdf
Numbers interpretation (4 years ago):
π crypto.stackexchange.com/questions/6025β¦
[10/17] π Scale out "horizontally"
We defined how to #scale up "vertically" by increasing capacity by adding more resources (#CPU, #storage), for example:
π Improved/optimized CPUs / Servers βΆοΈ More signatures βΆοΈ Larger Payment Channels βΆοΈ Faster #XRPLedger
. . .
We defined how to #scale up "vertically" by increasing capacity by adding more resources (#CPU, #storage), for example:
π Improved/optimized CPUs / Servers βΆοΈ More signatures βΆοΈ Larger Payment Channels βΆοΈ Faster #XRPLedger
. . .
[11/17] . . .
The next step is to learn about the #technical characteristics that the #XRPL can provide in order to #scale horizontally.
β‘οΈ Add #servers to a #cluster that operate as a logical unit to improve capacity.
In #XRPL jargon:
βΆοΈ "Federated #Sidechains"
. . .
The next step is to learn about the #technical characteristics that the #XRPL can provide in order to #scale horizontally.
β‘οΈ Add #servers to a #cluster that operate as a logical unit to improve capacity.
In #XRPL jargon:
βΆοΈ "Federated #Sidechains"
. . .
[12/17] . . .
If adding #servers isn't enough to #scale out enough to handle all of the #transactions on the #XRPL itself, there's always the possibility of spinning up a new #sidechain with purpose-fit rules if the #mainchain becomes overloaded.
π ripple.com/insights/a-visβ¦
If adding #servers isn't enough to #scale out enough to handle all of the #transactions on the #XRPL itself, there's always the possibility of spinning up a new #sidechain with purpose-fit rules if the #mainchain becomes overloaded.
π ripple.com/insights/a-visβ¦
[13/17] π High volume & High value TX
β We've prev. addressed how the #XRPL will manage large volume load, but how will it handle liquidity issues for high value #TX when the trading-pair is not liquid enough?
The solution proposed for this specific problem:
βΆοΈ #AMM
. . .
β We've prev. addressed how the #XRPL will manage large volume load, but how will it handle liquidity issues for high value #TX when the trading-pair is not liquid enough?
The solution proposed for this specific problem:
βΆοΈ #AMM
. . .
[14/17] . . .
The [A]utomated[M]arket[M]aker (#XLS30d) liquidity pools enable #liquidity provisioning without the need of smart-contracts, further enhancing the #CLOB-based #XRPL #DEX.
π dev.to/ripplexdev/xrpβ¦
The [A]utomated[M]arket[M]aker (#XLS30d) liquidity pools enable #liquidity provisioning without the need of smart-contracts, further enhancing the #CLOB-based #XRPL #DEX.
π dev.to/ripplexdev/xrpβ¦
[15/17] π High value & Low speed
For high-value #XRP TX where speed is unimportant, one may utilize #escrows, which are well-known owing to @Ripple's significant usage of them.
The following conditions apply:
β’ Time-based
β’ "crypto-conditions"
π datatracker.ietf.org/doc/html/draftβ¦
For high-value #XRP TX where speed is unimportant, one may utilize #escrows, which are well-known owing to @Ripple's significant usage of them.
The following conditions apply:
β’ Time-based
β’ "crypto-conditions"
π datatracker.ietf.org/doc/html/draftβ¦
[16/17] βοΈ As you can see, there are numerous methods to scale up and out, including adding #servers, boosting #CPU power, adding #sidechains, or leveraging #XRPL features such as #escrows and #payment-channels to meet transaction demand without overburdening the #XRPLedger.
[17/17] Thank you to everyone who took the time to read this lengthy topic β€οΈ
If you enjoyed the thread, please follow me:
@krippenreiter
Please feel free to contribute by sharing here π
If you enjoyed the thread, please follow me:
@krippenreiter
Please feel free to contribute by sharing here π
https://twitter.com/krippenreiter/status/1607521933373104128?s=20&t=t7WOdSEbnE57IaykvIbBZg
@threadreaderapp unroll
@WKahneman @digitalassetbuy @Fame21Moore @sentosumosaba @BCBacker @XRPcryptowolf @X__Anderson @stedas π
β My most recent article [π§΅] explores #XRPL's scalability options and approaches to meet global demand if necessary by growing horizontally and vertically with ease.
β My most recent article [π§΅] explores #XRPL's scalability options and approaches to meet global demand if necessary by growing horizontally and vertically with ease.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
