実用的なビザンチン断層トレランス（PBFT）とは何ですか？

PBFTは、ノードの最大3分の1が欠陥または悪意のある場合でも、分散システムのコンセンサスを有効にすることにより、ビザンチン将軍の問題を解決します。

2025/08/02 06:42

ビザンチン将軍の問題を理解する

実用的なビザンチン断層トレランス（PBFT）の基礎は、ビザンチン将軍の問題を解決することにあります。これは、信頼できないまたは悪意のある参加者の存在にもかかわらず、複数のアクターが決定を調整する必要がある分散コンピューティングの理論的シナリオです。この比phorでは、数人の将軍が都市を囲んでおり、攻撃するか退却するかに同意しなければなりません。コミュニケーションはメッセンジャーを介して発生しますが、一部の将軍は誤ったメッセージを送信する裏切り者である可能性があります。課題は、一部の入力が誤解を招く場合でも、忠実な将軍の間でコンセンサスを達成することです。ブロックチェーンおよび分散システムでは、これは、一部のノードが故障したり、悪意を持って行動したりする場合のトランザクションの妥当性にネットワークノードが一致するようにすることにつながります。 PBFTは、故障したノードの数が合計の3分の1を超えない限り、システムが機能的かつ一貫性を維持できるようにすることにより、これに対処するように設計されました。

PBFTがコンセンサスを達成する方法

PBFTは、ネットワークがシステム状態のコピーを維持するノードの既知のレプリカで構成されているという仮定の下で動作します。 1つのレプリカはプライマリ（リーダー）として指定され、他のレプリカはバックアップです。コンセンサスプロセスは、クライアントがプライマリにリクエストを送信するときに始まります。プロトコルは、合意を確保するためにいくつかのフェーズを進みます。

• プライマリは、クライアントリクエストやシーケンス番号など、すべてのバックアップレプリカへの事前準備メッセージを放送します。
• 各バックアップレプリカは、メッセージを検証すると、他のすべてのレプリカに準備メッセージを送信し、領収書と一貫性を確認します。
• レプリカが2F+1マッチングの準備メッセージ（ Fは故障したノードの最大数）を収集すると、準備された状態に入ります。
• 次に、各レプリカは、リクエストを適用する準備ができていることを示すコミットメッセージを送信します。
• レプリカが2F+1の有効なコミットメッセージを受信すると、リクエストを実行してクライアントに返信します。

クライアントは、F+1の同一の応答が結果を受け入れるのを待っており、いくつかのレプリカに欠陥がある場合でも正確性を確保します。この多相通信は、すべての正直なノードが同じ状態に到達し、障害のしきい値の下で安全性と活性を維持することを保証します。

PBFTの主な機能と利点

PBFTの最も重要な側面の1つは、その決定論的な最終性です。トランザクションがコミットされているため、最終的であり、仕事の証明システムの確率的最終性とは異なり、戻ることができません。これにより、PBFTは即時の一貫性を必要とするアプリケーションに適しています。もう1つの利点は、許可された環境での高性能です。ノードの数は限られており、既知であるため、メッセージ伝播は効率的であり、エネルギー集約的なコンセンサスメカニズムと比較して低レイテンシと高スループットが可能になります。

さらに、 PBFTはビザンチンの断層を許容します。つまり、クラッシュするメッセージだけでなく、任意のメッセージまたは悪意のあるメッセージを送信するノードを処理できることを意味します。この回復力は、敵対的な環境で重要です。また、プロトコルは、安全性（すべての正しいノードが同じリクエストの順序に同意する）と快適さ（プライマリが正直である限り進行が行われる）を保証します。これらのプロパティにより、PBFTはHyperledger Fabricなどのエンタープライズブロックチェーンプラットフォームに優先選択となります。

制限とスケーラビリティの課題

その強みにもかかわらず、PBFTは顕著な制限、特にスケーラビリティに直面しています。交換されたメッセージの数は、レプリカの数とともに2次に増加します。 Nノードを備えたシステムの場合、各フェーズにはO（n²）メッセージの複雑さが必要であり、ネットワークが拡大するにつれて非現実的になります。これにより、PBFTは、通常100未満のノード数から中程度のノード数を持つネットワークに制限されます。

もう1つの課題は、静的メンバーシップの仮定です。PBFTは、既知のレプリカの固定セットを想定しています。ノードの動的な追加または除去には、ネイティブにサポートされていない複雑な再構成プロトコルが必要です。さらに、集中型プライマリに依存すると、潜在的なボトルネックと単一の故障ポイントが導入されます。プライマリが悪意を持って動作するか、失敗した場合、システムはビュー変更プロトコルを開始して、ゆっくりとリソース集約型の新しいリーダーを選出します。

また、セキュリティは、3F+1ノードのシステムにF故障したノード以下が存在しないという仮定に依存します。このしきい値を超えると、システム全体の完全性が損なわれます。したがって、PBFTは、ノードのアイデンティティが審査および制御される許可ブロックチェーンに最適です。

実際のシステムにPBFTを実装します

プライベートブロックチェーンネットワークなどの実用的な環境でPBFTを展開するには、いくつかの構成手順が必要です。まず、参加しているノードのセットを定義し、一意の識別子を割り当てます。各ノードは、PBFTコンセンサスモジュールを実行し、ステートマシンのレプリカを維持する必要があります。

• Hyperledger FabricやApache BFT-Smartなどの互換性のあるフレームワークをインストールします。
• 共有構成ファイルでノードアドレスとパブリックキーを構成します。
• 1つのノードを最初のプライマリとして指定します。その他はバックアップとして機能します。
• リクエスト処理のバッチサイズとタイムアウト値を設定します。
• ロギングと監視を有効にして、プレペア前の追跡、準備、およびコミットします。
• リクエストを送信するクライアントインターフェイスを実装し、F+1応答を収集します。

すべてのノードが同期されていることを確認し、暗号化署名を使用してメッセージを認証します。ビューの変更を定期的に監視し、状態の遷移がレプリカ全体で一貫していることを検証します。パフォーマンスを維持するには、ネットワークの安定性と低遅延が重要です。

よくある質問

PBFTが機能するために必要なノードの最小数はいくらですか？

PBFTには、1つの故障したノードに耐えるために、少なくとも4つのノードが必要です。これは、f = 1の式3f+1から派生しています。 3つのノードを使用すると、単一の障害が3分の1のしきい値を超える可能性があり、コンセンサスが不可能になります。

PBFTは悪意のあるプライマリノードをどのように処理しますか？

プライマリが一貫性のない前準備メッセージを送信するか、行動しなかった場合、バックアップノードは矛盾を検出します。タイムアウトの後、彼らはビューの変更を開始し、新しいプライマリに切り替えるためのメッセージを放送します。 2F+1ノードが変更に同意すると、ラインの次のノードが新しいプライマリになります。

PBFTはパブリックブロックチェーンで使用できますか？

PBFTは、一般に、既知の認証されたノードの要件が高いため、一般的に公共のブロックチェーンには適していません。何千人もの参加者がいるパブリックネットワークは、スケーラビリティと潜伏期の問題に苦しむでしょう。主に許可またはコンソーシアムブロックチェーンで使用されます。

ノードの3分の1以上が故障した場合はどうなりますか？

故障したノードの数が3F+1システムでFを超える場合、コンセンサスはもはや保証できません。システムは、進行状況を停止する（livenives違反）または一貫性のない状態に到達する（安全性に違反する）、潜在的なフォークまたはデータの腐敗につながる可能性があります。