Thread by @AlexSkidanov

A short thread on HotStuff vs Tendermint for Libra

1/ LibraBFT uses HotStuff as the base for their consensus. I went through the paper today, and it appears to be practically unaltered version of the latest HotStuff that was accepted to PODC'19

Paper: developers.libra.org/docs/assets/pa…

2/ HotStuff is a consensus in the same family as Tendermint and PBFT. It improves on Tendermint in two aspects:

1. It is chained, meaning that k view changes take k+2 rounds of communication, instead of 2k
2. It is responsive (see below)

3/ Responsiveness means that once the network is synchronous, the protocol finishes in time that depends on the network latency, not on timeouts in the protocol. It is not the case in Tendermint, in which one always waits for the precommit timeout before moving to next view.

4/ There's, however, a certain risk of using HotStuff -- the fact that the chained version is very new. It was peer-reviewed for PODC, but other than that was not as scrutinized as Tendermint yet. Cosmos has been running Tendermint in production for more than a year now.

5/ Also in the particular context of Libra both advantages of HotStuff are not as important, and the responsiveness is also misleading.

In Cosmos less than 1% of all the votes go to the third view, at which point Tendermint incurs more rounds of communication than HotStuff

6/ I expect Libra to have higher requirements to validators uptime than Cosmos, thus the %% will be even smaller. That means that the lower number of rounds of communication will make little to no impact during normal operation.

7/ Now the responsiveness. The HotStuff paper defines the responsiveness as "the correct leader finishing the consensus in time that doesn't depend on the timeout"

8/ What is crucial here is the "the corect leader" part. The leader itself can be faulty and be offline or intentionally drag the protocol. The timeout for the proposal still must be waited for if the leader is faulty before moving to the next view.

9/ That IMO makes the claim of responsiveness in LibraBFT misleading, since in practice if byzantine nodes are present, the protocol might actually take time proportional to the timeout, not the actual network delay.

10/ With all that being said, if I was designing Libra, I would choose Tendermint over HotStuff, since the benefits of HotStuff will not play any significant role in the particular context of Libra, and the higher maturity of Tendermint should be a more important consideration.

11/ While in a context of a more permissionless blockchain, in which the participants of the consensus are less reliable, and view changes occur frequently, HotStuff advantages over Tendermint would become more important.

(It's worth mentioning that chained versions of Tendermint were also proposed, but none of them is as scrutinized as the basic Tendermint).