著者: ChiHaoLu (chihaolu.eth) ソース: medium 翻訳: Shanoba, Golden Finance

この記事では、Aztec レイヤー 2 ソリューションでのアカウント抽象化 (AA) の開発と関連コンテンツに焦点を当てます。 公式ドキュメント、ブログ、チュートリアルなど、Aztecの公式リソースを多数引用します。 これらの優れたリソースは、記事の最後にある参考文献セクションにあります。

背景

ZK-Rollups の他のネイティブ AA 実装と比較して Aztec は複雑さが増しているため、読者はこの記事をよりよく理解するためにいくつかのコンテキストを持っていると役立つ場合があります。

*スマートコントラクトウォレットとその機能に精通している

• EIP-4337に精通していること
• ZK-Rollupsのネイティブアカウント抽象化に精通していること
• UTXOの基本概念
• ZK-Rollupsの基本概念 ※ゼロ知識証明プログラムの基本概念

イントロダクション

アステカをざっと見る

Aztecは、イーサリアムのスケーラビリティとプライバシー保護を提供するために設計されたオープンソースのレイヤー2ネットワークです。 Aztec は zkSNARK プルーフを活用して、ZK-Rollup サービスを通じてプライバシー保護とスケーラビリティを提供します。 Aztecのユーザーは、プライベートトランザクションにアクセスするために、信頼できる第三者や追加のコンセンサスメカニズムを必要としません。

従来のZKロールアップでは、「ZK」が必ずしもプライバシーを意味しないことは誰もが知っています。 これは、ゼロ知識証明(ZKP)を使用して、特定の計算がオフチェーンで正しく実行されたことを証明することを意味します。 ただし、Aztecでは、スケーラビリティに加えてプライバシーがZK-Rollupに実装されています。 さらに深く掘り下げると、以前は各トランザクションの詳細がオンチェーンで公開されていましたが、Aztecでは、各トランザクションの入力と出力が暗号化されています。 これらのトランザクションはZKPによって検証され、暗号化された情報が正確であり、平文で発信されたことを証明します。 これらのプライベートトランザクションを構築するユーザーだけが、実際のプレーンテキスト情報を知っています。

シーケンサーやプローバーなど、ZK-Rollupの重要な文字でさえ、プレーンテキストが何であるかを判断できません。 送信者、受信者、トランザクションデータ、転送額など、トランザクションに関するすべての情報は非表示になります。 トランザクションの詳細を知っているのはユーザー自身だけですが、トランザクションの正確性を信頼できます。 この信頼性は、正当なトランザクションのみが、その正確性を証明する有効なゼロ知識証明を生成できるという事実に由来しています。

プライベートトランザクションの実装方法とその基本を検証する方法は、この記事の範囲を超えている大きなトピックです。 簡単に言えば、必要なのは、ZKPリストを検証するための「ゼロ知識証明検証のための追加レイヤー」であり、それぞれがプライベートトランザクションを検証します。 そのため、「ZK-ZK-Rollups」と呼ばれています。

ノワールとは?

Aztec では、ネイティブアカウントの抽象化が使用されるため、外部所有アカウント (EOA) と契約アカウントに違いはありません。 すべてのアカウントはスマートコントラクトです。 したがって、受託開発を理解することが重要であるため、Aztecの受託開発エコシステムの概要を簡単に説明します。 ただし、アカウント契約を自分で作成する予定がない場合は、この記事を読んで理解するために、コンピューターの電源を入れて契約書を作成する必要はありません。 必要なのは、アカウント契約コードのロジックを理解することだけです。 あなたはあなた自身の裁量でトピックの深さを探ることができます!

Noir は SNARK プログラムを書くための言語で、Circcom や ZoKrates と似ています。 回線の作成後にSolidity Verifierコントラクトを自動的に生成できるだけでなく、独自のプロトコルやブロックチェーンの作成にも使用できます。 Noir は Aztec に完全に依存しているわけではない (特定の証明システムにコンパイルされない) ため、証明システム用のバックエンド サーバーとスマート コントラクト インターフェイスを実装することで目標を達成できます。

Aztecでは、Noirは、変数(状態)と関数をプライバシーで保護できるスマートコントラクトを作成するために使用されています。

プライベートステータスとプライベートノートとは

