XRP Ledger（XRPL）で取引処理の遅延が発生し、ネットワーク運用上の課題が改めて浮き彫りになった。Rippleの元最高技術責任者（CTO）で、XRPLの共同開発者でもあるDavid Schwartz氏は、今回の事象について、分散構造そのものよりも高負荷時の監視体制とログ収集に問題があったとの見方を示した。

ブロックチェーンメディアのU.Todayが21日（現地時間）に報じた。報道によると、XRPLの運用チームは、レジャーのクローズ速度が通常より大きく低下する異常を確認。エンジニアが原因究明を進めるなか、コミュニティでは分散型ネットワークの信頼性を巡る議論が広がり、一部ノードの過負荷がネットワーク全体の停止につながるのかが焦点となった。

これに対しSchwartz氏は、XRPLのソフトウェアは多層的な安全対策で保護されていると説明。ネットワーク全体が機能不全に陥るシナリオは、大きく2つに限られるとした。

1つは、世界中のバリデーターサーバーで同時多発的に障害が起きる大規模なインフラ障害だ。同氏は、そうした事態は事実上、世界規模の自然災害に近い状況を想定する必要があると述べた。もう1つは、ノード間の合意形成を担う合意アルゴリズムが正常に機能しない、あるいはコード上の不具合によって中核的なプロトコル機能に問題が生じるケースだという。

今回の処理遅延について同氏は、システムの安全余力が低下している兆候と受け止めるべきだと指摘した。攻撃を受けていた可能性や、コード内部に潜んでいたバグが表面化した可能性があるとしている。

一方で、単一障害点（SPOF）に当たるとの見方は否定した。特定のノードが停止したり過負荷に陥ったりしても、XRPL全体がそれだけで停止する構造ではないとし、分散型ネットワークとして設計されている点を強調した。

実際に問題となったのは、監視体制の維持だった。Schwartz氏によると、合意ラウンドが遅延するとバリデーターは最大負荷に近い状態となり、内部の監視システムも十分に診断データを記録できなくなった。このため、正確な原因を特定し切れないままサーバーを再起動せざるを得なかったという。

その後の議論では、同氏のノードがXRP Ledger Foundation（XRPLF）の古いテストホストにログを送信していたことも判明した。設定面の問題や運用上の惰性が重なり、診断体制の弱さが露呈した格好だ。

現在は、エンジニアとコミュニティの運営メンバーが残存ログを手作業で分析し、不具合の特定と修正を進めている。Schwartz氏は、安全余力が一時的に低下していた可能性は認めつつも、過度に警戒すべき局面ではないと説明。開発チームは状況を把握しており、現行のコードベースにも運用を維持するだけの余力は残っているとの認識を示した。

今回の事案は、XRPLの分散構造そのものの脆弱性というより、高負荷時にも診断データの取得と運用の可視性をどう維持するかが重要な課題であることを示した。今後の調査では、処理遅延の直接要因に加え、バリデーターが高負荷状態に入った際でも、ログ収集と監視体制をどこまで安定して維持できるかが焦点となる見通しだ。

Schwartz氏は、インシデント発生中も自身のノードは正常に動作していた可能性が高いとしつつ、「監視機能に影響が出たため、断定は難しい」と説明。そのうえで、XRPL全体の安定性を脅かすのは、多数のサーバーが同時に停止する場合か、合意プロセスを含むネットワークレベルの重要機能に障害が発生する場合だと述べた。

さらに同氏は、「ソフトウェアには安全余力を確保するための多層的な保護がある。合意ラウンドの遅延は、その余力が低下している兆候であり、攻撃やバグの可能性も考えられる。ただ、主要な開発者がパニックに陥っていないのであれば、なお十分な余力が残っているはずだ」との見方を示した。