XRP LedgerのDeep Freeze機能
はじめに
この記事はXLS-77dとして提案されているDeep Freeze機能を紹介するものです。
この提案はまだ確定しているものではないため、今後変更される可能性があります。
Deep-freeze
概要
このAmendmentは、XRP Ledger上のトークン発行者が、凍結されたアカウント保有者によるトークンの不正使用を防止する機能を提供します。この文書では、凍結された資産と支払いの間の相互作用を強化し、トラストラインが解除されるまで凍結されたトークン保有者が資金を受け取れないようにすることを概説しています。これらの変更により、トークン発行者はXRPL上の規制をより容易に遵守できるようになります。例えば、制裁リストに記載されたウォレットへのトークンの流れを防止し、規制対象のステーブルコインや現実資産(RWA)などのユースケースにおけるコンプライアンスを強化します。
1. 概要
この提案は、支払い、オファー、DEX、AMMと相互作用する新しいDeep-freeze機能をトラストラインに導入します。本質的に、発行者はDeep-freezeされた保有者の資金の送受信をブロックすることができます。
2. 仕様
2.1. Deep-freezeメカニズム
Deep-freeze機能はトラストライン上の設定であり、発行者がDeep-freezeを実行する前に、トラストラインを「通常のfreeze」している必要があります。発行者がNo Freezeをアカウントで有効にしている場合、Deep-freezeを実行することはできません。
発行者がDeep-freezeを実行すると、そのトラストライン上のトークンに以下のルールが適用されます。
- Deep-freezeされたトラストラインの両当事者間での直接の支払いは引き続き可能です。
- そのトラストラインの相手方は、発行者への直接支払いを除いて、Deep-freezeされたトラストライン上の残高を 増減できなくなります。相手方はDeep-freezeされた通貨を発行者にのみ送信できます。
- 相手方はDeep-freezeされたトラストラインで他者との送受信ができません
- 相手方のDeep-freezeされたトラストライン上のトークンの売買オファーは未払いとみなされます
個々のアドレスは、発行者または金融機関へのトラストラインをDeep-freezeすることができます。これは金融機関と他のユーザ間の直接的な取引には影響しません。ただし、以下の効果があります。
- 第三者のアドレスがその金融機関のトークンをそのアドレスに送信することを防ぎます。
- また、そのアドレスが発行者以外のアドレスにトークンを送信することを防ぎます。
2.1.1. RippleStateオブジェクト
RippleState(トラストライン)オブジェクトにlsfLowDeepFreezeとlsfHighDeepFreezeという2つの新しいフラグが追加されます。
| フラグ名 | フラグ値 | 説明 |
|---|---|---|
lsfLowDeepFreeze |
0x02000000 |
lowアカウントがトラストラインをDeep-freezeし、highアカウントが資産を送受信できないようにします。 |
lsfHighDeepFreeze |
0x04000000 |
highアカウントがトラストラインをDeep-freezeし、lowアカウントが資産を送受信できないようにします。 |
2.1.2. TrustSetトランザクション
TrustSetトランザクションにtfSetDeepFreezeとtfClearDeepFreezeという2つの新しいフラグが導入されます。
| フラグ名 | フラグ値 | 説明 |
|---|---|---|
tfSetDeepFreeze |
0x00400000 |
トラストラインをDeep-freezeします。 |
tfClearDeepFreeze |
0x00800000 |
トラストラインのDeep-freezeを解除します。 |
tfSetDeepFreezeを設定しようとするTrustSetトランザクションは、以下のいずれかが真である場合にのみ成功します。
- 保有者が既にfreeze状態である(トラストライン上の
lsfLowFreeze/lsfHighFreezeで示される) - 同じ
TrustSetトランザクションでtfSetFreezeフラグも設定されている
TrustSetには以下の追加制限も導入されます。
- トラストラインが発行者によってDeep-freeze状態である場合(
lsfLowDeepFreeze/lsfHighDeepFreezeで示される)、発行者がtfClearDeepFreezeフラグも設定せずにtfClearFreezeフラグを設定すると、TrustSetトランザクションは失敗します。つまり、発行者はDeep-freezeも解除しない限り、トラストライン上の通常のfreezeを解除することはできません。
2.2. 支払いエンジン
支払いエンジンは、送信者と受信者を接続するステップで構成されたパスを実行します。一般的に、トラストラインへの資金の預け入れは以下の2つのステップのいずれかを通じて行われます。
- Rippling
- オーダーブックまたはAMM
この提案は、Deep-freezeされたトラストラインが残高を 増やせない ようにするため、上記の両方のステップに変更を提案します。
2.2.1. Rippling
この提案は次の更新を提案します。
Ripplingステップの結果としてDeep-freezeされたトラストラインへの資金の受け取りは失敗します。
例
Deep-freezeがRipplingに与える影響の例を見てみましょう。
+-------+ USD +---------+ USD +-------+
| Alice | ----------------------> | Gateway | ----------------------> | Bob |
+-------+ +---------+ (Bobはdeep-freeze状態) +-------+
以下のシナリオを考えてみましょう。
- 発行者アカウントがAliceとBobの両方にUSDを発行し、それぞれがトラストラインを持っています。
- 発行者は
tfSetFreezeとtfSetDeepFreezeフラグを設定したTrustSetを送信して、Bobのトラストラインをdeep-freezeします。 - AliceがBobにUSDの
Paymentを送信しようとします。BobのUSDトラストラインがdeep-freeze状態で資金を受け取れなくなっているため、トランザクションは 失敗 します。
2.2.2. オーダーブックとAMM
支払いエンジンでは、クロスカレンシー支払いが関与する場合、パスでオファーとAMMプールが消費され、トラストラインの残高が変更される可能性があります。この提案は、トラストラインがdeep-freeze状態の場合のオーダーブックステップの動作変更を導入します。
2.2.2.1. オーダーブック
この提案はオーダーブックステップに次の変更を導入します。
オファー所有者がTakerPaysトークン(購入額)についてdeep-freeze状態の場合、オファーは 未払い とみなされ、ステップは失敗します。
例
Deep-freezeがオーダーブックに与える影響の例を見てみましょう。
Bobのオファー
+-------+ USD +---------+ USD +--------------+ XRP +-------+
| Alice | ---------------------> | Gateway | ---------------> | 売り: 100 XRP| -----------> | Carol |
+-------+ SendMax: 100 USD +---------+ +--------------+ +-------+
Amount: 100 XRP | 買い: 100 USD |
+--------------+
(Bobはdeep-freeze状態)
以下のシナリオを考えてみましょう。
- 発行者アカウントがAliceとBobの両方にUSDを発行し、それぞれがトラストラインを持っています。
- 発行者は
tfSetFreezeとtfSetDeepFreezeフラグを設定したTrustSetを送信して、Bobのトラストラインをdeep-freezeします。 - AliceはBobのオファーを使用してUSDとXRPを交換する
Paymentトランザクションを通じて、CarolにXRPを送信しようとします。Bobのオファーはdeep-freezeされたトラストラインにより未払いとなるため、AliceはCarolへのXRP送信に失敗します。
2.2.2.2. AMM
現在、関与する資産についてAMMアカウントがfreeze状態の場合、AMMステップは失敗するため、AMMステップは変更を必要としません。資産がdeep-freeze状態の場合、既に通常のfreeze状態となっているため、追加のチェックは必要ありません。
2.3. OfferCreateトランザクション
この提案はOfferCreateトランザクションに新しい変更を導入します。
-
TakerPays(購入額)トークンが発行者によって deep-freeze されている場合、OfferCreateはtecFROZENを返します
さらに、TakerPaysトークンについてdeep-freeze状態となっている所有者の既存のオファーは、もはや約定できず、それをクロスする新しいオファーによって暗黙的にキャンセルされる 未払い オファーとみなされます。
2.4. AMMWithdrawトランザクション
この提案では、deep-freezeされたすべてのトークンが既に通常のfreeze状態となっており、通常のfreezeまたはdeep-freezeされたトークンの引き出しが防止されているため、deep-freezeによるAMMWithdrawトランザクションの変更は必要ありません。
3. 不変条件
考えられる不変条件。
- あらゆる種類のトランザクションの結果として、deep-freezeされたトラストラインの残高が増加することを禁止します。
- トラストラインは
lsfLowFreezeフラグも設定されていない限りlsfLowDeepFreezeフラグを設定できず、lsfHighDeepFreezeフラグについても同様です。
4. よくある質問
新しいフラグを導入せずに、既存のfreezeに受信禁止を組み込むことはできないのですか？
既存のfreeze機能を変更して受信を禁止することは、現在のユーザーのワークフローを混乱させる可能性のある重大な破壊的変更となります。代わりに、既存の動作に影響を与えることなく、追加の柔軟性を提供する設定可能なフラグを導入する方が望ましいです。
これを「block-receiving」という別の機能にすることはできないのですか？
block-receiving機能は、既存のfreeze機能と類似点があります。両者とも、未承認または制裁リストに載っている当事者による資金の移動を防ぐことを目的としているためです。別の機能として作成すると、機能を切り替えるための新しいアカウントレベルのフラグを追加する必要があるなど、不必要な複雑さが生じます。既存のフレームワークに統合することで、これらの複雑さを避けながら一貫性を維持できます。
MPTのfreeze/lockの動作はIOUとどのように異なりますか？
MPTのfreeze/lock機能は、今日のIOUの動作とは若干異なります。MPT保有者がロックされると、MPT支払いの送受信ができなくなるため、単一のフラグで十分です。対照的に、IOUの場合、通常のfreezeは送信のみを禁止します。発行者が受信も禁止したい場合は、deep-freezeを適用する必要があります。
Discussion