EIP-3074

より良く、より安全な使用体験

EIP-3074を使用すると、EOA(外部所有アカウント)は指定された契約に制御を移すことができ、それによって契約と同じ豊富な実行機能を得ることができます。EIP-3074より前は、EOAはERC20の承認やUniswapでのスワップなど、トランザクションごとに1つの操作しか実行できませんでした。EIP-3074以降、EOAは一度に複数の操作を実行したり、以前は想像もできなかったタスクを実行したりできます。簡単に言えば、EIP-3074はユーザーエクスペリエンスを大幅に向上させ、使い慣れたトークン認証方法が再形成され、ユーザーエクスペリエンスを変更することなくセキュリティが向上します。

さらに、EIP-3074により、EOAはロング自体でトランザクションをチェーンに送信する必要がなく、トランザクション手数料を支払うためにETHを調達する手間が省けます。

Invoker Contract

EOA の制御を取得できるコントラクトは、Invoker コントラクトと呼ばれます。もちろん、どんなコントラクトでもEOAを制御できるわけではなく、EOAは秘密鍵で署名する必要があり、署名の内容は、それがどのInvokerコントラクトであり、Invokerがどのような操作を実行できるかを明確に指定します。

EOA署名コンテンツは、どのInvokerコントラクト(invokerアドレス)を明確に指定し、そのInvokerコントラクトの操作(コミット)を承認し

実際の実行プロセスは、おそらく次のようになります。

1. アリスはEOA秘密鍵で署名し、署名の内容と署名をRelayerに渡します
2. RelayerはチェーンをInvokerコントラクト実行にもたらし
3. ます Invokerは署名を検証します。検証に合格すると、USDCを承認し、Uniswapに移動して取引所に送金し、最後に手数料としてUSDCをRelayerに送金するなどの操作をEOAとして実行できます。

注1:リレイヤーは必要ありません。アリスは、自分のシグネチャーコンテンツとシールをチェーンに持ち込むこともできます。

Invokerが署名を検証し、操作の実行を開始すると、EOAの(限定的な)制御を取得するような、Alice EOAとして実行されます。

ただし、EOAのノンス値は実行後に増加しないため、同じ署名が再利用される可能性があるため(EOAノンスが変更されないのと同じくらいロング)、Invokerは独自のノンスメカニズムを実装して再生を回避する必要があります。

Invoker コントラクトがリプレイ防止でない場合は、常に同じ承認を実行できます。

EIP-3074の実際の動作機構の紹介については、EIP3074の紹介を参照してください。

Application

Batchcall

複数のトランザクションの実行を1つにマージし、複数の承認された署名のプロセスと一部のガスコストを節約できます。

注:これには、現在コミュニティによってプッシュされているEIP-5792などのバッチコール機能もdAppがサポートする必要があります。それ以外の場合、dAppは、ユーザーを通常のEOAとして扱う場合、操作ごとに一度だけユーザーに署名を求めます。

セッションキー

ユーザーは、特定の条件下で、第三者が自分の代わりに行動することを許可することもできます。下の図のデリゲート キーは、承認されたサード パーティです。アクセスポリシーは、Uniswapのみの動作に制限したり、1日あたり最大1ETHを転送したり、認可の有効期間など、実行制限です。これらの条件は、Invoker コントラクト内で設計およびチェックされます。チェックに合格するとロング、サードパーティはユーザーのEOAとして操作を実行できます。

Telegram Botには、ユーザーのEOAに代わって操作を実行するための特定の権限を与えることができます

Native ETH Permit

が満たされロング(つまり、Permit署名が有効である)と、ETH転送をオーソライザーEOAとして実行でき、ネイティブETH Permitの効果が得られます。

指値注文

ユーザーが限度額注文条件を記入し、条件が満たされると、トークンのDEX承認、償還のためのDEXなど、ユーザーEOAとして実行できます。 DEX自体が提供する指値注文と比較して、ユーザーは事前に承認のためにDEXにトランザクションを送信する必要はありません。

アリスが注文を完了すると、同時に承認が実行されるため、事前の承認は必要ありません。

条件がより一般的に設計されている場合、それはインテント契約のようになります:ユーザーが指定した条件が満たされるとロング、誰でも自分のEOAの名前でインテントを実行できます。

インテント条件が満たされるとロング、誰でもユーザーのEOAの名前で実行を開始できます

Social Recovery

ユーザーがEOA秘密鍵を紛失した場合、彼女(アリス)は、署名したEIP-3074承認と、権限のある人(夫および信託代理人)の署名を使用して、EOAのすべての資産を譲渡できます。実際には、回収されるのは(譲渡可能な)資産であり、アカウント管理ではありません。EOA 秘密鍵が失われると、EOA はロング使用できなくなります。