パブリックブロックチェーンに関する私たちの理解によると、通常、すべての州はパブリックです。 アステカでは、プライベートステートの概念とその管理方法(追加、変更、削除)を把握することが重要です。 プライベートステートは暗号化され、その所有者が所有します。 たとえば、私がコントラクトの所有者である場合、そのコントラクト内の特定の変数を暗号化し、プライベート状態を隠すことができます。 このプライベートステートの所有者である私だけが、暗号文を解読して平文を取得できます。

プライベート状態は、データベース ツリーのみをアタッチして格納されます。 これは、状態値を直接変更すると、トランザクション ダイアグラムから多くの情報が漏洩する可能性があるためです。 ただし、データベースはプライベート状態の値を直接格納しません。 代わりに、暗号化された形式のプライベートノートとして記録されます(例:x=0 -> x=1) addr=0x00 -> addr=0x01。 したがって、実際には、これらのプライベート変数は、変数のように見えますが、実際には不変のプライベートノートの束で構成されています。 これは変数の抽象化です。 明確でない場合は、先に進みましょう。

プライベート状態を削除する必要がある場合は、そのプライベート状態に関連する無効な文字を別の無効なデータベースに追加して無効にすることができます。 プライベート状態を変更する必要がある場合は、まずプライベート状態を無効にしてから、新しいプライベートコメントを追加します。

無効化の概念については、後ほど説明します。 これは、プライベートノートをその無効な文字にリンクするために必要なキーと考えることができます。 無効なキーの所有者のみが、そのキーに関連付けられているプライベート ノートを識別して使用できます。

この時点で、賢明な読者は、この構造がUTXO(未使用のトランザクションアウトプット)と非常によく似ていることに気付いたかもしれませんし、UTXOを反復処理してプライベートステートの現在の状態を判断できます(ただし、トランザクションに署名するのはUTXOではなくユーザーであることを覚えておくことが重要です。 これについては後で説明します)。

プライベートノートとは何ですか? UTXOはノートと呼ばれ、このノートツリーをトラバースしてプライベート状態に関する情報を取得します。 プライベート状態を変更する場合、手順は次のとおりです。

1. ユーザは、その非公開ステータスに関連するすべての非公開メモをメモデータベースから取得します。 2.ユーザー(実際にはユーザーが実行するAztecノード)は、このDBツリーに取得した各注釈が存在することをローカルに証明します。
2. ユーザーが無効な文字を追加して、他のユーザーが同じリーフを再度読み取れないようにします。
3. ユーザーは、新しいリーフ (新しいコメント) を挿入して、このプライベート状態の値を更新します。

#アステカのAAメカニズム

プロトコル層とアプリケーション層とは

ご存知のように、EIP-4337は、トランザクションプロセス全体をアプリケーション層に移行し、オープンリレーシステムを実装し、スマートコントラクトのプログラム可能な性質を通じて署名(検証メカニズム)と支払いモデルを抽象化することを目的としています。 ただし、ネイティブアカウントの抽象化については、StarkNet、zkSyncの時代、またはこの記事の焦点であるAztecのいずれであっても、適切に機能するためには、特定の要素をレイヤー2のプロトコルにエッチングする必要があります。 たとえば、Aztec では、暗号化キーと無効なキーをプロトコル レベルで実装する必要があります。

ネイティブアカウントの抽象化を理解するには、チェーン全体がどのように機能するかを深く理解する必要があります(AAの実行ロジックが特定のレイヤー2プロトコルに自然にリンクされている「ネイティブ」と呼ばれると仮定します)。 例えば、zkSyncの時代にはシステムコントラクトを理解する必要があり、StarkNetではシーケンサーがどのように機能するかを理解する必要があり、Aztecではこれらの「キーとその基盤となるプライベートステート」の役割を理解することが重要です。

アカウントのエントリポイントと検証フェーズ

Aztec では、アカウント抽象化の他の実装とは異なり、アカウント コントラクトへのエントリ ポイントとして厳密に定義された関数名 (関数シグネチャ) はありません (EIP-4337 の validateUserOp、validateTransactionzkSync Era など) __validate__StarkNet)。 ユーザーは、アカウントコントラクトの任意の機能をエントリポイントとして自由に選択し、関連するパラメータを使用してトランザクションを送信できます。

