EIP-3074がウォレットおよびDAppに与える影響の詳細解説

2024.05.21

共有先

TechFlow厳選深潮セレクト

EIP-3074がウォレットおよびDAppに与える影響の詳細解説

EIP-3074により、EOAは契約と同じように豊かな実行能力を獲得し、多くの新しいアプリケーションシナリオが開かれた。

2024.05.21 - 07:55:04

EIP-3074

Web3業界の深掘り報道に専念し潮流を洞察

EIP-3074により、EOAは契約と同じように豊かな実行能力を獲得し、多くの新しいアプリケーションシナリオが開かれた。

執筆：Nic @ imToken Labs

EIP-3074

より良い、より安全なユーザーエクスペリエンス

EIP-3074 により、EOA は自身の制御権を特定のコントラクトに委譲でき、コントラクトと同様の柔軟な実行能力を獲得できるようになります。

EIP-3074 以前は、EOA がトランザクションを送信するたびに、ERC20 の approve や Uniswap での交換など、単一の操作しか行えませんでした。しかし EIP-3074 導入後は、複数の操作を一度に完了できるだけでなく、かつては想像もできなかったような新しい用途も可能になります。

要するに、EIP-3074 はユーザーエクスペリエンスを飛躍的に向上させ、既存の認可方法を再構築し、使いやすさを維持しつつセキュリティを高めます。

さらに、EIP-3074 を通じて、EOA は自らトランザクションをブロックチェーンに送信する必要がなくなり、ガス代として ETH を事前に用意するという煩わしさからも解放されます。

Invoker コントラクト

EOA の制御権を取得可能なコントラクトは「Invoker コントラクト」と呼ばれます。ただし、任意のコントラクトが制御権を得られるわけではありません。EOA は秘密鍵で署名を行い、その署名内容にはどの Invoker コントラクト（invoker address）に、どのような操作（commit）を許可するかが明示されます。

EOA の署名内容には、対象となる Invoker コントラクトアドレス（invoker address）およびそのコントラクトが実行できる操作（commit）が明確に指定されます。

実際の実行フローは以下の通りです：

Alice は自身の EOA 秘密鍵で署名を行い、署名内容と署名データを Relayer に提供します。
Relayer がそのデータをブロックチェーン上の Invoker コントラクトに送信して実行します。
Invoker コントラクトは署名を検証し、検証に成功すれば、Alice の EOA として操作を実行します。例えば、USDC の approve、Uniswap での資産交換、そして Relayer への手数料として USDC を支払うなどの処理を行います。

注1：Relayer は必須ではなく、Alice 自身が署名内容と署名を直接チェーン上に送ることも可能です。

Invoker が署名を検証した後は、すべて Alice の EOA 名義で操作が実行され、あたかもその EOA の（限定的な）制御権を取得したかのようになります。

ただし注意点として、この操作の実行後、EOA の nonce 値は増加しません。そのため、同じ署名が繰り返し使用される可能性があります（EOA の nonce が変わらない限り）。よって、Invoker コントラクト側で独自の nonce 機構を実装し、リプレイ攻撃を防ぐ必要があります。

Invoker コントラクトがリプレイ防止を実装していない場合、同一の認可が無限に繰り返し実行されてしまいます。

詳細を見る：EIP-3074 の実際の動作メカニズムについては、以下をご参照ください。
https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

主な用途

Batchcall

ユーザーが複数回に分けて行っていたトランザクションを1回にまとめて実行でき、何度も署名を行う手間やガスコストを削減できます。

注：これを利用するには DApp 側でも Batchcall 機能をサポートしている必要があります。現在コミュニティで提案されている EIP-5792 などが該当します。DApp がユーザーを通常の EOA として扱っている場合、各操作ごとに別々にトランザクションの署名を求め続けます。

EIP-5792 の詳細はブラウザで以下のリンクを開いてご確認ください：
https://eips.ethereum.org/EIPS/eip-5792

Session Key

ユーザーは、条件付きで第三者に操作を代理させることが可能です。下図の delegate key は認可された第三者、access policy は操作の制限条件（例：Uniswap のみ操作可、1日あたり最大1ETHまで送金可、有効期限など）を表しています。

これらの条件は Invoker コントラクト内で設計・チェックされ、条件を満たせば、第三者はユーザーの EOA 名義で操作を実行できます。

Telegram Bot にも特定の権限を与え、ユーザーの EOA 名義で操作を実行させることができます。

Native ETH Permit

条件を満たせば（つまり Permit 署名が正当であれば）、承認者の EOA 名義で ETH 転送を実行でき、ネイティブ ETH に対する Permit 効果を実現できます。

Limit Order

ユーザーが指値注文の条件を設定し、条件が満たされると、その EOA 名義で自動的に操作（DEX へのデジタル資産の approve、DEX での交換など）が実行されます。DEX 自体が提供する Limit Order と比較して、ユーザーは事前に DEX に approve するトランザクションを送る必要がありません。

Alice が注文を成立させる際に同時に approve が実行されるため、事前の approve は不要です。

