BFT・DAG 系コンセンサス

古典的なビザンチン障害耐性（BFT）から DAG（有向非巡回グラフ）構造を用いた次世代コンセンサスまで、許可型・無許可型ブロックチェーンの高性能合意設計の進化を体系化する記事である。BFT の根本である「1/3 未満の故障で Safety と Liveness を保証する」という数学的保証をいかに効率化・スケール化するかが、この分野の研究の中心課題だ。BFT の理論基盤（ビザンチン将軍問題・FLP 定理・部分同期モデル）は tech-203 で詳述しており、本記事はその実装系の体系化として読むことを想定している。情報カットオフ ~2025-08、confidence: medium 固定（2026-06 時点での外部再検証は未実施）。

古典 BFT — PBFT の原理と限界

PBFT（Practical Byzantine Fault Tolerance）（Castro & Liskov、1999）は実用 BFT プロトコルの嚆矢であり、現代のすべての BFT 実装の概念的出発点となっている。

PBFT のコンセンサスは 3 フェーズで構成される。(1) Pre-prepare（リーダーがメッセージをブロードキャスト）→ (2) Prepare（全ノードが Prepare を相互ブロードキャスト）→ (3) Commit（全ノードが Commit を相互ブロードキャスト）。3 フェーズの後、2f+1 のノードが同意した場合に決定が確定する（f = 故障バリデータ数、総数 n = 3f+1 以上が必要）。

PBFT の最大の問題は O(n²) の通信複雑度である。n ノードの場合、1 回の合意ラウンドで O(n²) のメッセージ交換が発生するため、バリデータ数が増加するとスループットが急激に低下する。100 ノード程度が実用上の上限とされており、パブリックチェーンの数万〜数十万ノードへのスケールは困難だ。

PBFT は 即時決定的ファイナリティを持つ点が PoW / Chain-based PoS と根本的に異なる。一度コミットされたブロックは数学的に覆ることがなく、1 ブロック確認で取引が最終的に確定する。

Tendermint / CometBFT — Cosmos エコシステムの心臓部

Tendermint（Jae Kwon、2014〜2015）は PBFT の 2 ラウンドコミットを部分同期ネットワークで実用化した BFT 実装であり、パブリックチェーン向けに最適化されている。CometBFT（2023〜）は Tendermint の後継実装で、ライブラリ化・モジュール化・パフォーマンス改善が加えられた。Cosmos Hub・Osmosis など多くの Cosmos SDK チェーンで採用されている（tech-172 参照）。

Tendermint の 1 ラウンドは Propose → Prevote → Precommit の 3 ステップで構成される。バリデータはそれぞれ 2/3 超の Prevote・Precommit を集めた後にコミットする。**ロック投票（Polka Lock）**は、あるバリデータが Precommit に投票した後は別の値に Prevote できないルールで、Safety を保証する核心メカニズムだ。ネットワーク分断時は新規ブロックを生成しない（Liveness を犠牲に Safety を維持）。

通信複雑度は O(n²) だが、PBFT より定数倍軽量な実装と、リーダーのラウンドローテーション設計により、数百バリデータ規模のパブリックチェーンで実用的に動作する（Cosmos Hub は 2025 年時点で 180 バリデータ）。

HotStuff 系 — 線形通信と DiemBFT・MonadBFT

HotStuff（Yin ら、2019）は BFT 研究の重要な転換点であり、O(n) 線形通信複雑度を達成した最初の実用 BFT プロトコルである。HotStuff ではリーダーがすべてのメッセージを集約して再配信する「星形通信」を採用し、各ノードが O(n) ではなく O(1) のメッセージを送受信する設計にした（集約署名を使って票をまとめる）。

HotStuff の進化系として特に重要なのが以下の実装だ。

DiemBFT（旧 LibraBFT、Meta）は HotStuff を Diem ブロックチェーン向けに最適化した実装で、継続的なリーダーローテーションと Pacemaker によるビューチェンジの効率化を加えた。Diem プロジェクト自体は 2022 年に清算されたが（tech-200 参照）、DiemBFT の技術的成果は Aptos と Sui に継承された。