ユーザーが選択した関数 (entrypoint() と呼びます) は、プライベート (ユーザーのプライベート実行環境で実行される) である必要があります。 アカウントコントラクト所有者のクライアント(ユーザーのウォレット)からのみ呼び出すことができます。 ユーザーのウォレットentrypoint()がローカルで実行されると、ゼロ知識証明も生成されます。 この構成証明は、オフチェーンの実行が発生し、成功したことを検証フェーズの Aztec プロトコルに通知します。

検証フェーズの制限

これは、検証フェーズでできることに制限を課すかどうかという問題にも及びます。 トランザクションの検証にはコスト制限がないため(基本的に、トランザクションの検証は関数ビューです)、攻撃者はmempoolに対してサービス拒否(DOS)攻撃を実行して、バンドラー(EIP-4337)またはオペレーター/シーケンサー(ネイティブAA)を侵害できることはよく知られています。 EIP-4337 は、禁止されているオペコードとストレージ アクセスを制限する方法を定義しています。 zkSync EraはOpCodeの使用を一部緩和しますが、StarkNetは外部コントラクトの呼び出しをまったく許可しません。

Aztec プロトコルでは、検証関数を実際に呼び出して結果が or であるかどうかを判断するのではなく、クライアントが添付されたゼロ知識証明を検証する必要があるため、trueAztecfalse は、他のプロトコルとは異なり、検証フェーズ中に制限を課しません。 アカウント内の契約エントリポイントは、他の契約を自由に呼び出したり、任意のストレージにアクセスしたり、任意の計算を実行したりできます。

インタラクションフロー

より詳細に言うと、zkSync EraとStarkNetでは、プロトコルが指定された関数をエントリポイントとして呼び出し、この制限を課すため、「アカウントコントラクト」のみがトランザクションを開始できます。 ただし、Aztecでは、プロトコルがエントリポイントとして呼び出す機能に制限がないため、「すべてのコントラクト」がトランザクションを開始できます。 つまり、Aztec では、ユーザーが特定のロール (EIP-4337 の EntryPoint コントラクトやネイティブ AA のシーケンサー/オペレーターなど) にトランザクションを送信し、ターゲット コントラクトを呼び出す固定された対話フローではなくなりました。 ユーザーはウォレットを介してトランザクションを送信し、ターゲットコントラクトが関連するインタラクションを直接完了できるようにすることで、柔軟性が大幅に向上します。

AA の別の実装である EIP-2938 に精通している場合は、Aztec がマルチテナント アプローチに似ていることに気付くでしょう。 ただし、これは自分で調べることができるより深いトピックです。

Aztec アカウントのキー

Aztec では、通常、各アカウントには署名キーとプライバシーマスターキーの 2 つのマスターキーがあります。

署名キー

署名キーは、秘密キーを使用して特定のアクションを実行するユーザーの承認を表すために使用されます。 簡単な例は、ユーザーが署名キーから派生した公開キーをアカウント コントラクトに記録する場合です。 生成された署名は、この署名キーを使用してトランザクションまたはメッセージに署名し、コントラクトに記録された公開キー(キーの形式で保存される所有者制御キーとも呼ばれます)と一致することを確認することで、コントラクト内で復元できます。 addressSolidityウォレットコントラクト)。

デジタル署名の楕円曲線のアルゴリズムの選択は、ユーザー次第です。 たとえば、イーサリアムはsecp256k1を使用していますが、アステカは使用する例のシュノールを提供しています。 アカウント コントラクトでは、entrypoint() 関数がエントリ ポイント (呼び出しのソース) として機能し、検証ロジック (is_valid_impl()) によって使用され、Schnorr 署名がレコード std::schnorr::verify_signature(…) の公開キーと一致するかどうかをチェックします。

署名鍵は、私たちがよく知っているスマートコントラクトウォレットの所有者が制御する鍵と基本的に同じなので、比較的理解しやすいはずです。 実際、署名キーは絶対に必要というわけではありません。 アカウント開発者が別の検証メカニズムを実装している場合、アカウントに署名キーがない可能性があります。

プライバシーマスターキー

Aztecアカウントのプライバシーマスターキーは譲渡できません。 各 Aztec アカウントは、秘密マスター キーに関連付けられています。 秘密マスター キーは公開マスター キーを導出し、公開マスター キーはコントラクト コードでハッシュされてアカウント コントラクトのアドレスを生成します。

