🧐

XRP LedgerのAccountPermission機能

2024/12/11に公開

ブロックチェーン

 はじめにこの記事はXLS-75dとして提案されているAccount Permission Delegationを紹介するものです。
原文
この提案はまだ確定しているものではないため、今後変更される可能性があります。

 Account Permission Delegation
 概要この提案は、XRPLアカウントの柔軟性と使いやすさを向上させるためのアカウント権限の委任機能を導入するものです。
現在、トラストラインの承認などの重要な発行者アクションには、アカウントの鍵による直接的な制御が必要であり、運用効率と複雑なユースケースの実現を妨げています。アカウント保有者が特定の権限を他のアカウントに選択的に委任できるようにすることで、この提案はセキュリティを損なうことなくアカウントの使いやすさを向上させることを目指しています。このメカニズムにより、マルチパーティワークフローや高度なアカウント管理戦略など、XRPLアプリケーションの新しい可能性が開かれます。

 1. 概要以下を提案します。

AccountPermissionレジャーオブジェクトの作成

AccountPermissionSetトランザクションタイプの作成
また、トランザクションの共通フィールドの追加も提案します。
この機能にはAccountPermission(仮称) Amendmentが必要となります。

 1.1. 用語
委任アカウント: 他のアカウントに権限を委任するメインアカウント

被委任アカウント: 権限を委任される側のアカウント

 1.2. 基本的なフロートークン発行者のIsaacは、セキュリティのベストプラクティスと責任の分離に従ってアカウントを設定したいと考えています。彼はAliceにトークン発行の管理を、Bobにトラストラインの管理を任せたいと考えています。また、KYCプロバイダーのKylieと協力しており、彼女にトラストラインの承認権限を与えたいと考えていますが、他の権限は与えたくありません（彼女は外部の関係者であるため）。
Issacは以下の権限を付与できます。
AliceのアカウントにPaymentトランザクションの権限
BobのアカウントにTrustSetトランザクションの権限
KylieのアカウントにTrustlineAuthorizeの詳細な権限
利用可能な権限の完全なリストはXLS-74d, Account Permissionsに記載されています。

 2. レジャーオブジェクト: AccountPermission
このオブジェクトは、アカウントが他のアカウントに委任した権限のセットを表し、DepositPreauthオブジェクトと同様のモデルとなっています。

 2.1. フィールド

フィールド名
必須?
JSONタイプ
内部タイプ
説明


LedgerIndex
✔️
string
Hash256
レジャーオブジェクトの一意のID

LedgerEntryType
✔️
string
UInt16
レジャーオブジェクトのタイプ(AccountPermission)

Account
✔️
string
AccountID
他のアカウントを承認したいアカウント

Authorize
✔️
string
AccountID
承認されたアカウント

Permissions
✔️
string
STArray
アカウントがアクセスできるトランザクション権限

OwnerNode
✔️
string
UInt64
送信者の所有者ディレクトリが複数のページで構成される場合に、どのページがこのオブジェクトにリンクしているかを示すヒント

PreviousTxnID
✔️
string
Hash256
このオブジェクトを最後に変更したトランザクションの識別ハッシュ

PreviousTxnLgrSeq
✔️
number
UInt32
このオブジェクトを最後に変更したトランザクションを含むレジャーのインデックス


 2.1.1. オブジェクトIDこのオブジェクトのIDは、AccountとAuthorizeフィールドのハッシュと、実装時に定義されるAccountPermissionオブジェクト用の一意のスペースキーを組み合わせたものになります。

 2.1.2. Permissions
このフィールドは、XLS-74d, Account Permissionsにリストされているアカウントに委任する権限の配列です。配列の最大長は10です。

 2.2. アカウントの削除AccountPermissionオブジェクトは削除ブロッカーではありません。

 3. トランザクション: AccountPermissionSet
このオブジェクトは、アカウントが他のアカウントに委任した権限のセットを表し、DepositPreauthトランザクションタイプと同様のモデルとなっています。

 3.1. フィールド

フィールド名
必須?
JSONタイプ
内部タイプ
説明


TransactionType
✔️
string
UInt16
トランザクションタイプ(AccountPermissionSet)

Account
✔️
string
AccountID
他のアカウントを承認したいアカウント

Authorize
✔️
string
AccountID
承認されたアカウント

Permissions
✔️
string
STArray
アカウントに付与されたトランザクション権限


 3.1.1. Permissions
