Preface
HotStuff proposed a three-stage voting BFT-type consensus protocol, which implements safety, liveness, and responsiveness characteristics. Through the introduction of threshold signatures in the voting process, O(n) message verification complexity is achieved. Hotstuff summarized and compared the current mainstream BFT consensus protocols, and constructed a model for implementing pipeline BFT consensus based on classic BFT consensus.
HotStuff is a consensus protocol based on View. View represents a consensus unit, and the consensus process is composed of views one after another. In a View, there is a certain Leader to lead the consensus agreement, and a consensus is reached after three stages of voting, and then switch to the next View to continue the consensus. If an abnormal situation occurs and a view fails to reach a consensus over time, it will switch to the next view to continue the consensus.
Basic hotStuff is the basic version of the consensus protocol. The confirmation of a block requires a three-stage vote to reach the consensus before entering the next block. pipeline hotStuff is a consensus protocol for pipelines, which improves the efficiency of consensus.
Content
State Machine Replication (SMR, State Machine Replication) refers to the state machine consisting of multiple replicas. When executing commands, the state of each replica is agreed upon by consensus.
If the initial state of each replica is consistent, then the order of input commands can be globally agreed through the consensus mechanism, and the state of each replica can be consistent.
In SMR, there is a Leader node that sends a proposal, and then each node participates in voting to reach a consensus.
The system input is tx, and the network node is responsible for packing these tx into a block, and each block contains the hash index of its parent block.
Basic HotStuff three-stage process
Chained hotStuff
In basic hotStuff, each stage of the three-stage voting is nothing more than sending out messages and then collecting votes, so the following methods can be used to simplify the protocol.
The votes in the Prepare stage are collected by leader1 corresponding to the current view, and prepareQC is generated after all the votes are collected. Then send prepareQC to leader2 of the next view. Leader2 starts a new prepare phase based on prepareQC. This is the prepare phase of leader2 and also the precommit phase of leader1. By analogy, leader2 generates a new prepareQC, and then sends it to leader3 of the next view. Leader3 starts its own prepare phase, which is also the commit phase of leader1 and the precommit phase of leader2.
The agreement was simplified to the following process:
- Leader node
- Wait for the NewView message, and then issue Proposal
- After issuing Proposal, wait for votes from other nodes
- Send a NewView message to the next Leader
- Non-leader node
- Waiting for Proposal message from Leader
- After receiving the Leader’s Proposal message, check the QC in the message, update the local prepareQC, lockedQC and other variables, and send a vote
- Send a NewView message to the next Leader
Dummy block
Under normal circumstances, there is a block in each View that generates and collects signatures, but the situation is not always so perfect, and sometimes no new blocks are generated. In order to keep the block height consistent with the viewNumber, the concept of dummy block is introduced in hotStuff. If a consensus cannot be reached in a View, then a Dummy block is added to the View.
