1. Cryptography
Lecture 24

2. Blockchains and Permissioned Blockchains

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

4. 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

5. 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

6. Consensus: All About Achieving “Total Order”
[Lamport, ACM TOPLAS 1984]
Servers (ledgers)
$100
$100
$100

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

8. 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

9. 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

10. 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

11. 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

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

13. 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

14. 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

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

16. Permissionless vs. Permissioned
M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 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

17. Permissionless vs. Permissioned
M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 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

18. 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]

19. Permissionless vs. Permissioned
M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 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

20. 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]

21. Permissionless vs. Permissioned
M. Vukolic, IFIP WG 11.4 Workshop – iNetSec 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

22. 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 …

23. “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

24. 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]

25. 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

26. 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

27. 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

28. 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