XRP Ledger(XRPL)の開発者は、ネットワークの固定供給量を超えるXRPを作り出すことが可能なバグを修正するために展開された緊急セキュリティパッチを擁護し、潜在的な攻撃者にこの欠陥を晒すことなく待つことはできなかったと、ブロックチェーンの通常2週間にわたるバリデータ投票を待つことはできなかったと主張した。

時間をかけて新しいコインを発行するネットワークとは異なり、XRP Ledgerは1,000億XRPの全供給量が最初から存在した状態でローンチされた。そのため、追加のトークンを発行できるコードパスは、この資産の根本的な性質に関わる問題だった。

パッチは9月25日、バグ報奨金プログラムでの報告から3日後にリリースされ、インストールしたサーバーでは即座に有効になった。開発者によれば、これは同システムが導入されてから10年以上で初めて、ネットワークの標準的な改正プロセスを意図的に回避したものである。このプロセスでは、プロトコルの変更は改正として提供され、80%を超えるバリデータが2週連続で支持した場合にのみ有効化される。XRPL財団が後にバージョン3.4.1への必須移行を擁護する際に引用したのも、同じ基準だった。

「通常の改正投票では、修正が発効する前に数週間公開状態となり、ネットワークのセキュリティが危険に晒されることになっていた」と、XRPL開発者は日曜日にX投稿で述べた。

この緊急対応による修正は、XRP Ledgerの分散性の度合いについて疑問を投げかけた。ウェブサイトでXRPLは完全に分散化されたパブリックブロックチェーンであると自らを説明しており、この説明は、ネイティブトークンであるXRPが証券と分類されるべきでないという議論の中心であった。こうした議論には規制上の意味合いがある。米国証券取引委員会(SEC)は2020年12月にRippleを未登録証券の提供として提訴しており、XRPの分散性の度合いはこの訴訟で繰り返し争点となってきた。

セキュリティ修正は「多くの疑問を投げかけた」

Cyber Capitalの創設者Justin Bons氏は木曜日、XRPを小口投資家に対して分散化されているものとして販売することは完全な詐欺」に相当すると述べた。同氏は、9月25日の緊急リリースがバイナリのみで提供され、ソースコードが一時的に非公開とされ、運営者にアップグレードを迫ったと主張した。

一方、XRPL財団は、標準的な改正プロセスを省略する決定は、バグの深刻度を評価した後、財団、RippleX、コア開発者、バリデータが共同で行ったものだと述べた。

「いかなる単一の当事者もその決定を単独で下すことはできませんでした。すべてのバリデータとノード運営者は実行するソフトウェアを選択でき、3.4.1が必須となったのは、80%を超えるバリデータの支持が2週間続くという通常の改正投票によるものです。プロトコルの変更は依然として改正プロセスを通じて行われます」と財団は述べた。

独立系バリデータ運営者のXRP Kuwaitも、協調的なアップグレードが中央集権的な管理を示すという主張を否定した。

「運営者がアップデートを調整すること自体が中央集権的な管理の証明であるという主張には同意できません」と同組織はX投稿で述べた。「調整は管理とは異なります。独立した運営者は、自らの独立性を手放すことなく、状況を評価し、互いに連絡を取り、同じ結論に達することができます。」

バグは無制限のXRP発行を可能にし得た

プロジェクトの脆弱性開示レポートによると、このバグは2015年から存在していたXRP Ledgerの決済エンジンにおける整数オーバーフローだった。

XRPの残高は固定された最大値を持つ64ビット整数として保存されている。合計が最大値を超えると、計算はエラーとならずに小さい数値へ折り返されていた。

攻撃者は、それぞれ非常に大きなXRP量を要求する特殊な価格設定のオファーを数百件作成し、それらすべてを消費する単一の支払いを送ることでこの欠陥を悪用できた。エンジンは各オファーの所有者に全額をクレジットしながら、買い手には折り返されたごく小さな合計額のみを請求する。差額は新たに作成された使用可能なXRPとして現れることになる。

レポートによると、この攻撃には意図的に構築されたオファーが必要であり、通常の取引活動では引き起こされ得なかった。開発者は、この問題がいかなるパブリックネットワークでも悪用された証拠は見つからなかったと述べた。

台帳のコアコンポーネントの一つにおける欠陥が約10年間検出されないままだった理由は、この開示が引き起こした議論の中で未解決の問題として残されている。