How the Scalability Trilemma drives blockchain innovation

The Scalability Trilemma (coined by Vitalik Buterin) is a concept worth digging into as advances in blockchain technology truly arise from trying to resolve it. A fascinating array of solutions drives the expansion of chains and projects.

Essentially, there are three key properties that a blockchain system needs to balance; but achieving all three attributes is a challenge that eludes most blockchain systems resulting in tradeoffs between these competing attributes. The trilemma posits that a blockchain can only optimize two out of three critical properties.

The three properties are:

Scalability: Scalability refers to how well a blockchain can handle a growing number of transactions.

Decentralization: Decentralization ensures no single entity controls a blockchain. A decentralized blockchain relies on a global network of computers, called nodes, running the blockchain's software. The chain can run without any trust dependencies on a small group of actors.

Security: Security ensures that transactions are valid and immutable once confirmed. The chain can resist a large percentage of participating nodes trying to attack it.

The Problem

The pioneer blockchain designs of Bitcoin and Ethereum prioritised decentralization and security leading to troublesome scalability issues as popularity increased. Gas and transaction fees reached formidable heights and led to virtual unusability in 2018 with transactions per second unable to come anywhere close to meeting demand.

These bottlenecks spurred a wave of research with each approach attempting to hold onto the core tenets of blockchain.

The Solutions

Solutions range in their success, whilst sharding and some layer 2 protocols have been successful, others such as federated blockchains have not.

Sharding

The concept of sharding, originally from database management, involves dividing a larger database into numerous smaller datasets across various nodes. A blockchain network is divided into multiple shards (n number of shards) with each shard consisting of a number of nodes (m). The total number of nodes in the blockchain network is n × m.

Each shard maintains its own independent blockchain, processing its own sequence of blocks and transactions without any interactions with other shards (transactions are processed in parallel within their respective shards unless a cross-shard communication mechanism is implemented).

info

Cross-shard transactions are more complex because they cause higher latency due to communication between shards, additional coordination overhead to manage transaction steps across shards and security challenges in maintaining consistent and secure data across multiple shards.

Sharding techniques can be Static, Dynamic or Layered.

Sharding techniques

Static Sharding is a technique that determines the shard size and number of shards based on the number of nodes that are then allocated equally across different shards.

Dynamic Sharding facilitates dynamic resource sharing to cope with demand. That may allocate the nodes across different shards and dynamically change the shard sizes and number of shards.

Layered Sharding entails allocating a shard with transactions and if it reaches capacity, any subsequent transactions are assigned to a shard with sufficient processing capability.

Zilliqa (ZIL) was the first public blockchain to implement sharding. NEAR Protocol uses a dynamic sharding approach called "Nightshade," where shards are added or removed based on network traffic, ensuring efficient scaling. TON (The Open Network) uses an "Infinite Sharding Paradigm," where shards can automatically split or merge based on transaction load.

Challenges are:

1. Scaling Byzantine Fault Tolerance consensus protocols. Scaling needs to work across the three phases of practical Byzantine fault tolerance. Pre-prepare, Prepare and Commit.

2. Ensuring secure and efficient shard formation

3. Enabling secure distributed transactions even with malicious coordinators.

Whilst successful as a solution, sharding is not without downsides. Whilst improving scalability, it introduces cross-shard latency and reduces per-shard decentralization.

Zero-Knowledge Rollups (ZK Rollups)

Zero-knowledge rollups or zk-rollups bundle hundreds of transactions off-chain. User transactions are submitted and executed by a Layer 2 operator. A cryptographic proof of their validity is then generated by a 'prover' often a SNARK or STARK. They confirm that the transactions are valid and this mathematical proof is submitted to the Layer 1 chain along with the bundles of transactions as a smart contract.

The Layer 1 chain uses a smart contract to verify the mathematical proof. If it is successful then the transaction is updated on-chain with near-instant finality.

