Blockchain Scalability Untangled and Deciphered

A complete guide to blockchain scalability challenges, solutions, and key projects.

Scalability is undoubtedly one of the most-discussed challenges the blockchain industry faces today from a technical perspective. Adoption being the largest non-technical challenge. At 500 Startups, I remember talking about our need to see more scalability -focused projects back in January. Within three months, I was completely overwhelmed by the sheer volume of scalability whitepapers. It seems like the entire blockchain ecosystem is working on scalability. From Proof of Time, Space, History, Authority, to every flavor of state-channels, n-tiered architectures… you name it, we saw it.

Determined not to drown in this ocean of scalability solutions, I ended up spending quite a bit of time going back to the basics and re-examine:

• Why we have a scaling issue in the first place
• What the root causes of the scalability issue in current blockchains are
• How we should logically go about tackling the problem

If like me, you enjoy learning about and keeping up-to-date on various blockchain developments, but at the same time feeling overwhelmed by the amount of information available out there, I hope this article can save you some time when it comes to the topic of blockchain scalability.

The Scalability Trilemma: Why We Sacrificed Scalability for Decentralization and Security

Bitcoin was monumental as for the first time, we, humans, have successfully implemented a decentralized, trustless payment network that is both open (anyone can join and exit the network at will), and secure.

But this is like experiencing the first Motorola phone back in 1983.

It looks like a brick and costs USD 3990. But what’s important is opens you to a whole new world of possibilities.

Martin Cooper of Motorola with first handheld mobile phone prototype DynaTAC model

In this first attempt, you can say that scaling was put in the back burner. Decentralization & security were the priorities. First, to ensure security against anyone trying to double-spend (trying to spend the same dollar twice), every participant is required validate every transaction, and to keep a full record of all historical transactions. Imagine how slow your purchase would be if every time you buy a cup of Starbucks coffee, the transaction needs to be validated and recorded by every Starbucks in the world

Photo Credit: Getty Images

Second, the network is designed, through its consensus protocol, to ensure that the more decentralized the network gets, the more secure it is against malicious attacks.

Given these two aspects of security, an arbitrary network throughput limit was set (~ 3tps) from the beginning to ensure:

• Anyone interested can join and test the network regardless of hardware status (processing and storage power). This was how many early adopters and current blockchain builders were able to participate in the beginning — using their desktop GPU to both satisfy their curiosity and also making a few bucks a week as miners. Not so bad when you were in high school and don’t need to pay for electricity!
• These participants with less powerful hardware can still keep up with the transaction validation,and storage of the historical records without causing the network to fail (in blockchain term, too many forks resulting from slow validation)

This arbitrary throughput limit was created by setting the block interval to 10 mins (average) and block size to 1MB. A block is the container used to hold transactions on the blockchain. All transactions need to be added to a block before they are propagated throughout the network for validation. With average transaction size is about 550 bytes, this results in throughput of 3tps.

Why can’t we just reduce the block interval and increase the block size until the network tps is on par with that of Visa or Paypal?

Main concerns are two-fold:

1. Centralization — Blindly ramping up tps this way may cause a jump in hardware processing and storage requirements for network participants, leading to centralization of the network into the hands of fewer participants.
2. Security — As a result of few participants, it will become easier for malicious players to mount a 51% attack on the network.

Four Components of Scalability

Scalability in blockchain can be defined by 4 components: throughput, latency, storage, and transaction fees. If you think of these as the drivers determining scalability, then any proposed solution will be tackling one or more of these areas.

We’ve built an amazing one-lane highway across the Pacific Ocean. But now what?

Photo Credit: Associated Press

1. Throughput is defined by the amount of data that flows over a network connection. On a highway, throughput of cars is dictated by the number of lanes and toll-booths. Right now, at 7tps (or 15 tps for ETH), blockchain is looking like a one-lane highway with lots of toll-booths!.

2. Latency refers to the delays incurred in the processing of network data. Again referring to the highway example, this is how fast the cars are going. At the moment, with 10-min avg block intervals and typical 6-confirmations required by different applications, we are talking about regular latency of 50–60 mins before a transaction is considered irreversible on the bitcoin network. (Shorter on ETH and Stellar but with different tradeoffs and still not short enough)

