PBFT View Change, Two-Chain HotStuff, and the Role of the Fourth Round

This note discusses a simplified version of HotStuff. I ignore pipelining and most engineering optimizations. The goal is to isolate three concepts: lockQC, commitQC, and highQC. With these concepts, we can compare PBFT view change, two-chain HotStuff with one extra QC, and three-chain HotStuff with one extra QC.

Model

Assume the standard Byzantine setting with $n > 3f$, where at most $f$ replicas are Byzantine. A quorum certificate, or QC, is formed after collecting $n-f$ votes. Since $n > 3f$, a QC contains at least $2f+1$ votes.

Each replica maintains a local lockQC. If a replica is locked on block $B$, it will not vote for a conflicting block unless the protocol gives it a valid unlock condition. A commitQC represents enough evidence for a block to be committed locally. During view change, the next leader chooses a highQC, which determines which certified branch the new proposal should extend.

The core question is local information. When a replica is locked on $B$, it may see a new proposal that conflicts with $B$. The replica must decide whether voting is safe. If it votes too early, two conflicting blocks may be committed. If it refuses forever, the protocol may lose liveness.

Two-Chain Plus One QC

In the two-chain setting, block $B$ can be committed once there is a QC for $B$ and a QC for a child of $B$. The lock is updated when a replica observes the relevant QC. Two cases matter.

Case 1: a replica is locked on $B$, and a new lockQC(B') appears. Suppose $B’$ conflicts with $B$. If a commitQC for $B$ already exists, then at least $f+1$ honest replicas must have participated in the certified path that commits $B$. These honest replicas will not vote for a conflicting block. Therefore, $B’$ can obtain at most $2f$ votes, which is not enough to form a QC. In other words, if lockQC(B') exists, then commitQC(B) cannot exist.

This observation gives a safety argument. Once a replica sees a conflicting lockQC(B'), the existence of that QC proves that $B$ has not been committed. The replica can safely move its lock to $B’`.

However, this fact alone does not give a clean liveness argument. A Byzantine leader can influence which QC is carried as highQC in later views. The protocol may keep returning to the old branch for several views. Thus, “switch when a conflicting lockQC appears” is safe, but it does not by itself explain how progress is forced.

Case 2: a replica is locked on $B$, and the leader proposes $B’$ extending parent(B). This case is harder. The new block $B’$ conflicts with $B$, but its justification is the QC of parent(B). The replica locked on $B$ now lacks global information.

If the replica votes for $B’$, it may be wrong. There may already be messages in the network that can complete a commit for $B$. In that execution, the replica helps form evidence for a conflicting branch.

If the replica refuses to vote for $B’$, it may also be wrong. It may be the case that $B$ will never be committed. If enough replicas stay locked and refuse sibling proposals, the protocol can stop making progress.

This is the core dilemma of two-chain HotStuff in this simplified view. The local state of the locked replica is not enough. Voting may break safety. Refusing may break liveness.

What PBFT New View Provides

PBFT addresses this incomplete-information problem explicitly. During view change, replicas send VIEW-CHANGE messages to the new leader. These messages include the prepared or locked state that each replica has observed. After collecting $n-f$ such messages, the leader constructs a NEW-VIEW message and chooses the highest safe certificate.

The important point is not the syntax of the message. The important point is the information aggregation. A single locked replica cannot know whether some other part of the network has enough evidence to commit $B$. The new leader, after receiving $n-f$ view-change messages, has a quorum-level view of the certified state.

If the selected highQC is on the branch of $B$, the protocol continues on that branch. The locked replica can keep voting for descendants of $B$.

Conversely, if the selected highQC is on another branch or only on parent(B), then the quorum-level view does not support continuing with $B$. The locked replica can move away from $B$ without creating a conflicting commit.

Thus, the $n-f$ messages in PBFT view change answer a concrete question: is there enough global evidence that the protocol must continue on $B$? PBFT pays a heavy communication cost to obtain this answer explicitly.

Three-Chain Plus One QC

HotStuff obtains a similar effect through the lock rule and the view number. Consider the same hard case. A replica is locked on $B$, and a leader proposes $B’$ that extends parent(B) rather than $B$.

In three-chain HotStuff, the safeNode predicate has two ways to accept a proposal. The proposal is safe if it extends the locked block. Otherwise, it is safe only if its justification has a higher view than the replica’s current lock.

The sibling block $B’$ does not extend $B$. Its justification is the QC of parent(B), whose view is no higher than the view of $B$. Therefore, a replica locked on $B$ will not vote for $B’`. The protocol does not ask the replica to guess whether $B$ may be committed elsewhere.

Now consider what happens if a conflicting lockQC(B') later appears in a higher view. This event itself carries information. Replicas locked on $B$ would not have voted for $B’$ before a valid unlock condition. Therefore, if $B’$ nevertheless obtains a QC, then by quorum intersection there cannot already be a commitQC for $B$. If such a commitQC existed, at least $f+1$ honest replicas would remain committed to the branch of $B$ and would not vote for the conflicting branch. Then $B’$ could not collect $n-f$ votes.

The higher-view lockQC(B') therefore provides the missing evidence. It proves that moving away from $B$ is safe. Since the QC also has a higher view, it satisfies the unlock condition. The replica can transfer its lock to $B’`.

This is the role of the extra round. Before the conflicting branch is certified, locked replicas refuse to vote for it. After the conflicting branch obtains a higher-view QC, the QC itself proves that the old branch was not committed. The protocol has converted the missing global information into a local certificate.

Summary

The same safety fact appears in both two-chain and three-chain reasoning. If a conflicting lockQC(B') already exists, then there is no commitQC(B). The existence of the conflicting QC proves that the old branch was not committed.

The difference is what happens before lockQC(B') exists. In the two-chain setting, a locked replica cannot decide locally whether to vote for a sibling proposal. PBFT solves this problem by collecting $n-f$ view-change messages and explicitly reconstructing a quorum-level view. Three-chain HotStuff solves it structurally. The view-number rule prevents unsafe votes before the conflicting branch is certified. Once the higher-view certificate exists, the certificate itself gives the unlock evidence.

Therefore, the fourth round is not an arbitrary extra delay. It is the mechanism that turns a global-information problem into a local-certificate check.