このトランザクションはDepositPreauthトランザクションタイプとは少し異なる動作をします。Unauthorizeフィールドを使用する代わりに、空のPermissionsリストを使用してアカウントの承認を解除します。

 3.2. 失敗条件
Permissionsが長すぎる(上限10)、または重複がある場合
指定された権限のいずれかが無効な場合

Authorizeで指定されたアカウントが存在しない場合

 3.3. 状態の変更提供されたフィールドに基づいて、AccountPermissionオブジェクトが作成、変更、または削除されます。

 4. トランザクション: 共通フィールド
 4.1. フィールド参考として、こちらに現在すべてのトランザクションの共通フィールドがあります。
以下フィールドの追加を提案します。


フィールド名
必須?
JSONタイプ
内部タイプ
説明


OnBehalfOf

string
AccountID
トランザクションが代理で送信されるアカウント


 4.2. 失敗条件
OnBehalfOfアカウントが存在しない場合

OnBehalfOfアカウントがトランザクションのAccountに代理でトランザクションを送信する権限を与えていない場合

OnBehalfOfアカウントがトランザクションのAccountに特定のトランザクションタイプ/詳細な権限を代理で送信する権限を与えていない場合

 4.3. 状態の変更トランザクションはOnBehalfOfアカウントから送信されたかのように成功します。

 5. 例
 5.1. Payment権限この例では、IsaacがAliceにPaymentの権限を委任しています。

 5.1.1. AccountPermissionSetトランザクション{
  TransactionType: "AccountPermissionSet",
  Account: "rISAAC......",
  Authorize: "rALICE......",
  Permissions: [{ Permission: { PermissionValue: "Payment" } }],
}
注: Permissionsの特殊なフォーマット(内部オブジェクトが必要)は、XRPLのバイナリフォーマットの特殊性によるものです。ツールで簡略化/単純化することができます。

 5.1.2. AccountPermissionレジャーオブジェクト{
  LedgerEntryType: "AccountPermission",
  Account: "rISAAC......",
  Authorize: "rALICE......",
  Permissions: [{ Permission: { PermissionValue: "Payment" } }],
}

 5.1.3. Paymentトランザクション{
  Transaction: "Payment",
  Account: "rALICE......",
  Amount: "1000000000",
  Destination: "rCHARLIE......",
  OnBehalfOf: "rISAAC......"
}

 5.2. TrustSet権限この例では、IsaacがBobにTrustSetの権限を委任しています。

 5.2.1. AccountPermissionSetトランザクション{
  TransactionType: "AccountPermissionSet",
  Account: "rISAAC......",
  Authorize: "rBOB......",
  Permissions: [{ Permission: { PermissionValue: "TrustSet" } }],
}

 5.2.2. AccountPermissionレジャーオブジェクト{
  LedgerEntryType: "AccountPermission",
  Account: "rISAAC......",
  Authorize: "rBOB......",
  Permissions: [{ Permission: { PermissionValue: "TrustSet" } }],
}

 5.2.3. TrustSetトランザクションこの例では、BobがUSD.Isaacトークン保有者であるHoldenのトラストラインを凍結しています。
{
  Transaction: "TrustSet",
  Account: "rBOB......",
  LimitAmount: {
  currency: "USD",
  issuer: "rHOLDEN......",
    value: "0",
  },
  Flags: 0x00100000, // tfSetFreeze
  OnBehalfOf: "rISAAC......"
}

 5.3. TrustlineAuthorize権限この例では、IsaacがKylieにTrustlineAuthorizeの権限を委任しています。

 5.3.1. AccountPermissionSetトランザクション{
TransactionType: "AccountPermissionSet",
Account: "rISAAC......",
  Authorize: "rKYLIE......",
  Permissions: [{ Permission: { PermissionValue: "TrustlineAuthorize" } }],
}

 5.3.2. AccountPermissionオブジェクト{
  LedgerEntryType: "AccountPermission",
  Account: "rISAAC......",
  Authorize: "rKYLIE......",
  Permissions: [{ Permission: { PermissionValue: "TrustlineAuthorize" } }],
}

 5.3.3. TrustSetトランザクションこの例では、KylieがHoldenのトラストラインを承認しています。
{
  Transaction: "TrustSet",
  Account: "rBOB......",
  LimitAmount: {
    currency: "USD",
issuer: "rHOLDEN......",
value: "0",
  },
  Flags: 0x00010000, // tfSetfAuth
  OnBehalfOf: "rISAAC......"
}
以下の場合、このトランザクションは失敗します。
Holdenとのトラストラインが存在しない場合
KylieがtfSetfAuthフラグ以外のトラストライン設定を変更しようとした場合

 6. 不変条件有効なAccountPermissionオブジェクトなしに、アカウントが他のアカウントの代理でトランザクションを送信することは決してできないようにすべきです。

 7. セキュリティ他のアカウントへの権限の委任には高度な信頼が必要です。特に、委任されたアカウントが資金(Payment)にアクセスできたり、準備金を利用できる(オブジェクトを作成するトランザクション)場合はなおさらです。さらに、AccountSet、SetRegularKey、SignerListSet、またはAccountPermissionSetトランザクション全体にアクセスできるアカウントは、当初の意図になかった場合でも、自身にあらゆる権限を与えることができます。これらのトランザクションへの承認には、ツールやUIで重要な警告を表示する必要があります。