3. Data Storage, which I also consider a key component of blockchain scalability, is at times less discussed. Remember immutability on the blockchain is achieved by having every node keep a copy of the entire transaction history of the chain. This means if hypothetically both latency and throughput is solved today and let’s say that lead to mass adoption of the blockchain by all kinds of business applications, many nodes will not be able to handle the size increase of the chain, which can result in further centralization of the network.

Size of Bitcoin Blockchain from 2010–2018. Source: www.statista.com

4. Transaction Fees are currently hindering scalability as it is simply too expensive right now to run any applications on BTC or ETH with massive writes onto the blockchain. As of Sept 2018, transaction fee for BTC is ~USD 0.78/txn and for ETH is ~USD 0.013/txn. While it may seem low, but not when you are looking to write millions of transactions.

A Simple Framework to Untangling All Scaling Solutions

From Layer 0 to Layer “x”, there have been an explosion of scaling focused projects. What I’ve find useful as a short-cut to understanding and assess each new project quickly is to build a simple framework as a reference point. On a logical level, we’ve got essentially four different angles of tackling scaling. All scaling projects takes on one or more of these angles:

1. Run Faster. Make each node process more transactions faster by shortening block intervals and let more transactions fit into each block. Challenge: Network starts to centralize as less powerful nodes drop out. An example being EOS, a high performance blockchain, which currently has only 21 block producers.
2. Divide & Conquer. Think Batch Processing — separate the transactions into batches to be processed and stored by different set of nodes on the network. Challenge: Higher risk of attack on a set of nodes which has lower security power.
3. Do More with Less. Develop new smarter ways to achieve consensus and immutability faster with less computing and storage power needed from each node/ network participant. Challenge: Current consensus protocol in Bitcoin is tried and tested. Any new methods will need take time to be thoroughly tested and proven.
4. Specialization — Instead of seeing a super blockchain as the panacea that cures all, leave blockchain to do what it does best at — being open, decentralized and trustless. Enable application-specific blockchains to be easily developed. Enable blockchains to be interoperable with each other as well as other components of our existing web infrastructure. Challenge: High level of complexity and requires multiple projects working together.

Classifying All Scalability Solutions Under the Simple Framework

Now let’s apply this framework to all the common scalability solutions we have seen so far.

(As purpose of this piece is to provide a good overview without wasting too much of your time, I won’t go into the details of each sample project listed but instead provide a link to in-depth articles I find useful on each project should you want to deep dive into it.)

Since in most content published today, you see the use of “Layer 1, “Layer 2” etc. to label scalability solutions, I will also mark here which layer each type of solution is generally classified under. Layer 1 simply refers to changes that are made to the blockhain itself, whereas Layer 2 loosely refers to any additional components that interact with the blockchain to improve scalability. Thus the different Layers provide amore physical structure of where a solution sits.

1)Run Faster. Layer 1 level as these are mainly “quick fixes” that looks at shortening block interval or increasing block size.

• Segregated Witness (SegWit) — the old block limit of 1MB is replaced by a more dynamic calculation of the upper blocksize limit. Changes also made to how data is organized in a transaction and how a transaction ID is calculated. These changes together can as much as double the transaction throughput when adoption gradually increases. The Segwit change was activated on bitcoin network in Aug 2017. Current adoption stands around 40%.
• Segwit2 — designed to increase the BTC blocksize to 2mb. Failed to activate.
• Bitcoin Cash (BCH) — increased block size to 8MB. Activated through a hard fork of bitcoin network in Aug 2017, creating Bitcoin Cash.

2) Divide & Conquer. These are Layer 1 solutions that looks to apply “Batch Processing” onto the blockchain.

• Sharding — an existing technology in the traditional database world which essentially separates large databases into smaller, faster and more easily managed parts. Companies like Google & Facebook all have their own sharding technology. In the blockchain world, sharding solutions have 2 variations: transaction sharding and state sharding. Key challenge for sharding on blockchain is mainly the potential security tradeoff. This is because to achieve consensus between shards, there is a need for constant communication between shards which will negatively impact its scalability but a necessary evil to prevent malicious attack on the network via a single-shard which has only fraction of the overall hash power. Key projects working on sharding solutions are:
• Zilliqa — Transaction sharding
• Ethereum — State sharding (Planned for 2019–2020, after network transitions to PoS).
• Quarkchain — Transaction & State sharding