条件をより汎用的に設計すれば、これはいわゆる Intent コントラクトのようなものになります。ユーザーが指定した条件が満たされれば、誰でもその EOA 名義で意図の実行を開始できます。

Intent 条件が満たされれば、誰でもユーザーの EOA 名義で実行を開始できます。

Social Recovery

ユーザーが EOA の秘密鍵を紛失した場合、当初署名済みの EIP-3074 認可と、信頼できる人物（Husband 及び Trust Agent）の署名を組み合わせることで、その EOA の資産をすべて移転できます。実際に「回復」されるのは（移動可能な）資産であり、アカウントの制御権そのものではありません。EOA の秘密鍵を紛失した後は、その EOA は二度と使用できなくなります。

ユーザーが EOA 秘密鍵を紛失した場合、当初認可された関係者が署名することで、EOA の資産を移転できます。

EIP-3074 の影響

資産認可の方式を改善し、approve/permit を置き換える可能性はあるか？

現在の DApp は、ユーザーが EOA であることを前提に設計されています。ユーザーは DApp コントラクトに対して「事前に approve する」「十分な量の資産を approve する」必要があります。これにより、ユーザーが常にオンラインである必要がなく、DApp の実行待ちや繰り返しの approve を避けられ、ユーザーエクスペリエンスが大きく向上します。

たとえば、指値注文やDCA（ドルコスト平均法）のような条件発動型アプリでは、条件が満たされたタイミングでユーザーがオンラインとは限らないため、DApp コントラクトが操作を実行できるよう、事前に十分な資産量を approve しておく必要があります。場合によっては繰り返し実行されることもあります。

ユーザーは DApp が円滑に操作できるよう、事前に多額の資産を approve しておく必要があります。

しかし、その代償として、ユーザーは DApp を信用せざるを得ず、偽の DApp に approve しないように注意し、リアルタイムで approve を取り消せるようにしなければなりません。

その後登場した permit モード（例：EIP-2612 や非ネイティブの Permit2）は、approve モードのユーザーエクスペリエンスとセキュリティを改善することを目的としています。ユーザーは、各 DApp コントラクトに大量の資産を approve する必要がなくなり（しかも各資産ごとに1回ずつ）、代わりに「1回の署名」で「指定時間内に指定数量の資産を引き出すこと」を許可できます。これにより、攻撃対象範囲が大幅に狭まり、ユーザーエクスペリエンスも大きく向上します。

詳しく知る：EIP-2612 の詳細は以下のリンクをブラウザで開いてください：
https://eips.ethereum.org/EIPS/eip-2612
Permit2 の詳細は以下のリンクをブラウザで開いてください：
https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18

ユーザーはオフチェーンで署名するだけでよく、資産数量と有効期間を指定できるため、approve よりも優れたユーザーエクスペリエンスとセキュリティを提供します。

しかし実際には、permit モードは依然として詐欺攻撃に頻繁に悪用されています。被害者は、DApp に与えるつもりの permit 署名を、実は攻撃者に与えてしまっているのです。

ユーザーが permit 署名を行う際、誰に認可するかは見えますが、それがどのような操作と組み合わされるのかはわかりません。

注：また、現在の permit 設計は、DCA や定期支払いなどの繰り返し操作に対応していません。permit にはリプレイ防止機構があるため、1度の送金後に同じ permit を再利用できません。つまり、将来のすべての繰り返し操作について、事前に個別に permit 署名を準備しておく必要があります。

詳しく知る：permit モードが詐欺攻撃に悪用された事例については、以下のリンクをブラウザで開いてください：
https://x.com/realScamSniffer/status/1783027808723435727
https://x.com/realScamSniffer/status/1784932506174967970
https://x.com/realScamSniffer/status/1786738218962223226

しかし EIP-3074 は変化のチャンスをもたらします。DApp 開発者が、EOA が Invoker を通じて複雑な操作ができることを認識すれば、ユーザーエクスペリエンスを高めるために安全性を犠牲にする必要がなくなります。つまり、「大量の資産を事前approve」「permitメッセージに署名して出金を許可」などの設計が不要になります。

代わりに、ユーザーは DApp の操作と approve をセットにして、Invoker を通じてアトミック（原子的）に実行します。approve と DApp 操作が同時に成功または失敗し、approve だけが単独で成功する可能性はありません。したがって、ユーザーはこの approve がまさに今回の操作のために使われることを確信できます。

しかも、ユーザーはオフチェーン署名による認可のため、permit と同じユーザーエクスペリエンスが得られます。つまり、DApp は将来的に permit モードを必要としなくなる可能性があるのです。ウォレットは permit 署名要求をブロックしたり、より厳格に審査したりできるようになり、特定の DApp が使えなくなるリスクを心配する必要もなくなります（逆にそれが詐欺に悪用されるリスクを減らせます）。

ユーザーは単に特定のアドレスに認可するのではなく、どのアドレスに何をするかを認可でき、シミュレーションによる実行結果さえ見えるようになります。

