XRPL財団（XRPレジャー財団）は12日、 XRP を新たに生み出せる脆弱性を修正した件について、X（旧Twitter）で経緯を説明した。「XRPは生成されたか」との問いには「いいえ」と答えている。
XRPの総供給量はXRPレジャー（XRPL）の立ち上げ時に1,000億XRPで固定され、新規発行を認める取引は存在しない。今回の不具合は、このルールを迂回できるものだった。
取引手数料は焼却される仕組みで供給量は減り続けており、現在は約999.86億XRP。同財団は、残高はすべてオンチェーンで公開されており、新たなXRPが生まれれば誰でも確認できると強調した。
9日に公開された脆弱性開示レポートによると、原因は決済エンジンの整数オーバーフロー（桁あふれ）だった。1回の支払いで注文板の多数のオファーをまとめて約定させる際、XRPの合計額を64ビット整数で上限チェックなしに加算していた。
合計が上限を超えると小さな値に巻き戻り、オファーの出し手には全額が支払われる一方、買い手には巻き戻った少額しか請求されない。この差額が新規のXRPになる構造だ。
XRPLには、取引がXRPを生成していないかを確かめる安全検査（インバリアント）が組み込まれている。ただし同じ計算方法を使っていたため、合計値が同様に巻き戻り、異常を検知できなかった。不具合は現行の決済エンジンが書かれた2015年から存在していたとみられる。
発動には実際の取引ではあり得ない価格の数百件のオファーを意図的に組む必要があり、通常の送金では到達しないため約10年見過ごされてきたという。
研究者のケイデン・リャオ（Cayden Liao）氏とVeria AIが9月22日、XRPLのバグ報奨金プログラムを通じて報告した。リップルXのエンジニアチームが再現に成功し、報告時の「メジャー」から「クリティカル」に重大度を引き上げた。
攻撃コストは準備金として預ける数百XRPと手数料程度にとどまり、悪用されれば1回の取引で総供給量を大きく上回るXRPを生成できた。公開ネットワーク上で悪用された証拠は見つかっていない。
XRPLで取引処理のルールを変える場合は通常、「アメンドメント」と呼ぶ手続きを踏む。新ルールを組み込んだソフトウェアを配布し、信頼されたバリデーターの80％超の支持が2週間続いた時点で、全サーバーが同じレジャーから一斉に切り替える仕組みだ。
今回の修正はこの手続きを経ず、各サーバーが修正版xrpld 3.4.1に更新した時点で有効になった。取引処理の変更を意図的にこの形で出したのは、アメンドメント制度の導入から10年余りで初めて。xrpldはオープンソースのため、修正を公開すれば不具合の場所も明らかになる。
同財団などは、通常の手続きでは公開から有効化までの数週間にわたり攻撃可能な状態が続くと判断した。
方針は同財団やリップルX、コア開発者、バリデーターが協議して決めた。デフォルトUNL（推奨バリデーターリスト）の運営者には、各自が公開している連絡先を通じて修正版を先行共有。一般公開と同じ9月25日には、デフォルトUNLのバリデーターの80％超が3.4.1を稼働させていた。
同財団は、どのソフトウェアを動かすかは各運営者が選ぶものであり、特定の1者が単独で下せる判断ではなかったとしている。
3.4.1には、メインネットで未稼働だったBatch機能の検証漏れを直す修正「fixBatchV1_2」も含まれる。こちらは通常のアメンドメント投票を経て10月9日に有効化され、旧版のサーバーはネットワークと同期できなくなった。
3.4.1への更新が事実上必須となったのは、この通常投票の結果による。同財団は、プロトコル変更は今後もアメンドメントを経るとしている。
再発防止策として同財団は、リップルXやコミュニティと連携し、数学的にコードの正しさを証明する形式検証やAIを使った攻撃テストを徹底的に導入する。セキュリティ研究者との協力やバグ報奨金制度の強化も進める方針だ。
AIによってこの種の不具合は攻撃側と防御側の双方にとって見つけやすくなっていると、同財団は指摘した。開示レポートは、修正済みとされた指摘をリリース候補版で再検証する工程を新たに加えるとしている。