当社は、ユーザーのaccount_address、partial_address、および総称して、アカウントの完全なアドレスとしてpublic_master_keyします。 プライベートな状態を扱う場合、公開鍵が意図したアドレスに対応していることを誰もが確認できるように、ユーザーはこれら 3 つの情報を提供する必要があります。

ただし、プライベートステートを処理するつもりがなく、欠落しているpublic_master_keyアプリケーション(DeFiなど)の場合は、そのpublic_master_keyフィールド0を入力するだけで、プライベートノートを受け取りたくないことを示すことができます。

そのため、Aztecでは、アカウントのセキュリティを強化するために、アカウントコントラクトに検証メカニズムや回復メカニズムを実装することができますが、プライバシーマスターキーに関連するメカニズムはプロトコルに印刷され、アドレスに関連付けられます。 したがって、互換性はありません。

ここでの意味は、このキーはイーサリアムのEOA(外部所有アカウント)の秘密鍵と同じくらい重要であり、アカウントの単一障害点(SPoF)になるということです。 ユーザーが紛失したり、アカウントのプライバシーマスターキーが盗まれたりした場合、アカウントが回復できないことは間違いありません。

また、プライバシーマスターキーは、BIP-32 と同様のプロセスを使用して、暗号化キーと無効なキーをエクスポートします。 ユーザーは、さまざまなアプリケーションやアクションで異なる暗号化キーと無効なキーを使用して、プライバシーとセキュリティを確保できます。

暗号化キー

暗号化キーの公開鍵は秘密メモの暗号化に使用され、秘密鍵は暗号化解除に使用されます。 例えば、トークン転送のシナリオでは、私(トークン送信者)が友人(トークン受信者)にトークンを転送したい場合、プライベートノートを暗号化して送信する必要があります(トークンの転送には変数の変更が含まれますが、基本的にバランスは友人の暗号公開鍵を使用してプライベートステート変数UTXOを変更することです)。

部外者から見ると、トークン受信者の暗号化秘密鍵を知らなければ、この秘密メモを解読したり、トークン受信者が誰であるかを知ることはできません。

ヌル文字

プライベートノートが使用されるたびに、そのプライベートコメントから派生した無効な文字が生成されます(無効なキーで暗号化されます)。 このメカニズムは、Aztecプロトコルが無効な文字が一意であるかどうかをチェックするため、二重支払いを防ぐために使用されます(他の人が同じ方法を使用して紙幣の場所を特定したり、資金を2回引き落としたりするのを防ぐため)。 その無効な文字をプライベートノートと照合するには、無効な秘密鍵で復号化する必要があるため、その所有者のみが2つの間の関係を確立できます。

#アステカトランザクション

Aztecでのトランザクションの概念の説明は、UTXO(プライベートノート)と混同されやすく、EVMとAztecでのトランザクションの実行モードがまったく異なるため、難しい場合があります。

アステカでは、すべてのトランザクションはゼロ知識証明の形でブロードキャストされます(明らかにプライバシー上の理由から)。 ユーザーは、以前のようにRPC APIを介してマイナーのmempoolまたはレイヤー2オペレーターにトランザクションオブジェクトを送信するのではなく、トランザクションに対応するプルーフを生成するために、ノード(ウォレットアプリケーションまたはクライアント)でローカルに計算を実行する必要があります。

トランザクションのハッシュとナンス

ユーザーがトランザクションをローカルで作成する場合、次の 2 つの重要な要素があります。

1. 送信者アドレス: これは、トランザクションを処理するアカウント契約のアドレスを表します。 このアカウント契約には、先ほど述べたエントリポイントがあり、外部の当事者がアクション(トランザクション)がアカウント所有者によって承認されているかどうかを確認するための検証機能として機能します。
2. ペイロードデータ:これには、署名、宛先コントラクトアドレス、値、データなど、トランザクションに関する情報が含まれます。

Aztecのプロトコルレベルでは、同じトランザクションが複数回実行されるのを防ぐ手段として、有効な各トランザクションのハッシュが使用されます。 アカウント コントラクトの開発者は、アカウント コントラクトと関連するロジックに nonce を含めるかどうかを決定できます。 たとえば、トランザクションの nonce フィールドを厳密に増やすことや、トランザクションを任意の順序で処理できるようにするなどの要件を設定できます。

プロトコルレベルでは厳密なノンス要件がないため、Aztecは、同じナンスとより高いガス料金で新しいトランザクションを送信して、保留中のトランザクションをキャンセルすることはできません。