AptosBFT（Jolteon / DiemBFT v4）は Aptos が採用する BFT コンセンサスで、パイプライン化された 2 フェーズコミットと継続的なリーダーローテーションが特徴だ。Shoal（2023）はその後継で、リーダー評判スコアを用いて低レイテンシリーダーを優先選択する。Shoal++（2024〜2025）はさらにパイプラインを深化させ、DAG-BFT との統合を強化している（tech-160 参照）。

MonadBFT（Monad）は HotStuff 系の独自実装で、2 フェーズ BFT + Pipelined コミット + Optimistic Responsiveness（遅延ノードを待たずに応答時間ベースで進行する最適化）を組み合わせ、1 秒ファイナリティ・10,000 TPS を目標とする（tech-161 参照）。

DAG-BFT の登場 — Narwhal とメンプール / 順序付けの分離

2021〜2024 年に台頭した DAG-BFT（DAG-based Byzantine Fault Tolerant Consensus）は、コンセンサスのスループットとレイテンシのボトルネックが「トランザクション伝播（mempool）」と「順序付け合意」の混在にあると認識し、この 2 つを構造的に分離する。

Narwhal（Spiegelman ら、2022 / Mysten Labs + Aptos）はメモリプールを DAG 構造で実装したデータ可用性レイヤーである。各バリデータは独立してバッチ（頂点）を構築し、前のバッチへの 2f+1 の証明を参照することで DAG を形成する。Narwhal は「全バリデータがデータを確認済みのバッチ集合」を保証するため、その上に乗る合意プロトコルはデータを再送せず「どの順序でコミットするか」だけを決定できる。これにより合意オーバーヘッドを大幅に削減できる。

Bullshark（Spiegelman ら、2022）は Narwhal の上に構築された非同期 DAG コンセンサスであり、DAG 上の「アンカー頂点」を決定論的に選択することで合意を導出する。非同期ネットワーク下でも動作する（FLP 不可能性を確率的ランダム性で回避）。DAG 構造のデータ構造的特性・監査ログへの不適合については tech-27 で論じている。

DAG-BFT の最前線 — Mysticeti・Shoal++

Mysticeti（Babel ら、2024 / Mysten Labs）は DAG-BFT の設計を大きく前進させた。Narwhal+Bullshark の構造を継承しつつ、**認証なし DAG（Uncertified DAG）**設計により頂点伝播に 2f+1 の署名証明を待つオーバーヘッドを除去した。各バリデータは楽観的に自分の頂点をすぐに公開し、後続の頂点からの参照が十分に集まった段階でコミットを確定させる。

Mysticeti の性能指標（Sui mainnet、2024 年実測）：

• ファイナリティ: WAN 環境で 0.5 秒前後
• スループット: 200,000+ TPS（実証実験段階）
• 2024 年採用: Sui が Bullshark から Mysticeti へ mainnet 切り替えを完了

Sui の高スループット実績の技術的根拠が Mysticeti への移行にある。

Shoal / Shoal++（Spiegelman ら、2023〜2024 / Aptos）は Aptos の DAG-BFT 実装で、Bullshark の上にリーダー評判機構とパイプライン化された 2 ラウンドコミットを追加した。レイテンシを削減しつつ非同期耐性を維持する設計で、AptosBFT と組み合わせることで Aptos の実行レイヤー（Block-STM）に最適なトランザクション供給を実現する（tech-160 参照）。

古典 BFT と DAG-BFT の比較

DAG-BFT は 2022〜2025 年に高スループット L1 の標準設計となりつつある。ただし DAG 上の「コミットルール」設計が複雑になるため、バグや意図しないセキュリティ特性のリスクも高まる点は注意が必要だ。代替合意方式（Proof of History・Avalanche・Hashgraph 等）とコンセンサスのセキュリティ課題の横断整理は tech-207 で論じる。