XRP Ledgerは、2026年7月31日にネットワークのピアツーピアインフラストラクチャの一部に負荷をかけたバリデーターマニフェストのフラッディングを阻止することを目的とした本番環境用ホットフィックス「xrpldバージョン3.2.1」をリリースした。xrpldは、参加者がXRPL上でノードやバリデーターを運用するために実行するリファレンスサーバーソフトウェアである。個々のノードが異常なデータ負荷に直面する中、ブロックチェーンは途切れることなく台帳の閉鎖を継続し、コンセンサスが完全に機能していたことを確認した。

XRP Ledger Operationsは公式Xアカウントを通じてリリースを発表した：

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

ノード管理者には、遅滞なくホットフィックスをインストールし、初回インストール直後に2回目の再起動を実行するよう指示された。更新されたビルドは、信頼されていないバリデーターデータが不釣り合いな量のメモリ、帯域幅、ストレージ、処理能力を消費することを防ぐ制御機能を導入している。

マニフェストフラッドがXRPLピアインフラに与えた影響

XRPLは、各運用者がUnique Node List（UNL）を通じて信頼済みとして指定するバリデーターのセットに依存している。ノードのUNLに含まれるバリデーターのみが、そのノードのコンセンサス意思決定に直接参加する。バリデーターマニフェストは、バリデーターの恒久的なマスターIDと、コンセンサスラウンド中に使用される一時的な署名キーを紐付ける。このアーキテクチャにより、運用者はマスター認証情報をオフラインに保ちながら、定期的にワーキングキーをローテーションし、バリデーターの確立されたネットワークIDを維持できる。

以前のxrpldバージョンでは、ノードが受け入れ、保存、再配信できる未知のバリデーターキーに関連付けられたマニフェストの数に上限がなかった。すべてのノードは信頼ステータスに関わらず、接続されたピアにマニフェストデータを中継するため、過剰な信頼されていないデータがネットワーク上に伝播し、ローカルキャッシュ内に蓄積された。

本インシデントは、アカウント残高、個別取引、台帳の検証ルールではなく、ピアレイヤーのメッセージ伝播に影響を与えた。この区別はブロックチェーンアーキテクチャにおいて一般的に重要である：コンセンサスレイヤーの障害はチェーンを停止させる可能性があるが、ピアレイヤーの障害は台帳の完全性を損なうことなく接続性を低下させる。XRPLは予定通り取引の処理と台帳の確定を続けていたが、ピア接続への負荷により接続性が低下し、ネットワーク上の情報配信が遅延した。

バージョン3.2.1における4つの保護策

バージョン3.2.1は13ファイルにわたる6つのコミットを導入している。これらの変更は、過大または反復的なマニフェストトラフィックがノードに負荷をかける可能性のある4つの重要なポイントで制御を実装する：

1. デコード前のサイズ拒否。 xrpldはデコード処理が開始される前に、予想されるエンコードサイズを超える個々のマニフェストを拒否するようになり、過大な入力が不必要な計算処理を引き起こすことを防いでいる。

2. 信頼されていないバッチの破棄。 ノードは信頼されていないマニフェストが過剰に含まれる受信バッチを破棄するようになった。重要な点として、ソフトウェアは過大なバッチを送信する古いピアを自動的に切断しないよう設計されており、アップグレード期間中のネットワーク分断リスクを軽減している。

3. ピア挨拶の制限。 本ホットフィックスは、2つのノードが新たなピア接続を確立する際に交換されるバルクマニフェスト挨拶を制限する。信頼済みレコードは完全に利用可能なまま維持され、信頼されていないゴシップは送信パスと受信パスの両方で制限される。

4. 未知キーの保存上限。 各ノードは未知のバリデーターキーに紐づくマニフェストを最大100件まで保存できる。この上限に達すると、以降のエントリは拒否され、信頼されていないマニフェストはディスクに永続化されなくなる。

必須の2回目の再起動と署名キーの確認

アップデートのインストール後、管理者は約1〜2分待機し、xrpldが稼働状態にあることを確認するよう指示された。次のステップに進む前に完全な同期は必要ない。

更新されたサービスの稼働が確認された後、運用者はxrpldを2回目の再起動を行う必要がある。運用チームはこの2回目の再起動をアップグレード手順の不可欠な最終ステップと位置づけている。

パッケージインストールを実行している管理者は、Rippleの現在のソフトウェア署名キーも確認すべきである。Rippleは2026年2月にxrpldパッケージの署名に使用されるGPGキーをローテーションした。したがって、置換キーをまだ信頼していないシステムは自動アップグレードを受け取れない可能性がある。

本ホットフィックスはネットワーク修正を導入せず、取引処理ルールを一切変更しない。代わりに、デコード、再配信、キャッシュ、永続ストレージの前に、信頼されていないピアデータに対する厳格な境界を確立する。マニフェストサイズ、バッチ量、接続挨拶、未知キーの保存を制限することで、XRP Ledgerは7月31日のフラッドで使用された4つの悪用経路を封鎖した。本インシデントは、コンセンサスが正常に機能し続ける中でも、ピアレイヤーの悪用が個々のサーバーに負荷をかける可能性があることを示した。これは他のブロックチェーンネットワークもピアプロトコルの強化によって対処してきた種類の脆弱性である。

完全な事後分析報告はコミュニティ向けに公開される予定である。