Honeybadger of BFT Protocols

1. The Honey Badger of BFT Protocols
Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, Dawn Song
University of Illinois, Urbana-Champaign,
Cornell University,
Tsinghua University,
University of California, Berkeley
Presented by Yongrae Jo, System software lab. at POSTECH

2. 2
https://medium.com/startup-grind/you-are-a-ceo-you-are-a-honey-badger-b37d532f39ad

3. 3
http://knowyourmeme.com/memes/honey-badger

4. 4
https://www.wired.com/2013/12/bitcoin-honey/

5. 5
HoneyBadgerBFT is a Cherry-Picker

6. 6
Motivation
●
Weakly (or partially) synchronous protocol such as PBFT
rely on network timing assumption …
– Not suited for real-world network
●
Designing practical (large-scale, high efficiency and
high-robust) Byzantine fault tolerant consensus
algorithm in asynchronous network
– Doesn’t rely on network condition

7. 7
Background
●
Timing assumptions in distributed systems
●
FLP Impossibility Result
●
Equivalence between consensus and other problems
●
Broadcast primitives
●
Randomized Byzantine Agreement
●
{Binary / Multi-valued / Vector / k-Set} Consensus
●
Erasure Coding
●
Threshold Encryption

8. 8
Background
●
Timing assumptions in distributed systems
●
FLP Impossibility Result
●
Equivalence between consensus and other problems
●
Broadcast primitives
●
Randomized Byzantine Agreement
●
{Binary / Multi-valued / Vector / k-Set} Consensus
●
Erasure Coding
●
Threshold Encryption

9. 9
Timing assumptions
●
Synchronous network
– All messages are delivered within Δ
●
Eventual synchronous network
– After unknwon GST(Global Stabilization Time), all
messages are delivered within Δ
●
Partially synchronous network
– Eventual synchronous, but Δ is unknown to the protocol
●
Weakly synchronous network
– Varying Δ along with the network conditions and protocol
Δ : timeout parameter

10. 10
No timing assumption on underlying network
Asynchronous Network

11. 11
But sadly, we have
FLP Impossibility Result

12. 12
Deterministic consensus algorithm in
asynchronous network is impossible
FLP Impossibility Result

13. 13
How to circumvent FLP result?
●
Sacrifice determinism
– Randomized Byzantine consensus algorithm
●
Adding timing assumption
– Partially sync., etc.
●
Adding oracle (failure detector)
●
Adding trusted component
●
Change the problem domain (e.g. not a single value, but
range of value or set of values)
●
Ref. Byzantine consensus in asynchronous message-
passing systems: a survey (2011)

14. 14
How to circumvent FLP result?
●
Sacrifice determinism
– Randomized Byzantine consensus algorithm
●
Change the problem domain (e.g. not a single value,
but range of value or set of values)
Ref. Byzantine consensus in asynchronous message-
passing systems: a survey (2011)
HoneyBadgerBFT
Asynchronous Agreement
on Common Set

15. 15
Equivalent problems to Consensus in
distributed computing area
Consensus
Atomic
Broadcast
State Machine
Replication
Group
Membership
Non-blocking
Atomic commit
Hadzilacos and Toueg, 1994
Chandra and Toueg, 1996
Cachin et al., 2001
Schneider, 1990
Guerraoui and Schiper, 2001
Guerraoui and
Schiper, 2001
~
~
reducible
related

16. 16
Contribution

17. 17
System Model
●
Node
– N nodes exist in network: P0 , … , Pn-1
– Each node receive transactions as input
– The goal of node is to reach consensus on a transaction
order
●
Client
– Submit a transaction, and consider it committed when the
client received signatures from majority of nodes
●
Transaction
– Identified as a unique string

18. 18
System Model
●
Static Byzantine faults
– n = 3f + 1
●
Network
– Purely asynchronous network
– Reliable authenticated point-to-point channel
– Adversary can control delivery schedule, but can’t stop
message from being delivered
●
Trusted setup
– Initial key distribution

19. 19
Atomic Broadcast
●
Consensus = Atomic Broadcast
●
HoenyBadgerBFT is Atomic Broadcast
●
Designing Atomic Broadcast solves consensus problem
Above properties should hold with high probability
Properties of Atomic Broadcast
Safety
Live-
ness

20. 20
Some Acronyms
●
ABC: Atomic Broadcast
●
ACS: Agreement on Common Subset or Asynchronous
Common Subset
●
RBC: Reliable Broadcast
●
MVBA: Multi-Valued Byzantine Agreement
●
ABA (or simply BA): Asynchronous Binary Agreement
●
TPKE : Threshold (Public Key) Encryption

