## 定義 ビザンチン障害(Byzantine fault)とは、ノードが応答しない・遅い・状態が古いといった「不正直だが誠実」な障害と異なり、ノードが恣意的に嘘をつく——矛盾する応答を返す、選挙で複数の矛盾する票を投じる等——障害モデルを指す。この環境で合意に至る問題は**ビザンチン将軍問題(Byzantine Generals Problem)**と呼ばれる。あるシステムが一部のノードが誤動作・プロトコル違反・悪意ある攻撃を行っても正しく動作し続けるとき、そのシステムは**ビザンチン耐障害性(Byzantine fault-tolerant)**を持つという。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Byzantine Faults") ## 適用領域と非適用領域 ビザンチン耐性が重要になるのは、(1) 航空宇宙のように放射線でメモリ・レジスタが破損しうる環境、(2) 参加者が相互不信の関係にある環境(暗号通貨・ブロックチェーンにおける合意形成)である。一方、データセンター内で単一組織が全ノードを管理する一般的なサーバサイドシステムでは通常想定しない——理由は、同一ソフトウェアを全ノードにデプロイする以上、あるノードのバグは他ノードにも共有され、ビザンチン耐性アルゴリズム(多くは 3 分の 2 超のノードの正常動作を要求する)がバグそのものを救えないため、また攻撃者が 1 ノードを侵害できれば同一ソフトウェアの他ノードも侵害できる可能性が高いためである。この場合の主たる防御は伝統的な認証・アクセス制御・暗号化・ファイアウォールになる。マルチテナントシステムでの相互不信テナントも、ビザンチン耐性でなくファイアウォール・仮想化・アクセス制御ポリシーによる隔離で扱う。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Uses of Byzantine fault tolerance") ## 弱い形の「嘘」への対策 完全なビザンチン耐性ではないが、ハードウェア故障・ソフトウェアバグ・誤設定に起因する不正なメッセージへの実用的な防御策として、アプリケーション層チェックサム・TLS 暗号化(パケット破損対策)、入力のサニタイズ・エスケープ・サイズ制限(SQL インジェクションやDoS対策)、複数 NTP サーバへの問い合わせと外れ値排除(誤設定サーバ対策)がある。これらは決意した攻撃者には耐えられないが、実用的で単純な信頼性向上策になる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Weak forms of lying") ## PBFT: ビザンチン耐性合意の具体アルゴリズム DDIA第9章と『詳説 データベース』第8章はいずれもビザンチン障害の定義と適用領域を抽象的に論じるにとどまるが、[[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]]は本概念が要求する耐性を実際に実装するアルゴリズム、Practical Byzantine Fault Tolerance(PBFT)を具体的に示す。PBFTは $n = 3f + 1$ のノードで $f$ 個のビザンチン障害ノードを許容し、ビューごとにプライマリ 1 つとバックアップで構成される。プロトコルは Pre-Prepare(プライマリがビューID・ID・ペイロード・ダイジェストを署名してブロードキャスト)・Prepare(バックアップが一致する $2f$ 個の Prepare メッセージを収集)・Commit(一致する $2f+1$ 個の Commit メッセージを収集)の3フェーズで進み、クライアントは $f+1$ の一致応答を得るまで実行結果を確信できない。ノード間の全通信は暗号化・署名され、ダイジェストによってペイロード全体の繰り返しブロードキャストを避ける。プライマリの障害が疑われるとビュー変更が発生し、$2f$ 件のビュー変更イベントを受けた新プライマリが新ビューを開始する。 このアルゴリズムは「クォーラム内の各ノードが相互に通信しなければならない」という本概念の抽象的な特徴づけ(N2のメッセージが必要)を、Prepare・Commitの各フェーズで具体的な閾値($2f$・$2f+1$)として実装したものである。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]] §14.5, §14.5.1, §14.5.2) ## 横断的知見 - **PBFTの具体的な閾値設計は、本ページが記録してきた「N2メッセージが必要」という抽象的な特徴づけと、非ビザンチン合意のクォーラム過半数($f+1$ / $2f+1$)設計を橋渡しする**: [[分散コンセンサス]]ページが記録するPaxos・Raftの過半数クォーラム($2f+1$ノードで$f$障害を許容)と比較すると、PBFTは同じ$f$障害耐性を得るために必要なノード数を$3f+1$へ増やし、かつ各フェーズで$2f$または$2f+1$個の一致メッセージを要求する。非ビザンチン合意が「過半数が同じ値に投票すれば安全」という単純な多数決で足りるのに対し、ビザンチン合意は「相手が嘘をついていないことを他ノードとの突き合わせで検証する」という追加の手続きを要するため、必要なノード数とメッセージ往復の両方が増加する。この対比は、なぜ本ページの「適用領域と非適用領域」節がビザンチン耐性を敵対的環境に限定すべきと論じるかの定量的な裏づけになる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]] §14.5, §14.5.1, [[分散コンセンサス]]) - [[分散コンセンサス]] は非ビザンティン条件下での安全性を前提とする Raft・Paxos を扱っており、本概念(ビザンティン条件下での合意の困難性)とは対比関係にある。両者の前提の違いは上のPBFT比較で定量的に突き合わせた。 - **異なる著者(Petrov / Kleppmann & Riccomini)が独立に、航空宇宙と暗号通貨という同じ2つの適用領域へ収束する**: DDIA第9章は「放射線でメモリ・レジスタが破損しうる航空宇宙」と「参加者が相互不信の暗号通貨・ブロックチェーン」をビザンチン耐性の主要適用領域として挙げるが、Database Internals第8章§8.7.3も独立に「航空宇宙業界(サブコンポーネントの応答をクロスバリデーションする)」と「暗号通貨(中央権威が存在せず敵対的参加者が価値を捏造しようとする)」を挙げる。両テキストの著者・出版年が異なるにもかかわらず同じ2領域に収束していることは、ビザンチン耐性の実務的な位置づけ(データセンター内の単一組織管理システムでは通常不要、という消極的な結論を含め)が分野内である程度定着した共通認識であることを示唆する。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]] §8.7.3, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Uses of Byzantine fault tolerance") - **Database Internals は任意障害(arbitrary faults)という語を主用語に置き、ビザンチン障害をその別名として導入する**: Database Internals第8章は障害モデルの分類(クラッシュ・欠落・任意)の一項目として「任意障害(arbitrary faults)。これは、ビザンチン障害(byzantine faults)と呼ばれることもあります」と述べ、"克服するのがもっとも困難な障害"と位置づける。DDIAは逆に「Byzantine Faults」を章の節タイトルとして直接採用しており、両ソースの用語選択の違い(任意障害を主・ビザンチン障害を副とするか、その逆か)自体が、実務者向け入門書(まず一般化した性質から導入)と理論寄りの教科書(まず歴史的な固有名から導入)という記述姿勢の違いを反映している可能性がある。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]] §8.7.3) ## 未解決の問い - ビザンチン耐性アルゴリズムが要求する「3 分の 2 超のノードが正常」という前提は、同一ソフトウェアの独立実装を複数用意する(N-version programming)ことでバグ耐性に転用できるか。そのコストは実務上正当化されるか。 - ブロックチェーン以外の分野(マルチクラウド・マルチベンダーの相互運用システムなど、単一組織が全ノードを管理しない環境)で、ビザンチン耐性が実用的な選択肢になる具体的な条件は何か。 - [[分散コンセンサス]] が前提とする「非ビザンティン(unreliable but honest)」モデルと、本概念のビザンティンモデルの間には中間的な障害モデル(例: 一部ノードだけが悪意を持つ)が存在しうるか。DDIA が言及する XFT(OSDI 2016)のような折衷アプローチはどのような前提を置くか。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]] - 概念: [[分散システム障害]] / [[フォールトトレランス]] / [[分散コンセンサス]] / [[2人の将軍の問題]] ## 出典 - Martin Kleppmann and Chris Riccomini, *Designing Data-Intensive Applications*, 2nd Edition, O'Reilly Media, 2026, Chapter 9, "Byzantine Faults". - Alex Petrov, *詳説 データベース*, オライリー・ジャパン, 2021, 8章, §8.7.3. - Alex Petrov, *詳説 データベース*, オライリー・ジャパン, 2021, 14章, §14.5〜§14.5.2(PBFTアルゴリズムの具体的な手順・閾値).