xrpl-dev-portal/content/concepts/consensus-protocol/consensus-protections.ja.md

html, parent, blurb, labels

html	parent	blurb	labels
consensus-protections.html	consensus.html	Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system.	ブロックチェーン

攻撃および障害モードに対するコンセンサスの保護

XRP Ledgerコンセンサスプロトコルは、 ビザンチンフォールトトレラント性 のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。

ネットワークに求められる特性を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。

このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。

個々のバリデータの不適切な動作

バリデータ とは、新しいレジャーバージョンの決定プロセスにアクティブに参加するサーバーです。バリデータは、そのバリデータを信用するように設定されているサーバーにのみ影響を与えます（間接的な影響を含む）。一部バリデータの動作が不適切であってもコンセンサスを継続できます。このような不適切な動作には、以下のさまざまなケースがあります。

• 使用できないかまたは過負荷状態である。
• ネットワークから部分的に切断されており、メッセージが遅延なしで届くのは一部の参加者に限られる。
• 他のサーバーを欺くかまたはネットワークを停止する目的で意図的に動作している。
• 外部要因（抑圧的な政府からの脅威など）からのプレッシャーによって不正に動作している。
• バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが偶発的に送信される。

一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新のコンセンサスに関する研究を参照してください。）

バリデータの約20%以上がアクセス不能であるか適切に動作していない場合、ネットワークはコンセンサスに達することができません。この間、新しいトランザクションを暫定的に処理できますが、新しいレジャーバージョンを検証できないため、これらのトランザクションの最終結果は未確定になります。このような状況では、XRP Ledgerが正常ではないことがただちに明らかになるため、待機するか、または信頼できるバリデータのセットを再設定するかを決定できる参加者からの人的介入が促されます。

無効なトランザクションを承認する唯一の方法は、80%以上の信頼できるバリデータがそのトランザクションを承認し、その結果に合意することです。（無効なトランザクションには、すでに使用された資金を送金するトランザクションや、ネットワークのルールに違反するトランザクションなどがあります。）つまり、信頼できるバリデータの過半数が 共謀する 必要があります。多数の信頼できるバリデータが世界各地域で異なる人々や企業により運用されている状況では、意図的にこれを達成することは非常に困難です。

ソフトウェアの脆弱性

あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバーをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。Rippleではこのような脅威に対処するため、次のようなさまざまな対策を導入しています。

• オープンソースコードベース。これにより、一般のユーザーが関連ソフトウェアをレビュー、コンパイルし、個別にテストできます。
• 公式XRP Ledgerリポジトリのあらゆる変更のための綿密で堅固なコードレビュープロセス。
• すべてのリリースと公式ソフトウェアパッケージへのRipple社員によるデジタル署名付与。
• セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
• 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与するBug Bountyプログラム。

シビル攻撃

シビル攻撃 とは、大量の偽IDを使ってネットワークのコントロールを試みる攻撃です。XRP Ledgerでは、シビル攻撃は多数のバリデータを操作して、他のバリデータにこれらのバリデータを信頼するように仕向ける形で攻撃をしかける可能性があります。このような攻撃は理論上は可能ですが、バリデータが信頼を得るには人間による介入が必要であるため、実際には非常に困難です。

攻撃者が操作する検証サーバーの数に関係なく、既存の参加者が攻撃者のバリデータを信頼しない限りは、これらの参加者が何を検証済みと判断するかについて、このようなサーバーが影響を及ぼすことはできません。その他のサーバーは、バリデータリストまたは明示的な設定によって信頼できると設定されたバリデータのみを信頼します。（デフォルトのバリデータリストの仕組みの概要については、バリデータ重複要件を参照してください。）

この信頼は自動的に形成されるものではありません。したがってシビル攻撃を成功させるには、ターゲットとなる人物や企業が、攻撃者のバリデータを信頼してXRP Ledgerサーバーを再設定するように仕向けるという難しい作業をこなさなければなりません。ある人物または企業がだまされてXRP Ledgerサーバーを再設定したとしても、自らの設定を変更していない他の人物や企業に対する影響は最小限となります。

51%攻撃

「51%攻撃」とは、特定の当事者が全採掘能力または投票能力の50%を超える割合を支配しているブロックチェーンに対する攻撃です。（厳密には、50%を わずかでも 超えていれば十分であるため、この攻撃の名前は多少間違っています。）XRP Ledgerは、コンセンサスメカニズムに採掘を採用していないため、51%攻撃に対し脆弱ではありません。これに最も類似するXRP Ledgerへの攻撃にはシビル攻撃がありますが、この攻撃を実際に実施することは困難です。

バリデータ重複要件

XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。このため、Rippleは推奨バリデータの署名付きリストを公開しています。このリストには、企業や業界、コミュニティが運用する信頼性が高く適切に管理されたサーバーが含まれます。

デフォルトでは、XRP LedgerサーバーはRippleが運用するバリデータリストサイトを使用するように設定されています。このサイトでは、Rippleが定期的に更新する推奨バリデータリスト（推奨 ユニークノードリスト （UNL））が公開されています。このように設定されているサーバーは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバーと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバー間でリストに対する署名済みの更新を直接中継できます。

技術的には、サーバーを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバーとの重複が十分ではない場合、サーバーはネットワークの他の部分と不一致になる可能性があり、サーバーが不一致の状態でアクションを実行すると資金を失う可能性があります。

コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、コンセンサスの研究ページを参照してください。

関連項目

• コンセンサスの入門レベルの概要については、コンセンサスについてを参照してください。
• コンセンサスプロトコルの詳細な説明については、コンセンサスを参照してください。
• コンセンサスプロトコルの設計に関する決定と背景については、コンセンサスの原理とルールを参照してください。
• コンセンサスプロトコルの特性と制約に関する学術研究については、コンセンサスの研究を参照してください。