3) Do More with Less. Also Layer 1 solutions that are finding better ways to select block producer, propagate transactions, or achieve consensus. These mainly consist of a myriad of new consensus protocols, replacements of the PoW mechanism, or modifications of the Byzantine Fault Tolerant model. Below are a few I find interesting and gives a good overview of the spectrum of solutions we have seen that are looking to improve scalability by doing things smarter.

Directed Acyclic Graphs (DAG) — if you vision blockchain as a linear chain, for DAG — think graph of trees/ sub-trees that flow in one direction. Most projects in this space are very much in the research stage. Interesting projects in this area includes:

• IOTA — one of the earliest implementations but often debatable whether it truly is a full DAG protocol
• DAGLabs which has released several papers on a series of DAG protocols from Ghost in 2013, to Spectre and more recently Phantom.
• ByteBall
• Hedera Hashgraph

Avalanche — a family of leaderless, metastable, and PoW-free protocols that can still achieve BFT consensus on an open network. Introduced in May 2018 by Team Rocket in collaboration with Professor Emin Gün Sirer from Cornell University, a well-respected blockchain pioneer.

Solana — introduces a new Proof of History (PoH) and Proof of Replication to achieve tps in the range of 710K while keeping latency to sub-second level. Founded in 2017 by highly experienced ex-Qualcomm engineers.

Algorand — Think of it as Proof of Stake without staking token. What is interesting is it proposes an incentiveless consensus that hinges on a key concept verifiable random function (VRF) . The Algorand protocol is co-authored by MIT Professor Silvio Micali, a Turing award-winning cryptographer.

Tendermint — Created in 2014, project focused on developing a protocol (Tendermint Core) focused on the consensus and network layer to support scalability and can be used by anyone to build their application specific blockchain. Currently used by OmiseGo and Cosmos Network as their consensus and network layer.

Thunder — essentially splits the “highway” into the fast lane and the slow lane. Under normal circumstances, if over ⅔ of the network nodes are honest, than transactions will be processed via the “optimistic fast path” which is instant. On event of error, the network will fall back to the “slow lane” of PoW for transaction processing. Founded by Cornell Professor Elaine Shi and Chris Wang, founder of Playdom which was sold to Disney for USD 500M.

