[What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?](https://decentralizedthoughts.github.io/2023-04-01-hotstuff-2/) Focuses on explaining the key component that forms the difference between these works: *How do we ensure liveness during a view change while simultaneously achieving other useful properties: responsiveness, good communication complexity, and fewer number of phases in the protocol?* # Overview of Approaches Assume all are partially synchronous protocols with $n \geq 3t+1$ are committing a single value. In a view, parties hope to certify at most one value One phase of votes ensures uniqueness of a value within the view Another phase allows parties to commit the value When a party commits a value v after the second phase, a principal invariant that is ensured is that $\geq 2t+1$ parties (thus $\geq t+1$ honest parties) are locked on v from the first phase. These honest parties guard the safety of the commit. *Thus, they would not vote on a conflicting value unless they are shown a proof that it is safe to do so* The [[commit-lock]] (or commit-adopt) paradigm ![[Pasted image 20230820092308.png]] If a leader fails or the network stalls, we can end up in one of three situations 1. No party has a lock and no value is committed 2. One or a few parties are locked on a value but no honest party has committed 3. 2t+1 parties are locked, some honest parties have committed but not all They are all safety-preferring protocols, meaning the locked parties guard the safety of a potential commit By default, we can assume case 3, and no votes for a conflicting value unless shown a proof otherwise When in case 2, we need some mechanism to ensure that these locked honest parties vote for a safe proposal from a leader (one that may conflict with a locked value) after a view-change. The different schemes differ in this regard Note: A malicious leader can, at most, delay progress by not sending a proposal in the view # How does the view-change protocol differ between PBFT, Tendermint, HotStuff, and HotStuff-2? Think about these two questions while reading: 1. What does the leader learn about the status of the system (w.r.t the three scenarios) at the start of a view? 2. How does the leader convince other parties about the status of the system (and thus to vote for its proposal)? ## PBFT At the start of a view, the leader collects a status of locks from 2t+1 parties Consider case 3 (some party has committed in earlier views) Among the 2t+1 locks, up to t can be malicious, and up to t can be from honest parties that are not locked on the committed value There is at least one honest party locked on the committed value This party would not vote for a leader proposal conflicting with the lock it holds, thus guarding the safety of the commit The leader would also learn about this lock when it collects the status message Consider case 2 (no party had committed in an earlier view, but some parties locked on the value) These parties' statuses may or may not be a part of the locks the leader receives. The leader convinces honest parties locked on a conflicting value to vote for the value it proposed by sending the *status certificate* with 2t+1 locks in its proposal ## Tendermint Improves PBFT by not requiring the leader to send a (2t+1)-sized status certificate, allowing it to perform a view change with linear complexity By receiving 2t+1 locks, an honest leader perhaps knows what to propose, but if parties do not have access to those locks (through status certificate) they may not vote for it. Example: p is locked on a value, leader proposes conflicting value, p cannot tell if we are in case 2 or 3. Tendermint requires leader to wait for a full delay time Ensures the leader receives locks from all honest parties, thus it can send a proposal that conforms with the value corresponding to the lock from the highest view, and send this lock together with the proposal\ The highest-ranked lock convinces all honest parties to vote on the proposal sent by the leader ## HotStuff Obtains both linear view change and responsiveness when the leader is honest after GST Uses the same argument as the one for safety. Safety: "If some party commits, then $\geq 2t+1$ parties hold a lock that will guard the safety of the commit and ensure the next leader receives it" For liveness, it introduces another phase of votes and gets "if some party locks, then $\geq 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" Next leader will learn about the highest lock through the 2t+1 keys it gets, and the proposal would respect the globally highest lock held by any honest party Locks guard the safety of a commit, but keys do not, thus honest parties only holding a higher key on a different value than the proposal can still vote for the proposal Three-phase protocol ## HotStuff-2 Do we need to add another phase to address livelessness concern? If a leader knows about the highest lock and can convince all honest parties about it, then the problem is solved. New leader has two options: 1. If the leader obtains a lock ([[Quorum Certificate]]) from preceding view, it knows that it has the maximal locked value that possibly exists in the system, and proceeds with the proposal in a responsive manner 2. Otherwise, leader knows that a timer delay must have expired in the preceding view. In that case, no responsiveness, so it waits for a delay in which all parties are guaranteed to enter the view to obtain the maximal locked value in the system