# イーサリアムPectraアップグレード:EIP-7702デプス解析及びベストプラクティス## イントロダクションイーサリアムはPectraアップグレードを迎えようとしており、これは重要な更新であり、いくつかの重要なイーサリアム改善提案が導入されます。その中で、EIP-7702はイーサリアムの外部アカウント(EOA)に対して革命的な改造を行いました。この提案は、EOAとコントラクトアカウントCAの境界を曖昧にし、EIP-4337に続くネイティブアカウント抽象化に向けた重要なステップであり、イーサリアムエコシステムに新しいインタラクションモデルをもたらします。Pectraはテストネットでの展開を完了し、近日中にメインネットに登場する予定です。本稿ではEIP-7702の実装メカニズムを深く分析し、それがもたらす可能性のある機会と課題を探り、さまざまな参加者に実用的な操作ガイドを提供します。## プロトコル分析###概要EIP-7702は新しい取引タイプを導入し、EOAがスマートコントラクトのアドレスを指定してコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行しながら、取引を開始する能力を維持できます。この機能はEOAにプログラマビリティとコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、マルチシグ管理、zk検証、サブスクリプション型支払い、取引スポンサーシップ、取引バッチ処理などの機能を実現できます。注目すべきは、EIP-7702がEIP-4337によって実現されるスマートコントラクトウォレットと完全に互換性があり、両者のシームレスな統合が新機能の開発と適用プロセスを大幅に簡素化することです。EIP-7702は、取引タイプSET_CODE_TX_TYPE (0x04)の取引を導入しました。そのデータ構造は以下のように定義されています:rlp([chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s])authorization_listフィールドは次のように定義されています:authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]新しい取引構造では、authorization_listフィールドを除いて、他はEIP-4844と同じ意味を持ちます。このフィールドはリスト型で、複数の承認エントリを含むことができ、各承認エントリには:- chain_idはこの認可委託が有効なチェーンを示します- addressは委託の対象アドレスを示します- nonceは現在の認可されたアカウントのnonceと一致する必要があります- y_parity、r、sは権限を持つアカウントが承認の署名データを署名するためのものです一つのトランザクション内のauthorization_listフィールドには、複数の異なる承認アカウント(EOA)によって署名された承認エントリが含まれることができ、つまりトランザクションの発起者は承認者とは異なり、承認者の承認操作に対してガスの代金を支払うことができます。###実装権限付与者が権限データに署名する際には、まずchain_id、address、nonceをRLPエンコードする必要があります。その後、エンコードされたデータとMAGIC数を一緒にkeccak256ハッシュ演算を行い、署名待ちのデータを得ます。最後に、権限付与者の秘密鍵を使用してハッシュされたデータに署名し、y_parity、r、sデータを取得します。MAGIC (0x05)はドメイン区切りとして使用され、異なるタイプの署名結果が衝突しないことを保証する目的があります。承認者が承認したchain_idが0のとき、承認者はすべてのEIP-7702をサポートするEVM互換チェーンで(の承認をリプレイすることを許可します。ただし、nonceもちょうど)と一致する必要があります。権限者が権限データに署名した後、取引の発起者はそのデータをauthorization_listフィールドに集約し、署名してRPCで取引をブロードキャストします。取引がブロックに含まれて実行される前に、提案者は取引を事前にチェックします。この際、toアドレスに対して強制チェックを行い、この取引が契約作成取引でないことを確認します。つまり、EIP-7702タイプの取引を送信する際、取引のtoアドレスは空であってはなりません。同時に、このような取引では、authorization_listフィールドには少なくとも1つの承認項目が含まれている必要があります。複数の承認項目が同じ承認者によって署名されている場合、最終的に最後の承認項目のみが有効になります。トランザクションの実行中、ノードは最初にトランザクション・イニシエータのnonce値を増やし、次にauthorization_listの各認可エントリに対してapplyAuthorization操作を実行します。 applyAuthorization操作では、ノードはオーソライザーのnonceをチェックし、オーソライザーのnonceを追加します。 つまり、トランザクションの開始者と承認者が同じユーザー (EOA)である場合、承認トランザクションに署名するときに nonce 値を 1 ずつ追加する必要があります。ノードが特定の許可項目を適用する際に、何らかのエラーが発生した場合、その許可項目はスキップされ、取引は失敗せず、他の許可項目は引き続き適用されます。これにより、一括許可シナリオにおいてDoSリスクが発生しないことが保証されます。アプリケーションの権限付与が完了すると、権限付与者のアドレスのcodeフィールドは0xef0100 || addressに設定されます。ここで、0xef0100は固定の識別子で、addressは委託先のターゲットアドレスです。EIP-3541の制限により、ユーザーは0xefバイトで始まるコントラクトコードを通常の方法でデプロイすることができず、このような識別子はSET_CODE_TX_TYPE (0x04)タイプのトランザクションによってのみデプロイできることが保証されています。承認が完了した後、承認者が承認を削除したい場合は、委任先のアドレスを0アドレスに設定するだけで済みます。EIP-7702によって導入された新しいトランザクションタイプにより、承認者(EOA)は、スマートコントラクトのようにコードを実行できるだけでなく、トランザクションを開始する能力も保持しています。EIP-4337と比較して、これによりユーザーはネイティブアカウント抽象(Native AA)により近い体験を提供され、ユーザーの使用ハードルが大幅に低下しました。## ベストプラクティスEIP-7702がイーサリアムエコシステムに新たな活力を注入したにもかかわらず、新しいアプリケーションシーンは新たなリスクももたらします。以下は、エコシステムの参加者が実践の過程で警戒すべき点です。### 秘密鍵の保管たとえEOAが委託後にスマートコントラクトに組み込まれたソーシャルリカバリーなどの手段を使って、秘密鍵の喪失による資金損失問題を解決できるとしても、EOAの秘密鍵が漏洩するリスクを回避することはできません。委託を実行した後、EOAの秘密鍵は依然としてアカウントに対して最高の制御権を持っており、秘密鍵を所持している限り、アカウント内の資産を自由に処分することができます。ユーザーやウォレットサービスプロバイダーがEOAの委託を完了した後、ローカルに保存されている秘密鍵を完全に削除しても、特にサプライチェーン攻撃のリスクが存在するシナリオにおいて、秘密鍵の漏洩リスクを完全に排除することはできません。ユーザーにとって、委託後のアカウントを使用する際には、常に秘密鍵の保護を最優先にし、注意を怠らないことが重要です: Not your keys, not your coins。### マルチチェーンリプレイユーザーは委任権限を署名する際、chainIdを通じて委任が有効となるチェーンを選択できます。もちろん、ユーザーはchainIdを0に設定して委任することも選択でき、これにより委任は複数のチェーンで再生され、有効になります。これにより、ユーザーは一度の署名で複数のチェーンで委任を行うことができます。ただし、複数のチェーン上で委任される同一のコントラクトアドレスには、異なる実装コードが存在する可能性があることに注意が必要です。ウォレットサービスプロバイダーは、ユーザーが委託を行う際に、委託の有効チェーンが現在接続されているネットワークと一致しているかを確認し、chainIdが0の委託に署名することによるリスクをユーザーに警告する必要があります。ユーザーはまた、異なるチェーン上の同じコントラクトアドレスが必ずしも同じコントラクトコードでないことに注意する必要があり、委託の目的を事前に理解しておくべきです。### 初期化できません現在、主流のスマートコントラクトウォレットのほとんどはプロキシモデルを採用しており、ウォレットプロキシはデプロイ時にDELEGateCALLを通じてコントラクトの初期化関数を呼び出すことで、ウォレットの初期化とプロキシウォレットのデプロイを原子操作として実現し、先に初期化される問題を回避します。しかし、ユーザーがEIP-7702を使用して委託を行う場合、アドレスのcodeフィールドのみが更新され、委託アドレスを呼び出して初期化することはできません。これにより、EIP-7702は一般的なERC-1967プロキシコントラクトのようにコントラクトデプロイのトランザクション内で初期化関数を呼び出してウォレットを初期化することができなくなります。開発者にとって、EIP-7702を既存のEIP-4337ウォレットと組み合わせて適応させる際には、ウォレットの初期化操作で権限チェックを行うことに注意するべきです(。例えば、ecrecoverを通じて署名されたアドレスを復元することで権限チェックを行い)、ウォレットの初期化操作が先行されるリスクを回避することができます。### ストレージ管理ユーザーがEIP-7702委託機能を使用する際、機能要件の変更やウォレットのアップグレードなどの理由により、異なるコントラクトアドレスに再委託する必要がある場合があります。しかし、異なるコントラクトのストレージ構造には違いがある可能性があり(、例えば異なるコントラクトのslot0スロットは異なるタイプのデータを表すことがあります)。再委託の状況では、新しいコントラクトが古いコントラクトのデータを偶然再利用する可能性があり、それによりアカウントのロックや資金の損失などの不利益な結果を引き起こす可能性があります。ユーザーにとって、再委託の状況を慎重に扱うべきです。開発者にとって、開発プロセスではERC-7201が提案するNamespace Formulaに従い、変数を指定された独立したストレージ位置に割り当てて、ストレージの競合リスクを軽減する必要があります。さらに、ERC-7779 (draft)はEIP-7702に特化した再委託の標準プロセスを提供しています：これには、ERC-7201を使用してストレージの競合を防ぎ、再委託の前にストレージの互換性を検証し、旧委託のインターフェースを呼び出してストレージの古いデータをクリーンアップすることが含まれます。### 偽チャージユーザーが委託を行った後、EOAもスマートコントラクトとして使用できるようになります。したがって、中央集権型取引所(CEX)は、スマートコントラクトの充填が一般化する状況に直面する可能性があります。CEXはtraceを通じて各充電取引の状態を確認し、スマートコントラクトの偽充電リスクを防ぐべきです。### アカウント変換EIP-7702の委任を実施した後、ユーザーのアカウントタイプはEOAとSCの間で自由に変換できるようになり、アカウントは取引を開始することも、呼び出されることも可能になります。これは、アカウントが自身を呼び出し、外部呼び出しを行うとき、そのmsg.senderもtx.originになることを意味し、EOAのみが参加するプロジェクトに対するいくつかのセキュリティ仮定を破ることになります。コントラクト開発者にとって、tx.originが常にEOAであると仮定することはもはや実行可能ではありません。同様に、msg.sender == tx.originによるチェックで再入攻撃を防ぐことも無効になります。開発者は開発プロセスにおいて、将来の参加者がすべてスマートコントラクトであると仮定すべきである。### コントラクト互換性既存のERC-721、ERC-777トークンは、コントラクトへの転送時にフック機能を持っており、これは受信者がトークンを正常に受け取るために対応するコールバック関数を実装する必要があることを意味します。開発者にとって、ユーザーが委託したターゲットコントラクトは、主流のトークンと互換性を確保するために、相応のコールバック関数を実装する必要があります。### フィッシングチェックEIP-7702の委託を実施した後、ユーザーアカウント内の資産はすべてスマートコントラクトによって制御される可能性があり、ユーザーがアカウントを悪意のあるコントラクトに委託した場合、攻撃者が資金を盗むことが容易になります。ウォレットサービスプロバイダーにとって、EIP-7702タイプのトランザクションをできるだけ早くサポートすることが特に重要であり、ユーザーが委任署名を行う際には、委任の対象契約をユーザーに強調して示すべきです。これにより、ユーザーがフィッシング攻撃のリスクにさらされる可能性を軽減します。さらに、アカウント委託の対象コントラクトに対して、より深い自動分析(オープンソースチェック、権限チェックなど)を行うことで、ユーザーがこのようなリスクを回避するのに役立ちます。## まとめこの記事では、イーサリアムの近日中に予定されているPectraアップグレードにおけるEIP-7702提案について探討します。EIP-7702は新しい取引タイプを導入することで、EOAにプログラム可能性とコンビナビリティを与え、EOAとコントラクトアカウントの境界を曖昧にします。現在、実戦で試されたEIP-7702タイプのスマートコントラクト標準が存在しないため、実際の応用において、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなどの異なるエコシステム参加者は、多くの課題と機会に直面しています。本記事で述べられているベストプラクティスの内容は、すべての潜在的リスクをカバーするものではありませんが、依然として各方面が実際の操作において参考にし、適用する価値があります。
EIP-7702解析:イーサリアムPectraアップグレードがEOAにプログラム可能性を与える方法
イーサリアムPectraアップグレード:EIP-7702デプス解析及びベストプラクティス
イントロダクション
イーサリアムはPectraアップグレードを迎えようとしており、これは重要な更新であり、いくつかの重要なイーサリアム改善提案が導入されます。その中で、EIP-7702はイーサリアムの外部アカウント(EOA)に対して革命的な改造を行いました。この提案は、EOAとコントラクトアカウントCAの境界を曖昧にし、EIP-4337に続くネイティブアカウント抽象化に向けた重要なステップであり、イーサリアムエコシステムに新しいインタラクションモデルをもたらします。
Pectraはテストネットでの展開を完了し、近日中にメインネットに登場する予定です。本稿ではEIP-7702の実装メカニズムを深く分析し、それがもたらす可能性のある機会と課題を探り、さまざまな参加者に実用的な操作ガイドを提供します。
プロトコル分析
###概要
EIP-7702は新しい取引タイプを導入し、EOAがスマートコントラクトのアドレスを指定してコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行しながら、取引を開始する能力を維持できます。この機能はEOAにプログラマビリティとコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、マルチシグ管理、zk検証、サブスクリプション型支払い、取引スポンサーシップ、取引バッチ処理などの機能を実現できます。注目すべきは、EIP-7702がEIP-4337によって実現されるスマートコントラクトウォレットと完全に互換性があり、両者のシームレスな統合が新機能の開発と適用プロセスを大幅に簡素化することです。
EIP-7702は、取引タイプSET_CODE_TX_TYPE (0x04)の取引を導入しました。そのデータ構造は以下のように定義されています:
rlp([chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s])
authorization_listフィールドは次のように定義されています:
authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]
新しい取引構造では、authorization_listフィールドを除いて、他はEIP-4844と同じ意味を持ちます。このフィールドはリスト型で、複数の承認エントリを含むことができ、各承認エントリには:
一つのトランザクション内のauthorization_listフィールドには、複数の異なる承認アカウント(EOA)によって署名された承認エントリが含まれることができ、つまりトランザクションの発起者は承認者とは異なり、承認者の承認操作に対してガスの代金を支払うことができます。
###実装
権限付与者が権限データに署名する際には、まずchain_id、address、nonceをRLPエンコードする必要があります。その後、エンコードされたデータとMAGIC数を一緒にkeccak256ハッシュ演算を行い、署名待ちのデータを得ます。最後に、権限付与者の秘密鍵を使用してハッシュされたデータに署名し、y_parity、r、sデータを取得します。MAGIC (0x05)はドメイン区切りとして使用され、異なるタイプの署名結果が衝突しないことを保証する目的があります。
承認者が承認したchain_idが0のとき、承認者はすべてのEIP-7702をサポートするEVM互換チェーンで(の承認をリプレイすることを許可します。ただし、nonceもちょうど)と一致する必要があります。
権限者が権限データに署名した後、取引の発起者はそのデータをauthorization_listフィールドに集約し、署名してRPCで取引をブロードキャストします。取引がブロックに含まれて実行される前に、提案者は取引を事前にチェックします。この際、toアドレスに対して強制チェックを行い、この取引が契約作成取引でないことを確認します。つまり、EIP-7702タイプの取引を送信する際、取引のtoアドレスは空であってはなりません。
同時に、このような取引では、authorization_listフィールドには少なくとも1つの承認項目が含まれている必要があります。複数の承認項目が同じ承認者によって署名されている場合、最終的に最後の承認項目のみが有効になります。
トランザクションの実行中、ノードは最初にトランザクション・イニシエータのnonce値を増やし、次にauthorization_listの各認可エントリに対してapplyAuthorization操作を実行します。 applyAuthorization操作では、ノードはオーソライザーのnonceをチェックし、オーソライザーのnonceを追加します。 つまり、トランザクションの開始者と承認者が同じユーザー (EOA)である場合、承認トランザクションに署名するときに nonce 値を 1 ずつ追加する必要があります。
ノードが特定の許可項目を適用する際に、何らかのエラーが発生した場合、その許可項目はスキップされ、取引は失敗せず、他の許可項目は引き続き適用されます。これにより、一括許可シナリオにおいてDoSリスクが発生しないことが保証されます。
アプリケーションの権限付与が完了すると、権限付与者のアドレスのcodeフィールドは0xef0100 || addressに設定されます。ここで、0xef0100は固定の識別子で、addressは委託先のターゲットアドレスです。EIP-3541の制限により、ユーザーは0xefバイトで始まるコントラクトコードを通常の方法でデプロイすることができず、このような識別子はSET_CODE_TX_TYPE (0x04)タイプのトランザクションによってのみデプロイできることが保証されています。
承認が完了した後、承認者が承認を削除したい場合は、委任先のアドレスを0アドレスに設定するだけで済みます。
EIP-7702によって導入された新しいトランザクションタイプにより、承認者(EOA)は、スマートコントラクトのようにコードを実行できるだけでなく、トランザクションを開始する能力も保持しています。EIP-4337と比較して、これによりユーザーはネイティブアカウント抽象(Native AA)により近い体験を提供され、ユーザーの使用ハードルが大幅に低下しました。
ベストプラクティス
EIP-7702がイーサリアムエコシステムに新たな活力を注入したにもかかわらず、新しいアプリケーションシーンは新たなリスクももたらします。以下は、エコシステムの参加者が実践の過程で警戒すべき点です。
秘密鍵の保管
たとえEOAが委託後にスマートコントラクトに組み込まれたソーシャルリカバリーなどの手段を使って、秘密鍵の喪失による資金損失問題を解決できるとしても、EOAの秘密鍵が漏洩するリスクを回避することはできません。委託を実行した後、EOAの秘密鍵は依然としてアカウントに対して最高の制御権を持っており、秘密鍵を所持している限り、アカウント内の資産を自由に処分することができます。ユーザーやウォレットサービスプロバイダーがEOAの委託を完了した後、ローカルに保存されている秘密鍵を完全に削除しても、特にサプライチェーン攻撃のリスクが存在するシナリオにおいて、秘密鍵の漏洩リスクを完全に排除することはできません。
ユーザーにとって、委託後のアカウントを使用する際には、常に秘密鍵の保護を最優先にし、注意を怠らないことが重要です: Not your keys, not your coins。
マルチチェーンリプレイ
ユーザーは委任権限を署名する際、chainIdを通じて委任が有効となるチェーンを選択できます。もちろん、ユーザーはchainIdを0に設定して委任することも選択でき、これにより委任は複数のチェーンで再生され、有効になります。これにより、ユーザーは一度の署名で複数のチェーンで委任を行うことができます。ただし、複数のチェーン上で委任される同一のコントラクトアドレスには、異なる実装コードが存在する可能性があることに注意が必要です。
ウォレットサービスプロバイダーは、ユーザーが委託を行う際に、委託の有効チェーンが現在接続されているネットワークと一致しているかを確認し、chainIdが0の委託に署名することによるリスクをユーザーに警告する必要があります。
ユーザーはまた、異なるチェーン上の同じコントラクトアドレスが必ずしも同じコントラクトコードでないことに注意する必要があり、委託の目的を事前に理解しておくべきです。
初期化できません
現在、主流のスマートコントラクトウォレットのほとんどはプロキシモデルを採用しており、ウォレットプロキシはデプロイ時にDELEGateCALLを通じてコントラクトの初期化関数を呼び出すことで、ウォレットの初期化とプロキシウォレットのデプロイを原子操作として実現し、先に初期化される問題を回避します。しかし、ユーザーがEIP-7702を使用して委託を行う場合、アドレスのcodeフィールドのみが更新され、委託アドレスを呼び出して初期化することはできません。これにより、EIP-7702は一般的なERC-1967プロキシコントラクトのようにコントラクトデプロイのトランザクション内で初期化関数を呼び出してウォレットを初期化することができなくなります。
開発者にとって、EIP-7702を既存のEIP-4337ウォレットと組み合わせて適応させる際には、ウォレットの初期化操作で権限チェックを行うことに注意するべきです(。例えば、ecrecoverを通じて署名されたアドレスを復元することで権限チェックを行い)、ウォレットの初期化操作が先行されるリスクを回避することができます。
ストレージ管理
ユーザーがEIP-7702委託機能を使用する際、機能要件の変更やウォレットのアップグレードなどの理由により、異なるコントラクトアドレスに再委託する必要がある場合があります。しかし、異なるコントラクトのストレージ構造には違いがある可能性があり(、例えば異なるコントラクトのslot0スロットは異なるタイプのデータを表すことがあります)。再委託の状況では、新しいコントラクトが古いコントラクトのデータを偶然再利用する可能性があり、それによりアカウントのロックや資金の損失などの不利益な結果を引き起こす可能性があります。
ユーザーにとって、再委託の状況を慎重に扱うべきです。
開発者にとって、開発プロセスではERC-7201が提案するNamespace Formulaに従い、変数を指定された独立したストレージ位置に割り当てて、ストレージの競合リスクを軽減する必要があります。さらに、ERC-7779 (draft)はEIP-7702に特化した再委託の標準プロセスを提供しています：これには、ERC-7201を使用してストレージの競合を防ぎ、再委託の前にストレージの互換性を検証し、旧委託のインターフェースを呼び出してストレージの古いデータをクリーンアップすることが含まれます。
偽チャージ
ユーザーが委託を行った後、EOAもスマートコントラクトとして使用できるようになります。したがって、中央集権型取引所(CEX)は、スマートコントラクトの充填が一般化する状況に直面する可能性があります。
CEXはtraceを通じて各充電取引の状態を確認し、スマートコントラクトの偽充電リスクを防ぐべきです。
アカウント変換
EIP-7702の委任を実施した後、ユーザーのアカウントタイプはEOAとSCの間で自由に変換できるようになり、アカウントは取引を開始することも、呼び出されることも可能になります。これは、アカウントが自身を呼び出し、外部呼び出しを行うとき、そのmsg.senderもtx.originになることを意味し、EOAのみが参加するプロジェクトに対するいくつかのセキュリティ仮定を破ることになります。
コントラクト開発者にとって、tx.originが常にEOAであると仮定することはもはや実行可能ではありません。同様に、msg.sender == tx.originによるチェックで再入攻撃を防ぐことも無効になります。
開発者は開発プロセスにおいて、将来の参加者がすべてスマートコントラクトであると仮定すべきである。
コントラクト互換性
既存のERC-721、ERC-777トークンは、コントラクトへの転送時にフック機能を持っており、これは受信者がトークンを正常に受け取るために対応するコールバック関数を実装する必要があることを意味します。
開発者にとって、ユーザーが委託したターゲットコントラクトは、主流のトークンと互換性を確保するために、相応のコールバック関数を実装する必要があります。
フィッシングチェック
EIP-7702の委託を実施した後、ユーザーアカウント内の資産はすべてスマートコントラクトによって制御される可能性があり、ユーザーがアカウントを悪意のあるコントラクトに委託した場合、攻撃者が資金を盗むことが容易になります。
ウォレットサービスプロバイダーにとって、EIP-7702タイプのトランザクションをできるだけ早くサポートすることが特に重要であり、ユーザーが委任署名を行う際には、委任の対象契約をユーザーに強調して示すべきです。これにより、ユーザーがフィッシング攻撃のリスクにさらされる可能性を軽減します。
さらに、アカウント委託の対象コントラクトに対して、より深い自動分析(オープンソースチェック、権限チェックなど)を行うことで、ユーザーがこのようなリスクを回避するのに役立ちます。
まとめ
この記事では、イーサリアムの近日中に予定されているPectraアップグレードにおけるEIP-7702提案について探討します。EIP-7702は新しい取引タイプを導入することで、EOAにプログラム可能性とコンビナビリティを与え、EOAとコントラクトアカウントの境界を曖昧にします。現在、実戦で試されたEIP-7702タイプのスマートコントラクト標準が存在しないため、実際の応用において、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなどの異なるエコシステム参加者は、多くの課題と機会に直面しています。本記事で述べられているベストプラクティスの内容は、すべての潜在的リスクをカバーするものではありませんが、依然として各方面が実際の操作において参考にし、適用する価値があります。