XRP Ledger、10月8日にXRPアカウントの権限委譲を有効化

更新 21:07 UTC： Batchが稼働開始した。XRPScanのダッシュボードによると、BatchV1_1はメインネットで有効化され、賛成30、反対5の35バリデータ中約85.7%の支持率が必須となる2週間の待機期間を通じて維持された。

委譲機能がXRPLで稼働開始

XRPの基盤であるXRP Ledgerで送金を扱う企業は、今週までにっちもさっちも行かなかった。主要な資産を管理する鍵をネット接続端末に置くか、署名が必要なたびに担当者をコンプライアンス業務から引き離すか、その二択だったからだ。この制約は10月8日、PermissionDelegationV1_1アメンドメントの発動で終わった。アカウント所有者が補助用アカウントに限定された権限を与え、マスターキーはオフライン保管のまま運用できるようになる。XRPの価格や供給量には触れない変更で、書き換わるのは「誰が、何のために、アカウントを操作できるか」だ。発動はXRPLの標準手順に沿った。トランザクションを検証する35の信頼済みバリデータのうち80%超の支持が2週間維持され、閾値は29票だった。9月に支持率がこの水準を下回ってカウントダウンが一度リセットされ、オンチェーンの記録では2回目の挑戦で通過した。想定される用途は24時間体制のコンプライアンスだ。ステーブルコイン発行者は、KYC手続きに基づく新規顧客の承認をコンプライアンス用アカウントに委譲しつつ、資産管理の鍵をコールドウォレットに置いたままにできる。個人口座向けにLedger Recovery Keyが強制しているのと同じオフライン運用の規律だ。補助アカウント1つにつき最大10件の権限を設定でき、内容は支出上限ではなく操作種別で定義される。顧客の承認、送金の実行、特定アカウントの凍結などが例だ。補助側は独自の鍵で署名し、付与された操作しか実行できず、所有者は随時、権限の変更や取り消しが可能である。銀行が既に送金部門とコンプライアンス部門を分けている業務分担を、台帳レベルで強制できる形になった。市場の規模も数字で示されている。XRP関連企業Evernorthが公表した第2四半期の平均Token化資産額は37億2000万ドル、RippleのRLUSDステーブルコインは約5億3900万ドル、合計で約42億6000万ドルに達する。この権限付き発行者の設計は中央銀行デジタル通貨の実証実験で試された構造とも重なり、台帳の大規模なステーブルコイン導入の流れをさらに後押しする。

オンチェーンの記録は発動の時点を特定している。バリデータは107,524,865番目のレジャーでEnableAmendmentトランザクションを確認し、開発者はすでに稼働中のネットワークで最初の委譲操作のテストを始めている。取り消し可能な権限付与について先に示した像に加えるべき設計上の詳細が1つある。マスターキーの変更など重要な機能は技術的に委譲できず、補助アカウントが借り受けた所有権を書き換えることは決してできない。この変更はほとんどの保有者にも影響しない。XRPを保管・送金する個人のウォレットは従来どおり動作し、機能は出納担当、業務担当、監査担当の職務分離が必要な大口アカウントに明確に向けられている。実際の展開は、主要なカストディアルサービスが権限ツールをインターフェースに組み込むかどうかにかかっている。

fixBatchV1_2とBatchV1_1の2つのBatchアメンドメントは数時間以内に発動する見通しだ。この日程は、2026年2月19日にセキュリティ研究者とCantina AIが、最初のBatchアメンドメントの署名検証に重大な論理欠陥を投票中に発見した時点まで遡る経緯の決着となる。Batch V1.1は置き換え版としてXRPLD 3.3.0に同梱され、より小さな欠陥はXRPLd 3.4.1で修正された。9月のコミュニティによる再投票では一時的な否決後に2週間のカウントダウンがやり直されたが、バリデータは待機期間なしでBatchとその修正を同時に発動させるよう票を調整済みだ。この機能は台帳上のアトミックな複数当事者コンセンサストランザクションを支えるものである。

