You may have heard and still hear about the debate going on, whether Bitcoin core should increase the block size to 2 MB or not. Sure, in the short term this seems like it would make sense. Bitcoin can currently only fit up to ~3,000 transaction per block[1]. When you double the block size to 2 MB instead of 1, this could potentially bring it to ~6,000 transactions in a block and increase transaction throughput. What are the downsides though, and how does XRP solve them? We'll look specifically at the storage complexity side of things for now.

Blockchain size

Let's take a look at how much storage space you will need to download the full history of the Bitcoin blockchain. We can see it'll be about 174 GB at the time of writing this[2]. Bitcoin requires you to have downloaded the full history of the network before you are allowed to start mining. For miners, 174 GB might not be much now, but that's only at 1 MB block sizes. To increase throughput, Bitcoin needs to increase block size but with bigger block size comes bigger blockchain history.


Visa, a large credit card company, is capable of doing 24,000 transactions per second in throughput[3]. How many transactions is that per block? Well, 24,000 x 600 (seconds in 10 minutes) = 14,400,000. That would equate to about 4.8 GB per block. Even if it hits half those transactions, that's still a whopping 2.4 GB per block. For the big players they could probably stay afloat and make tons of money, while pushing the little guys out of mining and effectively make Bitcoin centralized.

How does XRP solve this?

The first Ripple developers foresaw this issue that would eventually plague other blockchain networks, so they came up with the solution of a Sequence. The way the XRP Ledger works is it remembers the last transaction someone has sent and discards the rest.

For example, say Alice sent Bob 100 XRP. According to Bitcoin rules, the coins would be spent and everyone has to remember this transaction, and how Alice got the coins from Charles, and how Charles got the coins from Jill, all the way down to when they first came into existence. However, the XRP Ledger will only remember that Bob now has 100 XRP, Alice has 0, and forget how it got there. This is what is called the Sequence feature.

Here's an example of this in action. Below is the output of a successful transaction, giving statistics about Ledger Index, balance, etc. Pay attention to the Sequence field though.

  "id": 2,
  "status": "success",
  "type": "response",
  "result": {
    "account_data": {
      "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
      "Balance": "27389517749",
      "Flags": 0,
      "LedgerEntryType": "AccountRoot",
      "OwnerCount": 18,
      "PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
      "PreviousTxnLgrSeq": 6592159,
      "Sequence": 1400,
      "index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
    "ledger_index": 6760970

We can see that this account has a Sequence of 1,400. This means the account is on its 1,400th transaction, and the other 1,399 transactions have been discarded. All validators only need to know the latest transaction to move forward and the ledger mirrors this.

What does this all mean?

Most people when they talk about scalability think of transaction throughput and who can get the most transactions per second at the fastest time. They tend to forget that scalability can also mean how well you are able to store data in a constant and linear fashion. This shows that XRP is truly the most scalable asset in the market currently. I'm truly happy to be part of this community, and I hope you enjoyed this short but informative read :).

  1. ↩︎

  2. ↩︎

  3. ↩︎