XRPL、バリデーターマニフェストの洪水を受け、ノード運用者にxrpld 3.2.1へのアップグレードを促す

見出し：「マニフェスト洪水」でネットワークリソースが逼迫、XRPLがノードの緊急アップグレードを要請リップルのエンジニアリングディレクター、ヴィジャイ・カナは8月2日、開発者が7月31日にバリデーターの「マニフェスト洪水」を検出したことから、XRP Ledgerノード運用者に直ちにxrpld v3.2.1をインストールするよう呼びかけた。この迅速なパッチは、未知のバリデーターIDからのマニフェストデータの処理、保存、共有を制限し、攻撃者がノードのメモリ、ストレージ、帯域幅、CPUを枯渇させるのを防ぎ、運用者がパッチを展開する間もレジャーの通常操作を維持する。発生した事象 - 7月31日、開発者は未知のIDからバリデーターマニフェストが急増したことを観測した。レジャーは通常通りクローズし続けたが、ノードリソースとピアツーピア通信に負荷がかかった。 - 資金の盗難、トランザクションの改ざん、コンセンサスの失敗に関する公的な証拠は存在しない。開発者はCVEを発行せず、この事象に関連する財務的損失の推定値も公表していない。 - XRPLオペレーションズは技術的なポストモーテムを実施すると述べており、8月2日現在、洪水の発信元、総量、具体的なリソースへの影響は未公表である。バリデーターマニフェストの重要性 - バリデーターマニフェストは、バリデーターの安定したマスターアイデンティティと日常的なバリデーションメッセージで使用される一時的なキーを暗号的に結びつける署名済みレコードである。運用者が一時的なキーをローテートする際、マスターキーで署名された新しいマニフェストを公開し、ピアが変更を検証できるようにする。 - パッチ適用前、xrpldは認識していないバリデーターキーの適切に構造化されたマニフェストを受け入れ、キャッシュし、再配信できた。攻撃者は多数の未知IDを作成し、ピアがそのデータ処理にメモリ、ストレージ、帯域幅、処理能力を浪費させるよう仕向けることが可能だった。コードリポジトリではこの問題を「マニフェスト伝播の悪用」と記述している。 xrpld 3.2.1の内容 - 公式xrpld 3.2.1リリース（7月31日付；8月1日早朝に署名・公開）は13ファイルにまたがる6つのコミットを含む。そのうち4つのコミットが信頼できないマニフェストの処理を直接制限する。主な保護機能： - ノードが完全にデコードする前に過剰なサイズのマニフェストを早期に拒否し、悪意のあるオブジェクトごとのCPU負荷を軽減。 - 単一ネットワークメッセージで許可される信頼できないマニフェスト数を制限（受信時およびピア向けメッセージ作成時に適用）。過剰なバッチは切断せずに破棄され、パッチ展開の互換性を容易にする。 - メモリにキャッシュされる未知バリデーターID数を100個に制限。上限に達すると、新規未登録マニフェストは拒否されるが、信頼済みおよび記憶済みバリデーターは引き続き処理される。 - 信頼できないマニフェスト情報の保持とゴシップ伝播方法を変更し、設定済み/信頼されたバリデーターではなく未登録ピアのゴシップに焦点を当てる。これにより正当なバリデーターキーローテーションを維持しつつ、キャッシュの無制限な増加をブロックする。運用者向けガイドラインと展開ノート - カナはバリデーターおよびインフラ運用者に対し、「できるだけ早く」v3.2.1へのアップグレードを推奨した。推奨プロセス：通常のソフトウェア更新を実行し、xrpldが正常に動作していることを1〜2分待ってからサービスを再起動する。2回目の再起動により、パッチ適用前にメモリに保持されていた未知マニフェストをクリアするのに役立つ。 - 運用者はシステムがリップルの現在のGPGパッケージ署名キーを信頼していることを確認すべきである。リップルは2月18日にそのキーをローテートしており、新しいキーを信頼していないノードは自動アップグレードを受け取れない可能性がある。 - この更新はインフラ運用者（取引所、キューディアン、ウォレットバックエンド、データプロバイダー、XRPLサーバーを稼働させる企業）向けである。一般のXRP保有者は資金移動やキーのローテーション、何らかのアクションを必要としない。背景と今後のステップ - このパッチはより広範なxrpld v3.2.0の展開（6月15日）に続くものであり、v3.2.0では参照サーバー名がrippledからxrpldに変更され、運用者が設定を更新する必要があった。バリデーター間でのv3.2.0採用は広範なノードネットワークよりも速かったが、今回のマニフェスト洪水は残る運用者に3.2.1への移行を促す強力な理由となった。 - XRPLオペレーションズは技術的なポストモーテムを公表すると約束しており、その報告書では活動が最初に検出された時期、ノードが利用不能になったか否か、マニフェストの総量、および運用者がパッチをどれほど迅速に適用したかが詳細に記載される予定である。その報告書が公開されるまで、確認済みの情報は3.2.1の修正内容とアップグレード・再起動要請に限定されている。結論 XRPLインフラを運用している場合、これは緊急事態と捉えよ：xrpld 3.2.1へアップグレードし、推奨される2段階再起動手順を実行してメモリに残留した信頼できないマニフェストをクリアせよ。広範なXRPLコミュニティにとって、この事象はプロトコル自体の侵害ではなくリソース枯渇試みであったように見えるが、今後のポストモーテムがその範囲を完全に確認するために重要である。