XRPLの遅延後、デビッド・シュワルツがネットワークのリスクを説明

XRP Ledgerネットワークでの取引の遅延を引き起こした技術的な問題は、プロトコルアーキテクチャに関するより広範な調査をもたらしました。Rippleの元技術ディレクターであり、システムの開発者の一人であるデビッド・シュワルツは、事件の後に公開された評価でネットワークの脆弱なポイントを説明しました。

遅延する台帳の閉鎖が調査を開始

問題は、XRP Ledger Operationsチームがネットワーク内の異常を記録したことから発生しました。ネットワーク上の台帳が通常よりも明らかに遅く閉じることが、エンジニアたちを遅延の原因を調査するように促しました。この過程で、コミュニティ内での分散型構造の耐久性に関する疑問も浮上しました。

シュワルツは、XRPLソフトウェアが多層のセキュリティ構造で保護されていると述べました。しかし、ネットワーク全体を完全に停止させる可能性のある二つの基本的なシナリオが存在すると指摘しました。一つ目は、世界中の多数のバリデーターサーバーが同時にダウンすることです。シュワルツは、このような状況はグローバル規模の大規模な自然災害の際にのみ可能性があると伝えました。

二つ目のシナリオは、合意アルゴリズムにおけるエラーやプロトコルの基本機能の一つがコードレベルで損なわれることです。シュワルツは、最近の事件で記録されたラウンドの遅延がシステムの技術的セキュリティマージンの縮小を示しており、これは標的型攻撃やコード内で引き起こされる隠れたバグを示唆する可能性があると述べました。

デビッド・シュワルツは、ネットワーク全体を麻痺させる可能性は大規模なインフラの喪失や合意メカニズムの破損に限られており、最近の遅延はセキュリティマージンの減少を示していると強調しました。

単一障害点の主張に対する反論

シュワルツは、ネットワークが単一のノードや中心に依存しているという主張を否定しました。XRPLは完全に分散型の構造で機能していると述べ、巨大な中心、さらには自分のノードのダウンや過負荷がネットワーク全体の機能性に直接影響を与えることはないと語りました。

Rippleは、XRPエコシステムの主要企業の一つとして、決済インフラやブロックチェーンベースの金融ソリューションを開発しています。XRP Ledgerは、Rippleから独立して動作するオープンソースのブロックチェーンネットワークとして知られています。

監視システムが負荷の下で機能不全

事件の際に最も顕著な問題は、ネットワーク監視システムが高負荷の下で脆弱であることが明らかになりました。合意ラウンドが遅くなると、バリデーターは一瞬で最大負荷に達しました。シュワルツのノードも高いリクエストトラフィックに耐えられず、ローカルRPC接続がCLOSE_WAIT状態で停止しました。

ミニ辞書：RPCは、ソフトウェアが別のシステムからリモートでデータを要求し、コマンドを実行するための通信方法です。CLOSE_WAITは、接続が相手側からの終了信号を受信したが、ローカル側でプロセスがまだ完了していない状態を示します。

このロックのために、シュワルツの内部監視システムは、最も重要な瞬間に診断データを記録して送信できませんでした。このため、エンジニアは故障の正確な原因を特定できないままサーバーを再起動せざるを得ませんでした。

シュワルツは、ノードの接続がロックされたため、診断データが最も重要な瞬間に失われ、サーバーがなぜ正確に問題を引き起こしたのかを確認することなく再起動されたと伝えました。

古いテストサーバーへの記録が調査中

調査中に、XRPLの開発者の一人に属するセンターのログがXRP Ledger Foundationの古いテストメインフレームに送信されたことも明らかになりました。この状況は、事件時のデータの完全な収集をさらに困難にしました。

エンジニアリングチームとコミュニティオペレーターは、残されたログを手動で調査し、エラーを特定しようとしています。シュワルツは、セキュリティマージンに一時的な縮小があったものの、チームが状況を管理下に置いており、ネットワークアーキテクチャが作業を続けるのに十分な技術的なリザーブを持っていると述べました。