HotStuff

[4meta5]

HotStuff: BFT Consensus with Linearity and Responsiveness

Once network communication becomes synchronous, HotStuff enables a correct leader to drive the protocol to consensus at the pace of actual (vs.maximum) network delay—a property called responsiveness—and with communication complexity that is linear in the number of replicas.

[4meta5]

HotStuff: Three-chain Rules!

• Chain Quality necessitates fast/frequent proposer rotation for fairness and liveness
• Linearity means paying a communication cost that amounts to sending a proposal over the network once to everyone. This cost is kept against a broad range of network conditions, and includes proposer rotation.
• Responsiveness implies that the protocol can progress at network speed, i.e., as soon as messages from a quorum are collected, without waiting some a priori upper bound on network delay.

Optimistic responsiveness means that after GST a correct proposer needs to wait for only the (2/3)n fastest responses in order to guarantee progress. Linearity means that after GST a correct prosper needs only linear communication to commit a block.

• Protocols like PBFT are responsive but not linear while protocols like Tendermint and Casper are linear but not responsive* ~ittai

[4meta5]

What is the difference between PBFT, Tendermint, SBFT and HotStuff?

Randomization is a central tool in the design of protocols for distributed computing and cryptography. All the protocols mentioned above are deterministic. One can use a random leader election to gain better bounds and against more adaptive adversaries and models. There are two recent protocols that extend HotStuff and use randomization in powerful ways:

• VABA: gets O(1) expected rounds even in the asynchronous model and a strong adaptive adversary
• LibraBFT: can get O(1) expected rounds in the partial synchronous model and a somewhat adaptive adversary

[4meta5]

On LibraBFT's use of broadcasts

Like its distant ancestor PBFT, LibraBFT requires non-leader nodes to perform broadcasts under certain circumstances. Specifically, in LibraBFT:

1. Nodes regularly synchronize their states using broadcasts.
2. When a timeout is reached, e.g., because of network problems or a faulty leader, nodes send a timeout message to all other nodes.

The use of broadcasts for state synchronization facilitates the algorithm’s liveness analysis. However, it has the unfortunate side-effect of increasing the algorithm’s communication complexity. (Neither the state synchronization broadcasts nor the timeout broadcasts should affect the algorithm’s safety).

[4meta5]

HotStuff: BFT Consensus in the Lens of Blockchain by moratbuffalo