アカウントがブラックホール化されているかどうかを示すすべてのツールは、AccountSet、SetRegularKey、SignerListSet、またはAccountPermissionSetの権限が委任されているかどうかもチェックするように更新する必要があります。
一方で、このメカニズムは権限付与に対する詳細なアプローチも提供し、アカウントの全体的な制御を損なうことなく、特定の権限を選択的に委任することを可能にします。このアプローチは、セキュリティと使いやすさのバランスを取り、アカウント保有者がより効果的に資産と相互作用を管理できるようにします。

 付録
 付録A: XLS-49d、Multiple Signer Listsとの比較XLS-49dでは
デフォルトでマルチシグをサポート
署名者リストは委任アカウントが制御
権限ごとに最大1つのリスト(最大32の署名者)
署名者リストごとに1つの準備金
委任アカウントがトランザクション手数料を支払う
この提案では
直接的なマルチシグサポートはない(ただし、マルチシグ設定を持つアカウントに権限を委任することは可能)
委任されたアカウントの秘密鍵は自己管理(委任アカウントは委任先アカウントの署名者リストを制御しない)
準備金を負担することで、権限を任意の数のアカウント/署名者リストに委任可能
委任されたアカウントごとに1つの準備金
委任されたアカウントがトランザクション手数料を支払う
両者は若干異なるユースケースに有用です。XLS-49dは特定の機能を複数の署名で保護したい場合に有用で、この提案は特定の当事者に特定の機能へのアクセスを与えたい場合に有用です。この提案はXLS-49dのようなユースケースもサポートしますが、2つ目のアカウントを作成する必要があるため、より多くのXRPを必要とします。

 付録B: FAQ
 B.1: 誰がトランザクション手数料を支払うのですか？トランザクションを送信するアカウント(委任アカウント(OnBehalfOf)ではなく、委任されたアカウント(Account))が手数料を支払います。

 B.2: NFTokenMintの権限の使用は、既存のNFTokenMinterアカウントフィールドの使用とどのように比較されますか？NFTokenMinterフィールドはNFTokenMint以外の権限も提供することに注意してください。オファーやバーンに関する権限も提供します(もちろん、複数の権限を1つのアカウントに委任することは可能です)。
NFTokenMintフィールドを使用する最大の利点は、「無料」(追加の準備金が不要)であることです。本提案を使ってアカウントに権限を委任するには、1つのオブジェクト準備金(AccountPermissionオブジェクト用)が必要です。
一方、この提案では、必要な数のアカウントにNFTokenMint権限を持たせることができます。また、ミントアカウントは自身のアカウントではなく、直接あなたのアカウントにNFTをミントすることができます。
機能が重複していることを考えると、将来的にNFTokenMinterフィールドは非推奨になる可能性があります。

 B.3: ブラックホール化されたアカウントに権限を設定できますか？はい、特定のケースでは可能です。例えば、AccountDomainSet権限が委任されている場合でもアカウントは「ブラックホール化」とみなされますが、SetRegularKey権限が委任されている場合はそうではありません。ブラックホール化されたアカウントの定義は、このAmendment後に修正される必要があります。

 B.4: Batchトランザクション(XLS-56d)に権限を委任できますか？いいえ、BatchトランザクションではOnBehalfOfは許可されません。代わりに、内部トランザクションにOnBehalfOfフィールドを含めることができます。

 B.5: なぜアカウントの承認解除のプロセスがDepositPreauthトランザクションとAccountPermissionSetトランザクションで異なるのですか？DepositPreauthトランザクションにはUnauthorizeフィールドがあります。ここでそのようなパラダイムを使用するとより混乱を招くように思われましたが、強い反対があれば変更することができます。

