XRP LedgerのPermissioned Domain機能
はじめに
この記事はXLS-80: Permissioned Domainを紹介するものです。
Permissioned Domain
概要
この提案では、Permissioned Domains（認可ドメイン）の概念が紹介されています。Permissioned Domains（認可ドメイン）は、より広範なシステム内で管理された環境を構築し、ユーザのやりとりや資産の流れに特定のルールや制限を適用することを可能にします。このアプローチは、分散型ブロックチェーン技術の透明性とセキュリティのメリットと、従来の金融機関の規制要件とのギャップを埋めることを目的としています。
1. 概要
この提案は、XLS-70d を基に作成されています。認可には資格情報が必要であるためです。
私たちは次のことを提案します。
- レジャーオブジェクト
PermissionedDomainの作成 - トランザクション
PermissionedDomainSetの作成 - トランザクション
PermissionedDomainDeleteの作成
この機能にはAmendmentが必要です。この機能自体はXRPLに何らかの機能をもたらすものではないため、代わりにそれを使用する他のAmendmentによって制限されることになります。
1.1. 用語
- ドメイン：アカウントがその一部となる可能性があることを示すルールの集合。この仕様にはcredential-gatingが含まれますが、将来的にさらにオプションが追加される可能性があります。ドメインは「誰が参加できるか」に焦点を当てています。「どのように参加できるか」(例えば、使用可能なトークンなど)の側面は、使用されるプリミティブの他の方法で実行できます。
- ドメインのルール：ドメインを管理する一連のルール、すなわちドメインが受け入れる資格情報。
- ドメインのオーナー：ドメインを作成したアカウントであり、そのルールを変更したり、ドメインを削除できる唯一の存在。
- ドメインメンバー：ドメインのルールを満たすアカウント(すなわち、ドメインが受け入れる資格情報のいずれかを持つアカウント)。明示的な参加手順はありません。有効な資格情報を持つアカウントは、メンバーとなります。
2. レジャーオブジェクト：PermissionedDomain
このオブジェクトは、許可されたドメインを表します。
2.1. フィールド
| フィールド名 | 必須？ | JSONの型 | 内部の型 | 説明 |
|---|---|---|---|---|
LedgerEntryType |
✔️ | string |
UInt16 |
レジャーオブジェクトのタイプ（PermissionedDomain）。 |
Owner |
✔️ | string |
AccountID |
ドメインの設定を制御するアカウント。 |
OwnerNode |
✔️ | string |
UInt64 |
ディレクトリが複数のページで構成されている場合に、送信者の所有者ディレクトリのどのページがこのオブジェクトにリンクされているかを示すヒント。 |
Sequence |
✔️ | number |
UInt32 |
このドメインを作成したPermissionedDomainSetトランザクションのSequence値。このドメインを識別するために、Accountと組み合わせて使用します。 |
AcceptedCredentials |
✔️ | array |
STArray |
ドメインが受け入れる資格情報。これらの認証情報のいずれかの所有者になると、自動的にドメインのメンバーになります。 |
PreviousTxnID |
✔️ | string |
Hash256 |
このエントリを最後に変更したトランザクションの識別ハッシュ。 |
PreviousTxnLgrSeq |
✔️ | number |
UInt32 |
このオブジェクトを最後に変更したトランザクションを含むレジャーインデックス。 |
2.1.1. LedgerIndex
このオブジェクトのIDは、実装時に定義されるPermissionedDomainオブジェクトの固有のスペースキーと結合された、OwnerおよびSequenceフィールドを組み込んだハッシュとなります。
この値は、DomainIDとして必要なあらゆる場所で使用されます。
2.1.2. AcceptedCredentials
これは、資格情報の種類を参照する内部オブジェクトの配列です。この配列の最大長は10です。
この配列は「発行者」でソートされるため、一致するものを検索する際にパフォーマンスが向上します。
| フィールド名 | 必須？ | JSON 型 | 内部型 | 説明 |
|---|---|---|---|---|
Issuer |
✔️ | string |
AccountID |
資格情報の発行者。 |
CredentialType |
✔️ | string |
Blob |
発行者からの資格情報のタイプを識別するための（16進数エンコードされた）値。最大長は64バイト(XLS-70による)です。 |
2.2. アカウントの削除
PermissionedDomain オブジェクトは削除ブロッカーです。
3. トランザクション: PermissionedDomainSet
このトランザクションは、PermissionedDomainオブジェクトを作成または変更します。
3.1. フィールド
| フィールド名 | 必須？ | JSONの型 | 内部の型 | 説明 |
|---|---|---|---|---|
TransactionType |
✔️ | string |
UInt16 |
トランザクションの種類(PermissionedDomainSet)。 |
Account |
✔️ | string |
AccountID |
トランザクションを送信するアカウント。 |
DomainID |
string |
Hash256 |
変更するドメイン。既存のドメインを変更する場合は、このフィールドを含める必要があります。 | |
AcceptedCredentials |
✔️ | array |
STArray |
ドメインが受け入れる資格情報。これらの資格情報のいずれかの所有者は、自動的にドメインのメンバーとなります。空の配列は、フィールドの削除を意味します。 |
3.2. エラー条件
-
AcceptedCredentialsのいずれかの資格情報にIssuerフィールドが存在しない。 -
AcceptedCredentials配列が空であるか、長すぎる（最大10件）。 -
AcceptedCredentialsのいずれかの資格情報で、CredentialTypeが空であるか、またはCredentialTypeが64バイト(XLS-70による)を超えている。 -
DomainIDが含まれている場合：- そのドメインが存在しない。
-
Accountがドメインの所有者ではない。
3.3. ステートの変更
トランザクションが成功した場合:
-
PermissionedDomainオブジェクトが作成または変更される。
4. トランザクション: PermissionedDomainDelete
このトランザクションは、PermissionedDomainオブジェクトを削除します。
4.1. フィールド
| フィールド名 | 必須？ | JSONの型 | 内部の型 | 説明 |
|---|---|---|---|---|
TransactionType |
✔️ | string |
UInt16 |
トランザクションの種類(PermissionedDomainDelete)。 |
Account |
✔️ | string |
AccountID |
トランザクションを送信するアカウント。 |
DomainID |
✔️ | string |
Hash256 |
削除するドメイン。 |
4.2. エラー条件
-
DomainIDで指定されたドメインが存在しない。 - アカウントがドメインの所有者ではない。
4.3. 状態の変更
トランザクションが成功した場合、
-
PermissionedDomainオブジェクトが削除される。
5. 例
ドメインオブジェクトのサンプルは以下のようになります（共通フィールドは無視しています）。
{
Owner: 'rOWEN......',
Sequence: 5,
AcceptedCredentials: [
{
Credential: {
Issuer: 'rISABEL......',
CredentialType: '123ABC'
}
}
]
}
6. 不変条件
- ルールのないドメインは存在できません。
-
AcceptedCredentials配列は、1から10の長さでなければなりません。
7. セキュリティ
7.1. 発行者の信頼
資格情報を外部発行者に依存するには、ある程度の信頼が必要です。発行者の資格情報が侵害されたり偽造されたりした場合、システムは脆弱になります。
7.2. ドメイン作成者の信頼
ユーザは独自のドメインを作成できますが、ドメイン作成者に対する信頼は依然として重要です。悪意のあるドメイン作成者（またはハッカー）は、ドメインのユーザを違法な流動性にさらす可能性があります。
付録
付録 A: FAQ
A.1: なぜ「PermissionedDomain」という名称がこれほど長いのでしょうか。「Domain」と短縮しないのはなぜでしょうか。
「ドメイン」という用語はすでにAccountSetで使用されているため、この用語だけを使用すると混乱を招く可能性があります。
A.2: ドメインのオーナーは資格情報(Credential)発行者にもなれますか？
はい。
A.3: ドメインに他のタイプのルールを追加できますか？
はい、必要であれば可能です（ただし、トークンなどの参加の他の側面よりも、「誰が参加できるか」に焦点を当てる必要があります）。
A.5: 資格情報(Credential)とAND条件で利用できますか？
いいえ、その機能の設計を明確に行うことが困難なためです。
A.6: ドメイン所有者は、承認されたクレデンシャルに対して特別な権限を持っていますか？
いいえ(ドメイン所有者が当該の資格情報の発行者でない限り)。
A.7: ドメイン所有者は資格情報を保持する必要がありますか？
いいえ。
A.8: すべてのドメインルールを1つのオブジェクトにまとめるのではなく、ドメインルールごとにレジャーオブジェクトを作成するのはなぜですか？そうすれば、ドメインが持つことのできるルールの数に制限がなくなります。
これはうまくいきません。
すべてのドメインルールが確実に順守されるように、レジャーはドメインルールを順に処理する必要があります。ドメイン所有者が何百万ものオブジェクト（または何百万ものルール）を所有している場合、それらすべてのオブジェクトを順に処理することは、パフォーマンスの観点から非常に高コストになります。
Discussion