A brief history of scaling blockchains

In the year 2009, the time when Bitcoin first launched it was clear that, by design, it traded off transaction speed for decentralization and security.
Each block contained ~1mb of transactions. It took approximately 10 minutes to produce a new block. And it took another 45–60 minutes before you were sure your transaction had made it through.

This was so because there was a limitation on the number of transactions a network could process. Bitcoin aimed for ~20 transactions per second (tps), and in reality achieved about ~4 tps.

Scaling through simple parameter tweaks

So it became quite natural that the initial scalability solutions evolved around the idea that we could just stuff each block with more transactions.
To tackle this problem, we could simply make blocks bigger. Or, we could make each transaction smaller.

The implementation born out as a solution to this problem was cryptocurrencies like Litecoin and Bitcoin Cash which hard-forked from Bitcoin to with smaller transactions and larger blocks, respectively. In practice, these efforts yielded 2–10x tps optimizations.

But there was a fundamental issue with these scaling solutions was that each change required a hard fork. This required the community to rally behind the new chains and thus its adoption was very limited. There’s also a practical upper limit to how much we can tweak these dials while still ensuring decentralization.

Scaling through on-chain sharding

More solutions were found about the fact that transactions cluster around different social communities.

For example, transactions occurring within a shipping network in Dubai, vs. an eCommerce marketplace in Mumbai, vs. freelancer community in Bangalore, won’t often overlap.

It made sense to adopt a traditional database concept of sharding. In sharding, you can have different computing resources, nodes, handle different transactions in parallel in just one blockchain.
In theory, transactions are usually contained in clusters of networks and are easy to parallelize.

Zilliqa is a good example of this, which has developed a complex sharding algorithm.

Practically, parallelization is a very difficult task to achieve. The challenges range from how to securely allocate transactions per node, to ensuring data availability among nodes, to resolving network asynchronicity issues…

A simple case for this problem can be where there is a transaction C in node C, which depends on a transaction A in node A and a transaction B in node B, which also has other dependencies, added with the reality of network latencies… becomes difficult to resolve.

The list for brilliant, blockchain scalability solutions goes on and on. From blockchains that are represented less like chains and more like directed acyclic graphs, to much more faster consensus algorithms like PoS, PoA, specifical mutations of the federated BFTs and delegated BFTs that guarantee faster block validation & production… users now have a lot of options of solutions to choose from.

The challenge going forward might be around adoption.

Aside from canonical chains like Bitcoin, Ethereum, and Eos, the majority of upcoming blockchains remain quite underutilized and doesn’t receive many mentions and limelight. Moving forward, all chains in the ecosystem will need to find product-market fit, given the scaling tradeoffs they have made.