フィールド名	必須?	JSONタイプ	内部タイプ	説明
`LedgerIndex`	✔️	`string`	`Hash256`	レジャーオブジェクトの一意のID
`LedgerEntryType`	✔️	`string`	`UInt16`	レジャーオブジェクトのタイプ(`AccountPermission`)
`Account`	✔️	`string`	`AccountID`	他のアカウントを承認したいアカウント
`Authorize`	✔️	`string`	`AccountID`	承認されたアカウント
`Permissions`	✔️	`string`	`STArray`	アカウントがアクセスできるトランザクション権限
`OwnerNode`	✔️	`string`	`UInt64`	送信者の所有者ディレクトリが複数のページで構成される場合に、どのページがこのオブジェクトにリンクしているかを示すヒント
`PreviousTxnID`	✔️	`string`	`Hash256`	このオブジェクトを最後に変更したトランザクションの識別ハッシュ
`PreviousTxnLgrSeq`	✔️	`number`	`UInt32`	このオブジェクトを最後に変更したトランザクションを含むレジャーのインデックス

フィールド名	必須?	JSONタイプ	内部タイプ	説明
`TransactionType`	✔️	`string`	`UInt16`	トランザクションタイプ(`AccountPermissionSet`)
`Account`	✔️	`string`	`AccountID`	他のアカウントを承認したいアカウント
`Authorize`	✔️	`string`	`AccountID`	承認されたアカウント
`Permissions`	✔️	`string`	`STArray`	アカウントに付与されたトランザクション権限

はじめに

Account Permission Delegation

概要

1. 概要

1.1. 用語

1.2. 基本的なフロー

2. レジャーオブジェクト: AccountPermission

2.1. フィールド

2.1.1. オブジェクトID

2.1.2. Permissions

2.2. アカウントの削除

3. トランザクション: AccountPermissionSet

3.1. フィールド

3.1.1. Permissions

3.2. 失敗条件

3.3. 状態の変更

4. トランザクション: 共通フィールド

4.1. フィールド

4.2. 失敗条件

4.3. 状態の変更

5. 例

5.1. Payment権限

5.1.1. AccountPermissionSetトランザクション

5.1.2. AccountPermissionレジャーオブジェクト

5.1.3. Paymentトランザクション

5.2. TrustSet権限

5.2.1. AccountPermissionSetトランザクション

5.2.2. AccountPermissionレジャーオブジェクト

5.2.3. TrustSetトランザクション

5.3. TrustlineAuthorize権限

5.3.1. AccountPermissionSetトランザクション

5.3.2. AccountPermissionオブジェクト

5.3.3. TrustSetトランザクション

6. 不変条件

7. セキュリティ

付録

付録A: XLS-49d、Multiple Signer Listsとの比較

付録B: FAQ

B.1: 誰がトランザクション手数料を支払うのですか？

B.2: NFTokenMintの権限の使用は、既存のNFTokenMinterアカウントフィールドの使用とどのように比較されますか？

B.3: ブラックホール化されたアカウントに権限を設定できますか？

B.4: Batchトランザクション(XLS-56d)に権限を委任できますか？

B.5: なぜアカウントの承認解除のプロセスがDepositPreauthトランザクションとAccountPermissionSetトランザクションで異なるのですか？

Discussion

2. レジャーオブジェクト: `AccountPermission`

2.1.2. `Permissions`

3. トランザクション: `AccountPermissionSet`

3.1.1. `Permissions`

5.1. `Payment`権限

5.1.1. `AccountPermissionSet`トランザクション

5.1.2. `AccountPermission`レジャーオブジェクト

5.1.3. `Payment`トランザクション

5.2. `TrustSet`権限

5.2.1. `AccountPermissionSet`トランザクション

5.2.2. `AccountPermission`レジャーオブジェクト

5.2.3. `TrustSet`トランザクション

5.3. `TrustlineAuthorize`権限

5.3.1. `AccountPermissionSet`トランザクション

5.3.2. `AccountPermission`オブジェクト

5.3.3. `TrustSet`トランザクション

B.2: `NFTokenMint`の権限の使用は、既存の`NFTokenMinter`アカウントフィールドの使用とどのように比較されますか？

B.4: `Batch`トランザクション(XLS-56d)に権限を委任できますか？

B.5: なぜアカウントの承認解除のプロセスが`DepositPreauth`トランザクションと`AccountPermissionSet`トランザクションで異なるのですか？