Cryptography Lecture 24 Blockchains and Permissioned Blockchains ClientServer
Cryptography Lecture 24
Blockchains and Permissioned Blockchains
Client-Server Architecture Request Client Response Server • One server is a single point of failure or compromise
Blockchains are Replicated Servers Replicas (ledgers) Client • Blockchains tolerate Byzantine (arbitrary) failures – Integrity/safety: the code is executed correctly – Availability/liveness: the service is always available
Blockchain Consensus (What is it? Why hard? ) • Correct servers maintain the same consistent state, even – 1) under highly concurrent client requests – 2) when a fraction of servers are compromised – 3) under network asynchrony
Consensus: All About Achieving “Total [Lamport, ACM TOPLAS Order” 1984] • Servers (ledgers) $100
The “Total Order” Requirement Client 1: “Deposit $100” $100 $200 Client 1: “Deposit $100” $200
The “Total Order” Requirement Chase: “Charge 10%” Client 1: “Deposit $100” $100 $200 Client 1: “Deposit $100” $200 $180 Chase: “Charge 10%” $180
The “Total Order” Requirement Chase: “Charge 10%” Client 1: “Deposit $100” $100 $200 Client 1: “Deposit $100” $200 $180 Chase: “Charge 10%” $180
The “Total Order” Requirement Chase: “Charge 10%” $100 Client 1: “Deposit $100” $90 Chase: “Charge 10%” $90 $190 Client 1: “Deposit $100” $190
The “Total Order” Requirement Chase: “Charge 10%” $100 Client 1: “Deposit $100” $90 Client 1: “Deposit $100” $200 $190 Chase: “Charge 10%” $180
Characterizing Blockchains • Depend on how total order (consensus) is achieved
Characterizing Blockchains Membership Consensus Approach Examples Permissionless Dynamic Po. X (Proof of “X”) • Bitcoin, Ethereum Permissioned Fixed; know IDs of each other BFT (Byzantine fault tolerance) • Fabric, Iroha, Chios, BEAT • Permissionless: explicitly/implicitly rely on cryptocurrency • Permissioned: traditional Byzantine fault-tolerant distributed system (consortium blockchains, private blockchains)
Characterizing Blockchains Membership Consensus Approach Examples Permissionless Dynamic Po. X (Proof of “X”) • Bitcoin, Ethereum Permissioned Fixed; know IDs of each other BFT (Byzantine fault tolerance) • Fabric, Iroha, Chios, BEAT Hybrid (permissonless ) Dynamic Sybil resistant Po. X+ BFT • • Elastico, Omni. Ledger, Ethereum Casper • Permissionless: explicitly/implicitly rely on cryptocurrency • Permissioned: traditional Byzantine fault-tolerant distributed system (consortium blockchains, private blockchains) • Hybrid: use BFT to improve permissionless blockchains
How BFT Consensus Looks Like? • PBFT: 3 f+1 replicas to tolerate f Byzantine failures [Castro and Liskov, OSDI 1999]
M. Vukolic, IFIP WG 11. 4 Workshop – i. Net. Sec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (Po. X) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10 k~100 k tx/sec) Scalability (no. of ledgers) great (>1000) scale to >100 Scalability (no. of clients) great Adversary assumption < 25% computing power < 1/3 voting power Network synchrony assumption physical clock timestamps none for safety synchrony for liveness Correctness proof no yes Power cost huge small/negligible (laptops can do) Customer cost > $10, 000/1 MB (can only afford to store hashes) small/negligible: 4 -replication (cf. Google Chubby/Spanner 3 -replication) Development difficulty high (a system that only stores hashes needs architecture redesign, complex client-side software, client communication channels, etc) reasonable (mainly server-side) Ecosystem great Customer Generality vs. more general mostly special
M. Vukolic, IFIP WG 11. 4 Workshop – i. Net. Sec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (Po. X) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10 k~100 k tx/sec) Scalability (no. of ledgers) great (>1000) scale to >100 Scalability (no. of clients) great Adversary assumption < 25% computing power < 1/3 voting power Network synchrony assumption physical clock timestamps none for safety synchrony for liveness Correctness proof no yes Power cost huge small/negligible (laptops can do) Customer cost > $10, 000/1 MB (can only afford to store hashes) small/negligible: 4 -replication (cf. Google Chubby/Spanner 3 -replication) Development difficulty high (a system that only stores hashes needs architecture redesign, complex client-side software, client communication channels, etc) reasonable (mainly server-side) Ecosystem great Customer Generality vs. more general mostly special-purpose
25% Adversary in Permissionless Blockchains • If 50% adversary, completely take over blockchains [Eyal et al. , FC 2014] • If 25% adversary, selfish mining • Some single mining pool already takes over > 25% power • Some permissionless blockchains found 50% adversary (e. g. , Name. Coin)
M. Vukolic, IFIP WG 11. 4 Workshop – i. Net. Sec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (Po. X) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10 k~100 k tx/sec) Scalability (no. of ledgers) great (>1000) scale to >100 Scalability (no. of clients) great Adversary assumption < 25% computing power < 1/3 voting power Network synchrony assumption physical clock timestamps none for safety synchrony for liveness Correctness proof no yes Power cost huge small/negligible (laptops can do) Customer cost > $10, 000/1 MB (can only afford to store hashes) small/negligible: 4 -replication (cf. Google Chubby/Spanner 3 -replication) Development difficulty high (a system that only stores hashes needs architecture redesign, complex client-side software, client communication channels, etc) reasonable (mainly server-side) Ecosystem great Customer Generality vs. more general mostly special-purpose
Permisionless BC: Much Less Decentralized! • A recent FC paper by Cornell and Technion et al. , FC 2018] Universities shows a “surprising”[Gencer result – For both Bitcoin and Ethereum, the top 20 mining coalitions control over 90% of the mining power. – “These results show that a Byzantine quorum (BFT) system of size 20 could achieve better decentralization than Proof-of-Work mining at a much lower resource cost. ” • > 70%~80% mining pools in China • Almost all in Asia; seldom in US
M. Vukolic, IFIP WG 11. 4 Workshop – i. Net. Sec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (Po. X) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10 k~100 k tx/sec) Scalability (no. of ledgers) great (>1000); <20 mining pools scale to >100 Scalability (no. of clients) great Adversary assumption < 25% computing power < 1/3 voting power Network synchrony assumption physical clock timestamps none for safety synchrony for liveness Correctness proof no yes Power cost huge small/negligible (laptops can do) Customer cost > $10, 000/1 MB (can only afford to store hashes) small/negligible: 4 -replication (cf. Google Chubby/Spanner 3 -replication) Development difficulty high (a system that only stores hashes needs architecture redesign, complex client-side software, client communication channels, etc) reasonable (mainly server-side) Ecosystem great Customer Generality vs. more general mostly special-purpose
BFT for Consensus: “Emerging Standard” • Whether choosing permissioned or hybrid blockchains – A nearly “common” consensus is to use BFT • Used in (almost) all permissioned blockchains • Increasingly used in permissionless/hybrid blockchains – To improve the performance and deal with the finality of transactions – Examples: Peer. Census, Byz. Coin, Solidus, Hybrid Consensus, Elastico, Omni. Ledger, Rapid. Chain, and Ethereum Casper …
“BFT/Blockchain is Now!” • For a long time, BFT lacks – commercial support – rigorous implementations – killer applications • But now – We have them all • PS: – RSA (1977) takes about 25 years to dominate crypto/security – BFT (1982) may take about the same
Provable-Security Treatment • A provable security treatment of blockchains • “[A]ny claim for a “superior” consensus protocol that does not come with the necessary formal justification should be dismissed, analogously to the approach of “security by obscurity, ” which is universally rejected by experts” [Cachin and Vukolić, DISC 2018]
BChain [Duan, Meling, Sean, and Zhang, OPODIS 2014] • The first fully fledged chain-based BFT protocol • Highest throughput – Pipelined execution • Embedding recovery and proactive security
BChain [Duan, Meling, Sean, and Zhang, OPODIS 2014] • One of 5 mature projects within Hyperledger • Known as Iroha
BEAT: Asynchronous Blockchain Made Practica [Duan, Reiter, and Zhang, CCS 2018] • Blockchain, ideally – Working for asynchronous environments • 5 fully fledged instances fitting for different needs • Tested in 92 Amazon EC 2 servers evenly distributed among 5 continents
BEAT: Asynchronous BFT Made Practical [Duan, Reiter, and Zhang, CCS 2018] • A family of protocols for asynchronous networks – Built as a series of adaptations to Honey. Badger. BFT – Built using new primitive combinations Protocol Applicability Features BEAT 0 General BFT SMR • Efficient threshold encryption & coin flipping • Efficient erasure-coding support BEAT 1 BEAT 2 BEAT 3 General BFT SMR • BFT • storage/ledger Reduced latency via different subprotocol combination Reduced latency via client-side threshold encryption Storage/bandwidth savings through new protocol combo BEAT 4 BFT storage/ledger Read bandwidth savings through new fingerprinted cross checksums •
- Slides: 28