A gentle introduction to blockchain scalability (Part I)

Scalability, or rather lack of it, is one of the main roadblocks to the business adoption of blockchain technology. Why is it so hard to solve?

Bitcoin, in its current form, can handle around 7 transactions per second (TPS). Ethereum, which businesses are often more interested in as it can run smart contracts, can manage about 20. These are unacceptably low throughputs for most business applications. If you’ve just started researching blockchain, you’ll immediately see there is a “TPS war” going on between competing projects, and many of them claim to be much faster. If Ripple can handle thousands of transactions (and it can, indeed), shouldn’t everyone switch to XRP?

No.

Because of Kevin.

Let me explain.

Kevin is in the business of moving houses. He owns a small but reputable moving company, and he’s flooded with clients. If you are about to move and you text Kevin, you will find yourself in a “pick two” situation: a service can be fast and affordable, but poor; fast and great, but expensive; or great and affordable, but slow. You can never have all three, i.e., fast, great and affordable service. People think it is a joke, but it has been a subject of academic study since the 1950s under the fancy name “Project Management Triangle.”

Blockchains suffer from a very similar problem, called The Scalability Trilemma. It is essential to understand how constraints and trade-offs work in this space, before jumping on a train which looks shiny, fast and comfortable, but goes nowhere.

The Scalability Trilemma

A blockchain can only at most have two of three properties: fast, secure and decentralized. No one ever succeeded in creating a fast, secure and decentralized blockchain, although we are getting close (more on this later).

Let me add two important points before we dig deeper. First, I am not going to talk about the differences between public / private and permissionless / permissioned blockchains. Understanding them is crucial, and they will be part of an upcoming article, but we don’t need to know much about any of these to figure out the trilemma. Second, if you are a developer, you will find this way oversimplified. It’s intended.

So, how does an “ideal blockchain” looks like?

• It should be fast, or rather scalable, capable of handling thousands of transactions per second.
• It should be secure. Not free of bugs — those are inevitably present — but resistant to threats such as the 51% attack (one actor controlling more than half of the network), Sybil attacks (one actor forging and using multiple identities) or denial-of-service attacks.
• An ideal blockchain is decentralized. It ensures, among other benefits, that no single actor or a group of actors can hijack the chain, censor it, or introduce changes in governance through backroom deals. This can be important in business applications where the participants often don’t trust each other. In the case of public and permissionless blockchains, it allows anyone to join and participate in the network.

Satisfying all three at the same time is difficult.

We will never be able to build a blockchain which is faster than a traditional database running on a single server. The question is, how much speed are we willing to sacrifice.

If you want your blockchain to be as resilient to attacks as technologically possible, you need to choose Proof of Work as the consensus mechanism. In a Proof of Work system, nodes have to spend a significant amount of computing power (electricity) before they can add a block to the chain. This is a time-consuming process, so PoW chains like Bitcoin will not ever be able to compete in speed. This is not an issue; this is by design, as Bitcoin de-prioritizes network throughput.

Other consensus mechanisms (Proof of Stake, Delegated Proof of Stake, Proof of Authority, et cetera.) are significantly faster than PoW. You can’t run meaningful operations on a 7 transactions-per-second blockchain like Bitcoin, but the difference between 1000 and 15,000 TPS is irrelevant for most business applications. 1000 TPS is probably fast enough.

Non-PoW blockchains have to make a trade-off between security and decentralization and, unsurprisingly, they tend to sacrifice decentralization — no one wants to build on a vulnerable blockchain, after all. There is no single perfect solution, and individual preferences, as well as the use case, matter a lot. It’s easier to understand it through examples.

An extreme example of a fast and secure but centralized blockchain is Ripple. The validators (nodes which can add now blocks) are pre-selected by the Ripple Foundation. Participants in the network have to trust these validators, which kind of defeats the whole purpose of using a blockchain. Have we just traded unaccountable private banks for… another unaccountable private entity? The blockchain community generally dislikes Ripple, and I am sure you can see why. My unpopular opinion: Ripple is a fantastic technology, the company is incredibly efficient in business development, and I respect that. But it is a BINO. Blockchain In Name Only.

EOS is another controversial project heavily prioritizing security over decentralization. The EOS blockchain is maintained by 21 “block producers”: only they can add new blocks, and get a monetary reward. It looks very centralized compared to Bitcoin (more than 10000 nodes) or Ethereum (more than 12000 nodes), but the problem is not just technical, it’s political. First, it is widely reported that 17 of the 21 block producers are controlled by one entity, Huobi, through backroom deals. Second, EOS has a governance mechanism to reverse transactions, something they just did recently. Both go against the core philosophy of blockchain, and I would never recommend anyone to build applications on EOS. It doesn’t matter how good the technology is if the incentives in the network are entirely misaligned.

Stellar, in contrast, seems to be doing the right trade-offs. It lets *anyone* run a node; you don’t need to be “selected” by some unaccountable central entity. The problem with Stellar is the lack of incentives, as node operators don’t get a monetary reward. This design choice helps keep the transaction fees very low, but it is a double-edged sword.

There’s no free lunch. Low (or zero) transaction fee leads to less decentralization.

If people are not incentivized to participate in the network, groups and organizations with spare cash to spend will inevitably control most of the nodes. That said, Stellar is mostly doing it right.

The project trying the hardest to solve the trilemma is Ethereum (it was Vitalik who coined the term “scalability trilemma” in the first place). Ethereum is switching from Proof of Work to Proof of Stake sometime in the next 12–18 months, and this by itself will result in a higher TPS without sacrificing much of the security and decentralization it currently enjoys. Other developments like sharding will further increase the network’s throughput.

Coming in Part II

All the trade-offs and developments we discussed so far happen on the protocol level. It’s about the core logic. However, this is not the only way to scale a blockchain. Layer 2 solutions, which we will discuss in Part II, don’t increase the throughput, rather move some of the transactions (data) off the chain.

Imagine you want to store the results of a chess competition on the Ethereum blockchain (it’s a bad example as you should use a simple database, but bear with me). Every single move made by the players can be a transaction by itself, but you don’t necessarily want to store each one of them on the main blockchain. Since the players know the rules and generally trust each other, it’s enough if the individual moves are registered in transactions between the two of them. You can use the Ethereum chain to record the state of the board after every 5–10 moves or so, hitting a sweet spot between the amount of data stored and the chain being the representation of the truth.

Lightning Network, state channels, and Plasma in Part II — stay tuned!