HotStuff: BFT Consensus with Linearity and Responsiveness

1. Yongrae Jo
Pohang University of Science and Technology
System Software Laboratory
HotStuff: BFT Consensus with Linearity
and Responsiveness
Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, Ittai Abraham
2019 Symposium on Principles of Distributed Computing (PODC 2019)

2. 2
Motivation
⚫View change is slow
• Latency, (signature) computation
⚫View change is complex
⚫Long-standing leader reduces chain quality*
*The content of the blocks in the blockchain is contributed more by honest participants. (Bitcoin
Backbone Protocol, 2019)

3. 3
HotStuff: Overview
⚫View change is fast
• Linear view change with threshold signature
⚫View change is simple
• All phases are structurally similar
⚫View change occurs frequently
• Each request induce view change
• as with normal case

4. 4
Contribution
Communication
complexity
Communication complexity +
Computation complexity
(signature verification)
View change with
cascading leader failure

5. 5
Responsiveness & Optimistic Responsiveness
⚫ Responsiveness
• A consensus protocol is said to be responsive iff any transaction input to an
honest node is confirmed in time that depends only on the actual network
delay, but not on any a-priori known upper bound on the network delay
(Thunderella, EuroCrypt 2017)
⚫ Optimistic Responsiveness
• Responsiveness holds whenever “good condition” satisfied

6. 6
HotStuff Algorithms
⚫ Basic HotStuff
• Linear view change
• Threshold signature
⚫ Chained HotStuff
• Basic HotStuff with pipelining
⚫ Two-phase HotStuff
• No optimistic responsiveness

7. 7
Basic HotStuff: Overview
⚫ Proceeds in a succession of views with view numbers
⚫ View number is monotonically increased, either by timer interrupt
(called NextView), or by finishing a decision (same as starting a new
request)
⚫ Integrated view change
• No separated view change protocol other than normal case protocol
⚫ Linear communication with threshold signature
⚫ Three phases to commit
• (New-View) --> Prepare --> Pre-Commit --> Commit --> (Decide)

8. 8
Basic HotStuff: Quorum Certificate (QC)
⚫ Role
• A certificate to justify a specific phase of running protocol
• Protocol can proceed to the next step only after obtaining a valid QC
• If there is no valid QC in a phase within a certain time, <NEXT-VIEW>
interrupt is triggered
⚫ Consists of same tuples <type, viewNumber, node> with signatures
signed by (n – f) replicas
Constructed from Carried In Justifying phase
highQC Set of (n-f) <NEW-VIEW> msg <PREPARE> New View
prepareQC Set of (n-f) <PREPARE> votes <PRE-COMMIT> Prepare
precommitQC Set of (n-f) <PRE-COMMIT> votes <COMMIT> Pre-Commit
commitQC Set of (n-f) <COMMIT> votes <DECIDE> Commit
QC is made by a leader using threshold signature, verified by replicas

9. 9
Basic HotStuff: Data Structures
⚫ Message fields
• Type: {PREPARE, PRE-COMMIT, COMMIT, DECIDE, NEW-VIEW}
• Node: Client command, Parent link, Quorum Certificate (QC)
• Justify (optional field): used by leader to carry QC
• partialSig: used by replicas for votes (VoteMsg func.)

10. 10
Basic HotStuff: Data Structures
⚫ Tree and Branch
⚫ Local (state) bookkeeping variables
• viewNumber
• Incremented by NextView interrupt or final decision
• lockedQC
• Stores the highest QC for which a replica voted commit
• prepareQC
• Stores the highest QC for which a replica voted pre-commit
Node
Command
Parent link
Node
Command
Parent link
Node
Command
Parent link

11. 11
Basic HotStuff: Next View Interrupt
⚫ In all phases of Basic HotStuff, a replica waits for a message at view
viewNumber for a timeout period
⚫ After interrupting waiting, replicas increments viewNumber and starts
the next view

12. 12
Basic HotStuff: Overview
<DECIDE>
C
L
R
R
R
NEW-VIEW PREPARE PRE-COMMIT COMMIT DECIDE
<NEW-VIEW>
<PREPARE>
<PREPARE>
votes
<PRE-COMMIT>
<PRE-COMMIT>
votes
<COMMIT>
<COMMIT>
votes
<REPLY>

13. 13
Basic HotStuff: New-View (1)
L
R
R
R
C
1 Client send a command to all replicas

14. 14
Basic HotStuff: New-View (2)
L
R
R
R
2 Set a timer and wait <PREPARE> from leader
1 Set a timer and wait <NEW-VIEW> from replicas
<PREPARE>
Waited
<NEW-VIEW>
Waited
1 Send <NEW-VIEW> to leader

15. 15
Basic HotStuff: Prepare (1)
L
R
R
R
1
Create QC with the highest view number from <NEW-
VIEW> messages
2 Create a proposal from highQC and a command
2 Set a timer and wait <PREPARE> from leader
<PREPARE>
Waited
<NEW-VIEW>
Received