21. 21
ACS
MVBA RBC ABA
reduction
RBC ABA
ABC
reduction
CommonCoin
HonyeBadgerBFT
implement
use
Module relationships
MVBA module is actually not
used in HoneyBadgerBFT
use
To implement ABC(Atomic
Broadcast) is to implement
consensus

22. 22
ACS
MVBA RBC ABA
reduction reduction
RBC ABA
C. Cachin et al. Secure and
efficient asynchronous
broadcast protocols, 2001
Bracha’s Broadcast
G. Bracha, Asynchronous
byzantine agreement
protocols. Information and
Computation, 1987
C. Cachin et al.,
Asynchronous verifiable
information dispersal, 2005
Bracha’s Broadcast with
Erasure coding
A. Mostefaoui et al., Signature-free
asynchronous byzantine consensus
with t< n/3 and O(n^2) messages,
2014
|v| : Size of input
λ : Security parameter
M. Ben-Or et al., Asynchronous secure
computations with optimal resilience (1994)

23. 23
ACS
MVBA RBC ABA
reduction reduction
RBC ABA
C. Cachin et al. Secure and
efficient asynchronous
broadcast protocols, 2001
Bracha’s Broadcast
G. Bracha, Asynchronous
byzantine agreement
protocols. Information and
Computation, 1987
C. Cachin et al.,
Asynchronous verifiable
information dispersal, 2005
Bracha’s Broadcast with
Erasure coding
A. Mostefaoui et al., Signature-free
asynchronous byzantine consensus
with t< n/3 and O(n^2) messages,
2014
|v| : Size of input
λ : Security parameter
M. Ben-Or et al., Asynchronous secure
computations with optimal resilience (1994)
Good
batching

24. 24
ACS
MVBA RBC ABA
reduction reduction
RBC ABA
C. Cachin et al. Secure and
efficient asynchronous
broadcast protocols, 2001
Bracha’s Broadcast
G. Bracha, Asynchronous
byzantine agreement
protocols. Information and
Computation, 1987
C. Cachin et al.,
Asynchronous verifiable
information dispersal, 2005
Bracha’s Broadcast with
Erasure coding
A. Mostefaoui et al., Signature-free
asynchronous byzantine consensus
with t< n/3 and O(n^2) messages,
2014
|v| : Size of input
λ : Security parameter
M. Ben-Or et al., Asynchronous secure
computations with optimal resilience (1994)
Good
batching
HoneyBadgerBFT’s
cherry picking

25. 25
Modular Approach
●
HoneyBadgerBFT ‘s modular composition
– Module 1. HoneyBadgerBFT
– Module 2. ACS (Asynchronous Common Subset)
– Module 3. RBC (Reliable Broadcast)
– Module 4. BA (Asynchronous Binary Agreement)
– Module 5. CommonCoin

26. 26
HoneyBadgerBFT
use
use
use
use
ACS
RBC BA CommonCoin
Module Relationships in HoneyBadgerBFT
TPKE
use

27. 27
Module: HoneyBadgerBFT
●
Implements Atomic Broadcast (a.k.a Consensus)
●
Why Threshold Encryption?
– Adversary can selectively delay proposal from specific
node
– By using Threshold Encryption, adversary doesn’t know
whose proposals are coming from (Censorship
resiliency)
– Cachin et al., Practical asynchronous byzantine
agreement using cryptography(2000)

28. 28
123n
Message
Buffer(FIFO Queue)
Selection
Policy
2
1
3
Subset
Vector
Message = Transaction
(N, f+1) Threshold
Encryption
using Public key PK
ACS
Receive
Random selection
x y z
input
(bit vector)
01001….010
Threshold Decryption
with its own share
output
(bit vector)
Multicast
decrypted share
Wait until f+1 decrypted
shares are received
Recover original secret
using Public Key
Generate block
Remove batched transactions
from Buffer
Consensus on bit vector
Batch size

29. 29
(N, f+1) Threshold
Encryption

30. 30
Module: ACS
●
Agreement on common subset asynchronously
●
Protocol
– 1) Each node broadcast proposed value using RBC
– 2) After 1), ABA decides a vector of proposed value from
RBC
Quorum
size &
legitimate
contents
Properties of Asynchronous Common Subset
Above properties should hold with high probability
Liveness
Safety

31. 31

32. 32
Module RBC
●
(Byzantine) Reliable broadcast for proposal
●
Resolving leader bottleneck by using erasure coding
– Without erasure coding, O( N B )
– With erasure coding, O( B )
Outsourced from Bracha’s broadcast with erasure coding (Reed-Solomon Impl.) from
– C. Cachin and S. Tessaro. Asynchronous verifiable information dispersal (2005)
– G. Bracha, Asynchronous byzantine agreement protocols(1987)
Properties of Reliable Broadcast

