予備知識:EOAとコントラクトの違いを理解する
EVMと契約の実行プロセスを理解する
ERC-20における承認と許可の設計を理解する
ERC-20における承認と許可の設計を理解する
ERC-20における承認と許可の設計を理解する
- 詳細については、https://support.token.im/hc/zh-tw/articles/22181703417241
EIP-3074
▶ より良い、より安全な体験を
EIP-3074は、EOAが指定された契約にコントロールを与え、契約と同じ豊富な実行能力を得ることを可能にします。
EIP-3074以前は、EOAはERC20の承認やUniswapとの交換など、送信トランザクションごとに1つの操作に限られていました。
要するに、EIP-3074によって、エクスペリエンスは劇的に改善され、現在なじみのある認証方法は、同じエクスペリエンスを維持しながらセキュリティを向上させるために形を変えられます。
また、EIP-3074により、EOAは自身のトランザクションをチェーンに送信する必要がなくなり、取引手数料を支払うためにETHを調達する心配もなくなります。
▶インボーカー契約
EOAがEOAをコントロールできるようにする契約をインボーカー契約と呼びます。契約はインボーカー契約と呼ばれる。もちろん、どんなコントラクトでもEOAをコントロールできるわけではありません。EOAは秘密鍵で署名されなければならず、その署名によって、どのインヴォーカー・コントラクトなのか、インヴォーカーがどのようなアクションを実行できるのかが特定されます。
△EOAの署名は、どのインヴォーカー・コントラクト(インヴォーカー契約)に署名されているかを指定する。インボーカー・コントラクト(インボーカー・アドレス)と、そのインボーカー・コントラクトに対してオーソライズされたコミット。
実際の実行プロセスは次のようになります:
アリスは自分のEOA秘密鍵でインボーカーコントラクトに署名し、その内容と署名をリレイヤーに渡します。
Aliceは自分のEOA秘密鍵で契約書に署名し、署名の内容と自分の印鑑をRelayerに渡す。
Relayerは実行のためにInvoker契約書へのアップリンクを持ってくる。
インヴォーカーは署名を検証し、それが通ると、EOAとしてUSDCを承認し、Uniswapに行ってアセットスワップを行い、最後にUSDCの一部を使って手数料としてリレイヤーに渡すといった操作を行うことができる。
注1:リレイヤーは必要ありません。アリスはチェーン上に自身の署名内容と印鑑を持ち込むこともできます。
△インボーカーが署名を検証した後、署名の連鎖を開始する。Invokerは署名を検証し、操作を開始した後、あたかもEOAを(限定的に)コントロールするかのように、アリスEOAとしてそれを実行する。
しかし、実行してもEOAのnonce値は増えないので、(EOAのnonceが変わらない限り)同じ署名を再利用することが可能であることに注意してください。
△ Invokerのコントラクトがリプレイ防止でない場合、(EOA nonceが変更されない限り)同じ署名を再利用できる。コントラクトがリプレイ防止でない場合、同じ認証を常に実行できる。
もっと詳しく
EIP-3074が実際にどのように機能するかの説明は、https://medium.com/にあります。taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234
▶
バッチコール
複数のトランザクションの実行を1つにまとめることができ、複数の承認署名と一部のガス・コストが不要になります。
複数のトランザクションを1つにまとめて実行できるため、複数の承認署名が不要になり、ガス料金の一部を節約できます。
注意: これは、DAppが以下の機能もサポートする必要があります。注:これは、DAppが現在コミュニティによってプッシュされているEIP-5792のようなバッチコール機能もサポートすることを必要とします。そうでなければ、DAppは通常のEOAの場合と同様に、各操作に対してユーザーが署名するトランザクションをプロンプトするだけです。
EIP-5792について学ぶには、リンクをブラウザにコピーしてください: https://eips.ethereum.org/EIPS/eip-5792
セッションキー
ユーザーは、認可された第三者であるデリゲートキーや、実行の制限であるアクセスポリシーなど、特定の条件下で、第三者に自分の代わりに操作を実行させることもできます。デリゲートキーは権限を付与されるサードパーティであり、アクセスポリシーは操作をUniswapのみに限定する、1日最大1ETH、権限の有効期限など、実施される制限です。
これらの条件はInvokerコントラクト内で設計・チェックされ、それがパスする限り、第三者はユーザーEOAとして操作を実行することができます。
これらの条件は、インヴォーカー契約内で設計・チェックされます。/ /img.jinse.cn/7228581_image3.png">
△Telegram Botには、ユーザーのEOAに代わってアクションを実行する特定の権限を与えることができます。
ネイティブETH許可証
条件が満たされている限り(つまり許可証が合法的に署名されている限り)、認可されたEOAとしてETH送金を実行することができます。ネイティブETH Permitの効果を得るためのETH移転。
Limit指値注文
ユーザーは指値注文の条件を入力し、条件が満たされるまで待ち、その後、ユーザーのEOA IDは、DEXに関連するデジタル資産を承認するなど、実行するDEXスワップやその他の操作に移動します。DEX独自の指値注文と比較すると、ユーザーは事前にDEXに取引を送信して承認する必要はありません。
△アリスが注文を完了した時点でApproveが実行されるので、事前にApproveする必要はありません。
条件をより汎用的にするために、インテント契約のようなものになります。ユーザーが指定した条件さえ満たせば、誰でもApproveを使うことができます。ユーザーが指定した条件が満たされる限り、誰でもEOAとしてインテントを実行できる。
△ インテント条件が満たされている限り、誰でもユーザーのEOAとしてインテントを実行できる。誰でもユーザーの EOA に代わって実行を開始できる。
社会的回復
EOAキーを紛失したユーザーが、彼女が承認した人物(H.E.O.A.)と署名したEIP-3074を使用できるようにします。EIP-3074の認証は、彼女が認証した人物(夫および信託代理人)の署名とともに、ユーザーがEOA秘密鍵を紛失した場合に、EOAの全資産を譲渡することを可能にする。実際には、Recoverは口座の管理ではなく資産であり、EOAの秘密鍵を紛失した場合、EOAは使用できなくなります。
△ユーザーがEOAキーを紛失した場合、その権限を与えられていた他の誰かが署名することができます。最初にその権限を与えられた人が、EOA資産の譲渡を承認するために署名できる。
EIP-3074の影響
▶ 資産が承認される方法を改善します。
DAppは現在、ユーザーがEOAであるという前提で設計されています:ユーザーは、DApp契約に対して十分に多くのアセットを承認・認可しなければなりません。これにより、ユーザーは常にオンラインである必要がなくなり、DAppの実行を待ち、承認プロセスを何度も繰り返す必要がなくなり、ユーザーエクスペリエンスが大幅に向上します。
例えば、指値注文やDCAのような条件付きトリガーアプリでは、条件が満たされたときにユーザーが常にオンラインであるとは限らないため、DAppの契約が実行されるために事前に十分な数の資産を承認する必要があり、場合によっては何度も承認する必要があります。
△ユーザーはDApp契約を実行するために十分な数のアセットを承認しなければならない。DAppが資金を使って運営するためには、事前に十分な量の資産を承認する必要がある。
あるいは、後のpermitモデル、例えばEIP-2612 や、ネイティブではないPermit2があります。Permit2は、いずれも承認モードのエクスペリエンスとセキュリティを向上させることを目的としています。各DAppコントラクトに大量のアセットを承認する(各アセットを1回ずつ承認する)代わりに、ユーザーはDAppコントラクトが「指定された期間」内に「指定された量のアセットを引き出す」ことを承認するために「署名」するだけでよく、これは攻撃回数を大幅に減らすだけではありません。これにより、攻撃対象が大幅に減少するだけでなく、ユーザーエクスペリエンスも大幅に向上します。
詳細
EIP-2612の詳細については、以下のリンクをブラウザにコピーしてください:https://eips.ethereum. org/EIPS.org/EIPS/eip-2612
許可2 詳細については、以下のリンクをブラウザにコピーしてください:
https://medium。.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18
△ユーザーは署名をチェーンするだけでよく、資産の数や有効期間を指定できるため、承認よりも優れた体験とセキュリティを提供できる。
しかし、実際は承認だけではありません。許可証モデルは詐欺攻撃の手段として悪用され続けており、被害者はDAppsのためだと思って許可証に誤って署名してしまいますが、実際には攻撃者に与えられています。
△ ユーザーが許可証に署名するとき、誰に許可しているのかしかわかりません。ユーザが許可証に署名するとき、ユーザは自分が誰に権限を与えているかを見ることができるだけで、それに関連してどのようなアクションを実行できるようになるかはわからない。
注意:さらに、現在の許可証のデザインは、DCAやその他の定期的な支払いアプリなど、繰り返し操作を行うDAppsとは互換性がありません。というのも、パーミットにはアンチリプレイ機構があるため、一度送金した後は同じパーミットを使用することができず、今後の繰り返し操作のたびにパーミットを事前に署名する必要があるからです。
Learn more
DAppにおけるパーミットは初めてです。
permitモードが詐欺攻撃の手段として悪用された事件について知るには、以下のリンクをブラウザにコピーしてください:
https://x.com/realScamSniffer/status/1783027808723435727
https://x.com/realScamSniffer/status/1784932506174967970
https://x.com/realScamSniffer/status/1786738218962223226
しかし、EIP-3074は変化の機会をもたらします:DApp開発者がEOAがInvokerを通じて様々な複雑な操作を行うことができることを知れば、DAppインタラクションの設計は、ユーザーエクスペリエンスを向上させるためにセキュリティを犠牲にする必要がなくなります。例えば、「ユーザーは事前に大量のアセットを承認する」、「ユーザーは許可証に署名する」、「ユーザーは事前に大量のアセットを承認する」、「ユーザーは事前に大量のアセットを承認する」、「ユーザーは事前に大量のアセットを承認する」、「ユーザーは事前に大量のアセットを承認する」などです。例えば、「ユーザーが事前に大量の資産を承認する」、「ユーザーが引き出しを承認するために許可メッセージに署名する」などです。その代わりに、ユーザーはDApp操作とapproveを結びつけ、Invokerを通じてアトミック実行を行います:approveとDApp操作が一緒に成功するか、一緒に失敗するかのどちらかであり、approveが単独で成功する可能性はありません。approveが単独で成功する可能性はないので、ユーザーはこのapproveがこの操作のためのものだと確信できる。
また、ユーザーはオフチェーン署名認証を使用しているため、エクスペリエンスはpermitと同じです!これはDAppsがpermitモードを必要としなくなることを意味します!将来的には、ウォレットはユーザーが特定のDAppsを使用するのを妨げているかどうか(その代わりに詐欺に悪用されているかどうか)を心配することなく、permit署名リクエストをブロックしたり精査したりできるようになります。
△ユーザーはもはやアドレスを承認するだけではありません。
△ユーザーはもはや、ただ住所を承認するだけではありません。
注意:これは詐欺が完全になくなったという意味ではありません!ユーザーは、資金の承認や送金を可能にする詐欺的なウェブサイトに騙されてサインアップしてしまう可能性がありますが、少なくともサインアップしている内容を確認することができます。また、ウォレットはシミュレーションの結果を表示してユーザーに提示することもできるため、ユーザーは自分がどれだけのお金を失っているのか、またどれだけのお金を得ているのかを正確に知ることができます。どのような操作が行われているのか、またその結果すら知る術のない許可証に比べ、ユーザーは許可するかどうかを判断するための情報をより多く得ることができる。完璧なコントロールではないが、それでも現状よりは劇的に改善されるだろう。
▶nbsp;ウォレットがEOA nonceを処理する方法
現在、EIP->3074はEOA nonceを処理するように設計されています。3074はEOA nonce値を署名に含めるように設計されているため、EOAがnonce値を変更するトランザクションをチェーン上で実行するように送信するとすぐに、元のEIP-3074の認証は完全に無効になります。
前述のセッションキーやソーシャルリカバリーの方法のように、ユーザーが自分の代わりにEOAを操作する権限を誰かに与えている場合、EOA nonceは回避されなければなりません。これはメカニズムの経験と堅牢性に大きな影響を与えます。
ユーザー自身が操作を承認する場合、EOA nonceが変更されることを特に避ける必要はありません。なぜなら、EIP-3074署名はトランザクションと同じように、一定の期限までに実行されることが期待されているからです。EIP-3074署名がアップロードされるのを待っている場合、EOA自身のアップロードされたトランザクションは待たなければなりません。
注意: Invokerコントラクトは独自のnonceメカニズムを維持する(べきである)ため、EOAのnonceが変更されたかどうかに関係なく、署名が使用された後に再度署名する必要があります。
セッションキーとソーシャルリカバリーは、大規模に採用される前に、署名からEOA nonceを削除するルールを変更するEIP-3074を待たなければならない可能性が高いです。そのため、ウォレットは「ユーザーが承認した操作」のシナリオに焦点を当て、EIP-3074署名をトランザクションとして扱う必要があります。
しかし、ユーザーが自分のEIP-3074署名コンテンツをチェーンにアップロードしたい場合、ユーザーはEOA署名として使用できる自分のEIP-3074署名コンテンツをチェーンに持ち込む必要があることに注意してください。
ユーザーは、EIP-3074署名とアップロードされたトランザクションの2回署名しなければなりません。
アップリンクされたトランザクションは、トランザクションの実行を開始する前にEOA nonceを+1するので、ユーザーがEOA nonceをアップリンクした場合に+1されたであろうEOA nonceと一致させるために、EIP-3074署名用のユーザーのEOA nonceを事前に+1する必要があります。
ユーザーは2回署名する必要があります。
△ 自己アップロードによってEOA nonceに+1が追加されるため、ユーザーのEIP-3074署名のEOA nonceは、自己アップロードによるEOA nonceの+1と一致するように、1つ前のものでなければならない。EOA nonce +1なので、EIP-3074署名の検証を開始すると、EOA nonceが正しくないため失敗します。
△ユーザはEIP-3074署名をアップロードする前にEOA nonceを追加するように言及している。アップロード前にEOA nonce +1の3074署名。
概要とハイライト
EIP-3074は、EOAに、契約と同じくらい豊富な実行能力を与えます。コントラクトのように豊富な実行機能へのアクセスを提供し、多くの新しいアプリケーション・シナリオを開きます。
これはエクスペリエンスを劇的に向上させるだけでなく、現在の認可の方法を変更し、エクスペリエンスを変更することなく、よりセキュアにします。
また、EIP-3074はシンプルな署名であるため、ユーザーはそれを実行するために自分の署名をチェーンする必要がなく、手数料を支払うためのETHの入手を心配する必要がありません。
EIP-3074の用途には、バッチコール、セッションキー、ネイティブETHパーミット、リミットオーダー、ソーシャルリカバリーなどがあり、その多くはEOAでは不可能です。これらの多くはEOAでは不可能であり、リミットオーダーなどのいくつかは、使用するために事前承認や他の安全でない方法を必要とします。
EIP-3074は、現在の認可方法も変更します。permitは、指定されたアドレスにデジタル資産を無期限に引き出す権限を持たせることを直接認可し、ユーザーのEOAがトランザクションを送信して承認する必要があるため、使い勝手が悪く、安全ではありません;permitはユーザーの署名のみを必要とし、各署名はアセットの数と有効期限を指定します。
しかし、permitはまだ頻繁に詐欺に使われています。 署名するとき、ユーザーは承認先の住所、資産の数、有効期間を知っているだけで、何に使うために承認しているのかは知りません。"何に使うか "は別の署名(またはトランザクション)であり、通常のDAppは許可証と "何に使うか "の両方に署名するようユーザーに求めますが、それらはまだ2つの異なる署名であるため、ユーザーもウォレットも、許可証が要求されたときに何に使われるかを知る方法がありません。
EIP-3074では、ユーザーは(1)事前に大量の資産をDAppに承認する必要はなく、操作が実行されたときに承認することになり、これはpermitと同じです。(2)それは単なる署名であり、手数料を支払うためにETHを集めることを心配する必要はなく、これはpermitと同じです。効果はpermitと同じである。(2)単なる署名であり、ETHを集めて手数料を支払うことを心配する必要はない、permitと同じである。(3)各承認は指定された操作に結び付けられ、一緒に署名されるので、ユーザーは承認が何のためであるかを正確に知ることができ、permitよりも安全である!
EIP-3074が現在の承認と許可のモードをうまく置き換え、より安全な認証方法をユーザーに提供することが期待されています。