16. 16
Basic HotStuff: Prepare (2)
L
R
R
R
1 Broadcast <PREPARE>
2 Set a timer and wait <PREPARE> votes from replicas
2 Set a timer and wait <PREPARE> from leader
<PREPARE>
Waited
PREPARE> votes
Waited

17. 17
Basic HotStuff: Prepare (3)
L
R
R
R
1
Accept <PREPARE> if ‘accept condition’ is true
1. Quorum check
2. Safety check (no fork, increasing view #)
Accept condition
2 Set a timer and wait <PREPARE> votes from replicas
<PREPARE>
Received
PREPARE> votes
Waited

18. 18
Basic HotStuff: Prepare (3)
L
R
R
R
Accept condition
1
Accept <PREPARE> if ‘accept condition’ is true
1. Quorum check
2. Safety check (no fork, increasing view #)
2 Set a timer and wait <PREPARE> votes from replicas
<PREPARE>
Received
PREPARE> votes
Waited

19. 19
Basic HotStuff: Prepare (4)
L
R
R
R
1
2 Set a timer and wait <PRE-COMMIT> from leader
Send <PREPARE> vote to Leader
<PRE-COMMIT>
Waited
PREPARE> votes
Received

20. 20
Basic HotStuff: PreCommit (1)
L
R
R
R
1 Create prepareQC from <PREPARE> votes (V)
2 Set a timer and wait <PRE-COMMIT> from leader
<PRE-COMMIT>
Waited
PREPARE> votes
Received

21. 21
Basic HotStuff: PreCommit (2)
L
R
R
R
1 Broadcast <PRE-COMMIT> including prepareQC
2 Set a timer for <PRE-COMMIT> votes from replicas
<PRE-COMMIT>
Waited
<PRE-COMMIT>
votes
Waited
2 Set a timer and wait <PRE-COMMIT> from leader

22. 22
Basic HotStuff: PreCommit (3)
L
R
R
R
1 Update prepareQC to <PRE-COMMIT>.justify
<PRE-COMMIT>
Received
2 Set a timer for <PRE-COMMIT> votes from replicas
<PRE-COMMIT>
votes
Waited

23. 23
Basic HotStuff: PreCommit (4)
L
R
R
R
1 Send <PRE-COMMIT> votes to leader
2 Set a timer and wait <COMMIT> from leader
2 Set a timer for <PRE-COMMIT> votes from replicas
<COMMIT>
Waited
<PRE-COMMIT>
votes
Waited

24. 24
Basic HotStuff: Commit (1)
L
R
R
R
1 Create precommitQC from <PRE-COMMIT> votes (V)
2 Set a timer and wait <COMMIT> from leader
<COMMIT>
Waited
<PRE-COMMIT>
votes
Received

25. 25
Basic HotStuff: Commit (2)
L
R
R
R
1 Broadcast <COMMIT> containing precommitQC
2 Set a timer and wait <COMMIT> votes from replicas
<COMMIT>
Waited
2 Set a timer and wait <COMMIT> from leader
<COMMIT>
votes
Waited

26. 26
Basic HotStuff: Commit (3)
L
R
R
R
1 Update lockedQC to m.justify
<COMMIT>
Received
2 Set a timer and wait <COMMIT> votes from replicas
<COMMIT>
votes
Waited

27. 27
Basic HotStuff: Commit (4)
L
R
R
R
1 Send <COMMIT> votes to leader
2 Set a timer and wait <DECIDE> from leader
2 Set a timer and wait <COMMIT> votes from replicas
<DECIDE>
waited
<COMMIT>
votes
Waited

28. 28
Basic HotStuff: Decide (1)
L
R
R
R
1 Create commitQC from <COMMIT> votes (V)
2 Set a timer and wait <DECIDE> from leader
<DECIDE>
waited
<COMMIT>
votes
Received

29. 29
Basic HotStuff: Decide (2)
L
R
R
R
1 Broadcast <DECIDE> containing commitQC
<DECIDE>
waited
<COMMIT>
votes
Received

30. 30
Basic HotStuff: Decide (3)
L
R
R
R
1 Execute a client command in m.justify.node (committed
branch)
<DECIDE>
received
<COMMIT>
votes
Received
C
2 Send a response to client
3 Increments viewNumber and starts the next view
Client accepts (f+1)
matching responses
4

31. 31
Basic HotStuff: Prepare (Algorithm)
“as” block executed as atomically
A nextView interrupt aborts all operations in
any as block, and jumps to the “Finally” block.

32. 32
Basic HotStuff: Prepare (Algorithm)

33. 33
Basic HotStuff: Pre-Commit (Algorithm)

34. 34
Basic HotStuff: Commit (Algorithm)

35. 35
Basic HotStuff: Decide (Algorithm)

36. 36
Basic HotStuff: NextView Interrupt (Algorithm)

37. 37
Chained HotStuff
⚫ Generic Phase
• Considerably simplifying Basic HotStuff using structural similarity of each
phase
• {prepareQC, precommitQC, commitQC} → GenericQC
⚫ Message type reduction
• only two types of messages: <NEW-VIEW> and <GENERIC>
⚫ Pipelined phases
• Each command is pipelined across multiple views

38. 38
Fundamental Optimization Technique in CS: Pipelining
http://cslearners.blogspot.com/2010/03/pipeline-forwarding.html

39. 39
Fundamental Optimization Technique in CS: Pipelining
http://cslearners.blogspot.com/2010/03/pipeline-forwarding.html
Pre-commit
Prepare
Commit
New-View

40. 40
Pipelining HotStuff
Prepare Commit
Pre
Commit
Decide
New
View
Prepare Commit
Pre
Commit
Decide
New
View
Prepare Commit
Pre
Commit
Decide
New
View
v v+1 v+2 v+3 v+4
v-1
v-2
cmd1
cmd2
cmd3

41. 41
Pipelining HotStuff with Generic Phase
Prepare Commit
Pre
Commit
Decide
New
View
Prepare Commit
Pre
Commit
Decide
New
View
Prepare Commit
Pre
Commit
Decide
New
View
v v+1 v+2 v+3 v+4
v-1
v-2
cmd1
cmd2
cmd3
Generic Generic
Generic Generic
New
View
Generic Generic
Generic Generic
New
View
Generic Generic
Generic Generic
New
View
v v+1 v+2 v+3 v+4
v-1
v-2
cmd1
cmd2
cmd3

42. 42
Generic Phase
⚫ Incorporate {Prepare, PreCommit, Commit, Decide} into one common
phase: Generic
⚫ Exploit structural similarity between all phases {Prepare, PreCommit,
Commit, Decide}
⚫ Tracking dependency across views

43. 43
Chained HotStuff: (Notation)
b’’  b*.justify.node
b’  b’’.justify.node
b  b’.justify.node
b*  m.node
Replica receives message m: <GENERIC> from a leader:

44. 44
Chaining Dependency: One, Two, and Three Chain
b*
b’’
b’
b Great grand-parent of b* (Decide)
Grand-parent of b* (Commit)
Parent of b* (Pre-Commit)
Current node: b* (Prepare)
One-
Chain
Three-
Chain
Two-
Chain
b’’ = b*.justify.node = b*.parent
b’ = b’’.justify.node
b = b’.justify.node
v
v-1
v-2
v-3
A node can lie in one of three states = {One-chain: Pre-Commit, Two-chain: Commit, Three-chain: Decide}

45. 45
Chained HotStuff Algorithm: Generic phase (1)

46. 46
Chained HotStuff Algorithm: Generic phase (1)
// Checking Two-chain
// Checking One-chain
// Checking Three-chain

47. 47
Chained HotStuff Algorithm: Generic phase

48. 48
Chained HotStuff: Algorithm
Figure 1: Chained HotStuff is a pipelined Basic HotStuff where a
QC can serve in different phases simultaneously.

49. 49
Chaining Dependency: One, Two, and Three Chain
b*
b’’
b’
b Great grand-parent of b* (Decide)
Grand-parent of b* (Commit)
Parent of b* (Pre-Commit)
Current node: b* (Prepare)
One-
Chain
Three-
Chain
Two-
Chain
b’’ = b*.justify.node = b*.parent
b’ = b’’.justify.node
b = b’.justify.node
v
v-1
v-2
v-3
A node can lie in one of three states = {One-chain: Pre-Commit, Two-chain: Commit, Three-chain: Decide}

50. 50
Chaining Dependency: Handling View Failure
b*
b’’
b’’
b’ Great grand-parent of b* (Commit)
Grand-parent of b* (Pre-Commit)
Parent of b* (N/A) : Failed view
Current node: b* (Prepare)
One-
Chain
Two-
Chain
b’’ = b*.justify.node != b*.parent
b’’ = b*.justify.node
b’ = b’’.justify.node
v
v-1
v-2
v-3
Make a failed view a blank node(or dummy node)
The immediate ancestry parent does not justify the child node's phase

51. 51
Chaining Dependency: Handling View Failure
Figure 2: The nodes at views v4,v5,v6 form a Three-Chain. The node
at viewv8 does not make a valid One-Chain in Chained HotStuff (but
it is a valid One-Chain after relaxation in the algorithm of Section 6).

52. 52
Evaluation
2S: Two phase
3S: Three phase

53. 53
Conclusion
⚫ HotStuff is one of the state-of-the-art BFT consensus designed for
permissioned blockchain
⚫ HotStuff supports linear view change with threshold signature as well
as frequent view change