Solving the Scalability Trilemma in Blockchains

1,000 TPS! 5,000 TPS!! 22,000 TPS!!! — these are the numbers many of the newer blockchains highlight when they talk about their project. Although there are many technical innovations, such claims fail to take into account that increasing TPS (transactions per second) without considering the cost of running a full node comes with a decentralization tradeoff.

A new mental model called ScaDe (Scalability-per-unit-of-Decentralization) will help the industry design better blockchains.

Decentralization is essential for blockchains. More than 70% of the value generated by the crypto industry (aka market cap) belongs to the two most decentralized blockchains — Bitcoin and Ethereum — despite their limited TPS. We have not been able to get better throughput because blockchain architectures today are very inefficient at being both scalable and decentralized. This challenge is widely referred to as the scalability trilemma.

In this piece, I propose a new mental model called ScaDe (Scalability-per-unit-of-Decentralization) that helps the industry design better blockchains. We will then look at how succinct blockchains such as Coda, using zero knowledge proofs, can go beyond the limited ScaDe of present day blockchains.

Ultimately, we believe ScaDe is a better goal than TPS, because blockchains are not computers.

Trust Machines

When Ethereum dubbed itself “the world computer”, we all began conceptualizing blockchains as computers. Computers, however, are computation machines. They make computations, like addition and multiplication, extremely fast. True blockchains, on the other hand, are extremely bad computers. They make extremely slow computations, slower than a 1990 calculator. This translates to only 7 transactions per second for Bitcoin, and 15 for Ethereum.

This is because blockchains are trust machines, not computers. They enable everyone to trust the results of a sequence of computations, without trusting one or a set of known third parties. Digital gold, aka Bitcoin, was the first obvious application built on trust machines. It’s the calculator equivalent of computers. With the advent of Ethereum, developers in the space started building and imagining many other applications: tokens, game items, tickets, identity, global financial services — just to name a few.

However, current blockchain architectures are very inefficient at being trust machines. This is because anyone who wants to use a blockchain has to re-compute the entire sequence of computations on that blockchain. That is, unless they trust a third party that does it on their behalf, at which point you lose the main benefit of using a trust machine. Due to this inefficiency, we’ve had very limited success with scaling these trust machines. This fundamental challenge is widely referred to as the scalability trilemma.

The industry sees the current state of decentralization in popular blockchains like Bitcoin and Ethereum as mostly sufficient. Although decentralization isn’t an easy feature to quantify, it’s mostly about how many different entities have the practical ability to write to (or control) and read from (or access) the trust machine. Controlling nodes (miners or block producers) are compensated directly by the chain itself to stay honest. As such, no attack has taken place on the popular blockchains, despite a bounty worth tens of billions of dollars and 10 years of time to do so.

Most of the attention from new blockchain developers has been focused singularly on increasing the scale of blockchains, which is quantified as transactions per second (TPS).

Access nodes (or full nodes), on the other hand, suffer from a tragedy of the commons as the more people who want to use and access the blockchain, the more costly it becomes to run a full node. This puts a limit, sometimes a decreasing one, on the number of full nodes (currently at 10k in Bitcoin and 7k in Ethereum). This trend has been a major point of concern for developers, to the point where it became the fundamental reason the Bitcoin Cash fork happened back in 2017: because Bitcoin developers did not want to make it any harder for end users to run Bitcoin full nodes.

Despite this concern, most of the attention from new blockchain developers has been focused singularly on increasing the scale of blockchains, which is quantified as transactions per second (TPS).

Building for ScaDe

As discussed, many blockchain developers fail to take into account that increasing TPS comes with a decentralization tradeoff. No matter how much faster a consensus algorithm can get or more efficient data structures one implements, the hard fact is that users directly accessing the blockchain have to re-do all of the calculations to access the trust machine. This is why we have been stuck on a tradeoff frontier since the dawn of blockchains, where the Scalability-per-unit-of-Decentralization is not improving. If we want to design better trust machines, we need to start optimizing for a more holistic goal.

ScaDe, Scalability-per-unit-of-Decentralization, is not improving

We propose ScaDe, which stands for Scalability-per-unit-of-Decentralization, as a new mental model to design better blockchains. Although not a deterministic model, ScaDe can be conceptually constructed as a tradeoff curve for current and upcoming blockchains.