リクエストの実行

前述したように、ユーザーは状況に応じてアカウントコントラクト内の任意の機能をエントリポイントとして指定でき、Aztecでの操作は単純な取引オブジェクトによって制御されません。 実際、契約アカウントに何をすべきかを指示するのは、「実行要求」と呼ばれるオブジェクトです。 このオブジェクトは、“次のパラメータの 0x1234 つを使用してコントラクトの転送関数を呼び出す” など、ユーザーの動作を表します。

ユーザーはウォレット内でローカルにトランザクションを開始しますが、sender_addressはアカウントコントラクトのアドレスであり、ペイロード呼び出しターゲットコントラクトtransfer()内の関数の関連するエンコードデータと、アカウントコントラクトで検証できる署名が含まれています。 ウォレットは、これら2つの要素を実行リクエストに変換します。

次に、ウォレットは、プライベート・ノート、暗号化キー、または無効なシークレットをローカル仮想マシンに入力して、この実行リクエストをシミュレートします。 シミュレーションプロセス中に実行トレースが生成され、それが証明者に渡されてゼロ知識証明が生成されます。 この証明は、これらの計算(プライベート関数の実行)が実際にユーザーによってローカルに行われていることを示しています。

このプロセスを通じて、証明とprivate_data(このトランザクションのプライベートカーネル回路の出力)の2つの情報を取得します。 次に、ウォレットはこれら 2 つの情報を含むトランザクション オブジェクトを Aztec の Sequencer mempool に送信し、トランザクションを完了します。

EVM型ではなくクライアントベースのZKP型実行環境

Aztec では、EVM のようなチューリング マシンにすべての情報を入力して、更新された状態を生成するだけではありません。 代わりに、各Dapp内の回路に依存して、プライバシー情報がどのように機能するかを決定します。 つまり、Dapp開発者は、コントラクト変数の状態を証明する方法を持っている必要があります。 例えば、ERC-20トークンコントラクトにおけるユーザーの残高を考えてみましょう。 10個のDAIトークンを転送する場合、コントラクトには次のロジックがあります。

1.送信者の残高が10DAI(つまり、>10DAI)を超えているかどうかを確認します。 2. 送信者に十分な残高がある場合、送信者の 10 DAI の破棄を示す無効な文字が作成されます (これにより、送信者が 10 DAI のプライベートノートを所有していることを相殺できます)。 3.受信者の新しいプライベートメモを作成します。 4. 10 DAIで送信されるすべてのメッセージをブロードキャストして暗号化します。

部外者から見ると、新しい無効とコメントが表示されることしかなく、それらはすべて暗号化されています。 ですから、新しい取引が行われたことは誰もが知っていますが、内部で何が起こっているのかは、関係者だけが知っています。

Aztec アカウント契約の詳細

ウォレット

Aztecのウォレットは、ユーザーとブロックチェーンとのやり取りや個人データを管理する上で重要な部分です。 Aztecウォレットが処理する必要があるタスクの概要は次のとおりです。

1. アカウントの作成:ウォレットは、ユーザーが新しいアカウント契約を作成できるようにする必要がありますが、これは本質的にブロックチェーン上に新しいアカウント契約を展開することを意味します。 2.秘密鍵管理:ウォレットは、プライバシーマスターキーと署名キー(アカウントコントラクトの設計によって異なります)を含む、ユーザーのシードフレーズと秘密キーを管理する責任があります。 この管理は、ハードウェアウォレットの統合にも拡張できます。
2. アカウントの表示: ユーザーは、自分のアカウントと、残高やその他のプライベート ステータスを含む関連するステータスを表示できる必要があります。 これは、ウォレットがユーザーに関連するすべてのプライベートノートのローカルデータベースを維持する必要があることを意味します。
3. Dappsとの対話:ウォレットは、ユーザーとDappsの間の相互作用を促進する必要があります。 ユーザーがDappと対話すると、Dappはユーザーのアカウントからトランザクションを送信するように要求できます。
4. ユーザーの同意:Dappsは、トークンコントラクトの残高など、特定のコントラクト状態を表示するためにユーザーの同意を必要とする場合があります。 これらの状態を公開するには、ウォレットがユーザーリクエストを受信できる必要があります(残高を公開するにはユーザーキーの同意が必要なため)。
5. プルーフの生成:ユーザーに代わってトランザクションを送信するには、ウォレットがローカルでプルーフを生成できる必要があります。 これには、トランザクションの有効性のゼロ知識証明の作成と処理が含まれます。

