Solving the Blockchain Trilemma
The Trilemma in question
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: 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?
Self-allocation (to shards?)
No separate chains (proposal/security chains all interconnect)
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?