注：これは詐欺を完全に防げるという意味ではありません。ユーザーは依然として詐欺サイトに誘導され、approve や送金操作を署名させられる可能性があります。しかし、この場合でも、ユーザーは少なくとも今回署名する操作内容を確認できます。ウォレットはシミュレーション機能で実行結果を表示し、誰の残高がどれだけ減り、誰の残高がどれだけ増えるかを明確に提示できます。permit のように操作内容や実行結果が不明な状態よりも、ユーザーはより多くの情報を基に認可の判断ができるようになります。完璧な解決策ではありませんが、現状に比べて大きな改善となります。

ウォレットにおける EOA nonce の取り扱い

現在の EIP-3074 の設計では、EOA の nonce 値が署名内容に含まれています。そのため、EOA が1回トランザクションを送信して nonce を変更すると、従来の EIP-3074 認可はすべて無効になります。

ユーザーが他人に EOA 操作を代理させる場合（前述の Session Key や Social Recovery）は、EOA の nonce を変更しないように注意する必要があります。そうでなければ、すべての認可を再署名して委任先に渡す必要があり、ユーザーエクスペリエンスやメカニズムの堅牢性に大きな影響を与えます。

ユーザー自身が操作を認可する場合は、EOA の nonce 変更を特別に回避する必要はなく、EIP-3074 署名も期限付きで実行されることが期待されるためです。ただし、ウォレットは EOA の EIP-3074 トランザクションを管理する必要があります。EIP-3074 署名がチェーン上に送られるのを待っている間は、EOA 自身のトランザクション送信を保留にする必要があります。

注：Invoker コントラクト自体が（かつあるべき）独自の nonce 機構を維持するため、署名は使用後には再署名が必要となり、EOA の nonce が変わっていなくても同様です。

Session Key や Social Recovery は、EIP-3074 が EOA nonce を署名内容から除外するように仕様変更されるまで、大規模な採用は難しいでしょう。そのため、ウォレットは「ユーザー自身が操作を認可する」ケースに集中し、EIP-3074 署名を通常のトランザクションと同様に扱えば、EOA のトランザクション送信や nonce 変更を避ける必要はなくなります。

ただし注意点として、ユーザー自身が EIP-3074 署名をチェーン上に送る場合、以下の2つの欠点があります：

ユーザーは2回署名する必要がある：1回目は EIP-3074 署名、2回目はチェーン上送信のトランザクション署名。
チェーン上送信のトランザクションは、実行開始前に EOA nonce を +1 するため、ユーザーの EIP-3074 署名内の EOA nonce も事前に +1 しておかないと、自分自身で送信したことで生じた nonce +1 と一致せず、検証に失敗します。

自分自身でチェーン上に送信すると、最初に EOA nonce が +1 されるため、EIP-3074 署名の検証時に nonce が合わず失敗します。

ユーザーがチェーン上送信前に EIP-3074 署名内の EOA nonce を事前に +1 しておけば、検証を正常に通過できます。

まとめとポイント

EIP-3074 により、EOA はコントラクトと同等の豊かな実行能力を獲得し、多くの新しいアプリケーションが可能になります。
これによりユーザーエクスペリエンスが大幅に向上するだけでなく、現在の認可方式を変革し、使いやすさを損なうことなくより安全にします。
EIP-3074 は単なる署名であり、ユーザーは必ずしも自分で署名をチェーン上に送る必要はなく、ガス代として ETH を事前に用意する必要もありません。
EIP-3074 の用途には、Batch Call、Session Key、Native ETH Permit、Limit Order、Social Recovery などがあります。これらは多くが従来の EOA では不可能だったものであり、Limit Order など一部は事前認可といった安全性の低い方法を取る必要がありました。
EIP-3074 は現在の認可方式も変えるでしょう。approve は指定アドレスに無期限の資産引き出し権を付与し、EOA が事前に approve トランザクションを送る必要があるため、ユーザーエクスペリエンスとセキュリティの両面で劣ります。permit はユーザーの署名のみで済み、毎回資産数量と有効期間を指定できるため、approve よりも大幅に向上しています。
しかし、permit は依然として詐欺に頻繁に悪用されています。署名時、ユーザーは「誰に」「いくら」「いつまで」認可するかはわかりますが、「何のために使うか」はわかりません。「何のために使うか」は別の署名（またはトランザクション）に含まれます。正規の DApp はユーザーに permit と「何のために使うか」の両方を署名させますが、これらは別々の署名であるため、permit 署名を求められた時点で、ユーザーもウォレットもそれが「何のために使われるか」を知ることができません。
EIP-3074 があれば、(1) DApp に大量の資産を事前approveする必要がなく、必要な時にだけ approve すればよく、permit と同程度の利便性が得られます。(2) 単に署名するだけでよく、ガス代の ETH を用意する必要もありません（permit と同じ）。(3) 各 approve は特定の操作とバインドされ、一緒に署名されるため、ユーザーはこの approve が「何のために使われるか」を明確に把握できます。これは permit よりも安全です！
EIP-3074 が現在の approve 及び permit モードを置き換え、ユーザーにより安全な認可方法を提供することを期待しています。