bloXroute Labs
Published in

bloXroute Labs

The scalability problem, (very) simply explained

This post originally appeared on the bloXroute SubReddit.

There has been a lot of arguing around the “scalability problem”, and we’d like to explain what exactly is the scalability problem and what is causing it, so it’s obvious, even to the least technical members of the community. We will refer to Bitcoin, being the golden standard and most well-known crypto, but the problem is identical for all blockchains, permissionless or permissioned.

We think it’s worth pinpointing the problem, otherwise it’s going to be very hard to resolve it, right?

The way Bitcoin works, is that every time a new block is mined, it is being propagated to the entire Bitcoin network using a “P2P Propagation Mechanism”, which is a fancy name for saying the miner sends it to its 8–10 peers, who send it their peers, etc., until it reaches the entire network (or 95% of the network, since some nodes might have just gone offline, or restarting, or whatnot), and it is used because it is trustless.

It turns out that even in the optimal scenario, where no message ever gets lost, there is no congestion, there is no computational overhead, no latency, no network topology issues, this propagation creates a bottleneck.

Imagine this:
You have mined a 1MB block, and you are about to send it to your peers. You could send it to your peers either in parallel or sequentially, and it will take the same time, but sending sequentially will allow your first peers to start help propagating the block quicker, rather when all your peers have finished receiving it. So, in this optimal scenario, peers even propagate sequentially rather than in parallel.

Now, how long is it going to take the block to propagate? After 1 “hop”, in which the miner sends the block to a single peer, 2 nodes know about it. After another “hop”, 4 nodes know about it. After 3 “hops” 8 nodes know about it, and it increases exponentially until after 12–15 “hops” it reaches the entire network of thousands of nodes.

The current capacity of Bitcoin (BTC) is 1MB every 10 minutes, and since the average transaction size is ~540 bytes, it processes ~1950 transactions every 10 minutes, which translates to ~3 transactions per second (TPS). If you wanted to increase the capacity by x10, you could increase the blocksize by x10 (Bitcoin Cash’s approach), or you could reduce the time between blocks by x10. The negative side effects are going to be the same, so let’s start by thinking of x10 larger blocks.

If you increase the blocksize by x10, the number of “hops” you are going to need remains the same — 12–15 “hops”. However, now each hops requires sending not 1MB but 10MB block over a ~60 Mbps link (current average link speed in the Bitcoin network), and the time it takes will increase by x10, from 0.13 sec to 1.3 sec. The total propagation time will also increase by the same factor: x10.

Now, why do we care? Why did we walk you through this entire analysis?

Because the block propagation time defines the window of opportunity for forks to occur. Forks naturally occur only if you mine a new block, despite the fact a new block was already mined, which would happen if it’s still being propagated and you didn’t hear about it in time. If you wouldn’t have mined the block, there would be no fork, and if you would have heard about the new block, your incentive would have been to mine on top of it.

If you increase the block propagation time by x10, the probability for a fork to occur increases by almost x10, at least until that probability is very close to 1.0, since its directly depend on the ratio between (1) the block propagation time, and (2) the time between blocks (this is also why it doesn’t matter if you increase the block size or reduce the 10 minutes interval).

So, if you increase the blocksize by x10, you increase the block propagation time by x10, and you will see ~x10 more forks (once 10MB blocks are full), but this is still OK! Blockchains know how to resolve forks once the next block is mined.

But, if you want to scale from 3 TPS to 300 TPS (which is nowhere close to the tens of thousands required for B2B micro-transactions), and to increase the blocksize by x100, the block propagation time becomes so long that in reality it exceeds the 10 minutes interval between blocks! You will see forks occur at a higher rate than blocks which resolves them, and the blockchain “unravels” to more and more forks (since there is no longer consensus which is the “right” fork), and the blockchain breaks.

This is the scalability problem, and the reason why no blockchain can do full 300MB blocks every 10 seconds.

We will give more information about FIBRE, Falcon, Compact and Xthin blocks and Graphene in another post, but as a starting point we think it is crucial to identify this as the root cause of the scalability problem.

— — —

We’re always looking for good people!

If you’re equally excited to solve the scalability bottleneck for all blockchains, consider joining our team! We are always looking for passionate partners to help us on this important journey. Check out our available positions to work with us in our Chicago offices.

Learn more




Scaling blockchains to thousands of on-chain transactions per second. Today.

Recommended from Medium

What’s All the Fuss About Non-Fungible Tokens (NFTs)?

Some Feel-Good News About Rebakedinc to Brighten Your Day

Could Blockchain Technologies Level out Income Inequalities?


bloXroute Collaborates with Top Blockchains

AcknoLedger: Gateway to Web 3.0 Metaverses and Gaming NFTs

Can Blockchain Save the Global Farmer?


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
bloXroute Team

bloXroute Team

Scaling blockchains to thousands of on-chain transactions per second. Today.

More from Medium

What problems do cross-chain bridges solve?

Immutable Metadata

Grid showing tile locations in 21 million pixels image

Smart Contract — Legal and Technical view

Ethereum Scalability: Sharding Explained