レッスン3 — HotStuff と HyperBFT（単一リーダー BFT 系統）

問い

Hyperliquid は秒間約 20 万件の perp 取引をサブ秒 finality で処理する。その下のコンセンサスが HyperBFT — そして HyperBFT は奇抜な新設計ではない。HotStuff の variant である。HotStuff（2018）はさらに PBFT（1999）の派生で、この系統全体が、即時 finality を要する現代のほぼすべての非Ethereum L1の選択肢になっている。PBFT から HotStuff への跳躍は何によって可能になったか？

原理（最小モデル）

• PBFT は O(n²)、HotStuff は O(n). n = 100 で約 100 倍のメッセージ削減。可能にしたのは ① 閾値署名（BLS）と ② pipelined commit。
• 閾値署名で n² → n. 2f+1 バリデータの部分署名を サイズ O(1) の 1 つの集約署名 にまとめる。リーダーは集約だけをブロードキャスト、バリデータ同士の直接交信は不要。
• Pipelined commit. Block N、N+1、N+2 が異なるフェーズで同時並行に進む。スループットは 3 ブロック時間に 1 commit → 1 ブロック時間に 1 commit。
• 3 つの不変条件. Quorum Certificate（2f+1 投票の集約署名証明）/ View 番号（リーダー切り替え単位）/ Lock（view change 中の safety 違反防止）。

具体例

PBFT の 3 ラウンド:

Round 1 (Pre-prepare): リーダー → 全バリデータ:「ブロック B」
Round 2 (Prepare):     全 → 全:「B に投票した」          ← all-to-all = O(n²)
Round 3 (Commit):      全 → 全:「B を commit する準備ができた」 ← all-to-all = O(n²)

HotStuff の pipelined commit:

Block N:   Propose → Vote → Commit
Block N+1:           Propose → Vote → Commit
Block N+2:                     Propose → Vote → Commit

HotStuff の派生:

失敗例（誤解）

「Lock は fork を防ぐ」— 部分的に正しい。Lock が防ぐのは 矛盾する commit であって、fork そのものではない。Byzantine リーダーは矛盾するブロックを 提案 できるが、lock はそのうち 1 つだけが commit されることを保証する。

「HyperBFT は HotStuff そのまま」— 間違い。HyperBFT は HotStuff 派生だが、Hyperliquid は実装をオープンソース化していない。orderbook 取引のホットパスに合わせた低レイテンシ最適化（pipelining 深さ、リーダーローテーション、ネットワークトランスポート）が入っていると推測される。

🛑 予測。 PBFT は O(n²)、HotStuff は O(n)。n = 100 で約 100 倍のメッセージ削減を可能にした変更は何か？（ヒント: 暗号。答え: 閾値署名（BLS）。2f+1 バリデータの部分署名を 1 つの集約署名にまとめてサイズ O(1) に圧縮、all-to-all 通信が不要になる。）

ステップで組み立てる

Step 1: PBFT → HotStuff の 2 発明を言える

1. 閾値署名（BLS）: 部分署名を集約 → all-to-all 不要 → O(n)
2. Pipelined commit: フェーズを重ねる → 単位時間あたり commit 数が 3 倍

Step 2: 3 不変条件を 1 文で

• QC（Quorum Certificate）: 「2f+1 が B に投票した」の集約署名証明
• View 番号: リーダー切り替え単位
• Lock: 2f+1 が phase 2 で投票した後、次のリーダーは同じブロックを含めるか、含められない証明（より高い QC）を出す

Step 3: Byzantine リーダー検知のタイミング

Propose フェーズの後、2f+1 が yes 投票しなければ次のリーダーが view change で引き継ぐ。不正な提案は破棄。Liveness は 1 ラウンド余計に使うだけで回復。

答え合わせ

• HotStuff が Hyperliquid に適合する理由: 有界委員会で低レイテンシ + QC 検証コスト低（orderbook コードが包含検証を高速にできる）+ pipelining でスループット。
• HyperBFT が非公開だが推測できる範囲: HotStuff 派生 + ~20-25 バリデータ + サブ秒 finality + HyperEVM が orderbook と並列で同じコンセンサスで commit。非公開: pipelining 深さ、リーダーローテーション、view change 詳細、ネットワーク最適化。
• Tempo の系統: ホワイトペーパー未公開だが、ほぼ確実に HotStuff か Tendermint 系（親戚）。

合格基準

• PBFT O(n²) → HotStuff O(n) を可能にした 2 発明（閾値署名 + pipelining）を即答できる。
• QC / View / Lock の役割を 1 文で言える。
• HotStuff 派生 5 つ（Basic / Event-driven / DiemBFT / HyperBFT / Aptos BFT）の系譜を辿れる。

まとめ（3行）

• HotStuff = PBFT × 閾値署名（O(n²) → O(n)）+ pipelined commit。
• 3 不変条件 = QC（2f+1 集約署名）/ View（リーダー切り替え単位）/ Lock（safety 違反防止）。
• HyperBFT は HotStuff 派生で実装非公開、しかし系統と性能特性は公開仕様から推測できる。