From [[HotStuff BFT Consensus in the Lens of Blockchain]] Three phase, partially synchronous BFT [[SMR]] protocol Requires less than 1/3 malicious replicas (nodes) Uses three phases instead of the two popularized by [[PBFT]] and used by [[Casper]]/[[Tendermint]] Allows the leader to pick the highest QC it knows of Leads to [[Responsiveness]] - no worry about upper bound of consensus can be reached faster **Contribution of HotStuff is that it's the first BFT SMR protocol to achieve:** - **Linear View Change:** After GST, any correct leader sends only O(n) authenticators to drive a consensus decision. If cascading leader failures, comm cost is O(n^2) - **Optimistic Responsiveness:** After GST, any correct leader needs to wait for first n-f responses to guarantee it'll create a proposal that will make progress. Includes case where a leader is replaced. **NOT** dynamically available **NO** tolerance for asynchrony Uses [[Quorum Certificate]]s ![[Pasted image 20230818065823.png]] **Chained HotStuff** makes each round more efficient by effectively running four instances at once. ![[Pasted image 20230819090328.png]] # HotStuff-2 [[HotStuff-2 Optimal Two-Phase Responsive BFT]] Simplifies to two phases using the following logic: #### HotStuff Obtains a linear view change and responsiveness when the leader is honest after GST Addresses livelessness concern differently while still ensuring that the value corresponding to the highest lock is proposed by the leader. Uses the same argument as the one for safety For safety, we say "if some party commits, then >= 2t+1 parties hold a lock that will guard the safety of the commit and ensure that the next leader receives it" For liveness, HotStuff introduces another phases of votes and obtains "if some party locks, then >= 2t+1 parties know about the existence of this lock and thus hold a *key* corresponding to it. This key will be shared with the next leader to decide on a proposal appropriately." The next leader will learn about the highest lock through the 2t+1 keys it receives, and the proposal would respect the globally highest lock held by any honest party **Note:** locks guard the safety of a commit, but keys do not, and thus honest parties only holding a higher key on a different value than the proposal can still vote for the proposal. #### HotStuff-2 Looks at livelessness and asks *do we really need to add another phase to address this concern while still obtaining linear communication complexity and optimistic responsiveness?* If a leader knows about the highest lock and it can convince all honest parties about it, then the problem is solved. If a leader would receive a lock corresponding to the previous view, there cannot even exist a higher lock *Thus,* a proposal respecting this lock would be voted for by all honest parties and the livelessness concern does not exist. If a leader does not obtain a lock from preivous view, it'll wait to hear about the locks from all honest parties by waiting O($\Delta$) Happens when previous view is malicious or previous view before GST If we have a sequence of honest leaders after GST, each of them is guaranteed to drive progress responsively and generate a certificate in a view that will aid the next leader. *Thus,* all leaders except the first one in the chain can make honest parties commit responsively. ![[Pasted image 20230820083430.png]]