paint-brush
Scale and Decentralization Shouldn’t Be at Oddsby@EmreTekisalp_Coda
406 reads
406 reads

Scale and Decentralization Shouldn’t Be at Odds

by Emre TekisalpMarch 5th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Emre Tekisalp is the Head of Business Development at O(1) Labs, the team behind Coda Protocol. He explains how to judge a blockchain’s potential for meeting the needs of the modern digital economy. We’ve been wrongly thinking of blockchain systems as a zero sum game where you either get decentralization or you get scale, never attaining both at the same time. To sustain a rapidly growing userbase, blockchains should possess three key traits, while retaining, or even better increasing, decentralization. The Bitcoin blockchain, for example, can process at most 7 transactions per second.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Scale and Decentralization Shouldn’t Be at Odds
Emre Tekisalp HackerNoon profile picture

The blockchain industry has been caught in a very limited mindset of how to judge a blockchain’s potential for meeting the needs of the modern digital economy. Transactions per second (TPS), the dominant unit for measuring the ability to scale, appears to be the only concern when designing blockchains.

Indeed scale does matter, but as long as the blockchain stays decentralized. We’ve been wrongly thinking of blockchain systems as a zero sum game where you either get decentralization or you get scale, never attaining both at the same time. This notion is also known as the scalability trilemma.

We need to, and can, debunk this false idea. In order to focus on this goal, I am proposing a new mental model for evaluating a blockchain’s potential for success: ScaDe (Scalability-per-unit-of-Decentralization).

Why Scale Matters

Scale is a bit of a vague term, but it loosely refers to the ability of a blockchain to meet the needs of the modern digital economy. To sustain a rapidly growing userbase, blockchains should possess three key traits, while retaining, or even better increasing, decentralization: 

  1. Throughput (measured in transactions per second (TPS))
  2. Cost (measured in fees)
  3. Size (measured in data)

Without all of these characteristics, it’s unlikely the protocol will continue to be used over the long-term. 

The challenge has been achieving all of these qualities at once. The Bitcoin blockchain, for example, can process at most 7 transactions per second, with a transaction fee of a whopping 53 USD at peak times, and a current blockchain size of about 260,900 MB.

Compared to Visa, which says it can process up to 65K transactions per second, 7 TPS isn’t great. Spending 53 USD per transaction on the other hand, can be worth it for large values, but is hardly an improvement over our existing financial system. Additionally, a blockchain size of nearly 270 GB is massive. Streaming a Full HD Netflix show for 1 hour uses about 3 GB. 

Graph from Solving the Scalability Trilemma blog post showing the number of nodes of Bitcoin (blue) and Ethereum (red) over time. Though Ethereum once showed potential for greater decentralization than Bitcoin, the number of nodes has decreased over time.

At this point you might be wondering what Bitcoin is good for, given its latency, relatively high cost to send a transaction, and incredibly data-heavy blockchain.

Bitcoin continues to demonstrate utility as a store of value, which doesn’t require the same characteristics that are essential for transacting in a fast-paced digital economy. That said, Bitcoin’s design does not make it a great solution for p2p payments or as an infrastructure layer to power decentralized applications (dapps).

Attempted Solutions

Unfortunately most other cryptocurrency networks are not much better than Bitcoin when it comes to improving scalability while retaining decentralization.

As the below graph illustrates, generally speaking, as scalability improves, decentralization decreases, with the most “scalable” blockchains like Ripple coming awfully close to being centralized databases.

Graph from Solving the Scalability Trilemma blog post plotting number of nodes vs. Scale (TPS) for various blockchain networks. 

There are many protocol layers attempting to resolve blockchain’s scalability issue with layer-two solutions like Bitcoin’s Lightning Network or infrastructure solutions like sharding.

Unfortunately, layer-two solutions involve projecting some transactions off-chain for faster processing, which is a loss to transparency and security. In a similar vein, sharding involves the creation of smaller networks within the whole, but this solution puts these “mini consensus zones” at greater risk to attacks (when a majority of nodes collude against the whole to accept an incorrect version of the blockchain that benefits themselves).

Some projects have sought to address blockchain’s scalability issue by focusing on block size, which, in many ways, is the heart of the problem. Bitcoin has a fixed block size at about 1 MB.

This relatively small block size means a limited number of transactions can fit within each block (at the time of writing: 2,140 transactions/block). This creates competition over which transactions are processed first. Users who want faster processing can pay a higher fee, which means there is often a long queue of low-fee transactions that haven’t been prioritized by miners. 

Increasing block size allows for more transactions per block and so decreases competition over which transactions are validated first and lowers fees, but this choice introduces a different problem.

Larger block size means upping the resource requirements of both validating and full nodes, as they must process more data per block. A smaller pool of eligible nodes leads to centralization, which starts to errode the purpose of using a blockchain in the first place.

How Do We Fix It?

First, we need a new language to better encompass the solution blockchain projects should strive for—one that incorporates scale and decentralization. To give us a better way to talk about this, I’m proposing a new term: ScaDe (Scalability-per-unit-of-Decentralization).

By incorporating decentralization into the unit of measure that we are using to compare projects, we will be that much more accurate in our analysis of who is making real progress. To-date, scale and transactions per second (TPS) have been used synonymously, but as discussed at the top of this article, TPS is only one piece of what is required to meet the needs of the modern digital economy.

A scalable blockchain should not only be fast, but also have low fees and be lightweight from a data perspective—all without sacrificing decentralization.

If we continue to use only TPS to measure a project’s potential, we will be making judgements on which projects are teeing-up the future of the industry based on a third or less of the important information.

The new model, ScaDe, helps us work towards a solution that will genuinely meet the needs of the modern-day digital economy without sacrificing the core values of decentralization that make blockchain networks distinct from all other systems. 

(In full disclosure, our project, Coda Protocol, is utilizing recursive zk-SNARKs to eliminate the cumbersome issue of block size and instead represent the entire history of blockchain transactions in a light-weight proof that is only about 3 kb, or the size of a few tweets).