XRP Ledger、fixCleanup3_4_0のセキュリティ修正を10月23日に発動へ

80%の賛成が2週間のカウントダウンを起動

XRP Ledgerは、fixCleanup3_4_0アmendメントを10月23日の09:34(UTC)前後に発動する日程を確定させた。発動には、プロトコルが定める80%の绝对多数(スーパー多数)基準をバリデーターの支持が維持したまま超えていることが条件となる。アmendメントがこの基準を突破したのは10月9日で、ここから義務的な2週間のカウントダウンが始まった。オンチェーン探索データによれば、10月中旬の時点で32〜35の投票バリデーターのうち26〜29が賛成に回っている。ただし日程には安全弁が組み込まれている。発動前に支持が80%以下に落ちればカウントダウンはリセットされ、改めて2週間連続で十分な支持を保たなければならない。この仕組は「揺れる合意」による発動を防ぐためのものだ。支持が割れた状態でパッチが有効化されればネットワークが分断されかねない。残り2週間の間に一度でも基準を下回れば、セキュリティ修正は最短でも2週間先送りされる。運営側は合意が割れたまま変更を実行するリスクより、この遅延を飲む方がましと判断している。

新しい取引商品を追加する変更とは異なり、今回の更新は既存ソフトの挙動を修復する内容だ。パッチはRipple 3.4.0リリースに同梱され、レンディング基盤、自動マーケットメーカー(AMM)、トークン処理、エスクロー取引、アカウント権限を対象に覆う。レジャー上のアmendメントは持続的なスーパー多数の合意が形成されて初めて挙動を変えるため、アップグレードの日程がリリース日ではなくバリデーターの投票で表現されるのはこのためだ。日常的な残高やXRPの価格は影響範囲の外にあり、互換性の負担を背負うのはノード運営者だ。変更が有効化された後もネットワークのconsensus mechanismに追従し続けるには、ソフトの更新が必須となる。

PaymentBurnの欠陥とレンディングの凍結

一式の中で最も鋭い問題はPermissionDelegationV1_1.1に関わる。10月8日に有効化されたこの機能は、アカウント所有者がprivate keyを渡すことなく、別のアカウントに限定的な権限を委譲して特定の操作を実行させられるようにするものだ。委譲権限のひとつPaymentBurnは、指定トークンを代理者が焼却できるはずのものだが、ソフトの欠陥により一定条件下で操作がトークンを新規に生み出してしまう。意図と正反対の結果で、トークンの供給に直接触れる事象だ。権限値に関するXRPL公式ドキュメントは、クリーンアップ・アmendメントが有効になるまで運営者に対しこの権限を付与しないよう明示的に警告している。更新には他にも修正が含まれる。ボールトからの出金計算の是正、貸出延滞宣言の基準の引き締め、そして一部のAMM取引が裏付ける資産を受け取らずに流動性トークンを焼却してしまう問題の防止だ。最後の点は、APYを追う流動性提供者にとって見逃せない領域だろう。

一方で、商品そのものの承認は停止している。提案されているレンディング・プロトコルは、ユーザーがレジャー上で資産をプールし、固定条件で借入できる仕組みを想定する。借手が担保を差し出さないケースもあり、ブローカーがブロックチェーンの外で貸出条件の調整と信用審査を担う。システム全体を有効化するには3つの別個のアmendメントが必要で、10月15日から17日にかけてレンディング系2件はいずれも約17〜19の支持(約53%)にとどまり、必須のSingleAssetVaultは約19〜21を数えた。この2件と並んでSingleAssetVaultが必須とされるのは、上記の算定のためだ。3件のどれもスーパー多数に届いておらず、機能には発動日が設定されていない。walletやオフラインのRipple paper walletでXRPを保管するホルダーは何もする必要がない。ただし委譲機能の欠陥は、鍵管理が実務で破綻しやすいことを改めて示す事例であり、同じ論点は委譲機能が有効化された10月8日当たりのDavid Schwartzによる詐欺リンク警告の論点と重なる。

投票状況を併せて読むと、バリデーターが金融商品よりも修復を優先している構図が浮かぶ。10月23日の発動はレンディング基盤が走るレールを固めるが、商品自体は3つの修正案が同じ80%基準をそれぞれ超えるまでオフのまま、見通せる日程もない。今後2週間が実地試験になる。発動前に一度でも支持基準を下回ればカウントダウンは戻り、セキュリティ修正は遅れる。通過すれば、ノード運営者は10月8日の委譲機能有効化以降、公式ドキュメントが指摘し続けてきた焼却権限の露出をようやく解消できる。