XRP Ledgerの緊急アップデート
XRP Ledgerの開発者たちは、ネットワークの標準的な2週間のバリデーター承認プロセスを待たずに、重要なプロトコル修正を展開した異例のセキュリティ決定を擁護しています。この緊急アップデートは9月25日にリリースされ、攻撃者が暗号通貨の意図された供給制限を超えて使用できるXRPを作成できる可能性のある11年前の脆弱性に対処しました。
脆弱性とその影響
調査者たちは悪用の証拠を見つけていませんが、脅威を排除するために採用された方法は、分散型ネットワークが緊急事態にどのように対応すべきかについての議論を引き起こしています。通常のXRPLガバナンスフレームワークの下では、取引処理に影響を与える変更は、発効前に2週間連続して80％以上の信頼できるバリデーターの支持を受ける必要があります。しかし、9月のセキュリティパッチは異なる手順に従いました。
公式の脆弱性報告によれば、修正はxrpld 3.4.1にアップグレードされた各サーバーで即座に有効になり、承認された修正を通じて同時に発効するのではありませんでした。
開発者の見解とリスク
開発者たちは、XRP供給の脆弱性の深刻さが通常のプロセスを危険にさらしたと述べています。投票期間中に欠陥を悪用可能なままパッチを公開することは、攻撃者に悪用を再現するための十分な情報を与える可能性がありました。根本的な問題は、支払いエンジンにおける整数オーバーフローに関するものでした。
特別に構築された取引は、システムが送信者が実際に支払った以上のXRPをクレジットする原因となり、新しいトークンを作成する可能性がありました。研究者たちは脆弱なコードを2015年に遡って追跡しましたが、公共ネットワークで悪用された証拠は見つかりませんでした。
技術的な影響と今後の課題
この決定には技術的な影響もありました。通常、修正は互換性のあるサーバー全体で同時に発効し、バリデーターが同一の取引ルールを適用することを保証します。しかし、緊急アップデートは、アップグレードされたサーバーが特定の悪意のある取引を拒否する一時的な期間を作成し、古いバージョンがそれらを受け入れる可能性がありました。
この不一致は、攻撃者が十分なバリデーターがアップグレードする前に脆弱性を悪用しようとした場合、台帳の検証を中断させる理論的な可能性がありました。しかし、迅速な展開によりそのリスクは軽減されました。
開発チームの開示によれば、デフォルトのユニークノードリストの80％以上のオペレーターが9月25日までにバージョン3.4.1をインストールしていました。この対応は、通常の修正手続きを経て10月9日に発効した別のBatchセキュリティ修正とは異なります。
今後の展望
この事件は、深刻なネットワーク緊急事態において開発者やバリデーターオペレーターがどれだけの権限を行使すべきかについての疑問を引き起こしました。批判は、セキュリティに敏感なソースコードが公開される前にソフトウェアが一時的に配布されたことに部分的に焦点を当てています。
支持者たちは、攻撃者が公開された脆弱性を悪用するのを防ぐために即時の調整が必要だったと主張しています。XRPL財団は、オペレーターがアップデートをインストールすることを強制されたという提案を拒否し、バリデーターが自らのアップグレードの決定を下したことを強調しています。
この議論は、今後のXRPL貸付アップグレードが通常の投票プロセスを通過し続けている中で行われており、ルーチンのプロトコル変更が依然として持続的なバリデーターの支持を必要とすることを示しています。開発者たちは、修正をバイパスすることは、ネットワークガバナンスの標準的な代替手段になるのではなく、特に深刻なセキュリティ脅威に対してのみ留保されるべきだと主張しています。
XRP保有者にとって、即時の懸念は解決されました：脆弱性は修正され、調査者は既知の悪用は報告していません。長期的な疑問は、XRPLが将来の重要な脅威に迅速に対応しながら、どのように分散型の意思決定を維持できるかということです。