注意すべき重要な点は、ウォレットがジェネシスブロックから始まるすべてのブロックをスキャンし、ユーザーのキーを使用して関連するプライベートノートを検出して復号化し、将来の使用のためにローカルデータベースに保存する必要があることです。 これは、ユーザーの操作を容易にし、プライベートな状態データを効果的に管理できるようにするために重要です。

Aztec のもうひとつの重要な側面として、ユーザーが完全なアドレスをブロードキャストする必要があるとおっしゃいました。 ウォレットがターゲットトランザクションの受取人のために暗号ノートを作成するとき、受取人の完全なアドレスを取得できる必要もあります。 これは、受信者のアドレスのローカルデータベースを手動で入力または維持することで実現できます。 詳細については、公式の Aztec ドキュメントを参照してください。

アカウント契約

Aztec では、アカウント契約の主なタスクは、署名の検証 (トランザクションがアカウント所有者によって承認されているため、必ずしも「特定のデジタル署名アルゴリズムによって検証される」のではなく、より広範に承認されていることを確認する)、ガス消費量の管理、および他のコントラクトの呼び出しです。

これは、Schnorr署名アルゴリズムを使用したAztecアカウント契約の公式例です。 すべてのトランザクションのエントリポイントはentrypoint()関数です(開始点として関数または名前を自由に選択できますが、この場合はentrypoint()が使用されます)。

添付ファイルペイロードを使用して entrypoint() アカウントを呼び出すと、アカウント コントラクト entrypoint() は Aztec AA アカウント ライブラリ entrypoint() を呼び出します。

Aztec では、アカウント コントラクトを EntrypointPayload および Aztec AA アカウント ライブラリにインポートする必要はありません。 独自のアカウント契約ロジックを自由に設計できます。

はコンテキストであり、Aztec.nr のすべての関数で使用できるオブジェクトです。 コンテキストアプリケーションの実行に必要なすべてのカーネル情報が含まれています。 アステカの公式ドキュメントから引用。 - 背景は何ですか

上記は、Aztec AAアカウントライブラリのコードentrypoint()です。 これは、アカウントが_valid_implコントラクトで定義された検証関数()に基づいて、操作がアカウント所有者によって承認されているかどうかを判断する責任があり、トランザクションに必要な_calls操作を実装するために必要な呼び出しを行います。

つまり、この Aztec AA ライブラリを参照する必要があり、アカウント コントラクトに同じ関数シグネチャを持つ is_valid_impl 実装がない場合、この手順は失敗します。

もうひとつの重要な実装の詳細は、get_auth_witness() を使用して署名を取得することです。 ウィットネスの仕組みの詳細については、以下の参考資料を参照してください。 簡単に言うと、ミラーリング監視とは「ユーザーがやりたいことを行うための承認」です。

認証監視は、Aztec での操作を検証するためのスキームであるため、ユーザーは、プロトコルや他のユーザーなどのサードパーティが自分に代わってアクションを実行することを許可できます。 アステカの公式ドキュメントから引用。 — 認定証人

単に「署名」ではなく「証人」と呼ばれるのは、アカウント契約の検証方法が必ずしも署名の検証を伴わないためです。

例えば、アリスのアカウントからDeFiプラットフォームに1000トークンを送金する操作があるとします。 この場合、トークンコントラクトは Alice のアカウントコントラクトを照会して、Alice が「アクション」を承認したかどうかを確認する必要があります。 この「アクション」では、アリスのウォレット(ローカル)に認証証人を生成する必要があり、これはアリスのアカウントコントラクトを通じて検証できます。 アカウントコントラクトが正常に検証されると、トークンコントラクトは「アクション」が承認されたことを認識します。

まとめ

現在のところ、アステカは手数料の仕組みを実装しておらず、彼らの目標は手数料の支払いを抽象化することでもあります。 つまり、取引が有効であると見なされるためには、その取引が自社の手数料を賄うのに十分な資金をロックしていることを証明する必要があります。 ただし、これらの資金がどこから来るかは指定されていないため、即時交換による支払いまたは現物支払いが簡単に可能になります。