Cheapbft

1. CheapBFT: Resource-efficient
Byzantine Fault Tolerance
Rüdiger Kapitza(TU Braunschweig), Johannes Behl, Tobias Distler,
Simon Kuhnle, Klaus Stengel (Friedrich– alexander University
Erlangen–Nuremberg)
Christian Cachin, (IBM Research - Zurich)
Seyed Vahid Mohammadi(KTH – Royal Institute of Technology)
EuroSys 2012
Yongrae Jo (20172938)

2. 2
Why resource efficient?
# of Computer
(storage, CPU)
Network usage
Numerous efforts to make Byzantine fault tolerance
systems practical
● Improving performance(throughput/latency)
● Improving security: varying attack surfaces( distributed
trust, N-version programming )
But, from economical point of view, they require
high resource demand(# of computer, network usage)
Need at least 4 computers
to tolerate a single fault
Excessive
communication

3. 3
Traditional BFT
● PBFT (1999): requires 3f + 1 replicas to tolerate up to f faults
● By separating (2004) request ordering (agreement state) from
request process (execution stage):
– 2f + 1 replicas in execution stage
– 3f + 1 replicas in agreement stage
● Hybrid fault model: untrusted part + trusted part (e.g. MinBFT(2011))
– f + 1 replicas in execution stage
– 2f + 1 replicas in agreement stage
– But, it requires large trusted computing base (e.g. complete
virtualization layer, TPM) → performance bottleneck

4. 4
CheapBFT
● Composite protocol
– CheapTiny for normal case(fault-free)
– CheapSwitch for switching to MinBFT
– MinBFT for fault handling
● Hybrid fault model: untrusted part + trusted part
– CASH(trusted hardware)
– (fault-free) f+1 active replicas in both agreement stage and
execution stage
– (fault-free) 2f + 1 passive replicas (update the result)
– (fault) 2f + 1 active replicas for MinBFT

5. 5
Communication efficiency
● From 3 phase to 2 phase communication (MinBFT)
– Leader broadcasts request order to different replicas
– Replicas broadcast echo message to get 2f + 1
matching message to verify the leader
– But with trusted hardware, they can verify request
order locally (no broadcast needed)
PBFT – 3 phase MinBFT – 2 phase

6. 6
Resource efficiency
● From 3f+1 to 2f+1 replicas (e.g. A2M, MinBFT)
– 3f + 1 replicas are needed to tolerate up to f faulty replicas
– But with trusted hardware, 2f + 1 non-faulty active replicas needed
– Wanna know the reason why 3f+1 or 2f+1 numbers are discussed?
● See The Byzantine Generals Problem (L. Lamport, et al., 1982)
3f +1 2f +1
Attack!
Retreat!
How can I trust
my commander?
Let’s communicate
with others!
Commander
General General

7. 7
CASH: Trusted subsystem
● Counter Assignment Service in Hardware
● FPGA-based trusted subsystem
– Minimal trusted computing base
● Provides trusted counter services:
– Assigns monotonically increasing counter value to a message
– Message authentication and verification
● HMAC-SHA-256
– Symmetric-key for cryptographic operations
● CASH subsystem has shared secret key

8. 8
CASH: Algorithms
// Issuing certificate
// verifying certificate

9. 9
CASH: Fast and Small TCB
Message authentication and verification performance Size of TCB
SoftLib: software library running in
same process
SSL: software library running in
separate process
VM-SSL: OpenSSL in (Xen) VM

10. 10
CheapTiny CheapSwitch MinBFT
CheapBFT
Fault suspected
or detected
Agree on an abort history
(pending request)
Predefined number of agreement rounds x

11. 11
CheapTiny
Agreement
Stage
Execution
Stage
Two types of replicas:
Active, passive

12. 12
CheapTiny
:Agreement stage Agreement
Stage

13. 13
CheapTiny
:Execution stage
(reply, update)
Execution
Stage
Issue certificate
Passive replica

14. 14
CheapSwitch
Initiating a protocol switch
● When client fails to get f+1 matching
replies
● When a replica if it suspects or detects
another replica (e.g. false certificate)
Stopping CheapTiny protocol
● Non-faulty active replicas stop CheapTiny
protocol when it received <PANIC> message
Creating an Abort history: <HISTORY>
● Pending request can have three status
● Decided : Committed
● Potentially decided: Send <COMMIT>, but
not received yet
● Undecided: Not send <COMMIT>,
<PREPARE> received
Validating an
abort history
Ready for switching to
MinBFT (received f
matching <SWITCH>)

15. 15
MinBFT
●Efficient Byzantine Fault Tolerance (2011)
●Exploits trusted hardware (USIG)
●2f+1 active replicas
●Executed for only a limited period of time, then switching back to
CheapTiny
Assumption
Permanent replica
fault is rare!

16. 16
Evaluation
● A replica cluster of 8-core machines (2.3 GHz, 8 GB
RAM), 4 replicas(3f + 1, f = 1)
● A client cluster of 12-core machines (2.4 GHz, 24 GB
RAM) that are all connected with switched Gigabit
Ethernet. 5~400 clients
●
Adapting the BFT-SMaRt library (communication
layer)
●
Request batch size set to 20

17. 17
Evaluation
empty requests and empty replies
72,000 req/s

18. 18
Evaluation
4 KB requests and empty replies

19. 19
Evaluation
empty requests and 4 KB replies
→ Resource efficiency is more affected by the size of reply

20. 20
Evaluation
CheapSwitch: from CheapTiny to MinBFT
Protocol Switch

21. 21
Conclusion
● CheapBFT is the first Byzantine fault-tolerant
system to use f + 1 active replicas for both
agreement and execution during normal-case
operation (later: XPaxos, FastBFT, …)
● CheapBFT exploits small trusted hardware to
achieve resource efficiency(network, CPU)
● CheapBFT is resource efficient BFT protocol (#
of computer(CPU, storage), network usage)

22. 22
?
Can we say CheapBFT really achieves resource efficiency?
Only 2% less data than
MinBFT
empty requests and 4 KB replies
Need to be more tested under varying reply sizes

23. 23
Thanks