ユーザーがEOA秘密鍵を紛失した場合、他の権限のある人物がEOA資産の譲渡に署名し、承認することができます。

EIP-3074

トークン認証方法を改善し、承認/許可を置き換える可能性がありますか?

現在、dAppsは、ユーザーがEOAであることを前提に設計されており、ユーザーはdApp契約に対して「事前承認」と「十分な金額の承認」が必要です。つまり、ユーザーは常にオンラインを維持したり、dAppの実行を待ったり、常に再承認したりする必要がなく、ユーザーエクスペリエンスが大幅に向上します。指値注文やDCAなどの条件トリガーアプリケーションの場合、条件が満たされたときにユーザーがオンラインになっていない可能性があるため、dApp契約を実行するのに十分な金額を事前に承認する必要があり、反復的なプロセスになる可能性があります。

ユーザーは、dAppがそのお金で運営できるように、dAppに十分な金額を事前に承認する必要があります。

ただし、dAppを信頼するか、偽のdAppの承認を回避し、承認をすぐに削除できるようにすることも必要です

トークンネイティブのEIP-2612や非ネイティブのPermit2など、後に登場した許可モードはすべて、承認モードの使用体験とセキュリティを向上させるためのものです:ユーザーはロング各dAppコントラクトに多額のお金を承認する必要はありません(そして各トークンは一度承認されなければなりません)。その代わり、ユーザーは「名前に署名する」だけで、dApp契約が「指定された時間」内に「指定された金額を引き出す」ことを承認することができます。これにより、攻撃対象領域が大幅に減少するだけでなく、ユーザーエクスペリエンスも大幅に向上します。

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

しかし、実際には、許可モードは承認するだけでなく、詐欺攻撃の手法として頻繁に使用されています(1,2,3):被害者は、dAppの許可証だと思っていたものに誤って署名しましたが、実際には攻撃者に渡されました。

ユーザーが許可に署名すると、承認するユーザーのみが表示されますが、どの操作がそれとペアになって実行されるかはわかりません。

注:現在の許可設計は、DCAやその他の通常の支払いアプリケーションなどの反復操作dAppsと互換性がありません。これは、許可証にはリプレイ保護メカニズムがあるため、転送が完了すると、同じ許可証を再度使用することはできないため、ユーザーは今後の反復操作ごとに事前に許可証に署名する必要があるためです。

しかし、EIP-3074は変化の機会をもたらします:EOAがInvokerを介してさまざまな複雑な操作を実行できることをdApp開発者が知っている場合、dAppインタラクションの設計は、「ユーザーが多額の金額を事前承認する」や「ユーザーが引き出しを承認する許可メッセージに署名する」など、ユーザーエクスペリエンスを向上させるために注文のセキュリティをロングで犠牲にする必要はありません。代わりに、ユーザーはdApp操作をInvokerを介して承認およびアトミック実行に結び付けます:approveとdApp操作が一緒に正常に実行されるか、一緒に失敗するかのどちらかです。承認だけでは成功する可能性はないため、ユーザーはこの承認がこの操作に対するものであると確信できます。また、ユーザーはオフチェーン署名認証を使用しているため、ユーザーエクスペリエンスは許可と同じです。これは、dAppがロング許可モードを必要としないことを意味します!将来的には、ウォレットは、ユーザーが一部のdAppsを使用しなくなる(ただし、詐欺に使用される)ことを心配することなく、許可署名要求を直接禁止またはより厳格なレビューを行うことができます。

ユーザーはロング特定のアドレスを承認するだけでなく、特定のアドレスと何をすべきかを承認し、シミュレートされた実行結果を確認することもできます。

注:これは、詐欺を完全にブロックできるという意味ではありません。ユーザーは依然として詐欺サイトに騙される可能性があり、詐欺サイトはユーザーが署名するための承認または転送操作を整理できますが、現時点では、ユーザーは少なくともこの署名が何をしようとしているかを確認でき、ウォレットは表示実行結果をシミュレートしてユーザーに提示することさえできるため、ユーザーは誰がどれだけのお金を失い、誰がどれだけのお金を得るかを明確に知ることができます。どのような操作や実行結果かわからない許可と比較して、ユーザーは承認するかどうかを決定するためのより多くの情報を持っています。完治ではありませんが、それでも現状は大幅に改善されるでしょう。

ウォレットがEOAナンスを処理する方法

現在のEIP-3074の設計では、署名コンテンツにEOAノンス値が含まれるため、EOAが実行のためにトランザクションをチェーンに送信し、ノンス値を変更するロング、元のEIP-3074認証はすべて無効になります。

