Coins, Clubs, and Crowds: Scaling and Decentralization in Next-Generation Blockchains
Total Page:16
File Type:pdf, Size:1020Kb
Coins, Clubs, and Crowds: Scaling and Decentralization in Next-Generation Blockchains Prof. Bryan Ford Decentralized and Distributed Systems (DEDIS) School of Information and Communications (IC) [email protected] – dedis.epfl.ch Vienna BDLT Summer School – September 3, 2019 Where there’s data, there’s risk... Access, sharing compounds risk Weakest-Link Security “You can trust us!” Shared Access Partner A Business Partner B Partner C “All of us!” A Fundamental Challenge In today’s IT systems, security is an afterthought ● Designs embody “weakest-link” security Scaling to bigger systems → weaker security ● Greater chance of any “weak link” breaking Central Databases = Attractive Targets One of three credit rating agencies in the US ● Exposed sensitive personal information about 143 million people (44% of US population) The DEDIS lab at EPFL: Mission Design, build, and deploy secure privacy-preserving Decentralized and Distributed Systems (DEDIS) • Distributed: spread widely across the Internet & world • Decentralized: independent participants, no central authority, no single points of failure or compromise Overarching theme: building decentralized systems that distribute trust widely with strongest-link security Strongest-Link Security Weakest-Link Security Turning Around the Security Game Design IT systems so that making them bigger makes their security increase instead of decrease Weakest-link Strongest-link Scalable security security Strongest-link security DEDIS Laboratory Members Bryan Ford Philipp Jovanovic Associate Professor Postdoctoral Scholar Lefteris Kokoris-Kogias Kirill Nikitin Cristina Basescu Enis Ceyhun Alp Ph.D. Student Ph.D. Student Ph.D. Student Ph.D. Student Jeff R. Allen Kelong Cong Gaylor Bosson Noémien Kocher Software Engineer Software Engineer Software Engineer Software Engineer Today’s Hot Decentralized Technology (credit: Tony Arcieri) Bitcoin (2008) First successful decentralized cryptocurrency… How to track wealth (or anything)? Things Ledgers ● Gold, beads, cash... ● Who owns what? Precedent: the Rai Stones of Yap Stone “coins” weighing thousands of kilograms ● Left in place once created (“mined”) ● Ownership transfer by public proclamation (this comparison shamelessly borrowed from Gün Sirer and others) Distributed Ledgers Problem: we don't want to trust any designated, centralized authority to maintain the ledger Alice 5 BTC Bob 2 BTC Charlie 3 BTC ... Solution: “everyone” keeps a copy of the ledger! – Everyone checks everyone else's changes to it Alice's copy Bob's copy Charlie's copy Alice 5 BTC Alice 5 BTC Alice 5 BTC Bob 2 BTC Bob 2 BTC Bob 2 BTC Charlie 3 BTC Charlie 3 BTC Charlie 3 BTC ... ... ... Applications of Distributed Ledgers Can represent a distributed electronic record of: ● Who owns how much currency? (Bitcoin) ● Who owns a name or a digital work of art? ● What are the terms of a contract? (Ethereum) ● When was a document written? (notaries) ● What is the provenance of a part? (supply chain) ● Who are you? (self-sovereign identity) ● Who used data for what purpose? (access logs) ● … Distributed Trust is Old News Many algorithms allow us to distribute trust among multiple (preferably independent) parties Work correctly despite any one (or several) participants being compromised, maliciously colluding Example algorithms: ● Byzantine consensus ● Threshold cryptography (signing, encryption, …) Distributed Trust is Old News Many algorithms allow us to distribute trust among multiple (preferably independent) parties Work correctly despite any one (or several) participants being compromised, maliciously colluding Example algorithms: ● Byzantine consensus ● Threshold cryptography (signing, encryption, …) How Bitcoin was Groundbreaking Byzantine consensus (BFT) wasn’t remotely new, but Bitcoin solved it in an interesting new way ● Permissionless: “anyone” can participate – If you’re willing to waste energy continuously ● Scalable to thousands of consensus nodes – BFT was typically tested among 4, ~10s of nodes ● No long-lived leaders, supernodes, committees – Unspecialized nodes resist rapidly-adaptive attacks Properly-Designed Blockchains Eliminate Single Points of Compromise Weakest-link Strongest-link Collective Security: Security: Security: T = 1 T = 2-10 T = 100s,1000s T: threshold of compromised parties to break security Launched Global Wave of Interest in Decentralized Systems Limitations of Today’s Blockchains Public/permissionless (e.g., Bitcoin, Ethereum) ● Slow, weak consistency, low total throughput ● Limited privacy: leaky, can’t keep secrets ● User devices must be online, well-connected ● Mining is inefficient, insecure, re-centralizing Private/permissioned (e.g., HyperLedger, Corda) ● Weak security – single points of compromise Beware the Lemon Market George A. Akerlof won Nobel Prize in economics for observing: If buyers have less information than sellers about product quality, incentives lead to reduced quality The cybersecurity market is a lemon market… The Blockchain Lemon Market Today’s blockchain market is too. Economically-leading “first-to-market” designs completely compromise decentralized security ● One-click “Blockchain-as-a-Service” on cloud ● Non-Byzantine consensus in deployment ● Centralized PKI in permissioned blockchains DEDIS Blockchain Research Working to make tomorrow’s blockchains: ● Fast: responsive in seconds, not minutes/hours ● Scalable: support high transaction volumes ● Private: keeping confidential data secure ● Available: blockchain records usable offline ● Equitable: people-centric decentralization DEDIS next-generation blockchain infrastructure already available, in use by multiple partners DEDIS Blockchain Overview Key aspects of DEDIS blockchain architecture: ● Scaling: can we do enough, fast enough? ● Privacy: can we store and process secrets? ● Resilience: what if we’re poorly-connected? ● Stake: how to get equitable decentralization? Industry Impact, Applications, and Conclusion DEDIS Blockchain Overview Key aspects of DEDIS blockchain architecture: ● Scaling: can we do enough, fast enough? ● Privacy: can we store and process secrets? ● Resilience: what if we’re poorly-connected? ● Stake: how to get equitable decentralization? Industry Impact, Applications, and Conclusion Drawbacks of Nakamoto Consensus ● Transaction delay – Any transaction takes ~10 mins minimum in Bitcoin ● Weak consistency: – You’re not really certain your transaction is committed until you wait ~1 hour or more ● Low throughput: – Bitcoin: ~7 transactions/second ● Proof-of-work mining: – Wastes huge amount of energy Scaling Blockchains is Not Easy Many Approaches to Scaling Scalable BFT Sidechains share window of size w Microblocks Keyblocks keyblock (co-signed) L microblock (co-signed) share Miners miner (co-signer) L leader Horizontal Sharding Payment Networks Transactions Shard 3 Shard 1 Shard 2 ByzCoin: Marrying PBFT with PoW Use PoW to pick PBFT groups [USENIX Security ‘16] ● Permanent transaction commitment in seconds ● 700+ TPS demonstrated (100x Bitcoin, ~PayPal) Closely-related: Hybrid Consensus by Pass/Shi 1 2 3 ... 1 2 3 4 5 6 Key-Block 5-10 sec Micro-Block Miner Witnesses Co-Signature Bitcoin Cothority depends on Why PBFT Doesn’t Readily Scale Three phase: pre-prepare, prepare, commit In prepare & commit, leader must get at least two-thirds of all participants to “sign-off” ● Nodes sign-off via broadcast: O(N2) PBFT with Collective Signing (CoSi) Builds on CoSi, presented in [IEEE S&P ‘16] ByzCoin runs collective signing (CoSi) rounds to implement PBFT prepare, commit phases ● Efficient tree-structured communication ● Sign-offs compressed into 1 signature Reduce round cost from O(N2) to ~O(N) Announce Commit Challenge Response Horizontal Scaling via Sharding OmniLedger: A Secure Scale-Out Ledger [S&P 18] ● Break large collective into small random subgroups ● Builds on scalable bias-resistant randomness protocol (IEEE S&P 2017) ● Commit transactions cross-shard w/ 2-phase protocol Transactions Shard 3 Shard 1 Shard 2 OmniLedger: Key Intuition At any time a (possibly slow) consensus process maintains large (~1000s) list of miners/validators ● Use public randomness to pick smaller (10s, 100s) representative subgroups or shards – Subgroup size is security/performance tradeoff – Periodically refresh/re-form shards to handle churn ● Each shard manages subset of state (accounts) ● Transactions processed by one or a few shards – Typically one shard per account transaction affects – Cross-shard commit protocol ensures consistency OmniLedger Throughput Wide range of performance/security settings Problem: Secure Public Randomness Vietnam War Lotteries (1969) RandHound/RandHerd “Scalable Bias-Resistant Distributed Randomness” [IEEE Security & Privacy ‘17] TSS group 0 ● Standard t-of-n threshold model ● Efficient, scales to collective randomness thousands of parties (c,r0) CL (c,r) ● Compatible with GL (c,r1) (c,r2) GL ByzCoin, OmniLedger blockchains TSS group 1 TSS group 2 The Chicken-and-Egg Problem More scalable if we could use smaller groups… but need randomness to sample them securely! ● Sharding needs randomness needs sharding Addressed by RandHound, RandHerd protocols ● Scalable Bias-Resistant Distributed Randomness [IEEE S&P ‘17] ● RandHound: bootstrap protocol, O(n log n) efficiency ● RandHerd: repeating beacon, O(log n) cost/node/round The League of Entropy Public randomness beacon based on RandHerd ● Launched by EFPL-DEDIS, Cloudflare, Kudelski, University of Chile, Protocol Labs ● Simplifications, BLS instead of Schnorr signing Future: Function Scaling