Cryptography Lecture 24

Blockchains and Permissioned Blockchains

Client-Server Architecture One server is a single point of failure or compromise Request Response Client Server

Blockchains are Replicated Servers Blockchains tolerate Byzantine (arbitrary) failures Integrity/safety: the code is executed correctly Availability/liveness: the service is always available (No confidentiality provided, typically) Replicas (ledgers) Client

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 Order” [Lamport, ACM TOPLAS 1984] Servers (ledgers) $100 $100 $100

The “Total Order” Requirement Client 1: “Deposit $100” $100 $200 Client 1: “Deposit $100” $100 $200 $100

The “Total Order” Requirement Client 1: “Deposit $100” Chase: “Charge 10%” $100 $200 $180 Client 1: “Deposit $100” Chase: “Charge 10%” $100 $200 $180 $100

The “Total Order” Requirement Client 1: “Deposit $100” Chase: “Charge 10%” $100 $200 $180 Client 1: “Deposit $100” Chase: “Charge 10%” $100 $200 $180 $100

The “Total Order” Requirement Chase: “Charge 10%” Client 1: “Deposit $100” $100 $90 $190 Chase: “Charge 10%” Client 1: “Deposit $100” $100 $90 $190 $100

The “Total Order” Requirement Chase: “Charge 10%” Client 1: “Deposit $100” $100 $90 $190 Client 1: “Deposit $100” Chase: “Charge 10%” $100 $200 $180 $100

Characterizing Blockchains Depend on how total order (consensus) is achieved

Characterizing Blockchains Permissionless: explicitly/implicitly rely on cryptocurrency Permissioned: traditional Byzantine fault-tolerant distributed system (consortium blockchains, private blockchains) Membership Consensus Approach Examples Permissionless Dynamic PoX (Proof of “X”) Bitcoin, Ethereum Permissioned Fixed; know IDs of each other BFT (Byzantine fault tolerance) Fabric, Iroha, Chios, BEAT

Characterizing Blockchains Permissionless: explicitly/implicitly rely on cryptocurrency Permissioned: traditional Byzantine fault-tolerant distributed system (consortium blockchains, private blockchains) Hybrid: use BFT to improve permissionless blockchains Membership Consensus Approach Examples Permissionless Dynamic PoX (Proof of “X”) Bitcoin, Ethereum Permissioned Fixed; know IDs of each other BFT (Byzantine fault tolerance) Fabric, Iroha, Chios, BEAT Hybrid (permissonless) Sybil resistant PoX+ BFT Elastico, OmniLedger, Ethereum Casper

How BFT Consensus Looks Like? PBFT: 3f+1 replicas to tolerate f Byzantine failures [Castro and Liskov, OSDI 1999]

Permissionless vs. Permissioned M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (PoX) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10k~100k 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 Power cost huge small/negligible (laptops can do) Customer cost > $10,000/1MB (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 Customer Generality vs. Specialty more general mostly special

Permissionless vs. Permissioned M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (PoX) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10k~100k 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 Power cost huge small/negligible (laptops can do) Customer cost > $10,000/1MB (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 Customer Generality vs. Specialty more general mostly special-purpose

25% Adversary in Permissionless Blockchains If 50% adversary, completely take over blockchains If 25% adversary, selfish mining Some single mining pool already takes over > 25% power Some permissionless blockchains found 50% adversary (e.g., NameCoin) [Eyal et al., FC 2014]

Permissionless vs. Permissioned M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (PoX) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10k~100k 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 Power cost huge small/negligible (laptops can do) Customer cost > $10,000/1MB (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 Customer Generality vs. Specialty more general mostly special-purpose

Permisionless BC: Much Less Decentralized! A recent FC paper by Cornell and Technion Universities shows a “surprising” 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 [Gencer et al., FC 2018]

Permissionless vs. Permissioned M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 2015 Light blue parts: newly added/edited Permissionless vs. Permissioned Permissionless (PoX) (Bitcoin, Ethereum) Permissioned (BFT) (Hyperledger Fabric, Chios, Iroha) Consensus Finality no yes Latency huge (minutes to hours) great (matching network latency) Throughput limited great (10k~100k 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 Power cost huge small/negligible (laptops can do) Customer cost > $10,000/1MB (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 Customer Generality vs. Specialty 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: PeerCensus, ByzCoin, Solidus, Hybrid Consensus, Elastico, OmniLedger, RapidChain, 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 The first fully fledged chain-based BFT protocol [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 One of 5 mature projects within Hyperledger Known as Iroha [Duan, Meling, Sean, and Zhang, OPODIS 2014] One of 5 mature projects within Hyperledger Known as Iroha

BEAT: Asynchronous Blockchain Made Practical [Duan, Reiter, and Zhang, CCS 2018] Blockchain, ideally Working for asynchronous environments 5 fully fledged instances fitting for different needs Tested in 92 Amazon EC2 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 HoneyBadgerBFT Built using new primitive combinations Protocol Applicability Features BEAT0 General BFT SMR Efficient threshold encryption & coin flipping Efficient erasure-coding support BEAT1 Reduced latency via different subprotocol combination BEAT2 Reduced latency via client-side threshold encryption BEAT3 BFT storage/ledger Storage/bandwidth savings through new protocol combo BEAT4 Read bandwidth savings through new fingerprinted cross checksums Protocol Applicability Features BEAT0 General BFT SMR Efficient threshold encryption & coin flipping Efficient erasure-coding support BEAT1 Reduced latency via different subprotocol combination BEAT2 Reduced latency via client-side threshold encryption BEAT3 BFT storage/ledger Storage/bandwidth savings through new protocol combo BEAT4 Read bandwidth savings through new fingerprinted cross checksums