ユーザーが、上記のセッションキーやソーシャルリカバリー方法など、EOAの操作を他のユーザーに許可している場合は、EOAのノンスが変更されないようにする必要があります。それ以外の場合は、すべての承認に再度署名してトラスティに渡す必要があり、ユーザーエクスペリエンスとメカニズムの堅牢性に大きな影響を与えます。

ユーザーが自分で操作することを許可されている場合、EIP-3074署名はトランザクションのように特定の期限前に実行されることが期待されるため、EOAノンスが変更されるのを特に防ぐ必要はありません。ウォレットはEOAのより多くのEIP-3074トランザクションを管理する必要があるだけです:チェーンにアップロードされるのを待っているEIP-3074署名がある場合、EOA自体のトランザクションは待機する必要があります。

注: Invoker コントラクト自体は一連のノンス メカニズムを維持する (および維持する必要がある) ため、署名を使用した後も、EOA ノンスが変更されるかどうかに関係なく、再度署名する必要があります。

セッションキーとソーシャルリカバリは、EIP-3074がルールを変更して署名コンテンツからEOAノンスを削除するまで待ってから、大規模に採用する必要があります。したがって、ウォレットは「ユーザー承認操作」のユースケースに焦点を当て、EIP-3074署名をトランザクションとして扱うだけで済みます。EOA送信トランザクションの回避やEOAノンスの変更について心配する必要はありません。

ただし、ユーザーが自分のEIP-3074署名コンテンツをチェーンに持ち込む場合は、2つの欠点があることに注意してください。

1. ユーザーは、EIP-3074署名とオンチェーントランザクション署名の2回署名する必要があります。
2. オンチェーン トランザクションは、トランザクションの実行を開始する前に EOA ノンスに 1 を追加するため、ユーザーの EIP-3074 署名の EOA ノンスは、チェーン自体によって引き起こされる EOA ノンス +1 と一致するように、事前に 1 を追加する必要があります。

チェーンは最初に EOA ノンスに 1 を追加するため、EOA ノンスが一致しないため、EIP-3074 署名の検証は失敗します。

ユーザーが EIP-3074 署名の EOA ノンスに 1 を追加してからチェーンに持ち込むと、検証をスムーズに進めることができます。

概要とハイライト

• EIP-3074により、EOAはコントラクトと同じ豊富な実行機能を取得でき、多くの新しいアプリケーションシナリオが開かれます。
• これにより、ユーザーエクスペリエンスが大幅に向上するだけでなく、現在のトークン認証方法も変更され、同じユーザーエクスペリエンスを維持しながらより安全になります。
• さらに、EIP-3074は単純な署名であり、ユーザーは必ずしも実行のために署名をチェーンに持ち込む必要がないため、取引手数料を支払うためにETHを集めることを心配する必要はありません。
• EIP-3074の用途には、バッチ呼び出し、セッションキー、ネイティブETH許可、指値注文、およびソーシャルリカバリが含まれます。これらの多くは、以前はEOAが達成することは不可能であり、指値注文のように、安全でない事前承認方法を使用する必要があるものもあります。
• EIP-3074 では、現在のトークン認証方法も変更されます。approveメソッドは、特定のアドレスにトークンを無期限に引き出す権限を直接承認し、承認を実行するためにユーザーのEOAがトランザクションを送信する必要があるため、ユーザーエクスペリエンスとセキュリティは良くありません。許可方式では、ユーザーが署名するだけで済み、各署名に金額と有効期間が指定されるため、承認と比較してユーザーエクスペリエンスとセキュリティが大幅に向上します。
• ただし、この許可証は依然として詐欺で頻繁に使用されます。署名の際、ユーザーは誰を、どの程度、有効期間に承認するかしか知ることができませんが、この承認が何のためにあるのかはわかりません。「何のためにあるのか」は、別の署名(またはトランザクション)になります。通常のdAppsでは、ユーザーは許可証と「何のためにあるのか」に署名することができますが、それでも2つの異なる署名であるため、許可証への署名を求められても、ユーザーもウォレットもこの許可証が何に使用されるかを知ることはできません。
• EIP-3074では、ユーザー(1)は事前にdAppに多額の資金を承認する必要はなく、許可と同じ効果を持つ操作がある場合にのみ承認する必要があります。(2)それは単なる単純な署名であり、許可と同じ取引手数料を支払うためにETHを集めることを心配する必要はありません。(3)各承認は特定の操作に結び付けられ、一緒に署名されるため、ユーザーはこの承認が何のためにあるのかを明確に知ることができ、許可よりも安全です。
• EIP-3074は、現在の承認モードと許可モードを正常に置き換え、より安全な承認方法をユーザーに提供できることが期待されています。

免責事項:

1. この記事は [imToken Labs] からの転載です。すべての著作権は原著作者に帰属します[なし]。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。