The Blockchain Scalability Problem & the Race for Visa-Like Transaction Speed

Yes, blockchain has a scalability problem. Here’s what it is, and here’s what people are doing to solve it.

The battle for a scalable solution is the blockchain’s moon race. Bitcoin processes 4.6 transactions per second. Visa does around 1,700 transactions per second on average (based on a calculation derived from the official claim of over 150 million transactions per day). The potential for adoption is there but is bottlenecked currently by scalability.

A study published by Tata Communications in 2018 showed that 44% of organizations in its survey are adopting blockchain, but also alludes to the universal problems that arise from deploying new technologies. From an architectural level, the unsolved problem of scalability is emerging as a bottleneck to blockchain adoption and practical applications.

As Deloitte Insights puts it, “blockchain-based systems are comparatively slow. Blockchain’s sluggish transaction speed is a major concern for enterprises that depend on high-performance legacy transaction processing systems.” The world received a taste of the scalability problems in 2017 and 2018: severe transfer delays and high fees on the Bitcoin network, and the notorious Cryptokitties app that congested the Ethereum blockchain network (a network that thousands of decentralized applications rely on).

How Bad Is Blockchain Scalability Today?

In order to scale a blockchain, increasing the block size or decreasing the block time by reducing the hash complexity is not enough. With either method, the ability to scale reaches a ceiling before it can hit the transactions necessary to compete with businesses like Visa, which “handles an average of 150 million transactions every day” or around 1,736 transactions per second (TPS).

By comparison, Bitcoin transaction speeds are tremendously lower. Currently, the block size is set 1MB (1,048,576 bytes — although through SegWit, that size can scale to up to a theoretical 4MB) and the average transaction size is 380.04 bytes (assuming that each transaction is from one wallet to x other wallets — so a batch transaction would count as one transaction. I’ll talk more about batch transactions later and why I labeled it this way) and seems to be on the rise.Therefore, the average amount of transactions that can fit into one of Bitcoin’s blocks, currently, is calculated as:

The current Bitcoin block generation time is 10 minutes; i.e., every ten minutes, a new block is mined. In ten minutes (600 seconds), Bitcoin can average around 2,759.12 transactions based on previous assumptions. In other words, the Bitcoin blockchain can currently guarantee only 4.6 transactions per second.

Increasing Block Size or Decreasing Block Generation Time Won’t Solve the Problem: A Look at Non-SegWit TPS

The problem of scalability comes packaged with blockchain value propositions; therefore, one cannot simply increase scalability by changing parameters in the blockchain.

The Bitcoin community can adjust two variables to attempt to increase the TPS. One variable is the block size (B), which is currently hard coded at 1MB. Ideally, B should be increased to increase TPS. The other variable is the block generation time (TB), which is adjusted by changing the complexity of the hashing puzzle. Ideally, TB should be reduced to increase TPS.

Table 1: the different scenarios for increasing TPS will be examined in the section below. Only in S1 and S2 can the Bitcoin blockchain achieve Visa-like TPS, but both scenarios are impossible due to transaction propagation time, which will be discussed in this section as well.

Scenarios 1 & 2

In order to grow from 4.4 to Visa’s 1,736, Bitcoin would need to scale its TPS by 377.5x. In other words, B would need to be increased from 1MB to 377.5MB (Table 1, S1) or TB would need to be reduced from ten minutes to 1.6 seconds (Table 1, S2). A third scenario would be to adjust both. Any of the three scenarios are unachievable on the blockchain due to a third, uncontrolled factor: the relay time (TR) needed to broadcast a new block to every node on the Bitcoin network.

Currently, there are estimated to be 10,198 nodes in the Bitcoin network. Transmitting a 1MB (1,048,576 bytes) through the peer-to-peer network takes some time. The Karlsruhe Institute of Technology measures Bitcoin’s block propagation time, and the average block propagation time reported on January 17, 2019 was 13,989.42 milliseconds or approximately 14 seconds to propagate to 99% of the network. TB cannot fall below 99% of TR (TR99)=14 because if it does, then a new block would be generated before an old block would be received by most of the blocks in the network. The closer TB gets to TR99, the more issues arise with forks, orphan blocks and chain re-organizations, and (in extreme cases) security vulnerabilities like double-spend attacks.

Scenario 3

Even if TB = TR99 = 14, with a block size of 1MB, the Bitcoin blockchain would only be able to increase its speed to 188 TPS (Table 1, S3). While that scale represents a 188x increase in TPS, it is nowhere close to the 1,736 TPS Visa conducts daily; furthermore, it layers on the aforementioned risks. The other variable, B, can be readjusted, but not without affecting TR, which would affect TR99 and therefore the bottom limit of TB.

Scenario 4

