A Byte of Blockchain - Week 56 Blockchain Trilemma Part 2


4 min read


Last week we introduced the term Blockchain Trilemma. The term was coined by Ethereum co-founder Vitalik Buterin. We took a step back to explain Trilemma before we conceptualized it as Blockchain Trilemma.

There are three critical factors to consider when setting up a Blockchain but we can only choose two of the below three & sacrifice one:

  1. Decentralization

  2. Scalability

  3. Security

The more we decentralize & scale a Blockchain, it means

A. More transactions being processed requiring

B. More space for data which means

C. Less storage space & longer processing times.

But not scaling enough means

A. Less security as the number of nodes is less &

B. A smaller Blockchain has fewer nodes making it easy to initiate a 51% attack.

As we said last week, a solution to the Blockchain Trilemma requires First Principles thinking and there are many solutions proposed for this problem. Let us explore them today.

Solutions to the Trilemma

Before we get into the innovative solutions being designed to overcome the Blockchain Trilemma, what should be the primary consideration in designing a Blockchain - decentralization, scalability or security?

The primary consideration should be security because if the network is not secure, any amount of decentralization or scalability will not overcome the limitation of less security.

To get a perspective on the trilemma, a centralized system like VISA handles around 1,500 to 2,000 transactions per second (TPS). The approximate average TPS of the Bitcoin blockchain is about 5 (this may vary). Ethereum can handle roughly double that. (Source: here).

A solution to the Trilemma means decentralized systems can handle transactions at scale without compromising security. This will also lead to the mass adoption of Blockchain as a payment rail. But in most cases, only two of the three parameters are adopted with one given up leading to trade-offs depending on the objective of the project. The below table (Source: here) provides certain examples of such trade-offs (not all are Blockchains):

Chosen ParameterGiven up ParameterExamples
Scalability, SecurityDecentralizationRipple, EOS
Decentralization, ScalabilitySecurityEmail, SMTP*
Decentralization, SecurityScalabilityBitcoin, Ethereum

\SMTP (Simple Main Transfer Protocol) is a technical standard for transmitting email over a network*

Developers are still trying to find solutions to the Trilemma. There are two schools of thought on a solution:

  1. On-chain or Layer - 1 Solution

  2. Off-chain or Layer - 2 Solution

Before we deep dive into the above two solutions, the simplest way of thinking about it is

  1. Whether the solution entails modification to the base Blockchain or

  2. Does it entail adding a layer or infrastructure on top of the existing blockchain? It can even be an infrastructure connected to the Blockchain making it like a side addition.

The former (modification of existing Blockchain) is what represents the on-chain or layer-1 solution & the latter is the off-chain or layer - 2 solution.

On-Chain / Layer - 1 Solution

On-chain or Layer - 1 solution entails modification to the base Blockchain. There are two design solutions:

  1. Sharding

  2. Improving Consensus Mechanism


Before we get into Sharding in Blockchain, let us understand what sharding means.

A shard means a piece or fragment of a brittle substance. (Source: here)

Image by Alicja from Pixabay

So, a shard means a broken piece of glass or brittle substance. Another way to think about it is to break something whole into different parts.

Visualizing the above

The concept of sharding is popular in Databases as below:

A database shard is a horizontal partition of data in a database. Each shard is held on a separate database server instance, to spread the load. (Source: here)

What does this mean? Let us visualize it as below with simple table data:

If we extrapolate the above to a Blockchain, it means we need to "break the Blockchain" into different shards. The consensus algorithm & protocol remains the same in all the shards but each shard contains its data which means there are multiple blockchains with a common protocol but individual nodes maintain their part of the data. The transaction data is broken across multiple nodes in different shards.

In a Blockchain, full nodes download all parts of a transaction resulting in slower processing times. If we shard the Blockchain, the nodes can save part of the transaction depending on the shard it is in. So, the transaction load is split across nodes in different shards instead of all the nodes maintaining full transaction data.

So, is sharding the holy grail of scaling a Blockchain? What are the benefits of sharding? Is it all hunky dory & will Blockchains be scalable like Visa or Mastercard with sharding? Not exactly. Let us explore the pros & cons of sharding next week.