# イーサリアム 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 は、承認されたアカウントが承認するために署名したデータです。1つのトランザクション内の 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 を通じて取引をブロードキャストします。取引がブロックに含まれて実行される前に、Proposer はまず取引の事前チェックを行い、その中で to アドレスに対して強制チェックを行い、この取引が契約作成取引でないことを確認します。つまり、EIP-7702 タイプの取引を送信する際、取引の to アドレスは空であってはなりません。同時に、このような取引では、取引の authorization_list フィールドに少なくとも1つの承認項目が含まれていることが強制されます。もし複数の承認項目が同じ承認者によって署名されている場合、最終的には最後の承認項目のみが有効となります。その後、取引実行プロセスにおいて、ノードは最初に取引発起者のノンス値を増加させ、その後 authorization_list の各承認項目に対して applyAuthorization 操作を行います。applyAuthorization 操作では、ノードはまず承認者のノンスをチェックし、その後承認者のノンスを増加させます。これは、取引発起者と承認者が同一のユーザー(EOA)である場合、承認取引に署名する際にノンスの値を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もスマートコントラクトとして使用できるようになるため、取引所はスマートコントラクトの充電の普遍化に直面する可能性があります。取引所は、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タイプのスマートコントラクト標準が存在しないため、ユーザー、ウォレットサービスプロバイダー、開発者、取引所などの異なるエコシステムの参加者は、実際のアプリケーションにおいて多くの課題と機会に直面しています。本稿で述べるベストプラクティスの内容はすべての潜在的リスクをカバーするものではありませんが、実際の操作において各方面が参考にし、応用する価値があります。
EIP-7702デプス解析：イーサリアムPectraアップグレードはEOAとCAの境界を曖昧にする
イーサリアム 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 と同じ意味に従います。このフィールドはリストタイプで、複数の権限エントリを含むことができ、各権限エントリには:
1つのトランザクション内の 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 を通じて取引をブロードキャストします。取引がブロックに含まれて実行される前に、Proposer はまず取引の事前チェックを行い、その中で to アドレスに対して強制チェックを行い、この取引が契約作成取引でないことを確認します。つまり、EIP-7702 タイプの取引を送信する際、取引の to アドレスは空であってはなりません。
同時に、このような取引では、取引の authorization_list フィールドに少なくとも1つの承認項目が含まれていることが強制されます。もし複数の承認項目が同じ承認者によって署名されている場合、最終的には最後の承認項目のみが有効となります。
その後、取引実行プロセスにおいて、ノードは最初に取引発起者のノンス値を増加させ、その後 authorization_list の各承認項目に対して applyAuthorization 操作を行います。applyAuthorization 操作では、ノードはまず承認者のノンスをチェックし、その後承認者のノンスを増加させます。これは、取引発起者と承認者が同一のユーザー(EOA)である場合、承認取引に署名する際にノンスの値を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もスマートコントラクトとして使用できるようになるため、取引所はスマートコントラクトの充電の普遍化に直面する可能性があります。
取引所は、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タイプのスマートコントラクト標準が存在しないため、ユーザー、ウォレットサービスプロバイダー、開発者、取引所などの異なるエコシステムの参加者は、実際のアプリケーションにおいて多くの課題と機会に直面しています。本稿で述べるベストプラクティスの内容はすべての潜在的リスクをカバーするものではありませんが、実際の操作において各方面が参考にし、応用する価値があります。