Solving the Blockchain Trilemma

by Sreeram Kannan, David Tse, and Pramod Viswanath
Solving the Blockchain Trilemma
Contributors (4)
Oct 05, 2019

Real-time transcript.


The Trilemma in question

Decentralization: Democratizing
Security: Trust
Scalability: At scale

DSe: Bitcoin, Ethereum
DSc: IOTA?, Ghost?
ScSe: EOS?, … ?

The Promise + Gap

A major gap is scale: Core blockchains currently handle 20 Tx/s.

Decent: PoW, latency optimality, bandwidth efficiency.
Security: Adaptive adversaries, incentive compatibility.
Scaling: Storage + compute + b/w efficiency: scaling w/ # of nodes, w/ resources per node, w/ a given set+cost of nodes.


A composite approach reaching 250K Tx/s. (Contrast DFinity + Algorand at 1k Tx/s) Including Prism and other components.

Prism: vertical scaling

Separate current chain into three parts:
transaction blocks, voting blocks, and confirmation blocks.

Vertical scaling: Reliable confirmation via unreliable votes.

Implementation in Rust: w 1000 voting chains. See images from “Prism: Scaling Bitcoin 10,000x”. Algorand maintains solid throughput for latency down to ~2s. Throughput capped at 1K tps at adversary-power of 20%. Claims a throughput closer to 100K tps at adversary-power up to 44%.

Horizontal scaling

Horizontal scaling: storage + computation
Current sharding challenges include maintaining ~full state at ~all nodes. Track Storage + Compute.

Computation: ask many nodes randomly to validate.
Storage: polysharding? perhaps. Can we combine these?

  1. Self-allocation (to shards?)

  2. No separate chains (proposal/security chains all interconnect)

  3. Decouple validation from consensus
    :consistent even w/ no honest miners in a shard; live w/ at least 1.
    :computation and space/order efficient

Horizontal scaling: communication

Need to address: data availability and adversarial fuzzing. Error correction codes as a way to make spoofing [bad] ec-coding more expensive.
Approach: ‘coded merkle tree’. Small proof to demonstrate a fradulent proof.


nvme + sync + demo —> live version of the previous animation? 36 EC2s, 6 shards?

Transaction blocks are arranged into 6 shards (different colors, white to pink), miners sefl-selects which shards it mines for. miners contribute to both lingest-chain and voting blocks, on a common chain. The blocks cluster in to shards here? new central blocks include transcations from each of the shards.

~190k Tx/s: forking rate of <2%. self-reported stats: fairly distributed across the 6 shards.

Every client maintains all of the voting chains? 1 voting block is 0.1% the size of a txn block. Still a small part of the total workload?


No comments here