EIP-3074により、EOAは指定された契約に制御を委任することができ、これにより契約と同様の豊富な実行機能を得ることができます。EIP-3074の前、EOAは1つのトランザクションあたり1つの操作しか実行できませんでした。たとえば、ERC20トークンの承認やUniswapでのスワップなどです。EIP-3074以降、EOAは1つのトランザクションで複数の操作を完了できるため、以前は想像もできなかったユースケースが可能となります。要するに、EIP-3074はユーザーエクスペリエンスを大幅に向上させ、慣れ親しんだ認可方法を再構築しつつ、セキュリティを強化します。
さらに、EIP-3074により、EOAはもはや自分自身でチェーン上でトランザクションを送信する必要がなくなり、したがってトランザクション手数料を支払うために最初にETHを取得する必要がなくなりました。
EOAを制御できる契約は、Invoker契約と呼ばれます。どんな契約でも制御を獲得することはできません。EOAは、その秘密鍵で署名し、どのInvoker契約とどの操作をInvokerに実行することを許可するかを指定する必要があります。
通常、プロセスには次のような手順が含まれます:
アリスは、Invoker契約と認可された操作を指定して、自分のEOA秘密鍵で署名します。
アリスは署名済みコンテンツと署名をリレーアに提出します。
Relayerはトランザクションをオンチェーンに提出し、Invoker契約に送信します。
Invokerは署名を検証し、検証されると、USDCを承認したり、Uniswapで資産をスワップしたり、Relayerに手数料として一部のUSDCを支払ったりするなど、AliceのEOAとして操作を実行します。
注意:リレーアはオプションです。アリスは署名済みのコンテンツと署名を自分でチェーン上に提出することができます。
インボーカーは、アリスのEOAを制限された制御を持つかのように操作を実行します。ただし、実行後にEOAのnonceは増加しないため、同じ署名がEOAのnonceが変わらない限り再利用される可能性があります。したがって、インボーカーは再生攻撃を防ぐためにそのnonceメカニズムを実装する必要があります。
詳細を見る
EIP-3074の動作の詳細な紹介については、次を参照してください:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234
Batchcallを使用すると、ユーザーは複数のトランザクションを1つにまとめることができ、複数の承認署名のプロセスとガスコストを節約できます。これには、DAppsが現在推進されているEIP-5792などのBatchcall機能をサポートする必要があることに注意してください。このようなサポートがない場合、DAppsは操作ごとに個別のトランザクションを促し、ユーザーを通常のEOAとして扱います。
EIP-5792に関する詳細情報については、EIP-5792を参照してください。
セッションキー
ユーザーは、セッションキーを使用して、特定の条件下で第三者に操作を委任できます。以下の例では、デリゲートキーは認可された第三者を表し、アクセスポリシーは、アクションをUniswapに制限する、送金を1日あたり1ETHに制限する、認可の有効期限を設定するなど、運用上の制約を定義しています。これらの条件は、Invoker コントラクト内で設計およびチェックされます。チェックに合格すると、サードパーティはユーザーのEOAとして操作を実行できます。
例えば、Telegramボットは、ユーザーのEOAを代表して操作を実行するための特定の権限を付与される可能性があります。
ネイティブETH許可
条件が満たされている場合(つまり、許可署名が有効である場合)、操作は許可された EOA として実行でき、ネイティブ ETH 許可機能を有効にすることができます。
リミットオーダー
ユーザーは、一度満たされると、ユーザーのEOAとして操作を実行することを許可するリミットオーダー条件を設定できます。これには、DEX向けの関連デジタル資産を承認し、DEX上で資産を交換することが含まれます。DEX自体が提供するリミットオーダー機能と比較して、ユーザーはDEX向けに資産を事前に承認する必要がありません。
例えば、アリスがリミットオーダーを完了すると、承認が同時に実行され、事前の承認が不要になります。
条件をより一般的に設計することで、Intent契約を作成できます:指定された条件が満たされている限り、誰でもユーザーのEOAを代表して意図を実行できます。
ソーシャルリカバリー
ユーザーがEOAの秘密鍵を紛失した場合、以前に署名されたEIP-3074認証と、認可された当事者(たとえば、夫と信託代理人)からの署名を使用して、EOAからすべての資産を移転することができます。これにより(譲渡可能な)資産が回収されますが、アカウント制御は回復されません。EOAの秘密鍵が紛失すると、EOAは再度使用できません。
EIP-3074には、現在の承認/許可方法を改善したり、置き換えたりする可能性があります。現在、DAppsは、ユーザーがEOAであるという前提のもとで運用されています。ユーザーはDApp契約に十分な量の資産を事前に承認する必要があり、オンラインで常に滞在し、取引を繰り返し承認する必要がありません。これにより、ユーザーエクスペリエンスが大幅に向上します。
例えば、リミットオーダーやDCAなどの条件付きアプリケーションでは、ユーザーは条件が満たされた時にDAppが操作を実行できるように、大量の資産を事前に承認する必要があります。これは、複数回実行される可能性があります。
しかし、そのためには、ユーザーはDAppを信頼するか、偽のDAppsを承認しないようにし、リアルタイムで承認を取り消すことができなければなりません。
最近の許可モデルであるEIP-2612や非ネイティブのPermit2のようなモデルは、承認モデルのユーザーエクスペリエンスとセキュリティを向上させることを目指しています。ユーザーは各DApp契約に対して大量の資産を承認する必要はありません。代わりに、一度署名することで、DAppsに特定額の資産を特定の期間内に引き出す権限を与えることができます。これにより、攻撃面が大幅に削減され、ユーザーエクスペリエンスが向上します。
△ユーザーはオフチェーンでサインするだけでよく、資産の金額と有効期間を指定でき、承認よりも優れたユーザーエクスペリエンスとセキュリティを提供します。
しかし、実際には、承認だけでなく、許可モードは詐欺手法として頻繁に悪用されています。被害者は、DAppの使用を目的とすると信じている許可書に誤って署名しますが、実際には攻撃者に許可を与えているのです。
△ ユーザーが許可書に署名すると、誰が承認しているかはわかりますが、それと連動してどのような操作が行われるかはわかりません。
注意:現在の許可設計は、DCAやその他の定期的な支払いアプリケーションなど、反復的な操作を必要とするDAppsと互換性がありません。これは、パーミットにはアンチリプレイメカニズムがあり、トランザクションが完了すると、同じパーミットを再び使用できないためです。基本的に、ユーザーは将来の反復操作ごとに許可書に事前に署名する必要があります。
詳細を学ぶ:
許可モードが詐欺手段として悪用された事件について詳しく理解するには、次のリンクをブラウザにコピーして詳細をご確認ください:
しかし、EIP-3074は変化の機会をもたらします:DApp開発者がEOAがInvokerを介してさまざまな複雑な操作を実行できることに気づいたとき、DAppの相互作用の設計はもはやセキュリティを犠牲にする必要がなくなります。たとえば、「ユーザーが事前に大量の資産を承認する」あるいは「ユーザーが許可を取得するための許可メッセージに署名する」といったことがあります。
その代わりに、ユーザーはDAppの操作を承認アクションと結び付け、Invokerを介してそれらを原子的に実行します:承認とDAppの操作の両方が成功するか、失敗するか、どちらか一方が成功する可能性はありません。したがって、ユーザーはこの承認アクションが現在の操作のために特にあることを確認できます。
さらに、ユーザーはオフチェーン署名を使用して認可し、ユーザーエクスペリエンスは認可と同じです!これにより、DAppsはもはや許可モードを必要としません!将来、ウォレットは、特定のDAppsへのアクセスを防ぐことなく、むしろ詐欺に悪用されることを心配せずに、直接許可署名リクエストをブロックしたり、より厳密に検証することができます。
△ ユーザーは、以前は特定のアドレスにのみ権限を付与していましたが、今後はどのようなアクションを取るかを指定する必要があり、シミュレーションされた実行結果さえも確認できるようになります。
注意:これは詐欺を完全に防ぐことができるという意味ではありません!ユーザーはまだ詐欺サイトに騙される可能性があり、詐欺サイトはユーザーが署名するための承認や転送操作を作成することができます。ただし、この時点では、ユーザーは少なくとも署名が何を承認しているかを見ることができます。ウォレットは実行結果をシミュレートして表示し、誰がお金を失い、誰がお金を得るかをユーザーに明確に示すことさえできます。ユーザーが操作や実行結果を知ることができない許可と比較して、ユーザーは今では承認するかどうかを決定するためのより多くの情報を持っています。完璧な解決策ではありませんが、現状よりもかなり改善されています。
現在、EIP-3074の設計には、署名コンテンツにEOAのノンス値が含まれています。したがって、EOAがノンス値を変更するトランザクションをチェーン上に送信すると、すべての既存のEIP-3074承認が無効になります。
ユーザーが他の人に自分のEOAを操作することを許可する場合(上記のセッションキーまたはソーシャルリカバリの方法を介して)、EOAのノンスは変更されてはなりません。それ以外の場合、すべての承認は再び署名され、信託に引き渡す必要があります。これはユーザーエクスペリエンスとメカニズムの堅牢性の両方に大きな影響を与えます。
ユーザーが自分自身の操作を承認している場合、EOAのノンスを変更する必要はありません。トランザクションと同様に、EIP-3074署名は一定期間内に実行されることが期待されています。ただし、ウォレットはEOAのためにEIP-3074トランザクションを管理する必要があります:オンチェーンで待機中のEIP-3074署名がある場合、任意のEOAトランザクションは待機する必要があります。
注意:Invokerコントラクト自体は、独自のノンスメカニズムを維持する必要があります。そのため、EOAのノンスの変更に関係なく、各署名を更新する必要があります。
Session KeyとSocial Recoveryは、EIP-3074がルールを修正してEOA nonceを署名内容から削除した後に広く採用される可能性があります。したがって、ウォレットは「ユーザーが自分自身を操作することを許可する」シナリオに焦点を当て、EOAトランザクションがnonceを変更することに関する懸念を避けるようにすべきです。
ただし、ユーザーが自分でチェーン上でEIP-3074署名を提出したい場合、2つの欠点があります:
ユーザーは、EIP-3074署名のために1度、オンチェーントランザクション署名のために1度、2度署名する必要があります。
オンチェーン取引では、実行前にEOA nonceが増分されるため、EIP-3074署名のEOA nonceは、オンチェーン取引によるnonce変更に合わせて事前に増分する必要があります。
△ オンチェーン取引はEOA nonceを増やすため、nonceが一致しない場合はEIP-3074署名検証に失敗します。
△ユーザーは、検証に成功するために、EOA nonceをEIP-3074署名で事前に増分する必要があります。
これらの微妙なニュアンスを理解することで、ウォレットプロバイダーは、EIP-3074の認証により、EOAノンスの処理をより良く管理し、よりスムーズで安全なユーザーエクスペリエンスを確保できます。
EIP-3074により、EOAは指定された契約に制御を委任することができ、これにより契約と同様の豊富な実行機能を得ることができます。EIP-3074の前、EOAは1つのトランザクションあたり1つの操作しか実行できませんでした。たとえば、ERC20トークンの承認やUniswapでのスワップなどです。EIP-3074以降、EOAは1つのトランザクションで複数の操作を完了できるため、以前は想像もできなかったユースケースが可能となります。要するに、EIP-3074はユーザーエクスペリエンスを大幅に向上させ、慣れ親しんだ認可方法を再構築しつつ、セキュリティを強化します。
さらに、EIP-3074により、EOAはもはや自分自身でチェーン上でトランザクションを送信する必要がなくなり、したがってトランザクション手数料を支払うために最初にETHを取得する必要がなくなりました。
EOAを制御できる契約は、Invoker契約と呼ばれます。どんな契約でも制御を獲得することはできません。EOAは、その秘密鍵で署名し、どのInvoker契約とどの操作をInvokerに実行することを許可するかを指定する必要があります。
通常、プロセスには次のような手順が含まれます:
アリスは、Invoker契約と認可された操作を指定して、自分のEOA秘密鍵で署名します。
アリスは署名済みコンテンツと署名をリレーアに提出します。
Relayerはトランザクションをオンチェーンに提出し、Invoker契約に送信します。
Invokerは署名を検証し、検証されると、USDCを承認したり、Uniswapで資産をスワップしたり、Relayerに手数料として一部のUSDCを支払ったりするなど、AliceのEOAとして操作を実行します。
注意:リレーアはオプションです。アリスは署名済みのコンテンツと署名を自分でチェーン上に提出することができます。
インボーカーは、アリスのEOAを制限された制御を持つかのように操作を実行します。ただし、実行後にEOAのnonceは増加しないため、同じ署名がEOAのnonceが変わらない限り再利用される可能性があります。したがって、インボーカーは再生攻撃を防ぐためにそのnonceメカニズムを実装する必要があります。
詳細を見る
EIP-3074の動作の詳細な紹介については、次を参照してください:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234
Batchcallを使用すると、ユーザーは複数のトランザクションを1つにまとめることができ、複数の承認署名のプロセスとガスコストを節約できます。これには、DAppsが現在推進されているEIP-5792などのBatchcall機能をサポートする必要があることに注意してください。このようなサポートがない場合、DAppsは操作ごとに個別のトランザクションを促し、ユーザーを通常のEOAとして扱います。
EIP-5792に関する詳細情報については、EIP-5792を参照してください。
セッションキー
ユーザーは、セッションキーを使用して、特定の条件下で第三者に操作を委任できます。以下の例では、デリゲートキーは認可された第三者を表し、アクセスポリシーは、アクションをUniswapに制限する、送金を1日あたり1ETHに制限する、認可の有効期限を設定するなど、運用上の制約を定義しています。これらの条件は、Invoker コントラクト内で設計およびチェックされます。チェックに合格すると、サードパーティはユーザーのEOAとして操作を実行できます。
例えば、Telegramボットは、ユーザーのEOAを代表して操作を実行するための特定の権限を付与される可能性があります。
ネイティブETH許可
条件が満たされている場合(つまり、許可署名が有効である場合)、操作は許可された EOA として実行でき、ネイティブ ETH 許可機能を有効にすることができます。
リミットオーダー
ユーザーは、一度満たされると、ユーザーのEOAとして操作を実行することを許可するリミットオーダー条件を設定できます。これには、DEX向けの関連デジタル資産を承認し、DEX上で資産を交換することが含まれます。DEX自体が提供するリミットオーダー機能と比較して、ユーザーはDEX向けに資産を事前に承認する必要がありません。
例えば、アリスがリミットオーダーを完了すると、承認が同時に実行され、事前の承認が不要になります。
条件をより一般的に設計することで、Intent契約を作成できます:指定された条件が満たされている限り、誰でもユーザーのEOAを代表して意図を実行できます。
ソーシャルリカバリー
ユーザーがEOAの秘密鍵を紛失した場合、以前に署名されたEIP-3074認証と、認可された当事者(たとえば、夫と信託代理人)からの署名を使用して、EOAからすべての資産を移転することができます。これにより(譲渡可能な)資産が回収されますが、アカウント制御は回復されません。EOAの秘密鍵が紛失すると、EOAは再度使用できません。
EIP-3074には、現在の承認/許可方法を改善したり、置き換えたりする可能性があります。現在、DAppsは、ユーザーがEOAであるという前提のもとで運用されています。ユーザーはDApp契約に十分な量の資産を事前に承認する必要があり、オンラインで常に滞在し、取引を繰り返し承認する必要がありません。これにより、ユーザーエクスペリエンスが大幅に向上します。
例えば、リミットオーダーやDCAなどの条件付きアプリケーションでは、ユーザーは条件が満たされた時にDAppが操作を実行できるように、大量の資産を事前に承認する必要があります。これは、複数回実行される可能性があります。
しかし、そのためには、ユーザーはDAppを信頼するか、偽のDAppsを承認しないようにし、リアルタイムで承認を取り消すことができなければなりません。
最近の許可モデルであるEIP-2612や非ネイティブのPermit2のようなモデルは、承認モデルのユーザーエクスペリエンスとセキュリティを向上させることを目指しています。ユーザーは各DApp契約に対して大量の資産を承認する必要はありません。代わりに、一度署名することで、DAppsに特定額の資産を特定の期間内に引き出す権限を与えることができます。これにより、攻撃面が大幅に削減され、ユーザーエクスペリエンスが向上します。
△ユーザーはオフチェーンでサインするだけでよく、資産の金額と有効期間を指定でき、承認よりも優れたユーザーエクスペリエンスとセキュリティを提供します。
しかし、実際には、承認だけでなく、許可モードは詐欺手法として頻繁に悪用されています。被害者は、DAppの使用を目的とすると信じている許可書に誤って署名しますが、実際には攻撃者に許可を与えているのです。
△ ユーザーが許可書に署名すると、誰が承認しているかはわかりますが、それと連動してどのような操作が行われるかはわかりません。
注意:現在の許可設計は、DCAやその他の定期的な支払いアプリケーションなど、反復的な操作を必要とするDAppsと互換性がありません。これは、パーミットにはアンチリプレイメカニズムがあり、トランザクションが完了すると、同じパーミットを再び使用できないためです。基本的に、ユーザーは将来の反復操作ごとに許可書に事前に署名する必要があります。
詳細を学ぶ:
許可モードが詐欺手段として悪用された事件について詳しく理解するには、次のリンクをブラウザにコピーして詳細をご確認ください:
しかし、EIP-3074は変化の機会をもたらします:DApp開発者がEOAがInvokerを介してさまざまな複雑な操作を実行できることに気づいたとき、DAppの相互作用の設計はもはやセキュリティを犠牲にする必要がなくなります。たとえば、「ユーザーが事前に大量の資産を承認する」あるいは「ユーザーが許可を取得するための許可メッセージに署名する」といったことがあります。
その代わりに、ユーザーはDAppの操作を承認アクションと結び付け、Invokerを介してそれらを原子的に実行します:承認とDAppの操作の両方が成功するか、失敗するか、どちらか一方が成功する可能性はありません。したがって、ユーザーはこの承認アクションが現在の操作のために特にあることを確認できます。
さらに、ユーザーはオフチェーン署名を使用して認可し、ユーザーエクスペリエンスは認可と同じです!これにより、DAppsはもはや許可モードを必要としません!将来、ウォレットは、特定のDAppsへのアクセスを防ぐことなく、むしろ詐欺に悪用されることを心配せずに、直接許可署名リクエストをブロックしたり、より厳密に検証することができます。
△ ユーザーは、以前は特定のアドレスにのみ権限を付与していましたが、今後はどのようなアクションを取るかを指定する必要があり、シミュレーションされた実行結果さえも確認できるようになります。
注意:これは詐欺を完全に防ぐことができるという意味ではありません!ユーザーはまだ詐欺サイトに騙される可能性があり、詐欺サイトはユーザーが署名するための承認や転送操作を作成することができます。ただし、この時点では、ユーザーは少なくとも署名が何を承認しているかを見ることができます。ウォレットは実行結果をシミュレートして表示し、誰がお金を失い、誰がお金を得るかをユーザーに明確に示すことさえできます。ユーザーが操作や実行結果を知ることができない許可と比較して、ユーザーは今では承認するかどうかを決定するためのより多くの情報を持っています。完璧な解決策ではありませんが、現状よりもかなり改善されています。
現在、EIP-3074の設計には、署名コンテンツにEOAのノンス値が含まれています。したがって、EOAがノンス値を変更するトランザクションをチェーン上に送信すると、すべての既存のEIP-3074承認が無効になります。
ユーザーが他の人に自分のEOAを操作することを許可する場合(上記のセッションキーまたはソーシャルリカバリの方法を介して)、EOAのノンスは変更されてはなりません。それ以外の場合、すべての承認は再び署名され、信託に引き渡す必要があります。これはユーザーエクスペリエンスとメカニズムの堅牢性の両方に大きな影響を与えます。
ユーザーが自分自身の操作を承認している場合、EOAのノンスを変更する必要はありません。トランザクションと同様に、EIP-3074署名は一定期間内に実行されることが期待されています。ただし、ウォレットはEOAのためにEIP-3074トランザクションを管理する必要があります:オンチェーンで待機中のEIP-3074署名がある場合、任意のEOAトランザクションは待機する必要があります。
注意:Invokerコントラクト自体は、独自のノンスメカニズムを維持する必要があります。そのため、EOAのノンスの変更に関係なく、各署名を更新する必要があります。
Session KeyとSocial Recoveryは、EIP-3074がルールを修正してEOA nonceを署名内容から削除した後に広く採用される可能性があります。したがって、ウォレットは「ユーザーが自分自身を操作することを許可する」シナリオに焦点を当て、EOAトランザクションがnonceを変更することに関する懸念を避けるようにすべきです。
ただし、ユーザーが自分でチェーン上でEIP-3074署名を提出したい場合、2つの欠点があります:
ユーザーは、EIP-3074署名のために1度、オンチェーントランザクション署名のために1度、2度署名する必要があります。
オンチェーン取引では、実行前にEOA nonceが増分されるため、EIP-3074署名のEOA nonceは、オンチェーン取引によるnonce変更に合わせて事前に増分する必要があります。
△ オンチェーン取引はEOA nonceを増やすため、nonceが一致しない場合はEIP-3074署名検証に失敗します。
△ユーザーは、検証に成功するために、EOA nonceをEIP-3074署名で事前に増分する必要があります。
これらの微妙なニュアンスを理解することで、ウォレットプロバイダーは、EIP-3074の認証により、EOAノンスの処理をより良く管理し、よりスムーズで安全なユーザーエクスペリエンスを確保できます。