Batchが稼働開始した。XRPScanのダッシュボードによると、BatchV1_1はメインネットで有効化され、賛成30、反対5の35バリデータ中約85.7%の支持率が必須となる2週間の待機期間を通じて維持された。この機能は1つの外側のトランザクション内に2〜8件の内側のトランザクションを束ねるもので、利用者は「All or Nothing」「Only One」「Until Failure」「Independent」の4つの実行モードから選択できる。All or Nothing設定では、1件の内側の送金が失敗するとグループ全体が停止するが、Batch手数料は差し引かれたままのため、公式チュートリアルは外側の結果に頼らず個々のトランザクション結果と残高を確認するよう開発者に指示している。XRPLバリデータのVetは、店頭取引、デリバリー・バーセス・ペイメント決済、NFTとNFTの交換を初期のユースケースとして挙げ、この機能を機関投資家や個人開発者にとって大きな解放だと評した。Batchの中に別のBatchを入れ子にすることや、重複する内側のトランザクションはプロトコルによって拒否される。

改修を残す2つのバグ

委譲機能は1件の例外付きで稼働している。公式ガイダンスは、別の修正が発動するまでPaymentBurn権限を委譲しないよう利用者に求めている。この権限は本来、台帳上で発行されたトークンの廃棄を補助アカウントに委ねるものだが、特定条件下ではトークンを新規に発行できてしまい、発行者の許可なく供給量を膨らませる恐れがある。警告の対象は台帳発行トークンであって新規発行のXRPではなく、その他の細分化された権限は影響を受けていない。修正案は金曜時点で35票中27票に達しており、2週間のカウントダウンを開始して警告を解除するために必要な29票まであと2票だ。枠組みの残りの部分は設計どおりに動く。補助アカウントは個別の鍵ペアで各操作に署名するため、補助側端末が侵害されても権限の一部しか露出せず、資産管理の鍵は守られる。付与は書き換えも取り消しも自由だ。もう1つの不具合は票の集計そのものにある。10月8日にrippledのコードベースへ提出されたバグ報告によれば、バリデータが定期的なセキュリティキーの更新を行うと、当該バリデータがオンラインで投票を続けているにもかかわらず、一部のサーバーが集計から外してしまう。2台分を数え落としたサーバーは支持率を35ではなく33を分母に測るため、提案の通過が実際より近く見える可能性がある。恒久識別子でバリデータを識別するよう改める修正案はレビュー中だ。XRPLのアメンドメントはコンセンサスメカニズムによるバリデータ合意で採決され、ガバナンストークンの投票数ではない。その合意を集計するソフトウェア自体が、壊れうる部品であることも今回の一件が示した。

ダッシュボードのデータは両方の不具合に正確さを加える。バグ報告の提出者は、3台のバリデータが署名鍵を更新した後、正しい35と28ではなく、閾値26で33件の検証が記録されていたことを確認している。ただし、これまでにアメンドメントの合否判定が実際と異なった例はない。バリデータを恒久的なノードIDで追跡する修正案は、金曜時点でまだレビュー待ちだった。一方、XRPL Dashboardはメインネットで稼働中の95件のアメンドメントを掲載し、Batch関連の2件、fixBatchV1_2とBatchV1_1が同日の14:12と14:46 UTCに発動する可能性があると予測している。アメンドメントのページはまた、PermissionDelegationV1_1が重大なバグの発覚後に撤回された旧バージョンを置き換えたものだと記し、未発動のPaymentBurn修正をfixCleanup3_4_0としている。

残る制約は日程

今回の更新が取り除いたのは権限の空白であり、残ったのは日程だ。細かい制御がないことを理由にToken化ファンドや送金業務を見送っていた機関は、今後オンチェーン上で職務分担を組めるようになる。ただしPaymentBurnの修正が29票に達するまでその権限は委譲できず、9月のリセットは支持率が水準を下回れば2週間の時計がやり直されることも示した。2つの修正が両方通過するまでは、但し書き付きの機能導入となり、数週間単位で進む台帳の合意プロセスが引き続きカレンダーを決める。