If we focus the chart to a smaller subset of existing chains for which we can determine TPS and full node count, we do indeed see this relationship play out in real life.

Many of the use cases pursued by developers and entrepreneurs do indeed require achieving high throughput. However while doing that, we can’t let go of what is essential to a blockchain — achieving programmable trust without intermediaries. If we go back to having to trust a limited set of intermediaries, there is no point to using a really bad computer. Just use cloud computing, it’s way cheaper!

Not only does using a bad computer not make sense, but we are also seeing the adverse results of projects making decentralization tradeoffs as they can’t go beyond the present day ScaDe frontier. EOS has had the majority of its nodes get consolidated to Chinese actors. Libra is seeing intense regulatory pressure because all the nodes are known, even before its launch. The truth of the blockchain matter is that, the only way to increase the usability and reach of applications built on blockchains is finding ways to go beyond the present day ScaDe frontier. As such, this is the metric by which users and developers should be comparing their blockchain options, not TPS.

So, how do we achieve higher ScaDe?

Enter Zero Knowledge Proofs

Zero knowledge proofs (ZKPs) are computations that produce a proof which allows anyone to easily and cheaply verify that the computation was done correctly. So instead of doing a computation again to trust its result, you check the proof. (For more on ZKPs, check out a comprehensive guide here.) If applied to blockchains in a specific way, such as in Coda, this enables users to easily check computations that were done prior to them accessing the blockchain. So instead of re-computing all computations from the first block, any user can verify a simple proof that enables them to trust that the other participants computed all the transactions and rules of the blockchain correctly. This enables a 1,000x improvement to the complexity of running an access node. Currently the fastest time to bootstrap a Bitcoin node from scratch is 6.5 hours with a $2,000 desktop computer. With Coda, it’s milliseconds on an average smartphone.

If we don’t have to re-compute all transactions thanks to ZKPs, we can increase ScaDe by orders of magnitude.

Remember that we haven’t been able to go beyond the ScaDe frontier because no matter how we increase TPS, we had to re-compute all transactions. If we don’t have to do that anymore thanks to ZKPs, we can increase ScaDe by orders of magnitude.

Although we get immediate benefits to both decentralization and TPS using current state of ZKPs, we are indeed limited by engineering limitations of how fast proofs are computed and how fast data can travel through a P2P gossip network. The good news is, ZKPs present us with a sustainable path to continue increasing ScaDe (and hence TPS). Advances in computation of ZKPs, specifically SNARKs and its variants, have been improving proof speeds and other required features (such as trusted setups) in an exponential manner. In 2019, we saw as many new SNARK constructions as in every year before, combined. We’re also seeing prover speeds get faster multiple times, such as how we at O(1) Labs got a 4x speed improvement during the SNARK challenge.

Conclusion

The blockchain industry has lacked a framework that enables users and developers to accurately and fairly compare different blockchains for what they are — trust machines. The primary function of these machines, programmable trust, is enabled by how decentralized and permissionless they are. Popular chains like Bitcoin and Ethereum require users and developers to run equipment worth thousands of dollars or sign up for services from intermediaries. This prevents users who can benefit the most from crypto from accessing these chains, either because they do not have sufficient resources or are censored by these intermediaries. If we continue to build Blockchains in this manner, we will sacrifice the revolution of trust machines. Instead, we will end up replicating our existing financial system, just with a new set of logos for centralized incumbents.

I am proposing ScaDe as a mental model that pushes the industry to design better blockchains without decentralization tradeoffs. When we look at the blockchains that are live or are under development, most of them are stuck on a ScaDe frontier. This forces developers and users to make tradeoffs (digital gold [Bitcoin] vs regulated payments [Libra]).

The way to achieve better ScaDe is to design more efficient trust machines where every user does not need to re-compute every transaction since the genesis block in order to directly access the machine. By using Zero Knowledge Proofs (ZKPs) to fix the size of the blockchain to a tiny proof, we can achieve a far more efficient design, and better ScaDe. At Coda, we have been working on this for the past 2 years and have been publicly testing it for 6 months. We are targeting to launch the world’s first blockchain with a considerably better ScaDe in the summer of 2020.

This post was originally published on the Coda Protocol Blog