For example, by doubling the size of B (from 1MB to 2MB), the time it takes for each node on the network to download a new block, TR, would also increase — by approximately 2x; thus, at 2MB, TR99 = 28s, so TB’s lower limit would be 28s as well. By increasing B by any factor, and subsequently increasing TR by the same factor, the net TPS would remain the same — in this case, around 188 TPS (Table 1, S4). One solution for reducing the impact of B from TR­ is to increase the bandwidth among all the nodes within the Bitcoin network. Unfortunately, because it is a P2P network, that responsibility falls on the lap of each peer in the network.

The Emergence of SegWit

In 2017, Segregated Witness (SegWit) went into effect across all Bitcoin nodes. Note — I won’t go into all the details of SegWit but if you want to learn about its history and its role in the emergence of the Bitcoin Cash hard fork, take a look at this article:

It does what the name sounds like it does — segregating the witness part of each transaction from the actual transaction data. It occurred as a soft fork, so it was instituted without any major effects on the existing blockchain network and code. Due to the way that the witness transaction would be weighted, the new SegWit-enabled Bitcoin blocks could be theoretically increased to up to 4MB without changing the Bitcoin block size.

I say theoretically because there are additional factors that contribute to the final size of the SegWit block. In fact, if you check a Bitcoin blockchain explorer, you’ll see that (at least at the time this article was published) the average block size is still under 1MB.

But that isn’t to say that blocks can’t go past 1MB. In early 2018, we witnessed one of the largest (probably still the largest) block sizes generated, coming in weighing around 2.1MB. SegWit’s soft fork has helped improve block size without changes to the core code, but it still does not improve TPS in a scalable manner.

When examining the previous four scenarios under a proof-of-work consensus, we saw that simply increasing the block size or reducing the mining complexity could only take us so far. Even a combination of this would be limited due to transaction propagation time. Trying to mine new blocks faster than old blocks can propagate will lead to some pretty big security issues. SegWit has helped alleviate some of the TPS issues in the meantime, but a more scalable solution is still needed to achieve Visa-like TPS.

It seems that moving any piece into place to increase TPS moves another piece out of place somewhere else in the blockchain puzzle; regardless, there are projects and startups working to achieve the TPS answers needed to push blockchain adoption into a scalable stage.

Existing and Future Approaches to Solve Scalability

When looking for the potential answer to the scalability problem, multiple other issues arise. For example, if the answer is only applicable for one particular blockchain, then it relies on the assumption that the particular blockchain will be the one that needs that scalability in the future; otherwise, the effort is undue or misplaced. Another consideration is to understand what the trade-off may be. Right now, all solutions available come with limitations.

1. Batch Payments into One Transaction

Pros: Reduces the size of a transaction record by putting multiple transactions into one, allowing for more transactions overall per block, which can increase TPS to an extent.

Cons: Cannot batch multiple wallet’s transactions together; risks privacy

Batch payments has been a feature of Bitcoin (and therefore, Bitcoin’s forks including Digibyte, Dogecoin, Bitcoin Cash, etc.) through the RPC sendmany. Exchanges already do this, and you can see it when you try to look up your transaction ID on a blockchain explorer. What you might end up seeing is one wallet sending out to multiple different wallets. In that case, it’s a batch transaction.

The advantage of this is that putting it into one transaction means that 1) you only have to pay one transaction fee, and 2) you don’t have to write a full transaction that is, as I described previously, approximately 380 bytes, for each transaction. In fact, out of the 380 bytes that the transaction may be, only 34 bytes of that might be the transaction information.

Only a small portion of a transaction record on the block actually talks about the transaction.

If, for example, I wanted to send ten transactions at once, and I sent them as separate transactions, then it would be 380 x 10 = 3,800 bytes of space that I would take up on a block. On the other hand, if I batched the transaction together, the first transaction in the block would be included in the 380 bytes, and the next 9 would just be 34 bytes each; i.e., 380 + (34 x 9) = 686 bytes, which is 5.5x smaller.

If these transactions weren’t batched, then the size of this would be: 10 transactions x 380 bytes per transaction = 3,800 bytes

It does come with limitations, though; different transactions from different wallets cannot be batched. In other words, if there were ten people in line for coffee, those ten people can’t put all their transactions into one batch and send it off the Starbucks. Each would have to produce an individual transaction. Batch transactions are limited to one-to-multiple, not multiple-to-one. A batch transaction would be great, for example, in paying bills (electricity, Internet, phone, NetFlix, Hulu, insurance, etc.) at once.

Furthermore, a batch transaction may not be something you want to do for privacy’s sake. As David A. Harding mentions in his article about Bitcoin batch transactions, one issue of privacy in batch transactions may arise if you were to do payroll — anyone could check their transaction and see what other wallets (employees) were sent.