Thread by @krippenreiter

[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

[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…
. . .

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

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

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

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

[7/17] . . .

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

[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…

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

[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"
. . .

[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…

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

[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…

[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…

[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 👇

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.