Coda — one of the latest and most intriguing approaches to scalability without sacrificing decentralization by using zero-knowledge proofs (ZK-Snarks( to compress the entire blockchain so that the cost of validating transactions and data will always be inexpensive

Comparison of results released by the projects in their respective test environment. As of Aug, 2018.

Comparison of results released by the projects in their respective test environment. As of Aug, 2018.

4) Specialization. These are Layer 2 projects exploring ways to improve scalability by keeping only critical components on the chain while moving everything else into a separate stack. Thus, these are also sometimes called “off-chain” solutions.

State Channels — Direct channels are established between 2 parties where transactions take place directly. Only final settlement, once the channels are closed, is processed by the underlying blockchain. While this will alleviate the work burden on the blockchain, state channel projects will need to address the fact that at the end of the day, someone or organization will need to host and operate this second layer, which can introduce both additional fees, and also additional point of failure in terms of mismanagement, hacking and corruption.

Several projects making headway in this space include:

• Lightning Network — payment-specific state channel architecture that currently works on top of Bitcoin and Litecoin network. While other main blockchains such as Ethereum and Neo also have their own implementation of payment state channel projects named Raiden Network, and Trinity respectively, Lightning is the first to be live in production and by far the most referenced. Many other major blockchain such as zcash, ripple, stellar have all indicated they will test the Lightning Network.
• Generalized State Channels — the concept was first introduced in the Ethereum community to extend state channels to other activities outside of payments. L4 was the team working on it, and the project was named Counterfactual. Recently, they have announced a collaboration with Celer Network, another generalized state channel projected founded by a team of four PhDs from Princeton, MIT, UIUC and Berkeley. Enable developers to incorporate blockchain into use cases/ applications without needing to become experts in state channels or blockchain.

Side Chains — Concept of sidechains first came about, less of a scalability solution, but more of a solution to extend capabilities of the Bitcoin network. The basic idea is to build a smaller blockchain that runs, parallel to the Bitcoin main chain to explore newer functions, capabilities like Turing complete smart contracts without impacting the main Bitcoin blockchain. If you are interested in reading up more about the early sidechains, you can take a look at Rootstock, a sidechain enabling Turing complete smart contract capability on Bitcoin.

The sidechain term started to gain momentum again in 2017 with the introduction of Plasma, a new scalability design that adds new “child” blockchains on top of the main blockchain, in this case Ethereum. Arranged in a tree hierarchy the child-chain would also be able to produce its own child-chains, creating a number of branched blockchains off of Ethereum. Each branch can have different set of validators and own consensus mechanism so faster and less expensive transactions are achieved as operations on sub-chains do not need to be replicated across the entire main network.

For those of you who want to dive deeper into Plasma: the two plasma implementations I would recommend reading up on are Plasma MVP and PlasmaCash, which is the latest improved iteration of Plasma that leverages the non-fungible ERC721 tokens as part of the solution. The Project Team Loom Network has released their Plasma Cash implementation on GitHub testnet. Based on how quickly the specifics have changed in the last year alone, I’m sure you’ll be seeing quite a bit of news, and further developments on different Plasma implementations in the coming months.

Scalability Does Not Guarantee Adoption

But having scalability will get us one big step forward on our journey towards real adoption. As we approach Q4 2018, it is clear that at this moment, there is no real meaningful adoption of the blockchain by any industry outside of speculative trading. Despite the much fanfare you may have read, or heard through various media channels, we are still waiting for the first major implementation of the true blockchain (open, decentralized and secure; not some kind of butchered distributed database with a sprinkle of cryptography) by businesses. While reaching scalability does not automatically lead to mass adoption, it is undoubtedly a critical step to get us closer. At the end of the day, there will be no disruption if there is no adoption.

Who Will Win?

Now that you’ve seen how many different ways projects are tackling scalability, maybe you are asking yourself who will be the winners? Having observed quite a few projects across China, Korea and US, I believe that projects most likely to bring us real progress in scalability will be those who are:

1. Laser focused on development. The time for ”dilly-dallying” has passed. whitepapers, project roadshows no longer suffice — projects need to start delivering tangible products.
2. Actively partners with other projects with complement strengths and weaknesses. The future will be a world of many chains and platforms.
3. Deep dives into key industry where the team’s solution can alleviate the most pain points and start engaging the stakeholders through education. Enterprise adoption can be a gruesome long process that lasts months if not years.

How to Help?

The last point is where I see the most help is needed as majority of the scaling solution teams tend come from heavy tech backgrounds. This is natural given the myriad of technical challenges that need to be overcome for scaling to work.

“There’s a ‘two tribes’ vibe about a lot of this… because blockchains and cryptocurrencies are notoriously complicated, non-experts from other industries can end up confused by techno-speak, whereas advocates of the technologies are so excited by the potential that they give insufficient attention to important details of the industries they are aiming to revolutionise.” — The Economist

Having spent years in the enterprise IT space, one thing I learned well is that the key to a client is often less how good your technology is but how well you understand the existing pain points and how well you communicate in a language your client understands. I plan to spend more time helping projects work on connecting with the right industry players. This is so that for the projects, they don’t fall into the “If I Build it, They Will Come” trap, and for the industries, they get true insight into developments of open public blockchain instead of only private distributed ledger technology.

If you are from industry and curious about blockchain, I’d love to get your help in sharing your industry insights with project teams in the scalability space!

Thanks to Edith Yeung for encouraging me to write more and for showing me that the best way to learn is through getting feedback from as many people who are passionate about the same topic or idea as possible. Thanks to Chris McCann, Edith and Eric Chiu for the tireless editing help.

Disclaimer: Information in this article is not intended to be a source of investment, financial, technical, tax, or legal advice. This article cannot substitute for professional advice and independent factual verification.