33. 33
(N-2f, N)-Erasure coding scheme
Data
Block
A
B
C
D
Split data block into N pieces
of small data blocks
including parity block
E
F
G
H
I
J
K
L
A
B
C
D
E
F
G
H
I
J
K
L
Some corrupted
or lost
Recover original Data block only
from N-2f small blocks
or intentionally
omitted to save
space
N = 12, N-2f = 8
O(B)

34. 34
A B
h9
C D
h10
E F
h11
G H
h12
h13 h14
h
Erasure coded blocks
h1 h2 h3 h4 h5 h6 h7 h8
In (N-2f, N)-erasure
coding scheme, only N-
2f pieces of blocks are
needed to recover the
original.
Situation where N-f ECHO
msgs are not received yet,
But, received f+1 READY
msg

35. 35
Module BA
●
(Asynchronous) Binary & Randomized & Byzantine
Agreement on a single bit
●
Used for ensuring decided value from RBC instance
Outsourced from
●
Moustefaoui et al., Signature-free asynchronous byzantine consensus with t< n/3 and O(n ^2), 2014
●
Rabin M., Randomized Byzantine generals, 1983
Properties of Asynchronous Byzantine Agreement
Above properties should hold with high probability

36. 36
BA
BA 1
BA 2
BA 3
BA N
0 / 1
0 / 1
0 : I don’t agree with you
1 : I agree with you
Just think of BA as a blackbox
for 0/1 agreement
RBC 1
RBC 2
RBC 3
RBC N
Do you agree the result of
RBC instance? Yes(1) / No(0)
1 / 0 1 / 0 Vote
result
Vote
result
Vote
result
Vote
result

37. 37
Module CommonCoin
●
Distributed object that delivers the same sequence of
random bits b1 ,b2 ,... ,br ,... to each process
●
Return random
bit with threshold
encryption
Outsourced from Rabin M., Randomized
Byzantine generals (1983)

38. 38
Implementation
●
Python, gevent library for concurrent task
●
Threshold cryptography, Charm / PBC library
●
Docker container

39. 39
Evaluation Env.
●
EC2 t2.medium instances throughout 8 regions
spanning 5 continents
– 32, 40, 48, 56, 64, and 104 instances
●
Varying batch size: 256, 512, 1024, 2048, 4096, 8192, 16384,
32768, 65536, or 131072
●
N = 4f + 1
●
No faults or network interruptions

40. 40
Comm. cost vs Batch size
Comm. cost:

41. 41
Throughput vs Batch size

42. 42
Latency vs Throughput

43. 43
HoneyBadgerBFT vs PBFT
PBFT has
leader bottleneck

44. 44
Conclusion
●
HoneyBadgerBFT is the first practical asynchronous
Byzantine consensus protocol
●
HoneyBadgerBFT can be a suitable component in
cryptocurrency-inspired deployments of fault tolerant
transaction processing systems
●
HoneyBadgerBFT is building block for dependable
system based on asynchronous protocol

45. 45

46. 46
Thanks

47. 47
Any
Questions?

48. 48

49. 49
(RBC and BA) in ACS

50. 50
How PBFT fails

51. 51
Signature-Free Asynchronous Byzantine Consensus with
t < n/3 and O(n^2 ) Messages (2014)

52. 52
Signature-Free Asynchronous Byzantine Consensus
with t < n/3 and O(n^2 ) Messages (2014)

53. 53
Broadcast Primitives
●
Best-effort Broadcast
●
Reliable Broadcast
●
Uniform Reliable Broadcast
●
Stubborn Broadcast
●
FIFO Broadcast
●
Casual Broadcast
●
Total-Order Broadcast (Atomic Broadcast)
– Bracha’s Broadcast
●
...

54. 54
Bracha’s broadcast
https://lpd.epfl.ch/site/_media/education/sdc_byzconsensus.pdf

55. 55
Data
Block
Data
Block
Data
Block
O(N B)

56. 56
O(B)
A
B
C
D
E
F
G
H
I
J
K
L

57. 57
O(B)
A
B
C
D
E
F
G
H
I
J
K
L

58. 58
Data
Block
Data
Block
Data
Block
O(B)
Recover
original data block

59. 59
A
B
C
D
E
F
G
H
I
J
K
L
Data
Block
Recover from
small pieces of
blocks
A
B
C
D
Data
Block
Recover
Data
Block
E
F
G
H
Recover
Data
Block
I
J
K
L
Recover

60. 60
Why do we need RBC and additional BA? Normally, PBFT’s
reliable broadcast guarantee consistency
→ Asynchrony: In PBFT, there is explicit time bound. But, in
asynchronous network, RBC may fail. So for finality, additional
BA is needed to ensure that all correct processes decide same
value.