初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
ERCについてひたすらまとめたり、スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！
https://twitter.com/cardene777
https://chaldene.net/
https://qiita.com/cardene
https://zenn.dev/heku
https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58
https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4
また、これからも情報を見逃したくないという方はぜひ以下の購読ボタンを教えてください。
更新があった時、登録しているメールアドレス宛に通知が飛ぶようになります。
今回はXRP LEDGERについての第4回の記事になります。
第1回~第3回の記事は以下になります。
https://cardene.substack.com/p/xrp-ledger-introduction
https://cardene.substack.com/p/xrp-ledger-usecase
https://cardene.substack.com/p/xrp-ledger-concept-network
XRP LEDGERのコンセプトの1つである「コンセンサスプロトコル」についてまとめていきます。
この記事は以下の公式ドキュメントを参考にまとめていきます。
https://xrpl.org/docs/concepts/
コンセンサスプロトコル
コンセンサス
分散型システムでは、管理者という存在がいないため定められた一連のルールに従う必要があり、一連の処理の流れと結果についていつでも合意することができます。
これをコンセンサスプロトコルと言います。
コンセンサスプロトコルの特性
XRP Ledgerのコンセンサスプロトコルには、従来のデジタル資産や他のブロックチェーン技術とは異なるいくつかの特性があります。
全ユーザの合意
XRP Ledgerを使用する全てのユーザは、最新の台帳（Ledger）やトランザクションの順番について合意することができます。
これにより、ネットワーク全体でのデータの一貫性と正確性が保証されます。
中央オペレーター不要
XRP Ledgerは中央集権的な管理者を必要とせず、各ノードが独立してトランザクションを検証し合意形成に参加します。
これにより、単一障害点（システム全体の障害が一箇所の故障に依存すること）がなく、より高い耐障害性を持っています。
堅牢性
ネットワークの一部の参加者が不正行為を行ったり、ネットワークから離れたりしても、トランザクションの処理は継続されます。
ネットワークの停止
多数の参加者がアクセスできなくなったり、不正行為を行う場合、XRP Ledgerは不正なトランザクションを分離・確認する代わりに処理を一時停止します。
これは、誤った情報がブロックチェーンに記録されるのを防ぐための安全策です。
リソースの有効活用
XRP Ledgerは、トランザクションの確認において、他のブロックチェーンシステムとは異なり、大量の計算リソースを必要としません。
これにより、エネルギー消費を抑えることができます。
これらの特性は、次の三つの原則に基づいています。
正確さ
トランザクションデータの正確性が最も重視されます。
合意
ネットワークの全参加者がトランザクション内容について合意する必要があります。
処理の継続
ネットワークの運用を継続的に行うために、参加者の撤退や不正行為があってもシステムが停止することなく処理を続けることが求められます。
レジャーバージョン
XRP Ledgerでは、トランザクション履歴の記録と管理に「レジャーバージョン」（略して「レジャー」）というブロックを使用しています。
レジャーの構成要素
XRP Ledgerの各レジャーバージョンには主に三つの部分が含まれています。
現在の状態
レジャーに保存されているすべての残高やオブジェクト（アカウント、トークンなど）の最新の状態が含まれます。
この情報によって、システム全体の正確な現在の財務状況が把握されます。
取引履歴
このレジャーに至るまでに適用されたトランザクションの一連が記録されています。
これにより、どのアカウントがどのトランザクションを行ったか、そしてその結果としてどのような状態変更があったかが追跡できます。
メタデータ
レジャーインデックス（各レジャーに割り当てられた一意の番号）、レジャーの内容を一意に識別する暗号化ハッシュ、そして親レジャーに関する情報などが含まれます。
これにより、レジャー間の連続性が保たれ、任意の時点でのデータの整合性を確認できます。
レジャーインデックスとジェネシスレジャー
各レジャーは、直前のレジャーを基にして作成されます。
これはインデックス番号を通じて、ジェネシスレジャー（初期状態のレジャー、インデックス番号1）から連続しています。
XRP Ledgerでは、このジェネシスレジャーがすべての取引の起点となります。
コンセンサスプロトコルとレジャーの更新
XRP Ledgerのコンセンサスプロトコルは、新たな取引が前のレジャーにどのように適用されるかを決定し、それらの取引を明確に定義された順序で実行することで、全参加者が同じ結果を得ることを保証します。
このプロセスが完了すると、そのレジャーバージョンは「検証済み」と見なされ、次のレジャーバージョンの構築が始まります。
信頼に基づく検証
XRP Ledgerのコンセンサスメカニズムは、信頼と検証のプロセスに重きを置いて設計されており、ネットワーク全体の誠実さと堅牢性を保証するための独特の方法を採用しています。
バリデータとユニークノードリスト（UNL）
バリデータの選択
ネットワークの各参加者は、一連のバリデータを選択します。
これらのバリデータはネットワーク内で取引を検証し、コンセンサス形成に参加するために特別に設定されたサーバーです。
バリデータは信頼されるべき当事者によって運営され、常に誠実に行動することが期待されます。
ユニークノードリスト（UNL）
各参加者が選択するバリデータの集合は、ユニークノードリストと呼ばれます。
UNLは、その参加者が信頼するバリデータのリストであり、これらのバリデータがコンセンサスプロセスにおいて重要な役割を担います。
コンセンサスプロセス
コンセンサスの達成
各サーバーは、自分のUNLに含まれるバリデータからの情報を監視します。
十分な数のバリデータ（通常、信頼できるバリデータの80%以上）が特定の取引の結果に同意した場合、そのレジャーの結果は確定され、コンセンサスが宣言されます。
修正と再試行
バリデータ間で意見の不一致がある場合、バリデータは他の信頼するバリデータと協力して提案を修正し、再び合意を試みます。
このプロセスは、コンセンサスに達するまで繰り返されます。
課題と攻撃への対応
バリデータの行動
ネットワーク内のバリデータが全て誠実に行動するわけではありませんが、信頼できるバリデータのうち20%未満が不正行為をしている限り、ネットワークは正常に機能し続けます。
これは、大部分のバリデータが正しく機能していれば、少数の不誠実な行動がシステム全体に致命的な影響を与えることはないという設計に基づいています。
停止のシナリオ
信頼できるバリデータのうち20%以上が不正行動を取ると、ネットワークは一時的に停止します。
コンセンサス
XRP Ledgerはピアツーピア型の分散ネットワークであり、共有されたレジャー（台帳）を通じて世界中のユーザーが信頼できる情報にアクセスできる仕組みです。
このレジャーは各種の重要なデータを保持し、定期的に更新されます。
レジャーに含まれる主要な情報
アカウントの設定
各ユーザーアカウントの設定が記録されます。
XRPおよびトークンの残高
各アカウントのXRPとその他のトークンの残高が記録されます。
分散型取引所のオファー
取引所でのトランザクションオファーが記録され、実行待ちまたは実行された状態を反映します。
ネットワーク設定
トランザクションコストや準備金の金額など、ネットワーク全体の設定が含まれます。
タイムスタンプ
各レジャーバージョンには生成された日時のタイムスタンプが記録されます。
レジャーインデックスとレジャーハッシュ
各レジャーバージョンは一意の番号（レジャーインデックス）と、その内容のデジタルフィンガープリントとなるハッシュ値（レジャーハッシュ）で識別されます。
レジャーの更新と検証プロセス
XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。
各レジャーバージョンは、前のレジャーから引き継がれた取引と、新たに提案された取引が含まれます。
レジャーの内容にネットワークの参加者が合意すると、そのレジャーバージョンは検証済みとなり、内容が不変となります。
これにより、過去の全てのレジャーバージョンとそのトランザクションの履歴が形成され、ネットワークの透明性と監査性が保たれます。
トランザクションの承認とレジャーへの適用
各トランザクションはアカウント所有者によって暗号署名され、レジャーに反映される前にネットワークによって検証されます。
成功したトランザクションはtesSUCCESSという結果コードを持ち、レジャーにその変更が反映されます。
一方、失敗したトランザクションはtecクラスの結果コードが付与され、レジャーには影響を与えません。
他にterクラス、tefクラス、temクラスというコードがありますが、これはAPIの呼び出しによって返された暫定的な失敗を示します。
トランザクションコスト
XRP Ledgerでのトランザクション実行にはコスト（手数料）が伴い、この手数料はXRPで支払われ、その一部がburnされます。
これにより、ネットワークはスパムトランザクションを防ぐことができます。
APIと検証済みトランザクション
rippled APIを使用するときは、検証済みレジャーに含まれるトランザクションと候補トランザクションを区別する必要があります。
候補トランザクションはまだ最終確定されていないため、暫定的な結果が返されることがあります。
そのため、トランザクションの最終的な結果を知るには、それが検証済みのレジャーに含まれ、tesSUCCESSという結果コードが付与されるまで待つ必要があります。
コンセンサスと検証
XRP Ledgerのプロトコルは、ピアツーピアネットワークを通じてトランザクションを処理するための機構を持っています。
XRP Ledgerのプロトコル構造
トランザクションの提出と受信
クライアントアプリケーション（モバイルやウェブウォレット、金融機関のゲートウェイなど）は、トランザクションに署名してrippledサーバに送信します。
サーバはこれらを受け取り、ネットワーク内で中継して他のサーバへと伝えます。
追跡サーバとバリデータ
サーバは大きく分けて、トランザクションを分散しレジャーに関する問い合わせに応答する「追跡サーバ」と、追跡機能に加えてレジャーバージョンを進行させる「バリデータ」があります。
バリデータはコンセンサスプロセスに積極的に参加し、新しいレジャーの検証に関与します。
コンセンサスプロセス
候補トランザクションの共有
サーバ間でトランザクションが中継されることにより、ネットワーク全体で共有されます。
各サーバは候補トランザクションについて他のサーバと情報を交換し、次のレジャーで考慮するトランザクションのセットについて合意を試みます。
反復的合意形成
サーバは提案されたトランザクションセットについて、ユニークノードリスト（UNL）に含まれる信頼できるバリデータの意見を参考にしながら、合意に至るまで反復的に提案を更新します。
このプロセスは、必要に応じて複数回繰り返されることがあります。
検証のプロセス
レジャーの計算
コンセンサスプロセスが完了すると、各サーバは合意されたトランザクションセットを用いて新しいレジャーバージョンを個別に計算します。
この計算は、前の検証済みレジャーから始めて、トランザクションを正規順序（トランザクションを受け取った順序ではない）で適用することによって行われます。
結果の共有と比較
各バリデータは計算結果を含む署名付きメッセージをネットワークに送信します。
これにより、各サーバは自身の計算したレジャーを他のサーバの結果と比較でき、大多数のバリデータが同じ結果に署名している場合にそのレジャーを検証済みと認定します。
トランザクションの扱い
成功と失敗
合意に達したトランザクションは新しいレジャーに適用され、その結果が検証済みのレジャーとして記録されます。
失敗したトランザクションは次の機会に再び検討される可能性があります。
再試行と手数料
特定のトランザクションが成功しない場合、手数料の設定やネットワークの状況に応じて再試行されることがあります。
トランザクションの有効期限が設定されている場合、その期限内に処理されなければ失効します。
XRP Ledgerのプロトコルは、トランザクションの提出から検証までを包括的に管理し、ネットワークの透明性と信頼性を保証するための複雑なプロセスを実施しています。
コンセンサスの原理とルール
XRP Ledgerでのトランザクションのライフサイクルは、トランザクションの作成から検証済みのレジャーへの反映まで、複数の重要な段階を経ています。
このプロセスは、以下のステップで構成されます。
1. トランザクションの作成と送信
トランザクションの作成
アカウント所有者はトランザクションを作成し、デジタル署名を行います。
トランザクションの送信
署名されたトランザクションはXRP Ledgerネットワークに送信されます。
2. トランザクションの検証と受け入れ
形式の検証
送信されたトランザクションは形式が正しいかどうか検証されます。
不適切な形式のトランザクションはその場で拒否されます。
暫定的な成功または失敗
書式が正しいトランザクションは暫定的に成功する可能性がありますが、後に失敗することもありますし、逆のケースも考えられます。
3. コンセンサスプロセス
コンセンサスの間のトランザクション処理
候補トランザクションはコンセンサスプロセスの間、レジャーに含まれるかどうかを決定するために評価されます。
コンセンサスの成立と失敗
コンセンサスラウンドが成功すれば、そのレジャーは有効とされ、トランザクションは検証済みのレジャーに含まれます。
失敗した場合は、成功するまでコンセンサスプロセスが繰り返されます。
4. 検証済みレジャー
検証済みレジャーの確認
最終的に検証済みのレジャーに含まれるトランザクションは、その結果がレジャーの状態に反映されます。
5. アプリケーションでの取り扱い
検証済み情報の利用
アプリケーションは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼するべきです。
ベストプラクティス
LastLedgerSequenceの使用
このパラメータを設定することで、トランザクションが迅速かつ確定的に検証されるか、失敗するようにします。
トランザクションの結果の確認
検証されたレジャーでトランザクションの結果を確認し、LastLedgerSequenceを超えた場合はそのトランザクションが失敗したと見なします。
結果コードの確認
tesSUCCESSで"validated": trueの場合は恒久的に成功、それ以外で"validated": trueの場合は恒久的に失敗となります。
トランザクションのライフサイクルは、ネットワークの整合性とセキュリティを保ちながら効率的なトランザクション処理を可能にするために設計されています。
XRP Ledgerのコンセンサスメカニズム
トランザクションの共有
トランザクションはXRP Ledgerネットワークを介してすべてのサーバ（ノード）にブロードキャストされます。
これにより、ネットワークの各参加者が提出されたトランザクションを知ることができ、それに基づいて行動を取ることが可能になります。
トランザクションの検証
送信されたトランザクションは、形式的な正しさ、合法性、実行可能性を確認するために各サーバによって独立して検証されます。
これにより、不正または無効なトランザクションを事前にフィルタリングします。
コンセンサスプロセス
XRP Ledgerの核心となるのがコンセンサスプロセスです。
これは、すべての有効なトランザクションについてネットワーク内のサーバが合意に達するためのプロセスです。
コンセンサスに成功すると、トランザクションはレジャーに記録され、以降変更不可能となります。
レジャーの更新
コンセンサスプロセスが完了すると、新しいレジャーが生成され、これには合意されたトランザクションが含まれます。
このレジャーはネットワーク上のすべてのサーバに配布され、全ノードが同一のレジャー状態を保持することが保証されます。
二重支払いの防止
XRP Ledgerは、トランザクションが全ノードにブロードキャストされるため、同一の資金が複数回支払われる（二重支払い）を防ぎます。
一度トランザクションがレジャーに含まれ、その情報がネットワーク全体に共有されると、そのトランザクションによって動かされた資金は別のトランザクションで使用されなくなります。
また、コンセンサスプロセス中に、同一の資金に対する複数の支払い命令が存在する場合、これらのトランザクションは競合すると見なされ、ネットワークはどちらか一方のトランザクションを有効とすることにより合意に達します。
通常、どちらのトランザクションが先にネットワークに受け入れられるかに基づいて決定されます。
そのため、一度トランザクションが確定されると、その結果はすべてのノードで一貫しており、二重支払いのリスクを排除します。
コンセンサスの仕組み
XRP Ledgerのコンセンサスメカニズムは、二重支払い問題を解決するために設計されたプロセスです。
このプロセスは、トランザクションを効率的に処理し、全参加者が同意する確定的なレジャー状態を作成することを目的としています。
コンセンサスプロセスの概要
トランザクションの集約と初期の検証
各参加者（ノード）は送信されたトランザクションを集め、形式的な検証を行います。
有効と判断されたトランザクションは候補リストに追加されます。
トランザクションのソートとグループ化
トランザクションは確定的なルール（たとえばタイムスタンプや取引額など）に基づいてソートされます。
これにより、どのトランザクションが先に処理されるべきかが決定され、二重支払いの問題を防ぎます。
このとき、すべてのトランザクションをソートするのは非現実的であるため、グループにまとめてソートします。
コンセンサスの形成
各ノードは、他のノードとコミュニケーションを取りながら、候補トランザクションリストについての合意を試みます。
合意が形成されたトランザクションセットは、次のレジャー更新に使用されます。
レジャーの更新
合意に達したトランザクションは、XRP Ledgerに記録され、新しいレジャー状態が生成されます。
この新しいレジャーは全ノードに配布され、全体のレジャーの整合性が保たれます。
コンセンサスの利点と課題
透明性と分散化
XRP Ledgerは中央集権的な管理者がいないため、トランザクションの承認権限が分散され、透明性が保たれます。
各参加者は独立してトランザクションを検証し、全体の合意に貢献します。
スケーラビリティと速度
コンセンサスプロセスは数秒で完了するため、XRP Ledgerはリアルタイムに近いトランザクション処理が可能です。
これにより、国際的な送金や資産交換が迅速に行われます。
合意形成の課題
全参加者が同時に同じ情報を持たない場合、合意形成は遅れることがあります。
ネットワークの遅延や参加者間の不一致が発生した場合、コンセンサス達成に時間がかかることがあります。
コンセンサスルール
コンセンサスの主な役割は、参加者が二重支払いを防ぐためにグループ単位で処理するトランザクションについて合意形成できるようにすることです。
この合意形成は、以下の理由から容易です。
特に理由がなければ、全員がトランザクションの含有に合意する。
除外すべき理由があれば、全員が除外を希望する。
次のラウンドに問題がなければ含めることに合意する。トランザクションのグループ化に関心を示すことは極めてまれで、全員が最優先と認識すれば合意は容易になる。
確定的なルールでグループ編成でき、エッジケースのみ不合意となる。
参加者は正確さを最も重視し、レジャーの整合性のためにルールを適用する必要がありますが、二重支払い防止のために合意形成も重視します。
正確さの次に合意を重視することが、合意形成を促進します。
コンセンサスラウンド
XRP Ledgerのコンセンサスラウンドでは、参加者がトランザクションのグループについて合意形成を行い、トランザクションを処理します。
まず各参加者が有効と考えるトランザクションセットを表明し、次に参加者の見解を寄せ合わせていきます。
特定のトランザクションが過半数の支持を得られない場合は保留に、過半数の支持を得られる場合は追加に合意します。
ただし、合意形成の行き詰まりを防ぎ、必要な重複を減らすため、トランザクション追加に必要な支持のしきい値は時間とともに上昇します。
最初は50%ですが、合意しない場合は60%に上がり、その後はトランザクションが除外されるまで上昇し続けます。
除外されたトランザクションは次のレジャーバージョンに持ち越されます。
圧倒的多数が次に処理するトランザクションセットに合意し、参加者がこれを確認するとコンセンサスに達したと宣言します。
コンセンサス失敗の可能性
コンセンサスアルゴリズムで完全なコンセンサスの達成に失敗しない仕組みを作ることは非現実的です。
なぜなら、コンセンサスプロセスを完了するには、参加者の誰かが「コンセンサスに達した」と最初に宣言する必要がありますが、その時点では他の参加者がまだ合意に達していない可能性があるためです。
例えば、グループで部屋のどのドアから外に出るか合意する場合、いくら話し合っても誰かが最初にドアから出なければなりません。
その後に続く人が考えを変えて別のドアから出ることができるとしてもです。
このようなコンセンサス失敗の確率をゼロにはできませんが、低く抑えることはできます。
ただし、失敗確率を極端に下げようとすると、コンセンサスに時間がかかりすぎたり、ネットワーク障害への耐性が下がったりするトレードオフが生じます。
コンセンサス失敗の処理
XRP Ledgerでは、コンセンサスラウンドが完了すると、参加者は合意したトランザクションセットを適用して次のレジャーを生成します。
バリデータは次のレジャーの暗号フィンガープリント（検証投票）を公開し、参加者はこれを収集してコンセンサスの結果を確認します。
参加者には主に3つのケースがあります。
多数派と同じレジャーを構築した場合（最も一般的）。
多数派と異なるレジャーを構築した場合（多数派のレジャーに「ジャンプ」する必要あり）。
多数派が不明確な場合（コンセンサスラウンドが無駄になり、新しいラウンドが必要）。
ケース2では、参加者は多数派との合意に達するまで結果を最終結果として報告してはいけません。
ケース3ではネットワークが一時的に遅延しますが、次のラウンドで失敗する可能性は大幅に下がります。
まれにネットワーク全体が一時的に処理を進められなくなることがありますが、その代わりにトランザクションの平均確認時間は短くなります。
XRP Ledgerのコンセンサスプロセスは、非常に効率的で信頼性が高く、世界中でリアルタイムのトランザクション処理を可能にしています。
しかし、時には合意形成に失敗することもあり、その際には迅速な対応と適切なプロトコルに従って問題を解決します。
このプロセスにより、中央機関が不在であっても、安全かつ迅速に取引が行えるようになっています。
XRP Ledgerのコンセンサスメカニズムは、効率的で信頼性の高いグローバル決済システムを提供することを目的としています。
このシステムは、従来の金融システムに匹敵する、あるいはそれを超える性能を持つことを目指しています。
攻撃および障害モードに対するコンセンサスの保護
XRP Ledgerのコンセンサスプロトコルは、ビザンチンフォールトトレランス（BFT）の特性を持っており、これによって参加者間での不正行為や通信障害があってもシステムが正常に機能し続けることが保証されます。
このような耐障害性は、ネットワークの参加者が不定かつ変化する可能性があるオープンネットワーク環境において特に重要です。
個々のバリデータの不適切な動作への対応
不適切な動作のケース
使用できないかまたは過負荷状態。
ネットワークから部分的に切断されており、一部の参加者にしか遅延なしで届かない。
他のサーバを欺くかまたはネットワークを停止する目的で意図的に動作。
外部要因からの不正動作。
バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが送信。
バリデータの耐障害性
XRP Ledgerは、一部のバリデータが機能しなくなったり、不正を働いたりしてもコンセンサスプロセスを維持できるように設計されています。
信頼できるバリデータの約20%未満が不適切に動作している場合でも、ネットワークは効果的に機能を続けることが可能です。
ネットワークの分断への耐性
バリデータがネットワークの一部からのみアクセス可能な場合（部分的なネットワーク分断）、その影響を受けるのはそのバリデータに直接依存しているサーバーに限られます。
全体のネットワークの安定性や整合性には影響しません。
悪意のある行動または外部圧力への対応
どのバリデータも、XRP Ledgerのネットワーク全体に対する一方的な影響力を持たず、他の多くのバリデータの検証を通じてその動作がチェックされます。
また、不正な行動を取るバリデータはネットワークから除外される可能性があります。
ソフトウェアの脆弱性への対策
オープンソースの透明性
XRP Ledgerのコードベースはオープンソースであり、誰でもコードのレビューや監査が可能です。
これにより、ソフトウェアの脆弱性が発見されやすくなり、改善のための貢献も受け入れやすくなっています。
堅牢なコードレビュープロセス
新しいコード変更は厳格なレビューを経て承認されるため、潜在的なバグやセキュリティリスクを事前に除去する機会が増えます。
バグ報奨金プログラム
セキュリティ研究者が脆弱性を責任を持って報告することを奨励するためのバグ報奨金プログラムが設けられています。
これにより、攻撃者が悪用する前に脆弱性を修正できる可能性が高まります。
シビル攻撃に対する防御
シビル攻撃は、攻撃者が多数の偽のアイデンティティを作成し、ネットワークの意思決定プロセスを乗っ取ることを試みる攻撃です。
XRP Ledgerでは、シビル攻撃への耐性が以下のように確保されています。
バリデータの信頼構築
バリデータは、その信頼性を示すために時間とともに評価される必要があります。
新しいバリデータが信頼されるには、長期間にわたり安定して信頼できる行動を示す必要があります。
これにより、偽のバリデータが短期間でネットワークに影響を与えることが困難になります。
ユニークノードリスト（UNL）
各XRP Ledgerサーバーは、信頼できるバリデータのリスト（UNL）を持っています。
これにより、サーバーは特定のバリデータのみを信頼し、未知のバリデータからの不正な影響を無視することができます。
51%攻撃に対する防御
51%攻撃は、ネットワークの過半数の計算力または投票力を支配することにより、トランザクションの改変やブロックの書き換えを行う攻撃です。
XRP Ledgerでは、以下のように51%攻撃への耐性が確保されています。
コンセンサスベースのアプローチ
XRP Ledgerは採掘を基盤としたブロックチェーン技術を使用しておらず、代わりにコンセンサスプロトコルに依存しています。
これにより、計算力ではなく、相互信頼と検証に基づいた意思決定が行われます。
多様なバリデータ
XRP LedgerのUNLは、さまざまな地域や組織から選ばれたバリデータによって構成されています。
これにより、単一の組織や個人が過半数のバリデータをコントロールすることが困難になります。
バリデータ重複要件
XRP Ledgerでは、すべての参加者が検証済みとみなす内容について合意するために、各参加者は似たような信頼できるバリデータ群を選択することが重要です。
XRP LedgerサーバはXRPL財団やRippleが運用するバリデータリストサイト内の推奨されるバリデータリストは、各サーバが同じバリデータを信頼し、ネットワーク全体の整合性を保つのに役立ちます。
このプロセスは、次のように機能します。
リストの署名と検証
推奨バリデータリストはデジタル署名され、公開されます。
これにより、リストの内容が改ざんされることなく、信頼できるソースからのものであることが保証されます。
デフォルトリストの更新
XRP Ledgerサーバは定期的にリストを更新し、バリデータの変更や新たな信頼情報を反映します。
これにより、ネットワークの安定性とセキュリティが維持されます。
XRP Ledgerのコンセンサスプロトコルは、これらの複雑な攻撃や障害モードに対して高い耐性を持ちながら、効率的かつ透明な方法でトランザクションを処理し、全体のネットワーク整合性を保持するよう設計されています。
不変性チェック
XRP Ledgerにおける不変性チェックは、レジャーの整合性と信頼性を保証するための重要なセーフガードです。
不変性チェックの目的
コードの実行エラーの防止
XRP Ledgerのコードベースは複雑で、新しい機能の追加や既存のコードの修正が行われるたびに、予期しないエラーが発生する可能性があります。
不変性チェックは、これらのエラーがレジャーの整合性に影響を与える前に検出し、修正するための機会を提供します。
不正なトランザクションの阻止
不正または破損したトランザクションがレジャーに含まれると、全体のネットワークが不安定になり得ます。
不変性チェックは、これらのトランザクションがシステムに損害を与える前に拒否することで、ネットワークの安全を維持します。
ネットワークの信頼性の保持
XRP Ledgerの信頼性は、その正確さと安定性に大きく依存しています。
不変性チェックにより、トランザクションが厳格なルールに従って処理されることが保証され、ユーザーと開発者の信頼が維持されます。
不変性チェックの仕組み
不変性チェッカーは、トランザクションがレジャーにコミットされる前に動作します。
これはトランザクションの処理結果が以下の基準に従っているかどうかを検証するためです。
レジャーの総XRP供給量が一定であること。
アカウントの残高が負にならないこと。
トランザクションが他のレジャーの規則や制約に違反していないこと。
もしトランザクションがこれらのチェックを通過できない場合、システムは以下のいずれかの方法でそれを拒否します。
tecINVARIANT_FAILED
トランザクションは技術的には有効ですが、不変条件に違反しているため、何の効果もなくレジャーに含められます。
tefINVARIANT_FAILED
トランザクションが不変条件に違反するため、レジャーには一切含まれません。
有効な不変条件
トランザクション手数料チェック
トランザクションコストはマイナスにならず、指定されたコストを超えることができません。
このチェックは、ユーザーが意図した金額以上の手数料を誤って支払うことがないようにするためです。
また、手数料が負になることを防ぎ、システムの悪用を避けます。
XRPの生成や破棄
トランザクションはXRPを生成してはならず、手数料としてXRPを破棄するのみです。
XRPの総供給量は一定であるべきです
手数料による小さなXRPの破棄はインフレーションを防ぐ手段として設計されています。
アカウントの削除
アカウントはAccountDeleteトランザクションによってのみ削除可能です。
不適切な方法でのアカウント削除を防ぎ、ユーザーの資産を保護します。
XRPの残高確認
アカウントのXRP残高は常に0以上であり、許容される最大値を超えることはありません。
このチェックにより、不可能な残高（負の値や設定された上限を超える値）が存在しないことを確認します。
レジャーエントリの形式一致
すべてのレジャーエントリは、有効な形式とタイプでなければなりません。
レジャーの整合性を保持し、無効なデータ構造が導入されるのを防ぎます。
XRPのトラストライン
XRPはトラストラインを使用して作成できません。
XRPはレジャーに固有のアセットであり、トラストラインを必要とせずに動作します。
トラストラインとは、XRP Ledgerにおけるトークンを保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。
有効なトランザクションオファー
オファーは負でない金額でなければならず、XRP同士のトレードはできません。
負の値や不正なトレードペアを防ぎ、取引の透明性と公正性を保ちます。
有効なエスクロー
エスクローは0XRP以上の値を持つ必要があります。
無効なエスクロー取引を防ぎ、エスクローされた資金が有効であることを確認します。
手数料投票
XRP Ledgerにおける手数料投票プロセスは、バリデータがトランザクションコストとアカウントの必要準備金の変更について投票する方法です。
このプロセスは、XRP Ledgerの動的で進化する性質を反映し、ネットワークが変化する市場環境や技術的要求に適応できるように設計されています。
手数料投票プロセス
1. 投票の送信
256番目ごとに発生するフラグレジャーの前のレジャーで、各バリデータは現行のネットワーク設定と異なる設定を持っている場合、その設定を示す投票を送信します。
2. 投票の集計
フラグレジャー時には何も起こりませんが、バリデータは他の信頼できるバリデータからの投票を受信して記録します。
3. 妥協と提案
フラグレジャーの直後のレジャーで、バリデータは集計した投票に基づいて、合意に達した新しい設定のためのSetFee疑似トランザクションを提案します。
4. 設定の採用
SetFee疑似トランザクションがコンセンサスプロセスを通過すると、新しいトランザクションコストと準備金の設定が次のレジャーから有効になります。
設定可能なパラメーター
reference_fee最も安価なトランザクションを送信する時に必要なXRPの量（drop単位）。
推奨される値は
10 drop（0.00001 XRP）
account_reserveアカウントの準備金に必要なXRPの最小額（drop単位）。
推奨される値は
10,000,000 drop（10 XRP）
owner_reserveアドレスがレジャーで所有するオブジェクトごとに必要なXRPの量（drop単位）。
推奨される値は
2,000,000 drop（2 XRP）
手数料の最大値
手数料の最大値はシステムの内部データ型によって制限されており、以下の通りです。
reference_fee2^64 drop（これは存在したXRP総額よりも大きい数値です。）
account_reserve2^32 drop（約4294 XRP）
owner_reserve
2^32 drop（約4294 XRP）
このプロセスは、XRP Ledgerが健全で適応性のあるネットワークであり続けるために不可欠です。
それにより、市場の変動やネットワークの成長に応じて手数料設定を柔軟に調整することが可能になります。
ネガティブUNL
ネガティブUNLはXRP Ledgerのコンセンサスプロトコルに導入された機能で、信頼できるバリデータの一部が一時的にオフラインになっても、ネットワークの運営を滞りなく維持するためのものです。
この機能により、信頼できるバリデータの少なくとも80%が合意することが通常のコンセンサスの条件ですが、ネガティブUNLを利用することで、一部のバリデータが利用できない状態でも、残りのバリデータの合意でレジャーの更新が可能になります。
ネガティブUNLの背景と目的
XRP Ledgerは、バリデータと呼ばれる特定のノードによって運営される分散型ネットワークです。
これらのバリデータは、新しいレジャー（台帳）バージョンのコンセンサス（合意形成）に参加します。
通常、新しいレジャーが検証されるためには、信頼できるバリデータの80%以上の合意が必要です。
しかし、バリデータがハードウェアのメンテナンス、ソフトウェアのアップデート、自然災害など様々な理由でオフラインになる場合があります。
これにより、ネットワークが新しいレジャーの検証に必要なバリデータの数を確保できず、取引の確定が停止する可能性があります。
ネガティブUNLは、このような状況を防ぐために設計されました。
ネガティブUNLの仕組み
ネガティブUNLの定義
ネガティブUNLは、現在オフラインまたは機能していないと考えられる信頼できるバリデータのリストです。
このリストに載っているバリデータは、コンセンサスの過程で無視されます。
ネガティブUNLの更新
バリデータが再びオンラインになり、一貫して有効な投票を行うようになった場合、ネガティブUNLから削除されます。
コンセンサスの調整
ネガティブUNLを使用することで、オンラインのバリデータだけでコンセンサスに達することができ、ネットワークは定足数を満たすために必要なバリデータの数を調整することができます。
ただし、全体のバリデータの60%以上が合意に必要とされるというハードリミットが設けられています。
ネガティブUNLの利点とリスク
利点
ネガティブUNLを活用することで、一時的なバリデータの不足がネットワークの動作を妨げることなく、トランザクションの処理とレジャーの更新を継続できます。
リスク
もし20%以上のバリデータが同時にオフラインになると、ネガティブUNLもネットワークの正常な機能を支持するのに十分ではない場合があります。
その場合、ネットワークは新しいレジャーを検証できず、処理が停止する可能性があります。
ネガティブUNLは、ネットワークの柔軟性を高め、一時的な問題が全体の機能に深刻な影響を与えるのを防ぐための重要な機能です。
これにより、XRP Ledgerはより堅牢で信頼性の高い分散型ネットワークとして機能することが可能になります。
ネガティブUNLの仕組み
ネガティブUNLは、信頼できるバリデータが一時的にオフラインや同期不良となった場合に、それらのバリデータを一時的にコンセンサスプロセスから除外することを可能にするリストです。
これにより、ネットワークは残りのオンラインのバリデータのみでコンセンサスを継続できます。
信頼性評価
バリデータの信頼性は、過去256レジャーにわたってそのバリデータがネットワークとどれだけ一致していたかに基づいて評価されます。
この評価は、バリデータが信頼できるかどうかを判断するための指標として使用されます。
信頼性が50%未満の場合、バリデータはネガティブUNLに追加される可能性があります。
80%以上の場合、ネガティブUNLから削除されることがあります。
変更プロセス
ネガティブUNLの変更は「フラグレジャー」でのみ行われます。
これは、レジャーインデックスが256の倍数である時に定義される特別なレジャーです。
フラグレジャーにおいて、バリデータはネガティブUNLの更新を提案し、これらの提案は次のフラグレジャーで適用される計画が立てられます。
バリデータがネガティブUNLに追加されると、そのバリデータの投票はコンセンサスプロセスにおいて一時的に無視されます。
バリデータがオンラインに戻り、一貫性がある投票を再開した場合、ネガティブUNLから削除されます。
このプロセスは、UNLModifyと呼ばれる疑似トランザクションを通じて行われ、これによりネットワーク全体でバリデータの状態に関する合意が形成されます。
ネガティブUNLの重要性
ネガティブUNLは、ネットワークの安定性とセキュリティを保つための重要な機能です。
これにより、バリデータの一部が予期せずに利用できなくなった場合でも、XRP Ledgerはトランザクションを正常に処理し続けることができます。
また、ネットワークが中央集権的な障害点に依存しないことを保証し、分散型の本質を強化します。
このシステムは、外部環境や突発的な問題が発生した時にも、ネットワークの継続的な運用を支援するために設計されています。
制限
ネガティブUNLの容量は、全UNLの25%までと制限されています。
これは、有効UNL（信頼できるバリデータのリストからネガティブUNLにリストされたバリデータを除いたもの）が、全体のバリデータの少なくとも60%を占めるようにするためです。
これにより、ネットワークが2つ以上のサブネットワークに分断されるのを防ぎます。
バリデータの選択
複数のバリデータがネガティブUNLへの追加候補となる場合、サーバは親レジャーのハッシュと各バリデータ候補の公開鍵との間で排他的論理和（XOR）を計算し、結果が最も小さいバリデータを提案します。
この手法は、すべてのサーバがアクセス可能な情報を用いているため、どのバリデータを追加または削除するかについての合意形成を容易にします。
検証のフィルタリング
有効UNLの計算
ネガティブUNLにリストされたバリデータは、レジャーの検証時に無視されます。
このため、各サーバは、有効UNLを使用して定足数を計算し、レジャーの検証を行います。
定足数は有効UNLの80%以上でなければなりませんが、全体のバリデータの60%以上である必要もあります。
この双方の条件を満たすために、ネガティブUNLは慎重に管理されます。
定足数の保持
ネガティブUNLの導入により、一部のバリデータが一時的に機能しなくなった場合でも、ネットワークが分断されずに済みます。
これは、残ったバリデータがコンセンサスに達しやすくなるためです。
総合的な影響
ネガティブUNLの導入により、XRP Ledgerはバリデータの一時的な停止や問題が発生しても、トランザクションの処理とレジャーの更新を継続できるようになります。
これは、ネットワークの安定性と信頼性を高め、分散型の性質を強化するために非常に重要です。
また、ネガティブUNLはサーバーが自己の信頼性を評価する際にも役立ち、ネットワーク全体の健全性を保つのに寄与します。
以下の公式のドキュメントに具体例が載っています。
https://xrpl.org/ja/docs/concepts/consensus-protocol/negative-unl/#%E4%BE%8B
最後に
今回はXRP LEDGERのコンセプトの1つである「コンセンサスプロトコル」についてまとめました。
これからも他のブロックチェーンやサービスについてもまとめていきます。
情報を見逃したくないという方はぜひ以下の購読ボタンを教えてください。
更新があった時、登録しているメールアドレス宛に通知が飛ぶようになります。
また、拡散もしてくれると嬉しいです🙇♂️