Blockchain Trilemma

Blockchain characteristics are determined by their type and have particular implications. It is not an appropriate solution to use cases that necessitate a high level of privacy. If a solution is needed for a homogeneous environment where everyone trusts each other and has full control over the flow of data, and the environment itself is not exposed to any external threats – blockchain is going to be a very slow and disturbing database.
The technology becomes relevant if dealing with a lack of trust in the network. But before analysing specific blockchain use-cases, let’s break down the problems.

The Scalability Trilemma

[…] blockchain systems can only have at most have two of the following three properties:

~ Ethereum Sharding FAQ
Scalability Trilemma


Scalability is an ability to handle an increased workload.

Weinstock and Goodenough (2006)

Scalability can be achieved by applying a cost-effective strategy for extending a system’s capacity. The definition can be used against any distributed systems, e.g. in the cloud computing industry. One can handle an increased demand by allocating more resources, e.g. memory or CPU.

Once having an idea of what scalability means, the question arises:

What does it mean that the blockchain technology problem is lack of scalability?

The Ethereum team with Vitalik Buterin introduced a Scalability Trilemma which states that an ideal blockchain system should have three characteristics: scalability, security and decentralisation. According to the Trilemma, a blockchain system can have only two out of the three, e.g. improving scalability reduces a security level or the decentralised network on-chain. There is a trade-off between getting a higher degree of one property and sacrificing the other ones. The concept has probably derived from the CAP theorem which applies to distributed systems, thus for blockchain as well.

CAP stands for Consistency, Availability and Partition Tolerance. Any distributed system can have at most two of these aspects. It indicates that there cannot be a system that simultaneously: provides the same view of data to all the nodes, always responds to a user’s request and works as expected despite the arbitrary physical network partitioning triggered by network failures.


Public blockchains achieve much lower transaction throughput than the traditional payment methods. In the table below transactions per second (TPS) processed are mentioned.

Visa (2013)Visa (2017)BitcoinEthereumCordaHyperledger Fabric
24 00065 0003.3-77-1525803500

A limited throughput for Bitcoin is caused by its block size bound to 1 MB and a long block interval time, i.e. time of confirming a transaction, including it in a block. An expected latency is 10 minutes to create sufficient security. For comparison, another leading credit card company, Mastercard, claims to have the transaction processing speed below 500 ms.

Public permissionless blockchains like Bitcoin or Ethereum tend to use PoW as a consensus mechanism. The resulting latency is the cost of propagating block over the decentralised network and utilising a relatively expensive consensus protocol, which is required to prevent Sybil attacks (e.g. 51% attack). Increasing block size seems to be an obvious solution to this problem. However, it results in a higher computing power requirement for confirming transactions, which leads to the risk of network centralisation by supercomputers.


A conventional blockchain system requires a node to store the complete transaction history. Therefore, a full node requires vast amounts of storage.

A current Bitcoin’s blockchain size reaches nearly 300 GB.


The last scalability issue, related to networking, is the data transmission delay. In the Bitcoin model, each transaction broadcasts twice:

  1. After creation (and moving to a transaction pool).
  2. After transmitting within a mined block.

The bottom line

Often omitted is the fact that the scalability issue should be addressed primarily to permissionless blockchains. A transaction approval usually takes a few minutes. The problem is worse in public permissionless since every node is a validator.

In public permissioned, as in any private blockchains, only selected nodes can validate. Permissioned blockchain systems can perform significantly better, sometimes even close to permissioned networks, such as Visa, Mastercard or PayPal, due to a low number of nodes and utilising different consensus algorithms.

Permissioned blockchain relies on having a trusted authority. Increasing both scalability and security violates decentralisation by allowing a middle-man, which seems to be just what Scalability Trilemma addresses. Permissioned blockchains are controversial because the original blockchain assumptions put an emphasis on the idea of having a purely distributed system, and their existence seems to be a step back to centralisation.


Another challenge in the blockchain system is security and data privacy. While decentralisation is a desirable feature, it leads to trouble in maintaining data integrity. Timeliness of transactions can affect both system’s performance and security. One of the possible attacks is double-spending – a data integrity violation that may appear in purely distributed P2P systems like blockchain.

Double-spending problem (Bob spends the same Bitcoin to Alice and Carol)

Malicious peers are a threat to the network, and even there are machine learning (ML) efforts made to detect them. Allowing peers to verify new transactions is a way to prevent transferring ownership more than once. However, to verify transactions, their log has to be transparent. One of the most prominent blockchain technical limitations (addressed by Drescher) is lack of privacy. The system has to reconcile two opposite concepts: transparency and privacy.

Blockchain is a type of distributed system, and such a system is as safe and trustworthy as its members are diverse and dispersed.

The blockchain security model is yet another limitation. Users identification, authentication and authorising their transactions require a pair of keys. A public key is an account number or, in terms of cryptocurrency, a wallet address. A private key is used to generate a unique digital signature to confirm who makes the transaction. Blockchain uses powerful cryptography methods. Its security model is not a problem itself. Unlike centralised applications in the P2P system, there are no security procedures to revoke access to the account when one looses their own private key. The situation is not rare. Most users store their private keys on the computer where it is prone to be stolen either by malware or hard disk failure. Few ways to avoid losing the key is creating its backup or using offline storage. If the user fails to keep the key in a safe place, there is no way to reset it like most real-world systems allow to do with a password.


Public blockchains suffer from many scalability issues, and the private ones tend to be centralised by an intermediary. Permissionless is not secure, since it allows nodes to be anonymous and permissioned may lead to centralisation as well.

Major scalability solutions try to improve research areas such as network efficiency, storage, data usage and a consensus algorithm. There are also attempts to reduce the impact of the third missing feature from the Trilemma.

Various blockchain types have different favourable properties and concerns connected to their distributed nature. On deciding to use blockchain, dealing with the problems is inevitable. However, it the main goal is to benefit from the advantages it gives.


Java software engineer, DevOps enthusiast. Enjoys developing her own and university projects on GitHub. Her spare time spends actively doing rock climbing and pole dancing.