XRP Ledger(XRPL)は、1つのアカウントの管理権限を複数の委任アカウントに分割できるようにするアップグレードの発動に近づいており、これにより単一の運用鍵の権限が制限されます。

PermissionDelegationV1_1は、トランザクションを頻繁に処理するものの、日常の運用システム内でアカウント全体を制御できる鍵を保有したくない組織向けに設計されています。たとえばステーブルコイン発行体は、顧客の信頼線(発行済み資産を保持するレジャーの仕組み)の承認を行うシステム、支払いを処理するシステム、アカウントのセキュリティを管理するより保護された仕組みなど、別々のシステムを必要とする場合があります。この修正案により、これらの業務を複数のXRPLアカウントに分割できるようになります。

「銀行型」とされる要素は責任の分離です。これは規制上の承認や銀行による採用の確認を意味するものではありません。侵害された委任アカウントは、割り当てられた役割の範囲内で悪用される可能性は残りますが、攻撃者がメインアカウントの全権限を自動的に得ることはなく、単一の運用鍵が漏洩した場合の被害を軽減できます。

XRPLは各権限をオンチェーンで強制

XLS-75仕様では、権限を割り当てるアカウントはデリゲータ(delegator)と呼ばれます。デリゲータは、相手アカウントとそのアカウントが実行できる操作を指定したDelegateSetトランザクションを送信します。関係はDelegateレジャーエントリに保存されます。

委任先は自身の鍵で署名し、代理を務めるアカウントを指定してトランザクション手数料を支払います。XRPLは記録された権限外のリクエストを拒否し、デリゲータは後からその権限を更新または削除できます。

公式ドキュメントには、トランザクションタイプ単位の権限とより細かい粒度の権限が列挙されており、各委任先が受け取れるのは最大10個までです。利用可能な細粒度の制御は事前定義されているため、組織は任意の制限を作成できるわけではありません。委任先も資金のあるアカウントを維持する必要があり、各委任はオンチェーンオブジェクトを作成するため、デリゲータが所有する各レジャーオブジェクトに対して保持が必要な最小XRP額であるオーナーリザーブの要件が増加します。

署名鍵の変更や新しい委任先の指定など、機密性の高い権限は委任できません。オープンレジャーに即座に取り込めないトランザクションも、キューに入る代わりに失敗します。

29票で条件付きカウントダウンが開始

ライブ修正案トラッカーによると、PermissionDelegationV1_1は9月21日、XRP Ledgerの35信頼済みバリデータのうち29の支持を得て14日間の発動期間に入りました。修正案はレジャーのルールを変更するための組み込みの仕組みであり、バリデータの継続的な支持が新しいプロトコルコードをメインネットにもたらします。少なくとも28のバリデータが支持を維持する必要があり、それを下回るとカウントダウンはリセットされます。CoinDeskが報じたところによると、支持が途切れなければ、10月5日11:18 UTCに発動する見込みです。

コードはすでにXRPLサーバーソフトウェアに存在しますが、発動前はメインネットで使用ません。別の修正案Batch V1.1も同じ2週間のプロセスを経ていますが、こちらはアカウントの権限ではなくリンクされたトランザクションに関するものです。

マルチシグの代替ではない

マルチシグは、アクションの承認に必要な承認済み当事者の数を決定します。権限委任は、運用アカウントが要求できる操作を制限するものです。組織は、委任先を支払いのみに制限しつつ、各支払いに複数人の承認を求めることで、両者を組み合わせることができます。

鍵が侵害された場合、マルチシグは盗まれた1つの署名者が承認閾値を満たすのを防げます。権限委任は、委任アカウントが侵害された後でも攻撃者が利用できるトランザクションタイプを制限できます。ただし、いずれの制御も業務上の指示が正当かどうかを検証するものではありません。

初期版はメインネット到達前に失敗

コミュニティのテスターが、最初のPermissionDelegation実装において、一定の条件下で、委任トランザクションが不適切に署名された場合でも別のアカウントにトランザクション手数料を請求できる可能性があることを発見しました。高額手数料の送信を繰り返すことで、秘密鍵を明かすことなく被害者のXRP残高が減少するおそれがありました。

この不具合はテスト中に発見され、修正案がメインネットで発動されることはありませんでした。公式の脆弱性開示では、ライブのユーザー資金の損失は報告されていません。

Coindooは以前、Permission Delegationがxrpld 3.3.0の修正案群とともに改訂版として復活した理由を検証しました。今回の新たな投票は、バリデータが後継案の発動を検討する用意ができたことを示しています。

発動だけでは機関採用は確立されない

ウォレットやカストディ各社は、委任権限の作成、確認、取り消しのためのインターフェースを依然として構築する必要があります。特定の銀行による展開は発表されておらず、どのアカウントにどの権限を付与するかは機関自身が判断する責任を負います。

コンプライアンスの決定もレジャー外に留ま。企業は引き続き、自社のシステムを通じて本人確認、制裁スクリーニング、リスクレビューを実施します。XRPLはどの委任先がその承認を送信できるかを強制しますが、顧客を承認すべきかどうかを判断するわけではありません。

この機能の利用は公開されたDelegateエントリを通じて確認できますが、アドレスを企業に紐付けるには自主的な開示が必要な場合があります。委任アカウントにもリザーブと手数料のためにXRPが必要ですが、発動しても利用量やトークンへの自動的な需要が生まれるわけではありません。

実運用が次の試金石

バリデータの支持が維持されれば、ウォレットの統合、新しいDelegateエントリ、名前の明らかされた導入事例などが証拠となります。これらのシグナルは、組織がアカウントの所有と日常業務のプロトコルレベルでの分離を必要としているかどうかを示すことになります。

今回の投票によりアカウントへの限定アクセスが可能になります。その価値は、組織が権限をどれだけ狭く設定するか、またデモ以外でこの機能を利用するかどうかに左右されます。

本記事は情報提供のみを目的としており、金融、法務またはセキュリティに関する助言を構成するものではありません。バリデータの支持状況と発動時期は変更される可能性があります。