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:

The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality_Segregated Witness (SegWit) has activated on Bitcoin. As of today, all SegWit-ready nodes on the Bitcoin network are…_bitcoinmagazine.com

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.

Source: https://www.blockchain.com/charts

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.

2. Bitcoin Cash

Pros: can store more transactions than Bitcoin in one block, which increases capable TPS

Cons: is only a temporary solution, as its TPS is still far below the 1,700 global TPS that Visa conducts on an average day. The solution is also limited to Bitcoin Cash, so it cannot be a solution for other blockchains.

If you look back at the scenarios that I proposed previously to theoretically scale TPS, scenario 1 might sound familiar. That’s because an attempt at it has already occurred — namely, the Bitcoin Cash hard fork, which occurred in August 2017. The primary motivator of the hard fork was to increase the block size to 8MB (an increase of 8x) from 1MB non-SegWit Bitcoin blocks.

But in a best-case scenario, this solution is still far from the answer that the world is looking for in regards to scalability.

Bitcoin Cash is a hard fork of Bitcoin, designed as an alternative to Bitcoin with the added value proposition of faster transactions. It does primarily increasing the block size (B); even though it has increased transaction speed compared to Bitcoin, it still does not have nearly enough TPS to compete in the global transacting space.

3. The Lightning Network

Pros: near-instant transactions between parties, with no fees

Cons: transacting occurs off-chain, requires users to have a lightning node, and is limited to Bitcoin-core-based blockchains (e.g., Bitcoin Cash, Litecoin, Digibyte, Dogecoin)

Going into the details of how the Lightning Network works on a granular level will be a bit too detailed for this article, but there are plenty of resources that guide you in a way that I think is easy to understand. In a nutshell, the Lightning Network lets you take your Bitcoins off the blockchain and transact with another party privately. For example, I might plan to have coffee every morning for the next month. I want to transact in Bitcoin, but I don’t want to stand in front of the coffee line waiting for my block confirmations like a dweeb who doesn’t know what Lightning Network is.

So what I do is, I can create what’s called a payment channel on the Lightning Network. This new payment channel doesn’t run transactions through the Bitcoin blockchain — instead, think of it as a reserve. I deposit, say 0.5 BTC into it, and that’s a reserve that I can then use to pay anyone else that I’m connected with on the Lightning Network.

Once I’m done, I come back to the blockchain and tell it, “Hey, I sent Starbucks 0.1 BTC for coffee over the course of a month, just deduct that from the balance I put in initially.” Then I have 0.4 BTC left over. Of course, this is a very simplified way of explaining what actually goes on, so definitely take a look at other resources if you want to learn about the features of the Lightning Network.

Unfortunately, it is a Bitcoin-only solution for off-chain transacting, available for Bitcoin and Bitcoin-forked blockchains like Digibyte and Litecoin. The advantage that the Lightning Network delivers is its instant and zero-fee transacting, which enables micro-transacting as well as the ability to buy coffee without the wait.

In its current stage, though, creating the payment channel requires a bit more knowledge than what the average Bitcoin buyer might be comfortable with, and it still requires on-chain transacting before and after the life of a user’s Lightning node. Therefore, the Lightning network is a great solution for scaling TPS for Bitcoin and Bitcoin-like cryptocurrencies, but it only solves the problem off-chain.

4. EOS & Other High-Performance Blockchains

Pros: high theoretical scalability

Cons: centralization, which can lead to (and has historically led to) censorship

High-performance blockchain projects use different consensus mechanisms. One of the most popular alternatives to Proof of Work (PoW) is Proof of Stake (PoS). A recent project, EOS, uses what it calls a delegated proof-of-stake (dPoS), which is a modified version of PoS. In dPoS, users like you and me who stake aren’t actually part of the virtualized mining process; instead, we vote on who is. EOS use delegated PoS (dPoS)to claim up to 3,996 TPS but the trade-off is centralization, which gives key stakeholders more power than the rest of the community.

EOS only has 21 nodes (Block Producers), and in June 2018, those Block Producers froze seven EOS accounts. While the reasoning behind the freezing may be justified, it demonstrates the amount of authority one organization has on the entire blockchain, and their ability to execute on that authority.

The blockchain community wants scalability, which is what gave rise to the popularity of EOS, but the trade-off is censorship and control due to centralization. For a list of other additional flaws that can compromise the integrity of EOS, take a look at this article: EOS is not a blockchain, it’s a glorified cloud computing service (disclaimer: the research was funded by Consensys, and the founder of Consensys is the cofounder of Ethereum).

5. bloXroute

Pros: it is a on-chain solution and blockchain-agnostic, so it can be an answer for scalability for potentially all blockchains

Cons: it is still in development, and building/operating a global CDN is an expensive feat that is yet to be accomplished in the blockchain space

Outside of blockchain-specific projects, startups are starting to emerge to tackle the problem on a larger scale. One of the most interesting projects I’ve seen so far in the space is a startup called bloXroute. I discovered the company last week during my research into the blockchain space. The idea behind the company is to transpose a content delivery network (CDN) onto blockchain networks to solve the scalability issues.

What Is a CDN?

CDNs are what supercharge Internet speed today. They are the reason why, when you turn on your next YouTube video, it no longer needs to show you the loading spinner and make you wait three minutes to watch a one-minute video. If you’ve never experienced those issues before, you’re just too young to understand.

A content distribution network sounds complex and fancy, and while building one is more complex than you’d ever imagine, the idea is pretty simple — put large-size content on computers (called servers) close to populations, so that whenever, say, someone in Manhattan wants to download a piece of content to view, they don’t need to download it all the way from some computer in Santa Clara, California; instead, there is a closer version of it stored in some place close to New York. The largest company in the CDN space is Akamai [NASDAQ:AKAM], and was created as a solution to reduce the latency of large files over the Internet.

By the same respect, bloXroute intends to take the concept of the CDN and apply it to the blockchain space as a blockchain distributed network (BDN); after all, if blocks are to eventually scale to gigabytes in size, transfer speeds will become an issue.

bloXroute intends to run a trial of its BDN in Q1 2019. The results from this trial will give us a better indication of its progress in building out a global network for scaling blockchains. Furthermore, it intends to release a security token, BLXR, that pays dividends to shareholders. The dividends are generated from transaction fees, which are charged for each transaction after bloXroute surpasses 100 TPS per blockchain. In my follow-up article, I’ll be taking a deeper dive into bloXroute.

Next Steps

I’ve spent the past couple of weeks reading up on articles, speaking with folks in the community and trying to learn as much as I can around the scalability issues of the blockchain, and it’s only scratching the surface. In my follow-up articles, I’ll be publishing more information on scalability and scalability solutions, as well as interesting companies/projects I see in the space.

Got something to add? Have I thought about something incorrectly? Please let me know!