翻訳: ほうれん草ほうれん草!ソース：＃＃＃ 序章デジタル資産とは、金融資産や実物経済資産の所有権など、価値のデジタル表現を指します。デジタル資産エコシステムには、より効率的な取引を促進し、金融包摂を高め、経済的価値を引き出す可能性があります。中央銀行デジタル通貨（CBDC）、トークン化された銀行負債、および潜在的に十分に規制されたステーブルコインは、精巧な一連のスマートコントラクトと組み合わせることで、この新しいデジタル資産エコシステムの交換媒体として機能する可能性があります。初期の試験では可能性が示されているものの、ブロックチェーンやピアツーピアの資金の流れで普及しているこれらの新しい形式のデジタル通貨は、現在すでに存在している国内の即時決済システムなどの電子決済システムを超えた有用性を証明する必要があります。提供された。デジタル通貨の大きな利点の 1 つは、プログラム機能のサポートです。ただし、これは現在も議論と議論が行われているテーマです。事業者は、プログラム可能性が交換媒体として機能するデジタル通貨の能力を犠牲にしないようにする必要があります。通貨の単一性は維持されるべきであり、プログラム性によって通貨の流通が制限され、システム内の流動性の断片化を招いてはなりません。この記事では、お金自体をプログラムすることなくお金を特定の目的に向けることを可能にする目的限定お金 (PBM) の概念の技術概要を説明します。 PBM は、さまざまな台帳テクノロジーや通貨形式で動作するように設計された共通プロトコルを採用しています。標準化されたフォーマットを通じて、ユーザーは選択したウォレットプロバイダーを使用してデジタル通貨にアクセスできるようになります。このペーパーでは、MAS の Orchid プロジェクトで最初に導入された PBM の概念に基づいて構築し、それをより広範囲のアプリケーション シナリオに拡張する方法について説明します。### 背景と動機業務効率の向上とユーザーエクスペリエンスの向上を目的としたデジタルへの取り組みは、近年大幅な勢いを増しています。ただし、金融におけるデジタル作業には課題がないわけではありません。#### 市場の拡散と細分化決済スキームとプラットフォームの急増により、デジタル金融サービスを導入する際にユーザーが直面する可能性のある複雑さと課題が増大しています。たとえば、決済事業者は多くの場合、スキームごとに異なる特性を持つ流通チャネルを運営しています。スキーム所有者にとって、マーチャントを独自のプラットフォームに組み込むことは非常にリソースを消費します。同時に、他のプラットフォームへの統合により、小売業者の運営上の労力が増大し、さまざまな支払いスキームを処理および受け入れるために小売スタッフを訓練する必要があります。民間の独立した取り組みにより、ユーザー エクスペリエンスを簡素化し、デジタル化の可能性を実現するために、これらの取り組みを単一のプラットフォームに統合することが試みられてきました。ただし、すべての取り組みにわたってオープンで相互運用可能であることを保証するには、これらの取り組みをさらに進める必要があります。これらのプラットフォームは、エコシステムに加入している消費者や販売者に限定されるべきではありません。相互運用可能な決済システムは柔軟性を高め、企業と消費者にシームレスな決済体験を可能にします。#### 通貨のプログラマビリティと代替可能性従来の口座ベースの台帳システムとは異なり、デジタル通貨は、個々の保有資産に固有の特性をプログラムし、デジタル通貨の使用方法を決定する可能性を提供します。ただし、デジタル通貨にプログラミング ロジックを直接実装すると、その特性と交換媒体としての受け入れが変更されます。このアプローチはデジタル通貨の機能を拡張しますが、使用条件が多様かつ動的である場合、実行可能な交換媒体としてのデジタル通貨の使用が制限されます。また、新しい条件やユースケースが必要になるたびに、流通しているすべてのデジタル通貨を再プログラミングする必要もあります。もう 1 つのアプローチは、デジタル通貨の発行者が、それぞれ異なるロジック プログラミングを備えた複数のバージョンのデジタル通貨を提供することです。ただし、これらのデジタル通貨は交換可能ではなく、市場の流動性が断片化しているため、このアプローチは現実的ではない可能性があります。デジタル通貨の代替可能性を維持して自由に交換できるようにする方法を理解するために、この論文ではさまざまなプログラミング モデルを検討します。#### プログラミング モデルプログラム可能な支払いとは、事前に定義された一連の条件が満たされると自動的に実行される支払いを指します。たとえば、口座振替や定期注文と同様に、毎日の支出制限や定期的な支払いを定義できます。プログラム可能な支払いは通常、データベース トリガーを設定するか、会計台帳とクライアント アプリケーションの間にあるアプリケーション プログラミング インターフェイス (API) ゲートウェイの形式で実装されます。これらのプログラムによるインターフェイスは、従来の台帳と対話し、プログラムされたロジックに基づいて銀行口座残高を調整します。プログラマブルマネーとは、価値の保存自体にルールを埋め込み、その使用を定義または制限できる可能性を指します。たとえば、価値の保存をホワイトリストに登録されたウォレットにのみ送信したり、トランザクション レベルのフィルタリングが完了した後に転送したりするようにルールを定義できます。プログラム可能な通貨の実装には、トークン化された銀行負債と中央銀行デジタル通貨が含まれます。プログラミング ロジックと価値自体が切り離されているプログラマブル決済とは異なり、プログラマブル マネーは自己完結型であり、プログラミング ロジックを含み、価値の保存場所として機能します。プログラム可能なお金が他の当事者に送金されると、ロジックとルールも移動します。プログラム可能な支払いの利点は、さまざまな形式のお金に適用できる一連のプログラミング ロジックや条件を定義できることです。同時に、プログラム可能な通貨は自己完結型であり、当事者間のピアツーピアの条件付き論理転送という利点があります。世界中の中央銀行、商業銀行、決済サービスプロバイダーがさまざまな中央銀行デジタル通貨、トークン化された銀行負債、ステーブルコインの設計を模索しているため、将来の金融情勢はさらに多様化すると予想されます。したがって、さまざまな形式のデジタル通貨とやり取りするための共通のフレームワークを確保し、既存の金融インフラとの相互運用性を確保する必要性が高まっています。3 番目のモデルである Purpose-Bound Money (PBM) は、MAS の Orchid プロジェクトの初期段階で検討されており、プログラム可能な支払いとプログラム可能な通貨の概念と機能に基づいています。 PBM とは、基礎となるデジタル通貨を使用できる条件を指定する協定を指します。 PBM は、仲介者なしでピアツーピア転送を可能にするベアラー手段です。 PBM には、価値の保存手段としてのデジタル通貨と、プログラムされた条件に基づいてその使用を識別するプログラミング ロジックが含まれています。条件が満たされると、デジタル通貨は解放され、再び拘束が解除されます。これは、デジタル クーポンとして使用される PBM の例で説明できます。クーポンには、あらかじめ定められた利用条件が設定されています。クーポン保有者は、商品やサービスと引き換えに参加加盟店にクーポンを提供できます（プログラム可能な支払い機能）。場合によっては、クーポン スキームの条件により、個人間の送金が許可されます (プログラム可能な通貨機能)。したがって、消費者は PBM ベースのギフト券を購入し、それを参加小売業者で使用できる別の人に譲渡することができます。ただし、通常のクーポンとは異なり、PBM は支払者が PBM を使用できる方法を制限しますが、受取人は制限しません。消費者が PBM を使用して購入代金を支払うと、使用条件が満たされていればデジタル通貨が PBM から解放され、販売者に転送されます。その後、販売者はデジタル通貨を他の目的 (サプライヤーへの支払いなど) に自由に使用できます。#### 目的限定通貨このセクションでは、PBM のライフサイクルと、PBM を構成するさまざまなコンポーネントについて説明します。このセクションでは、主要なエンティティとその相互作用について概説し、PBM ライフサイクルにおけるそれらの役割を強調します。#### システムアーキテクチャの概要PBM プロトコルは、デジタル資産ベースのネットワークで使用されるテクノロジー スタックを記述する 4 層モデルを指します。図 2 に示すように、ネットワークのコンポーネントは、アクセス層、サービス層、資産層、プラットフォーム層の 4 つの異なる層に分類できます。 PBM のプログラミング ロジックはサービスとみなすことができますが、デジタル通貨は資産層にあります。デジタル通貨が PBM としてバインドされると、サービス層と資産層にまたがります。PBM はテクノロジー中立になるように設計されており、さまざまな種類の台帳や資産にわたって機能するように設計されています。 PBM は分散型台帳と非分散型台帳の両方に実装できることが期待されています。**アクセス層**アクセス層は、ユーザーがさまざまなインターフェイスを通じてさまざまなサービスと対話する層です。**サービス層**サービス層は、デジタルアセットに関連するさまざまなサービスを提供します。通常、資産層の最上位で動作し、ユーザーがデジタル資産を管理および活用できるようにします。**アセットレイヤー**アセット層は、デジタルアセットの作成、管理、交換をサポートします。**プラットフォーム層**プラットフォーム層は、実行、ストレージ、トランザクションのコンセンサスのための基盤となるインフラストラクチャを提供します。#### コンポーネント図 3 に示すように、PBM は、使用目的を定義するラッパーと、担保として機能する基礎となる価値の保存という 2 つの主要コンポーネントで構成されます。この設計により、既存のデジタル通貨を、ネイティブのプロパティを変更せずにさまざまな目的に導入できます。 PBM が本来の目的に使用されると、デジタル通貨はいかなる条件や制限もなく使用できるようになります。デジタル通貨の発行者は、デジタル通貨の管理を維持し、断片化を防ぎ、メンテナンスを容易にします。**PBM ラッパー**基礎となるデジタル通貨が利用できる条件を指定するスマート コントラクト コードの形式で実装された PBM ラッパー。 ＰＢＭラッパーは、ＰＢＭがその意図された目的にのみ使用できるように、例えば、特定の期間、特定の小売店で、所定の額面で有効であるようにプログラムすることができる。 PBM ラッパーで指定された条件が満たされると、基礎となるデジタル通貨が解放され、受信者に転送されます。たとえば、PBM ラッパーは ERC-1155 マルチトークン スマート コントラクトとして実装できます。セクション 3.5 では、PBM 設計で考えられる一連のフローを示します。**デジタル通貨**PBM によって拘束された基礎となるデジタル通貨は、PBM の担保として使用されます。 PBM の条件が満たされると、基礎となるデジタル通貨が解放され、所有権が目的の受信者に移転されます。デジタル通貨は、価値の優れた保存、会計単位、交換媒体としての通貨の機能を果たさなければなりません。デジタル通貨は、CBDC、トークン化された銀行負債、または十分に規制されたステーブルコインの形で存在できます。たとえば、デジタル通貨は、ERC-20 互換の代替トークン スマート コントラクトの形式で実装できます。### キャラクターとインタラクションアクターは、さまざまな方法で実装できる柔軟な抽象化です。エンティティは複数の役割を保持したり、異なるエンティティが役割を実行したりできます。**PBM クリエイター**このエンティティは、PBM 内のロジックの定義、PBM トークンの作成および配布を担当します。**PBM ホルダー**このエンティティは 1 つ以上の PBM トークンを保持します。このエンティティは、有効期限が切れていない PBM トークンと引き換えることができます。**PBM コンバーター**PBM トークンが転送されると、このエンティティは基礎となるデジタル通貨を受け取ります。＃＃＃ ライフサイクル使用されるプログラミング言語やネットワーク プロトコルに関係なく、PBM は一貫したライフサイクル フェーズで設計されており、さまざまなテクノロジ実装間での互換性が確保されています。このセクションでは、PBM の目的の機能と関連するライフサイクル フェーズの概要を説明します。図 4 は、PBM ライフサイクルのさまざまな段階を示しています。**発行済み**PBM ライフサイクルはリリース フェーズから始まります。ここでは、PBM スマート コントラクトが作成され、PBM トークンが鋳造されます。デジタル通貨の所有権は PBM スマート コントラクトに移転されます。デジタル通貨は現在、ERC-1155 または同等のものを使用して実装できる PBM スマート コントラクトによって管理されています。デジタル通貨の使用には、PBM スマート コントラクトで指定された条件が適用され、すべての条件が満たされた場合にのみ解放されます。**分布**PBM トークンが発行された後、PBM トークンは、PBM 作成者によって使用目的のエンティティ (つまり、PBM 保有者) に配布されます。 PBM 保有者は、ラップされた形式で PBM トークンを受け取り、PBM 作成者が設定した元の条件の下でのみトークンを引き換えることができます。**移行**この段階では、PBM トークンは、プログラミング ルールに従ってラップされた形式で、あるエンティティから別のエンティティに転送できます。転送フェーズはオプションであり、ユースケースによって異なります。政府の補助金 (学習補助金など) では、PBM トークンを他の国民に譲渡できない場合があります。商業用バウチャー (小売モールのバウチャーなど) では、PBM トークンは他の消費者に譲渡できます。**交換**引き換えフェーズは、PBM で指定されたすべての条件が満たされた後に発生します。この時点で、PBM トークンのラップが解除され、基礎となるデジタル通貨トークンの所有権が受信側エンティティに譲渡されます。事業体はデジタル通貨トークンを自由に使用でき、その使用にはデジタル通貨発行者が指定した条件のみが適用されます。**期限切れ**有効期限フェーズとは、PBM で指定された特定の条件 (有効期限など) が明示的に違反または期限切れになり、PBM トークンが PBM 保有者にとって永久に使用できなくなる状況を指します。期限切れの PBM トークンは、集約して破棄または「焼却」して、基礎となるデジタル通貨を PBM 作成者に返すことができます。あるいは、PBM 保有者が期限切れの PBM とさらにやり取りするのを防ぐために、PBM を無期限に停止することもできます。### シーケンスの流れPBM の実装は、設計、アプローチ、テクノロジーによって異なります。このセクションでは、図 5 に示すように、PBM が 3 つの部分に分割される設計について検討します。この実装では、デジタル通貨のリリースに関して次の条件が定義されています: (1) ホワイトリストとブラックリストによるアクセス制御、(2) PBM ラッパーの有効期限、および (3) PBM トークン タイプの有効期限。#### PBM トークン マネージャーたとえば、ERC-1155 マルチトークン標準が採用されている場合、PBM 作成者は、同じ PBM ラッパー内で異なる値 ($1、$2、$5 など) を表す異なる PBM トークン タイプを作成できます。 PBM トークン マネージャーは、さまざまなトークン タイプを簡単に管理し、各トークン タイプの残高を維持するためのインターフェイスを提供します。このコンポーネントの主な機能をいくつか示します。1. PBM トークン タイプを作成します。2. 各 PBM トークン タイプの詳細を取得します。3. 各PBMトークンの供給残高を増減します。4. PBM トークンの有効期間を確認します。#### PBM ロジックこのコンポーネントを使用すると、ユーザーは PBM ラッパーを無駄のない状態に保ちながら、複雑なビジネス条件を作成できます。この例では、このコンポーネントは、ホワイトリストに登録されたアドレスとブラックリストに登録されたアドレスのリストを保存および管理します。このコンポーネントの主な機能をいくつか示します。1. ホワイトリストにアドレスを追加または削除します。2. ブラックリストにアドレスを追加または削除します。3. PBM トークンを転送できるかどうかを確認します。4. PBM トークンのラップを解除できるかどうかを確認します。#### PBM ラッパーこのコンポーネントには、基礎となるデジタル通貨の使用を制限する条件が含まれています。デジタル通貨はERC-20と互換性があり、中央銀行デジタル通貨、トークン化された銀行負債、またはステーブルコインの形をとる可能性があります。説明のために、ERC-1155 マルチトークン標準が PBM ラッパーの実装に使用されると仮定します。 ERC-20、ERC-721、またはそれらの同等品などの他の標準も実装に使用できます。このコンポーネントの主な機能をいくつか示します。1. PBM トークンを鋳造します。2. PBM トークンを書き込みます。3. PBM トークンを転送します。4. 追加の検証のために PBM ロジック コンポーネントと対話します。5. PBM トークン マネージャーと対話して、PBM トークン タイプを管理します。図 6 は、異なる PBM スマート コントラクト間の相互作用を示しています。後続のセクションでは、PBM ライフサイクルの各段階の詳細なシーケンス フローを示します。#### PBM ライフ サイクル: リリース フェーズ > PBM の初期化図 7 は、PBM スマート コントラクトを初期化する手順を示しています。この段階で、PBM 作成者は、PBM を初期化し、異なる PBM コンポーネント間の接続をセットアップするためのさまざまなパラメーターを提供します。#### PBM ライフサイクル: 発行フェーズ > PBM トークン タイプの作成図 8 は、新しい PBM トークン タイプを作成する手順を示しています。この段階で、PBM 作成者は、さまざまな値を表すさまざまなトークン タイプを作成できます。#### PBM ライフサイクル: 発行フェーズ > PBM トークンの鋳造上記の手順を完了すると、PBM 作成者は配布用の PBM トークンの作成を開始できます。図 9 は、PBM トークンを鋳造する手順を示しています。鋳造プロセスの前に、PBM 作成者は、PBM 作成者に代わってデジタル通貨を転送するための PBM ラッパー スマート コントラクトを承認する必要があります。これは、鋳造プロセスのステップ 7 を実行するために必要なステップです。• ステップ 1: PBM 作成者はバッチ ミント プロセスを開始します。• ステップ 2: ミントと配布は 1 つのトランザクションで行われる可能性があるため、PBM ラッパーは PBM ロジックを呼び出して、受信者がブラックリストに登録されているかどうかを確認する必要があります。• ステップ 4 ～ 6: PBM トークンの鋳造に必要なデジタル通貨トークンの総数を計算します。• ステップ 7 ～ 10: デジタル通貨トークンの所有権を担保として PBM ラッパーに譲渡します。• ステップ 11 ～ 14: PBM トークン タイプの供給バランスを増やします。• ステップ 15: PBM トークンを作成します。#### ホワイトリスト/ブラックリストのアドレスPBM は、トークンの受信を許可するアドレスのセットとトークンの受信を許可しないアドレスのセットをチェックする条件付きロジックを使用してプログラムできます。この例では、受信者がブラックリストに載っている場合、PBM トークンは転送できません。受信者がホワイトリストに載っていない場合、PBM トークンのラップを解除することはできません。 PBM 作成者は、PBM のライフサイクル全体を通じて次の機能にアクセスできます。技術的には、配布フェーズと転送フェーズは同じプロセスであり、関係する役割が異なるだけであることに注意することが重要です。 PBM がホワイトリストのアドレスに配布される場合、PBM はデジタル通貨を解凍して解放します。#### PBM ライフサイクル: 配布/転送配布または転送フェーズでは、PBM トークンはラップされた形式で転送されます。 2 つのステージの唯一の違いは、関与する役割です。図 11 に、関連する手順を示します。PBM トークンの転送時のいくつかの重要な手順とその考慮事項の概要を以下に示します。• ステップ 3 ～ 5: PBM トークンが転送できるかどうかを確認します。ここで追加の条件を追加できます。この例では、受信者がブラックリストに登録されているかどうかを確認します。• ステップ 6 ～ 8: PBM のラップを解除してデジタル トークンを解放できるかどうかを確認します。ここで追加の条件を追加できます。この場合、受信者はホワイトリストに登録されている必要があります。• ステップ 9: PMB トークンをラップされた形式で転送します。#### PBM ライフサイクル: 配布/転送 - 転送の失敗図 12 は、失敗した PBM トークン転送に関連する手順を示しています。 PBM トークンは転送されておらず、カプセル化された形式でまだ存在しています。#### PBM ライフ サイクル: 償還フェーズPBM トークンを転送する場合、すべての条件が満たされると、PBM トークンはラップを解かれ、基礎となるデジタル通貨トークンが受信者に解放されます。いくつかの重要な手順とその考慮事項を以下に概説します。• ステップ 6 ～ 8: PBM トークンのラップを解除して、基礎となるデジタル トークンを解放できるかどうかを確認します。すべての条件が満たされると、PBM トークンのラップを解除できます。この例では、受信者がすでにホワイトリストに登録されているかどうかを確認します。• ステップ 9 ～ 11: 受信者に転送するデジタル通貨トークンの数を計算します。• ステップ 12: PBM トークンを書き込みます。この手順はオプションであり、PBM 作成者の要件によって異なります。場合によっては、PBM トークンが記念品として保管されることがあります。• ステップ 13 ～ 16: PBM トークンの数を減らします。私たちの設計では、トークンの有効期限はステップ 7 ではなくステップ 14 で検証されます。これは、設計によれば、トークン マネージャーが PBM トークンに関するすべての側面を管理するように設計されているためです。ステップ 7 で検証を実装する人もいます。• ステップ 17 ～ 20: PBM ラッパーは、デジタル通貨トークンの所有権を受信者に譲渡します。• ステップ 21: PBMUnwrap イベントを発行する**PBM ライフ サイクル: 有効期限フェーズ > 期限切れの PBM トークンの償還** このフェーズでは、PBM 保有者が PBM トークンを償還しようとしますが、条件の少なくとも 1 つが明らかに違反しているか有効期限が切れており、転送は失敗します。この例では、トークンの有効期限が切れています。いくつかの重要な手順とその考慮事項を以下に概説します。ステップ 6 ～ 8: 償還フェーズのステップ 14 でトークンの有効期限の検証を実装したため、PBM トークンはラップされていないとみなされます。ステップ 14: トークンの有効期限が切れているため、検証は失敗しました。#### PBM ライフ サイクル: 有効期限フェーズ > PBM の取り消し少なくとも 1 つの条件が明らかに違反または失効した場合、PBM 保有者は PBM トークンを使用できず、デジタル通貨はロックされたままになります。この例では、トークンの有効期限が切れています。 PBM 作成者には、期限切れの PBM トークンを取り消して、基礎となるデジタル通貨トークンを復元するオプションがあります。• ステップ 1: PBM 作成者が元に戻す操作を開始します。• ステップ 2 ～ 4: 引き出すデジタル通貨トークンの数を計算します。• ステップ 5 ～ 8: 出金してトークン残高を 0 に設定します。• ステップ 9 ～ 12: デジタル通貨トークンを PBM 作成者に転送します。• ステップ 13: PBM 撤退イベントを発行します。### 設計上の考慮事項このセクションでは、PBM の実装方法に影響を与える可能性のあるいくつかの設計上の選択と要素について説明します。相互運用性は、さまざまなサービスプロバイダーによる PBM の実装が決済エコシステムの断片化につながらないようにするために重要です。独自のネットワークを実行している PBM プロバイダーは、独自の閉鎖的なパートナー エコシステム内に「壁に囲まれた庭園」を作成する場合があります。これは、PBM プロバイダー間の独占的でレントシーキング行為につながる可能性があります。これを放置すると、取引を完了するために複数の異なるシステムを利用したり、高額な仲介手数料を支払ったりする必要が生じ、消費者に悪影響を及ぼす可能性があります。したがって、PBM テクノロジーは、異なるプラットフォーム、ウォレット、決済システム、レール間で相互運用できるように最初から設計される必要があります。これにより、PBM 受信者は、政府が提供する、または選択した商用ウォレット プロバイダーからの PBM トークンにアクセスして使用できるようになります。共通の標準を採用することで、PBM トークンがさまざまなウォレット サービス プロバイダーと互換性を持つことが保証されます。これにより、デジタル資産を異なるプラットフォームや関係者間で転送できるようになります。さらに、同じインフラストラクチャを複数のユースケースで再利用できるため、実装の労力とコストが削減されます。このペーパーの PBM 設計は、ブロックチェーン ベースおよび非ブロックチェーン ベースの台帳システムを含む、さまざまな種類の台帳に適用できることを目的としています。この記事の概念を説明するために、例として特定の技術的な実装を示します。将来の PBM 実装は、このペーパーで参照されているものとは異なる台帳システムに基づく可能性があると想定しています。サービスプロバイダーは、自社のビジネスモデルと意図したユースケースに最適なサポート元帳のタイプを選択する必要があります。デジタル通貨 概念的には、PBM は基礎となるデジタル通貨の種類に関係なく、共通のフレームワークを提供します。PBM は基礎となるデジタル通貨からその価値を導き出すため、PBM の受容性、認識される価値、および使いやすさは、関連するデジタル通貨と強く相関しています。したがって、デジタル通貨を裏付ける準備資産と、それに関連する規制上の影響およびコンプライアンス要件を考慮することが重要です。 CBDC、トークン化された銀行債務、ステーブルコインは異なるレベルの保証を提供し、異なる規制監督の対象となります。 PBM の変種は、目的限定トークンの形式で存在する場合があり、基礎となるデジタル通貨が、価値の保存ではなく支払い義務を表すトークンに置き換えられます。これは債務償還を表すのと同様の目的を果たす可能性がありますが、決済はアトミックかつリアルタイムではなく遅延ベースで行われるため、決済が失敗するリスクがあります。デジタル通貨に対する世界的な規制環境は依然として進化しているため、PBM の規制上の扱いは管轄区域によって異なる場合があります。プライバシー PBM 設計の構成可能性は、中央銀行発行の CBDC を基礎となるデジタル通貨として使用しながら、PBM ラッパー スマート コントラクトを民間部門が開発できることを意味します。代わりに、政府機関が PBM ラッパー スマート コントラクトを開発し、政府支払いを裏付ける PBM の担保として民間通貨の形でトークン化された銀行債務を使用する可能性があります。 PBM 作成者とデジタル通貨発行者の役割を分離することで、通貨の発行とその使用方法と使用場所の両方を単一の組織が監督できないような取り決めを作成できます。その結果、政府機関が保有するデータの量は、許可された機能を実行するために必要な情報に限定されます。追加の安全策として、認可された機関によって匿名で資金移動を行えるような取り決めを設けることも可能かもしれません。たとえば、転送を開始する個人に転送を行う権限があることを確認するために、転送前に別のレジストリと照合するように PBM 条件を設定できます。ただし、この例では、レジストリは転送の性質を監視せず、受信者が誰であるかを指定しません。登録は、承認されているかどうかを当事者に通知するだけです。#### ポリシーに関する考慮事項PBM は公的部門だけでなく民間部門でも使用できます。 PBM の技術的な実装はどのユースケースでも同様である可能性がありますが、公的部門によって開発、管理、使用される場合には、追加のポリシーの考慮事項が必要になる場合があります。個人のお金の使い方にどのような制約を課すべきかについては、世界中でさまざまな意見があります。たとえば、流行中に救援金を配布する過程で、一部の管轄区域では金融商品やサービスの購入に救済資金を使用することを許可していますが、他の管轄区域ではその使用を制限しています。一方、一部の中央銀行はデジタル通貨の使用方法に制限を設けないとの姿勢を示している。したがって、PBM ベースのソリューションを設計する場合、政策立案者はデジタル通貨を誰が発行して配布するかを検討し、その使用条件を指定する必要があります。#### デジタルへの対応新しい形式の支払い手段の導入によりユーザー エクスペリエンスが変化する可能性があり、ある程度の調整と適応が必要になります。これは、一部のユーザーには好意的に受け止められるかもしれませんが、他のユーザーには煩わしいと思われるかもしれません。たとえば、商店や国民の中には紙のクーポンの使用に慣れていて、モバイル アプリケーションには慣れていない人もいるかもしれません。これにより、商店や国民が PBM を採用することが妨げられる可能性があります。したがって、関係者のデジタル能力を PBM プログラムの設計に組み込む必要があります。特に、より脆弱な人々にとって、ユーザー エクスペリエンスを直感的でアクセスしやすいものにすることが重要です。1 つのアプローチは、デジタル通貨または PBM にアクセスするためにユーザーが自分のキーを管理する必要がある複雑さを抽象化しながら、最初から簡素化されたユーザー エクスペリエンスを提供することです。あるいは、PBM を既存の支払いレールと相互運用するように設計することもでき、それによってラストワンマイルの法定通貨決済と加盟店の受け入れにおける摩擦を軽減できます。#### 安全なプログラミングスマート コントラクト コードへの依存度が高いことを考えると、ソフトウェア展開プロセスの一環としてコードのセキュリティを確保するガバナンス フレームワークを確立することが重要です。これは、論理的な正しさの検証、潜在的な脆弱性の評価と防止、標準化された Oracle データの提供を担当する信頼できるエンティティに参加することで実現できます。このフレームワークは、PBM ラッパー スマート コントラクトだけでなく、デジタル通貨レイヤーにも適用する必要があります。これは、PBM 作成者が、遅延送金やサプライ チェーンの支払い管理などのコンポーネントに複雑なロジックを統合したい場合に特に重要です。悪意のあるコードの導入など、潜在的なシステム セキュリティ リスクを積極的に軽減するには、独立した監査を行うことを強くお勧めします。さらに、分散台帳に基づくネットワークの場合、信頼できるサードパーティ組織を「オラクル」として雇用して、ネットワークに信頼できる外部データ入力を提供することができます。#### PBM の潜在的な用途このセクションでは、PBM が使用される例をいくつか示します。**プリペイドパッケージ**消費者は、取引している販売業者が倒産した場合、将来の商品やサービスの配送のために前払いした保証金を失う可能性があります。 PBM は、企業が商品の製造またはサービスの提供前に保証として料金を請求する必要がある場合に使用されます。 PBM は、支払条件を含めることで配送不能のリスクに対処し、消費者が事前に約束した金額を「引き出す」前に企業が消費者の義務を確実に履行できるようにします。サービスが完了すると、資金の引き出しが自動的にトリガーされます (消費者の PBM 電子ウォレットからの直接引き落とし)。企業は料金を前払いすることはできませんが、サービスの提供後に料金が支払われるという保証があります。**オンライン ビジネス**オンラインで買い物をするとき、消費者は通常、購入したい商品に対して前払いをします。支払い完了後、商品は消費者に発送されます。未配達または未払いのリスクを軽減するために、消費者と販売者はさまざまな取り決めを利用できます。クレジット カードと前払い形式は販売者を保護しますが、消費者は保護しません。代金引換の取り決めは消費者にはメリットがあるかもしれませんが、販売者、特に再利用できない食品などの生鮮品の場合は保証されません。 PBM は代替ソリューションを提供し、サービス義務が満たされた場合に資金が送金されることを販売者と消費者に保証します。**合意**住宅購入者が不動産購入の申し込みを開始するとき、支払いを必要とするさまざまなマイルストーンがあります。 PBMは、不動産の販売条件に基づいて作成できます。不動産開発のさまざまな段階または販売プロセスの段階でマイルストーンが達成されたときに資金を放出するように条件を定義できます。実際には、PBM は住宅購入者に共通の標準テンプレートに基づくことができます。**商用リース**不動産を賃貸するとき、家主は、損害や家賃の不払いに対する保護の手段として、テナントに保証金の提供を要求する場合があります。この敷金はリース期間中家主が保有し、テナントがリース契約に基づくすべての義務を履行した場合に限り、リース終了時にテナントに返還されます。テナントが通常の損耗を超えて物件に損害を与えた場合、またはテナント契約に基づく費用の支払いを怠った場合、家主は残りの資金を返す前に、修繕費または未払いの家賃を保証金から差し引くことができます。 PBM は、テナント契約の当事者が保証金を全額返金する可能性がある場合に、保証金の役割を果たすことができます。紛争が発生した場合、紛争が解決されるまで PBM は一時停止されることがあります。**貿易金融**貿易金融商品は、企業が国際貿易取引のリスクと複雑さを管理するのに役立ちます。国境や通貨を超えて複数の当事者が関与する貿易を促進するために、貿易金融プロバイダーは信用状、銀行保証、請求書の取り立てなどのさまざまなサービスを提供しています。これらのサービスは、支払いが安全かつ効率的に行われるようにすると同時に、債務不履行や詐欺に対する保護も提供します。貿易金融商品は PBM としてモデル化でき、サービス義務が満たされると支払いが自動的に行われます。これらは、当事者間で譲渡できる交渉可能な手段になる可能性があります。**寄付**潜在的な寄付者は、自分の寄付が予定の受益者に届き、予定の目的に使用されるかどうかがわからないため、社会的活動に貢献することを躊躇する可能性があります。さらに、遠隔地にいる海外の受益者への寄付には、経済的に実行可能な送金の選択肢が限られているため、複数の仲介者が関与する可能性が高くなります。その結果、受益者は元の寄付額の一部しか受け取らないことになる可能性があります。 PBM を使用すると、透明性と説明責任を高めることができます。たとえば、PBM を使用すると、特定の条件が満たされた場合にのみ、意図した受益者のみが資金にアクセスできるようにすることができます。**国境を越えた支払い**国境を越えた支払いには、資金の流れの管理やマクロプルーデンス政策措置、マネーロンダリング対策 (AML) やテロ資金供与対策 (CFT) 基準などの政策要件や規制要件が適用されます。これらの対策や基準に準拠するには、高いコストと処理の遅延が伴います。既存のポリシー要件を条件として PBM に組み込むことで、コンプライアンスチェックを自動化し、コストを大幅に削減し、国境を越えた支払いの効率を向上させることができます。設計によるコンプライアンスへのこのアプローチは、G20 が国境を越えた支払いのロードマップを改善するという状況において、規制と政策の相互運用性を達成するのに役立つ可能性があります。**将来の仕事**デジタル通貨分野の開発は急速に進化しています。このセクションでは、将来の可能性のある研究分野について説明します。**アカウントの抽象化**現在、ほとんどの小売ユーザーはデジタル資産ウォレットの使用に慣れておらず、この不慣れさが悪意のある攻撃者によって悪用されるリスクを高める可能性があります。このリスクを軽減するには、スマート コントラクト ウォレットとも呼ばれるアカウント抽象化を使用して、デジタル資産トランザクションのユーザー エクスペリエンスとセキュリティを向上させることができます。このテクノロジーにより、ユーザーが基盤となるテクノロジーを理解する必要なく、アカウントの回復、取引制限、紛失したアカウントの凍結などの機能が可能になります。**オフライン支払い**将来の研究には、スマートフォン以外のモダリティ (カードなど) やネットワーク接続への依存を減らすためのオフライン支払いでの PBM の使用の調査が含まれる可能性があります。これは、人々がスマートフォンやデジタル決済サービスを使用せずに参加できるようにすることで、金融包摂を高めることを目的としています。**名前の宛先指定**現在、携帯電話番号を銀行口座番号の代わりとして使用して送金することが可能です。銀行口座番号がない場合、ネーム アドレッシング サービスは、ウォレット アドレスを意味のある識別子にマッピングすることで、そのアドレスのプロキシを提供します。これにより、ユーザー エクスペリエンスが向上し、転送が目的の受信者に確実に届くようになります。＃＃＃ 結論はこの論文では、さまざまな形式の交換媒体と対話するための共通プロトコルとしての PBM の概念を示し、デジタル通貨を本来の特性を変更することなくビジネスや政策の目標をサポートするためにどのように使用できるかを強調します。 PBM は当初、シンガポール金融管理局の Orchid プロジェクトを通じて導入されましたが、私たちはその技術設計コンセプトがより幅広い国際的な聴衆に適用できるかもしれないと想定しました。より広範な採用を実現するために、PBM 技術フレームワークは、さまざまな組織の参加者が参加するオープンソース方式で設計および開発されています。この文書は、Orchid プロジェクトによって開始された基礎に基づいて構築されており、世界中の中央銀行、金融機関、フィンテック企業からの共同寄稿の結果です。特に、この記事は特定の政策目標を推進したり、技術的解決策を推奨したりするものではありません。この記事の著者は、提案されたソリューションのパフォーマンスや適切性についていかなる表明も保証も行いません。この記事で提供されている例は、単に説明を目的としたものです。各管轄区域の政策上の考慮事項と状況は独特であるため、政策立案者は、目的を最もよく満たす金融インフラとテクノロジーの組み合わせを評価する必要があります。デジタル通貨およびデジタル資産エコシステムの将来の発展により、さらなる機会がもたらされ、将来の取り組みで対処する必要があるリスクが生じる可能性があることが予見可能です。グローバルなフィンテック コミュニティのメンバーは、このホワイトペーパーで提示された概念を基にして、学んだことをグローバルなフィンテック コミュニティに貢献することが奨励されています。**参考資料**シンガポール金融管理局 (MAS)。 （2022年10月31日）。 Project Orchid: プログラマブル デジタル SGD [PDF] 。から取得Lee、A. (2021 年 6 月 23 日)。プログラマブルマネーとは何ですか。から取得イタリア共和国 [イタリア共和国]。 （2019年4月19日）。 2019 年 4 月 19 日の法令: 市民権収入カードの使用 [2019 年 4 月 19 日の法令: 市民権収入カードの使用].官報。から取得インド準備銀行。 （2022年10月7日）。中央銀行デジタル通貨に関するコンセプトノート、項目 5.7: プログラマビリティ。から取得パネッタ、F. (2023 年 1 月 23 日)。デジタルユーロ：いつでもどこでも必要なときに私たちのお金 [Speech] 。欧州議会の経済通貨委員会で発表された。から取得国際決済銀行。 （2019年4月1日）。 「用語集」の「公的分野」。から取得Carstens、A. (2023 年 2 月 22 日)。イノベーションと金融の未来 [Speech] 。シンガポール金融管理局で発表。エイドリアン・T.、マンシーニ・グリフォリ・T.（2023年6月19日）。決済および契約プラットフォームの台頭 [PDF] 。から取得国際決済銀行。 （2023年6月20日）。 Ⅲ．将来の金融の青写真 : 古いものを改善し、新しいものを可能にする [PDF] 。から取得
シンガポール金融庁 MAS: 目的限定通貨 (PBM) の 4D 詳細説明テクニカル ホワイト ペーパー
翻訳: ほうれん草ほうれん草!
ソース：
＃＃＃ 序章
デジタル資産とは、金融資産や実物経済資産の所有権など、価値のデジタル表現を指します。デジタル資産エコシステムには、より効率的な取引を促進し、金融包摂を高め、経済的価値を引き出す可能性があります。中央銀行デジタル通貨（CBDC）、トークン化された銀行負債、および潜在的に十分に規制されたステーブルコインは、精巧な一連のスマートコントラクトと組み合わせることで、この新しいデジタル資産エコシステムの交換媒体として機能する可能性があります。初期の試験では可能性が示されているものの、ブロックチェーンやピアツーピアの資金の流れで普及しているこれらの新しい形式のデジタル通貨は、現在すでに存在している国内の即時決済システムなどの電子決済システムを超えた有用性を証明する必要があります。提供された。デジタル通貨の大きな利点の 1 つは、プログラム機能のサポートです。ただし、これは現在も議論と議論が行われているテーマです。事業者は、プログラム可能性が交換媒体として機能するデジタル通貨の能力を犠牲にしないようにする必要があります。通貨の単一性は維持されるべきであり、プログラム性によって通貨の流通が制限され、システム内の流動性の断片化を招いてはなりません。この記事では、お金自体をプログラムすることなくお金を特定の目的に向けることを可能にする目的限定お金 (PBM) の概念の技術概要を説明します。 PBM は、さまざまな台帳テクノロジーや通貨形式で動作するように設計された共通プロトコルを採用しています。標準化されたフォーマットを通じて、ユーザーは選択したウォレットプロバイダーを使用してデジタル通貨にアクセスできるようになります。このペーパーでは、MAS の Orchid プロジェクトで最初に導入された PBM の概念に基づいて構築し、それをより広範囲のアプリケーション シナリオに拡張する方法について説明します。
背景と動機
業務効率の向上とユーザーエクスペリエンスの向上を目的としたデジタルへの取り組みは、近年大幅な勢いを増しています。ただし、金融におけるデジタル作業には課題がないわけではありません。
市場の拡散と細分化
決済スキームとプラットフォームの急増により、デジタル金融サービスを導入する際にユーザーが直面する可能性のある複雑さと課題が増大しています。たとえば、決済事業者は多くの場合、スキームごとに異なる特性を持つ流通チャネルを運営しています。スキーム所有者にとって、マーチャントを独自のプラットフォームに組み込むことは非常にリソースを消費します。同時に、他のプラットフォームへの統合により、小売業者の運営上の労力が増大し、さまざまな支払いスキームを処理および受け入れるために小売スタッフを訓練する必要があります。
民間の独立した取り組みにより、ユーザー エクスペリエンスを簡素化し、デジタル化の可能性を実現するために、これらの取り組みを単一のプラットフォームに統合することが試みられてきました。ただし、すべての取り組みにわたってオープンで相互運用可能であることを保証するには、これらの取り組みをさらに進める必要があります。これらのプラットフォームは、エコシステムに加入している消費者や販売者に限定されるべきではありません。相互運用可能な決済システムは柔軟性を高め、企業と消費者にシームレスな決済体験を可能にします。
通貨のプログラマビリティと代替可能性
従来の口座ベースの台帳システムとは異なり、デジタル通貨は、個々の保有資産に固有の特性をプログラムし、デジタル通貨の使用方法を決定する可能性を提供します。ただし、デジタル通貨にプログラミング ロジックを直接実装すると、その特性と交換媒体としての受け入れが変更されます。このアプローチはデジタル通貨の機能を拡張しますが、使用条件が多様かつ動的である場合、実行可能な交換媒体としてのデジタル通貨の使用が制限されます。また、新しい条件やユースケースが必要になるたびに、流通しているすべてのデジタル通貨を再プログラミングする必要もあります。
もう 1 つのアプローチは、デジタル通貨の発行者が、それぞれ異なるロジック プログラミングを備えた複数のバージョンのデジタル通貨を提供することです。ただし、これらのデジタル通貨は交換可能ではなく、市場の流動性が断片化しているため、このアプローチは現実的ではない可能性があります。デジタル通貨の代替可能性を維持して自由に交換できるようにする方法を理解するために、この論文ではさまざまなプログラミング モデルを検討します。
プログラミング モデル
プログラム可能な支払いとは、事前に定義された一連の条件が満たされると自動的に実行される支払いを指します。たとえば、口座振替や定期注文と同様に、毎日の支出制限や定期的な支払いを定義できます。プログラム可能な支払いは通常、データベース トリガーを設定するか、会計台帳とクライアント アプリケーションの間にあるアプリケーション プログラミング インターフェイス (API) ゲートウェイの形式で実装されます。これらのプログラムによるインターフェイスは、従来の台帳と対話し、プログラムされたロジックに基づいて銀行口座残高を調整します。
プログラマブルマネーとは、価値の保存自体にルールを埋め込み、その使用を定義または制限できる可能性を指します。たとえば、価値の保存をホワイトリストに登録されたウォレットにのみ送信したり、トランザクション レベルのフィルタリングが完了した後に転送したりするようにルールを定義できます。プログラム可能な通貨の実装には、トークン化された銀行負債と中央銀行デジタル通貨が含まれます。プログラミング ロジックと価値自体が切り離されているプログラマブル決済とは異なり、プログラマブル マネーは自己完結型であり、プログラミング ロジックを含み、価値の保存場所として機能します。プログラム可能なお金が他の当事者に送金されると、ロジックとルールも移動します。
プログラム可能な支払いの利点は、さまざまな形式のお金に適用できる一連のプログラミング ロジックや条件を定義できることです。同時に、プログラム可能な通貨は自己完結型であり、当事者間のピアツーピアの条件付き論理転送という利点があります。世界中の中央銀行、商業銀行、決済サービスプロバイダーがさまざまな中央銀行デジタル通貨、トークン化された銀行負債、ステーブルコインの設計を模索しているため、将来の金融情勢はさらに多様化すると予想されます。したがって、さまざまな形式のデジタル通貨とやり取りするための共通のフレームワークを確保し、既存の金融インフラとの相互運用性を確保する必要性が高まっています。
3 番目のモデルである Purpose-Bound Money (PBM) は、MAS の Orchid プロジェクトの初期段階で検討されており、プログラム可能な支払いとプログラム可能な通貨の概念と機能に基づいています。 PBM とは、基礎となるデジタル通貨を使用できる条件を指定する協定を指します。 PBM は、仲介者なしでピアツーピア転送を可能にするベアラー手段です。 PBM には、価値の保存手段としてのデジタル通貨と、プログラムされた条件に基づいてその使用を識別するプログラミング ロジックが含まれています。条件が満たされると、デジタル通貨は解放され、再び拘束が解除されます。
これは、デジタル クーポンとして使用される PBM の例で説明できます。クーポンには、あらかじめ定められた利用条件が設定されています。クーポン保有者は、商品やサービスと引き換えに参加加盟店にクーポンを提供できます（プログラム可能な支払い機能）。場合によっては、クーポン スキームの条件により、個人間の送金が許可されます (プログラム可能な通貨機能)。したがって、消費者は PBM ベースのギフト券を購入し、それを参加小売業者で使用できる別の人に譲渡することができます。
ただし、通常のクーポンとは異なり、PBM は支払者が PBM を使用できる方法を制限しますが、受取人は制限しません。消費者が PBM を使用して購入代金を支払うと、使用条件が満たされていればデジタル通貨が PBM から解放され、販売者に転送されます。その後、販売者はデジタル通貨を他の目的 (サプライヤーへの支払いなど) に自由に使用できます。
目的限定通貨
このセクションでは、PBM のライフサイクルと、PBM を構成するさまざまなコンポーネントについて説明します。このセクションでは、主要なエンティティとその相互作用について概説し、PBM ライフサイクルにおけるそれらの役割を強調します。
システムアーキテクチャの概要
PBM プロトコルは、デジタル資産ベースのネットワークで使用されるテクノロジー スタックを記述する 4 層モデルを指します。図 2 に示すように、ネットワークのコンポーネントは、アクセス層、サービス層、資産層、プラットフォーム層の 4 つの異なる層に分類できます。 PBM のプログラミング ロジックはサービスとみなすことができますが、デジタル通貨は資産層にあります。デジタル通貨が PBM としてバインドされると、サービス層と資産層にまたがります。
PBM はテクノロジー中立になるように設計されており、さまざまな種類の台帳や資産にわたって機能するように設計されています。 PBM は分散型台帳と非分散型台帳の両方に実装できることが期待されています。
アクセス層
アクセス層は、ユーザーがさまざまなインターフェイスを通じてさまざまなサービスと対話する層です。
サービス層
サービス層は、デジタルアセットに関連するさまざまなサービスを提供します。通常、資産層の最上位で動作し、ユーザーがデジタル資産を管理および活用できるようにします。
アセットレイヤー
アセット層は、デジタルアセットの作成、管理、交換をサポートします。
プラットフォーム層
プラットフォーム層は、実行、ストレージ、トランザクションのコンセンサスのための基盤となるインフラストラクチャを提供します。
コンポーネント
図 3 に示すように、PBM は、使用目的を定義するラッパーと、担保として機能する基礎となる価値の保存という 2 つの主要コンポーネントで構成されます。この設計により、既存のデジタル通貨を、ネイティブのプロパティを変更せずにさまざまな目的に導入できます。 PBM が本来の目的に使用されると、デジタル通貨はいかなる条件や制限もなく使用できるようになります。デジタル通貨の発行者は、デジタル通貨の管理を維持し、断片化を防ぎ、メンテナンスを容易にします。
PBM ラッパー
基礎となるデジタル通貨が利用できる条件を指定するスマート コントラクト コードの形式で実装された PBM ラッパー。 ＰＢＭラッパーは、ＰＢＭがその意図された目的にのみ使用できるように、例えば、特定の期間、特定の小売店で、所定の額面で有効であるようにプログラムすることができる。 PBM ラッパーで指定された条件が満たされると、基礎となるデジタル通貨が解放され、受信者に転送されます。たとえば、PBM ラッパーは ERC-1155 マルチトークン スマート コントラクトとして実装できます。セクション 3.5 では、PBM 設計で考えられる一連のフローを示します。
デジタル通貨
PBM によって拘束された基礎となるデジタル通貨は、PBM の担保として使用されます。 PBM の条件が満たされると、基礎となるデジタル通貨が解放され、所有権が目的の受信者に移転されます。デジタル通貨は、価値の優れた保存、会計単位、交換媒体としての通貨の機能を果たさなければなりません。デジタル通貨は、CBDC、トークン化された銀行負債、または十分に規制されたステーブルコインの形で存在できます。たとえば、デジタル通貨は、ERC-20 互換の代替トークン スマート コントラクトの形式で実装できます。
キャラクターとインタラクション
アクターは、さまざまな方法で実装できる柔軟な抽象化です。エンティティは複数の役割を保持したり、異なるエンティティが役割を実行したりできます。
PBM クリエイター
このエンティティは、PBM 内のロジックの定義、PBM トークンの作成および配布を担当します。
PBM ホルダー
このエンティティは 1 つ以上の PBM トークンを保持します。このエンティティは、有効期限が切れていない PBM トークンと引き換えることができます。
PBM コンバーター
PBM トークンが転送されると、このエンティティは基礎となるデジタル通貨を受け取ります。
＃＃＃ ライフサイクル
使用されるプログラミング言語やネットワーク プロトコルに関係なく、PBM は一貫したライフサイクル フェーズで設計されており、さまざまなテクノロジ実装間での互換性が確保されています。このセクションでは、PBM の目的の機能と関連するライフサイクル フェーズの概要を説明します。図 4 は、PBM ライフサイクルのさまざまな段階を示しています。
発行済み
PBM ライフサイクルはリリース フェーズから始まります。ここでは、PBM スマート コントラクトが作成され、PBM トークンが鋳造されます。デジタル通貨の所有権は PBM スマート コントラクトに移転されます。デジタル通貨は現在、ERC-1155 または同等のものを使用して実装できる PBM スマート コントラクトによって管理されています。デジタル通貨の使用には、PBM スマート コントラクトで指定された条件が適用され、すべての条件が満たされた場合にのみ解放されます。
分布
PBM トークンが発行された後、PBM トークンは、PBM 作成者によって使用目的のエンティティ (つまり、PBM 保有者) に配布されます。 PBM 保有者は、ラップされた形式で PBM トークンを受け取り、PBM 作成者が設定した元の条件の下でのみトークンを引き換えることができます。
移行
この段階では、PBM トークンは、プログラミング ルールに従ってラップされた形式で、あるエンティティから別のエンティティに転送できます。転送フェーズはオプションであり、ユースケースによって異なります。政府の補助金 (学習補助金など) では、PBM トークンを他の国民に譲渡できない場合があります。商業用バウチャー (小売モールのバウチャーなど) では、PBM トークンは他の消費者に譲渡できます。
交換
引き換えフェーズは、PBM で指定されたすべての条件が満たされた後に発生します。この時点で、PBM トークンのラップが解除され、基礎となるデジタル通貨トークンの所有権が受信側エンティティに譲渡されます。事業体はデジタル通貨トークンを自由に使用でき、その使用にはデジタル通貨発行者が指定した条件のみが適用されます。
期限切れ
有効期限フェーズとは、PBM で指定された特定の条件 (有効期限など) が明示的に違反または期限切れになり、PBM トークンが PBM 保有者にとって永久に使用できなくなる状況を指します。期限切れの PBM トークンは、集約して破棄または「焼却」して、基礎となるデジタル通貨を PBM 作成者に返すことができます。あるいは、PBM 保有者が期限切れの PBM とさらにやり取りするのを防ぐために、PBM を無期限に停止することもできます。
シーケンスの流れ
PBM の実装は、設計、アプローチ、テクノロジーによって異なります。このセクションでは、図 5 に示すように、PBM が 3 つの部分に分割される設計について検討します。この実装では、デジタル通貨のリリースに関して次の条件が定義されています: (1) ホワイトリストとブラックリストによるアクセス制御、(2) PBM ラッパーの有効期限、および (3) PBM トークン タイプの有効期限。
PBM トークン マネージャー
たとえば、ERC-1155 マルチトークン標準が採用されている場合、PBM 作成者は、同じ PBM ラッパー内で異なる値 ($1、$2、$5 など) を表す異なる PBM トークン タイプを作成できます。 PBM トークン マネージャーは、さまざまなトークン タイプを簡単に管理し、各トークン タイプの残高を維持するためのインターフェイスを提供します。このコンポーネントの主な機能をいくつか示します。
PBM ロジック
このコンポーネントを使用すると、ユーザーは PBM ラッパーを無駄のない状態に保ちながら、複雑なビジネス条件を作成できます。この例では、このコンポーネントは、ホワイトリストに登録されたアドレスとブラックリストに登録されたアドレスのリストを保存および管理します。このコンポーネントの主な機能をいくつか示します。
PBM ラッパー
このコンポーネントには、基礎となるデジタル通貨の使用を制限する条件が含まれています。デジタル通貨はERC-20と互換性があり、中央銀行デジタル通貨、トークン化された銀行負債、またはステーブルコインの形をとる可能性があります。説明のために、ERC-1155 マルチトークン標準が PBM ラッパーの実装に使用されると仮定します。 ERC-20、ERC-721、またはそれらの同等品などの他の標準も実装に使用できます。このコンポーネントの主な機能をいくつか示します。
図 6 は、異なる PBM スマート コントラクト間の相互作用を示しています。後続のセクションでは、PBM ライフサイクルの各段階の詳細なシーケンス フローを示します。
PBM ライフ サイクル: リリース フェーズ > PBM の初期化
図 7 は、PBM スマート コントラクトを初期化する手順を示しています。この段階で、PBM 作成者は、PBM を初期化し、異なる PBM コンポーネント間の接続をセットアップするためのさまざまなパラメーターを提供します。
PBM ライフサイクル: 発行フェーズ > PBM トークン タイプの作成
図 8 は、新しい PBM トークン タイプを作成する手順を示しています。この段階で、PBM 作成者は、さまざまな値を表すさまざまなトークン タイプを作成できます。
PBM ライフサイクル: 発行フェーズ > PBM トークンの鋳造
上記の手順を完了すると、PBM 作成者は配布用の PBM トークンの作成を開始できます。図 9 は、PBM トークンを鋳造する手順を示しています。
鋳造プロセスの前に、PBM 作成者は、PBM 作成者に代わってデジタル通貨を転送するための PBM ラッパー スマート コントラクトを承認する必要があります。これは、鋳造プロセスのステップ 7 を実行するために必要なステップです。
• ステップ 1: PBM 作成者はバッチ ミント プロセスを開始します。
• ステップ 2: ミントと配布は 1 つのトランザクションで行われる可能性があるため、PBM ラッパーは PBM ロジックを呼び出して、受信者がブラックリストに登録されているかどうかを確認する必要があります。
• ステップ 4 ～ 6: PBM トークンの鋳造に必要なデジタル通貨トークンの総数を計算します。
• ステップ 7 ～ 10: デジタル通貨トークンの所有権を担保として PBM ラッパーに譲渡します。
• ステップ 11 ～ 14: PBM トークン タイプの供給バランスを増やします。
• ステップ 15: PBM トークンを作成します。
ホワイトリスト/ブラックリストのアドレス
PBM は、トークンの受信を許可するアドレスのセットとトークンの受信を許可しないアドレスのセットをチェックする条件付きロジックを使用してプログラムできます。この例では、受信者がブラックリストに載っている場合、PBM トークンは転送できません。受信者がホワイトリストに載っていない場合、PBM トークンのラップを解除することはできません。 PBM 作成者は、PBM のライフサイクル全体を通じて次の機能にアクセスできます。技術的には、配布フェーズと転送フェーズは同じプロセスであり、関係する役割が異なるだけであることに注意することが重要です。 PBM がホワイトリストのアドレスに配布される場合、PBM はデジタル通貨を解凍して解放します。
PBM ライフサイクル: 配布/転送
配布または転送フェーズでは、PBM トークンはラップされた形式で転送されます。 2 つのステージの唯一の違いは、関与する役割です。図 11 に、関連する手順を示します。
PBM トークンの転送時のいくつかの重要な手順とその考慮事項の概要を以下に示します。
• ステップ 3 ～ 5: PBM トークンが転送できるかどうかを確認します。ここで追加の条件を追加できます。この例では、受信者がブラックリストに登録されているかどうかを確認します。
• ステップ 6 ～ 8: PBM のラップを解除してデジタル トークンを解放できるかどうかを確認します。ここで追加の条件を追加できます。この場合、受信者はホワイトリストに登録されている必要があります。
• ステップ 9: PMB トークンをラップされた形式で転送します。
PBM ライフサイクル: 配布/転送 - 転送の失敗
図 12 は、失敗した PBM トークン転送に関連する手順を示しています。 PBM トークンは転送されておらず、カプセル化された形式でまだ存在しています。
PBM ライフ サイクル: 償還フェーズ
PBM トークンを転送する場合、すべての条件が満たされると、PBM トークンはラップを解かれ、基礎となるデジタル通貨トークンが受信者に解放されます。
いくつかの重要な手順とその考慮事項を以下に概説します。
• ステップ 6 ～ 8: PBM トークンのラップを解除して、基礎となるデジタル トークンを解放できるかどうかを確認します。すべての条件が満たされると、PBM トークンのラップを解除できます。この例では、受信者がすでにホワイトリストに登録されているかどうかを確認します。
• ステップ 9 ～ 11: 受信者に転送するデジタル通貨トークンの数を計算します。
• ステップ 12: PBM トークンを書き込みます。この手順はオプションであり、PBM 作成者の要件によって異なります。場合によっては、PBM トークンが記念品として保管されることがあります。
• ステップ 13 ～ 16: PBM トークンの数を減らします。私たちの設計では、トークンの有効期限はステップ 7 ではなくステップ 14 で検証されます。これは、設計によれば、トークン マネージャーが PBM トークンに関するすべての側面を管理するように設計されているためです。ステップ 7 で検証を実装する人もいます。
• ステップ 17 ～ 20: PBM ラッパーは、デジタル通貨トークンの所有権を受信者に譲渡します。
• ステップ 21: PBMUnwrap イベントを発行する
PBM ライフ サイクル: 有効期限フェーズ > 期限切れの PBM トークンの償還 このフェーズでは、PBM 保有者が PBM トークンを償還しようとしますが、条件の少なくとも 1 つが明らかに違反しているか有効期限が切れており、転送は失敗します。この例では、トークンの有効期限が切れています。いくつかの重要な手順とその考慮事項を以下に概説します。
ステップ 6 ～ 8: 償還フェーズのステップ 14 でトークンの有効期限の検証を実装したため、PBM トークンはラップされていないとみなされます。
ステップ 14: トークンの有効期限が切れているため、検証は失敗しました。
PBM ライフ サイクル: 有効期限フェーズ > PBM の取り消し
少なくとも 1 つの条件が明らかに違反または失効した場合、PBM 保有者は PBM トークンを使用できず、デジタル通貨はロックされたままになります。この例では、トークンの有効期限が切れています。 PBM 作成者には、期限切れの PBM トークンを取り消して、基礎となるデジタル通貨トークンを復元するオプションがあります。
• ステップ 1: PBM 作成者が元に戻す操作を開始します。
• ステップ 2 ～ 4: 引き出すデジタル通貨トークンの数を計算します。
• ステップ 5 ～ 8: 出金してトークン残高を 0 に設定します。
• ステップ 9 ～ 12: デジタル通貨トークンを PBM 作成者に転送します。
• ステップ 13: PBM 撤退イベントを発行します。
設計上の考慮事項
このセクションでは、PBM の実装方法に影響を与える可能性のあるいくつかの設計上の選択と要素について説明します。相互運用性は、さまざまなサービスプロバイダーによる PBM の実装が決済エコシステムの断片化につながらないようにするために重要です。独自のネットワークを実行している PBM プロバイダーは、独自の閉鎖的なパートナー エコシステム内に「壁に囲まれた庭園」を作成する場合があります。これは、PBM プロバイダー間の独占的でレントシーキング行為につながる可能性があります。これを放置すると、取引を完了するために複数の異なるシステムを利用したり、高額な仲介手数料を支払ったりする必要が生じ、消費者に悪影響を及ぼす可能性があります。したがって、PBM テクノロジーは、異なるプラットフォーム、ウォレット、決済システム、レール間で相互運用できるように最初から設計される必要があります。これにより、PBM 受信者は、政府が提供する、または選択した商用ウォレット プロバイダーからの PBM トークンにアクセスして使用できるようになります。
共通の標準を採用することで、PBM トークンがさまざまなウォレット サービス プロバイダーと互換性を持つことが保証されます。これにより、デジタル資産を異なるプラットフォームや関係者間で転送できるようになります。さらに、同じインフラストラクチャを複数のユースケースで再利用できるため、実装の労力とコストが削減されます。このペーパーの PBM 設計は、ブロックチェーン ベースおよび非ブロックチェーン ベースの台帳システムを含む、さまざまな種類の台帳に適用できることを目的としています。この記事の概念を説明するために、例として特定の技術的な実装を示します。将来の PBM 実装は、このペーパーで参照されているものとは異なる台帳システムに基づく可能性があると想定しています。サービスプロバイダーは、自社のビジネスモデルと意図したユースケースに最適なサポート元帳のタイプを選択する必要があります。デジタル通貨 概念的には、PBM は基礎となるデジタル通貨の種類に関係なく、共通のフレームワークを提供します。
PBM は基礎となるデジタル通貨からその価値を導き出すため、PBM の受容性、認識される価値、および使いやすさは、関連するデジタル通貨と強く相関しています。したがって、デジタル通貨を裏付ける準備資産と、それに関連する規制上の影響およびコンプライアンス要件を考慮することが重要です。 CBDC、トークン化された銀行債務、ステーブルコインは異なるレベルの保証を提供し、異なる規制監督の対象となります。 PBM の変種は、目的限定トークンの形式で存在する場合があり、基礎となるデジタル通貨が、価値の保存ではなく支払い義務を表すトークンに置き換えられます。これは債務償還を表すのと同様の目的を果たす可能性がありますが、決済はアトミックかつリアルタイムではなく遅延ベースで行われるため、決済が失敗するリスクがあります。
デジタル通貨に対する世界的な規制環境は依然として進化しているため、PBM の規制上の扱いは管轄区域によって異なる場合があります。プライバシー PBM 設計の構成可能性は、中央銀行発行の CBDC を基礎となるデジタル通貨として使用しながら、PBM ラッパー スマート コントラクトを民間部門が開発できることを意味します。代わりに、政府機関が PBM ラッパー スマート コントラクトを開発し、政府支払いを裏付ける PBM の担保として民間通貨の形でトークン化された銀行債務を使用する可能性があります。 PBM 作成者とデジタル通貨発行者の役割を分離することで、通貨の発行とその使用方法と使用場所の両方を単一の組織が監督できないような取り決めを作成できます。
その結果、政府機関が保有するデータの量は、許可された機能を実行するために必要な情報に限定されます。追加の安全策として、認可された機関によって匿名で資金移動を行えるような取り決めを設けることも可能かもしれません。たとえば、転送を開始する個人に転送を行う権限があることを確認するために、転送前に別のレジストリと照合するように PBM 条件を設定できます。ただし、この例では、レジストリは転送の性質を監視せず、受信者が誰であるかを指定しません。登録は、承認されているかどうかを当事者に通知するだけです。
ポリシーに関する考慮事項
PBM は公的部門だけでなく民間部門でも使用できます。 PBM の技術的な実装はどのユースケースでも同様である可能性がありますが、公的部門によって開発、管理、使用される場合には、追加のポリシーの考慮事項が必要になる場合があります。
個人のお金の使い方にどのような制約を課すべきかについては、世界中でさまざまな意見があります。たとえば、流行中に救援金を配布する過程で、一部の管轄区域では金融商品やサービスの購入に救済資金を使用することを許可していますが、他の管轄区域ではその使用を制限しています。一方、一部の中央銀行はデジタル通貨の使用方法に制限を設けないとの姿勢を示している。したがって、PBM ベースのソリューションを設計する場合、政策立案者はデジタル通貨を誰が発行して配布するかを検討し、その使用条件を指定する必要があります。
デジタルへの対応
新しい形式の支払い手段の導入によりユーザー エクスペリエンスが変化する可能性があり、ある程度の調整と適応が必要になります。これは、一部のユーザーには好意的に受け止められるかもしれませんが、他のユーザーには煩わしいと思われるかもしれません。たとえば、商店や国民の中には紙のクーポンの使用に慣れていて、モバイル アプリケーションには慣れていない人もいるかもしれません。これにより、商店や国民が PBM を採用することが妨げられる可能性があります。
したがって、関係者のデジタル能力を PBM プログラムの設計に組み込む必要があります。特に、より脆弱な人々にとって、ユーザー エクスペリエンスを直感的でアクセスしやすいものにすることが重要です。
1 つのアプローチは、デジタル通貨または PBM にアクセスするためにユーザーが自分のキーを管理する必要がある複雑さを抽象化しながら、最初から簡素化されたユーザー エクスペリエンスを提供することです。あるいは、PBM を既存の支払いレールと相互運用するように設計することもでき、それによってラストワンマイルの法定通貨決済と加盟店の受け入れにおける摩擦を軽減できます。
安全なプログラミング
スマート コントラクト コードへの依存度が高いことを考えると、ソフトウェア展開プロセスの一環としてコードのセキュリティを確保するガバナンス フレームワークを確立することが重要です。これは、論理的な正しさの検証、潜在的な脆弱性の評価と防止、標準化された Oracle データの提供を担当する信頼できるエンティティに参加することで実現できます。
このフレームワークは、PBM ラッパー スマート コントラクトだけでなく、デジタル通貨レイヤーにも適用する必要があります。これは、PBM 作成者が、遅延送金やサプライ チェーンの支払い管理などのコンポーネントに複雑なロジックを統合したい場合に特に重要です。悪意のあるコードの導入など、潜在的なシステム セキュリティ リスクを積極的に軽減するには、独立した監査を行うことを強くお勧めします。さらに、分散台帳に基づくネットワークの場合、信頼できるサードパーティ組織を「オラクル」として雇用して、ネットワークに信頼できる外部データ入力を提供することができます。
PBM の潜在的な用途
このセクションでは、PBM が使用される例をいくつか示します。
プリペイドパッケージ
消費者は、取引している販売業者が倒産した場合、将来の商品やサービスの配送のために前払いした保証金を失う可能性があります。 PBM は、企業が商品の製造またはサービスの提供前に保証として料金を請求する必要がある場合に使用されます。 PBM は、支払条件を含めることで配送不能のリスクに対処し、消費者が事前に約束した金額を「引き出す」前に企業が消費者の義務を確実に履行できるようにします。サービスが完了すると、資金の引き出しが自動的にトリガーされます (消費者の PBM 電子ウォレットからの直接引き落とし)。企業は料金を前払いすることはできませんが、サービスの提供後に料金が支払われるという保証があります。
オンライン ビジネス
オンラインで買い物をするとき、消費者は通常、購入したい商品に対して前払いをします。支払い完了後、商品は消費者に発送されます。未配達または未払いのリスクを軽減するために、消費者と販売者はさまざまな取り決めを利用できます。クレジット カードと前払い形式は販売者を保護しますが、消費者は保護しません。代金引換の取り決めは消費者にはメリットがあるかもしれませんが、販売者、特に再利用できない食品などの生鮮品の場合は保証されません。 PBM は代替ソリューションを提供し、サービス義務が満たされた場合に資金が送金されることを販売者と消費者に保証します。
合意
住宅購入者が不動産購入の申し込みを開始するとき、支払いを必要とするさまざまなマイルストーンがあります。 PBMは、不動産の販売条件に基づいて作成できます。不動産開発のさまざまな段階または販売プロセスの段階でマイルストーンが達成されたときに資金を放出するように条件を定義できます。実際には、PBM は住宅購入者に共通の標準テンプレートに基づくことができます。
商用リース
不動産を賃貸するとき、家主は、損害や家賃の不払いに対する保護の手段として、テナントに保証金の提供を要求する場合があります。この敷金はリース期間中家主が保有し、テナントがリース契約に基づくすべての義務を履行した場合に限り、リース終了時にテナントに返還されます。テナントが通常の損耗を超えて物件に損害を与えた場合、またはテナント契約に基づく費用の支払いを怠った場合、家主は残りの資金を返す前に、修繕費または未払いの家賃を保証金から差し引くことができます。 PBM は、テナント契約の当事者が保証金を全額返金する可能性がある場合に、保証金の役割を果たすことができます。紛争が発生した場合、紛争が解決されるまで PBM は一時停止されることがあります。
貿易金融
貿易金融商品は、企業が国際貿易取引のリスクと複雑さを管理するのに役立ちます。国境や通貨を超えて複数の当事者が関与する貿易を促進するために、貿易金融プロバイダーは信用状、銀行保証、請求書の取り立てなどのさまざまなサービスを提供しています。これらのサービスは、支払いが安全かつ効率的に行われるようにすると同時に、債務不履行や詐欺に対する保護も提供します。貿易金融商品は PBM としてモデル化でき、サービス義務が満たされると支払いが自動的に行われます。これらは、当事者間で譲渡できる交渉可能な手段になる可能性があります。
寄付
潜在的な寄付者は、自分の寄付が予定の受益者に届き、予定の目的に使用されるかどうかがわからないため、社会的活動に貢献することを躊躇する可能性があります。さらに、遠隔地にいる海外の受益者への寄付には、経済的に実行可能な送金の選択肢が限られているため、複数の仲介者が関与する可能性が高くなります。その結果、受益者は元の寄付額の一部しか受け取らないことになる可能性があります。 PBM を使用すると、透明性と説明責任を高めることができます。たとえば、PBM を使用すると、特定の条件が満たされた場合にのみ、意図した受益者のみが資金にアクセスできるようにすることができます。
国境を越えた支払い
国境を越えた支払いには、資金の流れの管理やマクロプルーデンス政策措置、マネーロンダリング対策 (AML) やテロ資金供与対策 (CFT) 基準などの政策要件や規制要件が適用されます。これらの対策や基準に準拠するには、高いコストと処理の遅延が伴います。既存のポリシー要件を条件として PBM に組み込むことで、コンプライアンスチェックを自動化し、コストを大幅に削減し、国境を越えた支払いの効率を向上させることができます。設計によるコンプライアンスへのこのアプローチは、G20 が国境を越えた支払いのロードマップを改善するという状況において、規制と政策の相互運用性を達成するのに役立つ可能性があります。
将来の仕事
デジタル通貨分野の開発は急速に進化しています。このセクションでは、将来の可能性のある研究分野について説明します。
アカウントの抽象化
現在、ほとんどの小売ユーザーはデジタル資産ウォレットの使用に慣れておらず、この不慣れさが悪意のある攻撃者によって悪用されるリスクを高める可能性があります。このリスクを軽減するには、スマート コントラクト ウォレットとも呼ばれるアカウント抽象化を使用して、デジタル資産トランザクションのユーザー エクスペリエンスとセキュリティを向上させることができます。このテクノロジーにより、ユーザーが基盤となるテクノロジーを理解する必要なく、アカウントの回復、取引制限、紛失したアカウントの凍結などの機能が可能になります。
オフライン支払い
将来の研究には、スマートフォン以外のモダリティ (カードなど) やネットワーク接続への依存を減らすためのオフライン支払いでの PBM の使用の調査が含まれる可能性があります。これは、人々がスマートフォンやデジタル決済サービスを使用せずに参加できるようにすることで、金融包摂を高めることを目的としています。
名前の宛先指定
現在、携帯電話番号を銀行口座番号の代わりとして使用して送金することが可能です。銀行口座番号がない場合、ネーム アドレッシング サービスは、ウォレット アドレスを意味のある識別子にマッピングすることで、そのアドレスのプロキシを提供します。これにより、ユーザー エクスペリエンスが向上し、転送が目的の受信者に確実に届くようになります。
＃＃＃ 結論は
この論文では、さまざまな形式の交換媒体と対話するための共通プロトコルとしての PBM の概念を示し、デジタル通貨を本来の特性を変更することなくビジネスや政策の目標をサポートするためにどのように使用できるかを強調します。 PBM は当初、シンガポール金融管理局の Orchid プロジェクトを通じて導入されましたが、私たちはその技術設計コンセプトがより幅広い国際的な聴衆に適用できるかもしれないと想定しました。
より広範な採用を実現するために、PBM 技術フレームワークは、さまざまな組織の参加者が参加するオープンソース方式で設計および開発されています。この文書は、Orchid プロジェクトによって開始された基礎に基づいて構築されており、世界中の中央銀行、金融機関、フィンテック企業からの共同寄稿の結果です。
特に、この記事は特定の政策目標を推進したり、技術的解決策を推奨したりするものではありません。この記事の著者は、提案されたソリューションのパフォーマンスや適切性についていかなる表明も保証も行いません。この記事で提供されている例は、単に説明を目的としたものです。各管轄区域の政策上の考慮事項と状況は独特であるため、政策立案者は、目的を最もよく満たす金融インフラとテクノロジーの組み合わせを評価する必要があります。
デジタル通貨およびデジタル資産エコシステムの将来の発展により、さらなる機会がもたらされ、将来の取り組みで対処する必要があるリスクが生じる可能性があることが予見可能です。グローバルなフィンテック コミュニティのメンバーは、このホワイトペーパーで提示された概念を基にして、学んだことをグローバルなフィンテック コミュニティに貢献することが奨励されています。
参考資料
シンガポール金融管理局 (MAS)。 （2022年10月31日）。 Project Orchid: プログラマブル デジタル SGD [PDF] 。から取得
Lee、A. (2021 年 6 月 23 日)。プログラマブルマネーとは何ですか。から取得
イタリア共和国 [イタリア共和国]。 （2019年4月19日）。 2019 年 4 月 19 日の法令: 市民権収入カードの使用 [2019 年 4 月 19 日の法令: 市民権収入カードの使用].官報。から取得
インド準備銀行。 （2022年10月7日）。中央銀行デジタル通貨に関するコンセプトノート、項目 5.7: プログラマビリティ。から取得
パネッタ、F. (2023 年 1 月 23 日)。デジタルユーロ：いつでもどこでも必要なときに私たちのお金 [Speech] 。欧州議会の経済通貨委員会で発表された。から取得
国際決済銀行。 （2019年4月1日）。 「用語集」の「公的分野」。から取得
Carstens、A. (2023 年 2 月 22 日)。イノベーションと金融の未来 [Speech] 。シンガポール金融管理局で発表。
エイドリアン・T.、マンシーニ・グリフォリ・T.（2023年6月19日）。決済および契約プラットフォームの台頭 [PDF] 。から取得
国際決済銀行。 （2023年6月20日）。 Ⅲ．将来の金融の青写真 : 古いものを改善し、新しいものを可能にする [PDF] 。から取得