This approach dramatically reduces network congestion, lowers gas costs and increases throughput while security is inherited from the underlying Layer 1 chain.

Challenges are:

1. Layer-2 protocols like ZK-rollups enhance throughput but rely on centralized provers/ This can potentially create new attack surfaces.

2. Possible trade-off with decentralization due to centralized provers.

It's mainly Layer 2 scaling solutions for Ethereum that use zk-rollups. Popular ZK-rollup blockchains include StarkNet, zkSync, and Polygon Zero.

State Channels

State channels enable two or more participants to securely transact off-chain with only the initial opening and final closing states recorded on the main blockchain.

Channels are simple peer-to-peer protocols. They use cryptography to demonstrate that the summary data they generate is the result of a valid set of transactions. A multisig smart contract ensures the transactions are signed by the correct parties.

Participants lock funds in a smart contract, exchange signed updates directly, and settle the final balance on-chain.

This allows for high-frequency, private, and low-cost transaction throughput and lower costs for users.

The Lightning Network is probably the most well-known project using state channels for Bitcoin. Ethereum (ETH) Uses the Raiden Network for ERC-20 token transfers and specialized platforms like Connext (formerly part of SpankChain) and Counterfactual for general state updates (e.g., in gaming or dApps).

Challenges are:

1. A state channel can fail potentially putting funds at risk.

The following solutions have been less effective at achieving the aims of balancing the central tenets of the blockchain whilst improving scalability.

Delegated Proof-of-Stake (dPoS)

Delegated Proof of Stake (DPoS) is a blockchain consensus mechanism where users vote to elect delegates who validate transactions and create new blocks. It combines a democratic process with a collateral staking system to enhance efficiency and address the limitations of traditional Proof of Stake.

With Proof-of-Stake, the higher a stake a validator has in the blockchain, the greater likelihood they are selected to validate a transaction. In doing so, they earn the transaction fees associated with the transaction. In delegated-Proof-of-Stake (dPoS), token holders vote for the delegate they choose to validate the transaction. In doing so, they consider factors like reputation and reliability. This additional voting layer prevents centralization whilst also improving transaction speeds. dPoS prevents the same validators being repeatedly chosen to perform validation simply because they have the highest stake regardless of their performance. This democratization of the validation process is thought to make the chain less centralized and so more secure from bad actors.

Transaction speeds increase because the need to wait until a certain number of untrusted nodes have verified a transaction before it can be confirmed is eliminated.

Projects using dPoS include EOS with 21 elected block producers. TRON (TRX) with 27 Super Representatives (SRs) for network consensus and BitShares - One of the earliest platforms to implement DPoS, focusing on decentralized exchanges.

Challenges:

1. dPoS does not necessarily tackle the centralization tendencies of Proof-of-Stake, it simply reintroduces centralization along different lines. For example, a particular validator may be the most reliable and efficient and so is constantly voted for.

2. Trust is not distributed architecturally within the system technologically, it becomes prone to the risk of potential collusion among delegates. Security is reduced.

3. dPoS achieves scalability but at the expense of decentralization.

Federated Blockchains

Federated or consortium blockchains blend features of private blockchains and public blockchains. They are typically set up with only a few participants such as investment banks or other financial providers. Validators are pre-selected and then all other participating nodes must agree on a transaction for it to be added to the chain.

R3 Corda is a prominent platform utilized by over 60 financial institutions to provide consortium blockchain services.

IBM Food Trust (Supply Chain) connects retailers, suppliers, and producers (e.g. Walmart, Nestle) to enhance transparency and food traceability.

Challenges

1. This solution optimizes security and scalability for its participants very much at the expense of decentralization. Such purposes provide utility for a different set of usecases than traditional blockchains.

### Conclusion

The blockchain trilemma endures as a limitation in the evolution of decentralized systems. The pursuit of solutions that harmonize security, scalability, and decentralization remains an important driver of innovative and bleeding edge technology.