EIP-3074

Expérience d’utilisation meilleure et plus sûre

EIP-3074 permet aux EOA (Externally Owned Accounts) de transférer le contrôle à un contrat spécifié, obtenant ainsi les mêmes capacités d’exécution riches que le contrat. Avant EIP-3074, un EOA ne pouvait effectuer qu’une seule opération par transaction, telle que l’approbation de l’ERC20 ou l’échange sur Uniswap. Après EIP-3074, un EOA peut effectuer plusieurs opérations à la fois, ou même accomplir des tâches auparavant inimaginables. En termes simples, EIP-3074 améliore considérablement l’expérience utilisateur, et la méthode d’autorisation de jeton familière sera remodelée, augmentant la sécurité sans modifier l’expérience utilisateur.

De plus, grâce à EIP-3074, EOA n’a plus long besoin d’envoyer des transactions à la chaîne par lui-même, éliminant ainsi le problème d’avoir à augmenter l’ETH pour payer les frais de transaction.

Contrat de l’invocateur

Le contrat qui permet d’obtenir le contrôle de l’EOA est appelé contrat de l’invocateur. Bien sûr, n’importe quel contrat ne peut pas prendre le contrôle de l’EOA : l’EOA doit signer avec une clé privée, et le contenu de la signature spécifiera clairement de quel contrat d’Invoker il s’agit et quelles opérations l’Invoker est autorisé à effectuer.

Le contenu de la signature EOA spécifiera clairement le contrat de l’appelant (adresse de l’appelant) et autorisera les opérations de ce contrat de l’appelant (commit)

Le processus d’exécution réel ressemblera probablement à ceci :

1. Alice signe à l’aide de sa clé privée EOA, puis donne le contenu et la signature de la signature au relayeur
2. Le relayeur amène la chaîne à l’exécution du contrat de l’invocateur
3. L’invocateur vérifie la signature. Après avoir réussi la vérification, il peut effectuer des opérations en tant qu’EOA, telles que l’approbation de l’USDC, puis l’accès à Uniswap pour la plateforme d’échange, et enfin le transfert d’USDC au Relayer en tant que frais de traitement.

Remarque 1 : Il n’est pas nécessaire de relayer. Alice peut également apporter son propre contenu et son propre sceau à la chaîne.

Une fois que l’appelant a vérifié la signature et commencé à exécuter l’opération, celle-ci est exécutée en tant qu’EOA Alice, ce qui revient à obtenir un contrôle (limité) de l’EOA.

Cependant, il convient de noter que la valeur de nonce de l’EOA ne sera pas augmentée après l’exécution, de sorte que la même signature peut être réutilisée (aussi longue que le nonce EOA reste inchangé), de sorte que l’Invoker doit implémenter son propre mécanisme de nonce pour éviter la relecture.

Si le contrat de l’Invoker n’est pas à l’épreuve de la rejouabilité, la même autorisation peut être exécutée à tout moment.

Pour une introduction au mécanisme de fonctionnement réel de la EIP-3074, veuillez vous référer à : Introduction à EIP3074

Application

Batchcall

Permet aux utilisateurs de fusionner l’exécution de plusieurs transactions en une seule, ce qui permet d’économiser le processus de plusieurs signatures autorisées et certains coûts de gaz.

Remarque : Cela nécessitera que la dApp prenne également en support la fonction Batchcall, telle que EIP-5792, qui est actuellement poussée par la communauté. Dans le cas contraire, la dApp ne demandera à l’utilisateur de signer qu’une seule fois pour chaque opération si elle traite l’utilisateur comme un EOA normal.

Clé de session

Les utilisateurs peuvent également autoriser un tiers à agir en leur nom sous certaines conditions. La clé de délégué dans le diagramme ci-dessous est le tiers autorisé ; la politique d’accès est la restriction d’exécution, telle que la limitation à l’exploitation uniquement d’Uniswap, le transfert d’un maximum de 1 ETH par jour, la période de validité de l’autorisation, etc. Ces conditions sont conçues et vérifiées dans le cadre du contrat de l’Invoker. Aussi longue que la vérification est réussie, le tiers peut exécuter des opérations en tant qu’EOA d’un utilisateur.

Telegram Bot peut recevoir des autorisations spécifiques pour effectuer des opérations au nom de l’EOA de l’utilisateur

Native ETH Permit

Dans la mesure long les conditions sont remplies (c’est-à-dire que la signature du permis est légale), le transfert de ETH peut être effectué en tant qu’EOA de l’autorisateur, obtenant ainsi l’effet du permis ETH natif.

Ordre Limit

L’utilisateur remplit les conditions ordre limite, et lorsque les conditions sont remplies, il peut être exécuté en tant qu’EOA de l’utilisateur, y compris l’approbation des jetons pour DEX, l’envoi de DEX pour le rachat, etc. Par rapport à la Ordre Limit fournie par DEX elle-même, les utilisateurs n’ont pas besoin d’envoyer des transactions à DEX pour approbation à l’avance.

Lorsqu’Alice termine un ordre, elle exécute une approbation en même temps, éliminant ainsi le besoin d’approbation préalable.

Si la condition est conçue pour être plus générale, elle deviendra comme un contrat d’intention : aussi longues que les conditions spécifiées par l’utilisateur sont remplies, n’importe qui peut exécuter l’intention au nom de son EOA.

Tant long la condition d’intention est remplie, n’importe qui peut lancer l’exécution au nom de l’EOA de l’utilisateur

Social Recovery

Lorsque l’utilisateur perd la clé privée de l’EOA, il (Alice) peut utiliser l’autorisation EIP-3074 qu’elle a signée, ainsi que les signatures de sa personne autorisée (mari et agent fiduciaire) pour transférer tous les actifs de l’EOA. En réalité, ce qui est récupéré, ce sont les actifs (transférables), pas le contrôle des comptes. Une fois la clé privée EOA perdue, l’EOA ne peut plus être utilisée plus long.

Lorsque l’utilisateur perd la clé privée EOA, d’autres personnes autorisées peuvent signer et autoriser le transfert des ressources EOA.

Impact de l’EIP-3074 Amélioration des

méthodes d’autorisation des jetons, et éventuellement remplacement de l’approbation/du permis ?

À l’heure actuelle, les dApps sont conçues en partant du principe que l’utilisateur est un EOA : l’utilisateur doit « pré-approuver » et « approuver une somme d’argent suffisante » pour le contrat dApp. Cela signifie que les utilisateurs n’ont pas besoin de rester en ligne tout le temps, d’attendre que la dApp s’exécute ou de réapprouver constamment, ce qui améliore considérablement l’expérience utilisateur. Pour les applications déclenchées par des conditions telles que les ordres à cours limité ou DCA, les utilisateurs peuvent ne pas être en ligne lorsque les conditions sont remplies, ils doivent donc pré-approuver une somme d’argent suffisamment importante pour que le contrat dApp s’exécute, et il peut s’agir d’un processus répétitif.

L’utilisateur doit approuver à l’avance un montant suffisamment important pour la dApp afin que la dApp puisse fonctionner avec son argent.

Mais il est également nécessaire de faire confiance à la dApp ou d’éviter d’approuver la fausse dApp, et de pouvoir supprimer l’approbation immédiatement

Les modes de permis qui sont apparus plus tard, tels que le jeton natif EIP-2612 ou le non-natif Permit2, sont tous destinés à améliorer l’expérience d’utilisation et la sécurité du mode d’approbation : les utilisateurs n’ont plus long besoin d’approuver de grosses sommes d’argent pour chaque contrat dApp (et chaque jeton doit être approuvé une fois). Au lieu de cela, l’utilisateur n’a qu’à « signer un nom » pour autoriser le contrat dApp à « retirer le montant spécifié » dans le « délai spécifié ». Cela réduit non seulement considérablement la surface d’attaque, mais améliore également considérablement l’expérience utilisateur.

Les utilisateurs n’ont qu’à signer off-chain et peuvent spécifier le montant et la période de validité, offrant ainsi une meilleure expérience utilisateur et une meilleure sécurité qu’approuver.

Mais en fait, non seulement approuver, mais le mode permis a été fréquemment utilisé comme méthode d’attaque frauduleuse (1,2,3) : les victimes ont signé par erreur ce qu’elles pensaient être un permis pour une dApp, mais qui a en fait été donné à l’attaquant.

Lorsque les utilisateurs signent un permis, ils ne peuvent voir que qui autoriser, mais ils ne savent pas quelles opérations seront associées à celui-ci pour l’exécuter.

Remarque : La conception actuelle du permis n’est pas compatible avec les dApps à fonctionnement répétitif, telles que DCA ou d’autres applications de paiement régulières. En effet, le permis dispose d’un mécanisme de protection contre le rejeu, de sorte qu’une fois le transfert effectué, le même permis ne peut plus être utilisé, ce qui signifie que les utilisateurs doivent signer un permis à l’avance pour chaque opération répétitive future.

Cependant, EIP-3074 apporte une opportunité de changement : lorsque les développeurs de dApp savent qu’EOA peut effectuer diverses opérations complexes via Invoker, la conception de l’interaction dApp n’a plus long besoin de sacrifier la sécurité dans l’ordre pour améliorer l’expérience utilisateur, comme « les utilisateurs pré-approuvent une grosse somme d’argent » et « les utilisateurs signent un message d’autorisation pour autoriser le retrait ». Au lieu de cela, les utilisateurs lient les opérations dApp à l’approbation et effectuent l’exécution atomique via Invoker : soit les opérations approuvent et dApp sont exécutées avec succès ensemble, soit elles échouent ensemble. Il n’y a aucune possibilité de succès pour l’approbation seule, de sorte que les utilisateurs peuvent être sûrs que cette approbation concerne cette opération. Et les utilisateurs utilisent l’autorisation de signature off-chain, de sorte que l’expérience utilisateur est la même que celle du permis ! Cela signifie que dApp n’aura plus longtemps besoin du mode permis ! À l’avenir, les portefeuilles pourront interdire directement ou effectuer des examens plus stricts des demandes de signature d’autorisation, sans avoir à se soucier de savoir si cela incitera les utilisateurs à ne pas utiliser certaines dApps (mais à leur tour à être utilisées pour des escroqueries).

Les utilisateurs n’autorisent pas plus longtemps simplement une certaine adresse, mais autorisent une certaine adresse et ce qu’il faut faire, et même voir le résultat de l’exécution simulée.

Remarque : Cela ne signifie pas que les escroqueries peuvent être complètement bloquées ! Les utilisateurs peuvent toujours être trompés par des sites Web frauduleux, et les sites Web frauduleux peuvent toujours organiser des opérations d’approbation ou de transfert pour que les utilisateurs signent, mais à ce stade, les utilisateurs peuvent au moins voir ce que cette signature va faire, et les portefeuilles peuvent même simuler l’affichage des résultats d’exécution et les présenter aux utilisateurs, afin que les utilisateurs puissent savoir clairement qui perdra combien d’argent et qui gagnera combien d’argent. Par rapport aux permis qui ne savent pas quel résultat d’opération ou même d’exécution, les utilisateurs disposent de plus d’informations pour décider d’autoriser ou non. Bien qu’il ne s’agisse pas d’un remède parfait, il s’agira tout de même d’une amélioration substantielle de la situation actuelle.

Comment le Portefeuille gère les nonces EOA

La conception actuelle EIP-3074 inclura la valeur de nonce EOA dans le contenu de la signature, de sorte que long EOA envoie une transaction à la chaîne pour exécution et modifie la valeur nonce, toutes les autorisations EIP-3074 d’origine seront invalidées.

Si l’utilisateur autorise quelqu’un d’autre à utiliser l’EOA, comme la clé de session ou la méthode de récupération sociale mentionnée ci-dessus, le nonce de l’EOA doit être empêché de changer. Dans le cas contraire, il est nécessaire de signer à nouveau toutes les autorisations et de les remettre au syndic, ce qui a un impact considérable sur l’expérience utilisateur et la robustesse du mécanisme.

Si l’utilisateur est autorisé à opérer par lui-même, il n’est pas nécessaire d’empêcher spécifiquement la modification du nonce EOA, car la signature EIP-3074 devrait toujours être exécutée avant une certaine date limite comme la transaction. C’est juste que le portefeuille doit gérer plus de transactions EIP-3074 de l’EOA : s’il y a des signatures EIP-3074 en attente d’être téléchargées sur la chaîne, alors les transactions de l’EOA elle-même devront attendre.

Remarque : Le contrat Invoker lui-même maintiendra (et devrait) un ensemble de mécanismes de nonce, de sorte qu’après l’utilisation de la signature, elle doit toujours être signée à nouveau, que le nonce EOA change ou non.

Session Key et Social Recovery devront très probablement attendre que EIP-3074 modifie les règles pour supprimer le nonce EOA du contenu de la signature avant de pouvoir être adoptés à grande échelle. Par conséquent, le portefeuille doit uniquement se concentrer sur le cas d’utilisation des « opérations autorisées par l’utilisateur » et traiter la signature EIP-3074 comme une transaction. Il n’est pas nécessaire de s’inquiéter d’éviter l’envoi de transactions EOA ou de modifier le nonce EOA.

Cependant, il convient de noter que si l’utilisateur souhaite apporter son propre contenu de signature EIP-3074 à la chaîne, il y aura deux inconvénients :

1. L’utilisateur doit signer deux fois : une fois pour la signature EIP-3074 et une fois pour la signature de transaction off-chain.
2. Étant donné que la transaction hors chaîne ajoutera 1 au nonce EOA avant que la transaction ne commence à s’exécuter, le nonce EOA dans la signature EIP-3074 de l’utilisateur doit être pré-ajouté 1 pour correspondre au nonce EOA +1 causé par la chaîne elle-même.

Étant donné que la chaîne ajoutera 1 au nonce EOA en premier, la vérification de la signature EIP-3074 échouera en raison d’une incompatibilité EOA nonce.

Si les utilisateurs ajoutent 1 au nonce EOA dans la signature EIP-3074 avant de l’intégrer eux-mêmes à la chaîne, la vérification peut se dérouler sans problème.

Résumé et faits saillants

• EIP-3074 permet à EOA d’obtenir les mêmes capacités d’exécution riches que les contrats, ouvrant de nombreux nouveaux scénarios d’application.
• Cela améliorera non seulement considérablement l’expérience utilisateur, mais modifiera également la méthode actuelle d’autorisation des jetons, la rendant plus sûre tout en conservant la même expérience utilisateur.
• De plus, EIP-3074 est une signature simple, et les utilisateurs n’ont pas nécessairement besoin d’apporter la signature sur la chaîne pour l’exécution, il n’y a donc pas besoin de s’inquiéter de collecter des ETH pour payer les frais de transaction.
• Les utilisations d’EIP-3074 incluent l’appel par lots, la clé de session, le permis ETH natif, l’ordre limit et la récupération sociale. Bon nombre d’entre eux étaient auparavant impossibles à réaliser pour les OEA, et certains, comme l’ordre limit, nécessitaient l’utilisation de méthodes d’autorisation préalable dangereuses.
• EIP-3074 modifiera également la méthode d’autorisation de jeton actuelle. La méthode d’approbation autorise directement une adresse spécifique à avoir le pouvoir de retirer des jetons indéfiniment, et elle exige que l’EOA de l’utilisateur envoie une transaction pour exécuter l’approbation, de sorte que l’expérience utilisateur et la sécurité ne sont pas bonnes ; La méthode d’autorisation ne nécessite que la signature de l’utilisateur, et chaque signature spécifiera le montant et la période de validité, ce qui améliore considérablement l’expérience utilisateur et la sécurité par rapport à l’approbation.
• Cependant, le permis est encore fréquemment utilisé dans les escroqueries. Lors de la signature, les utilisateurs peuvent seulement savoir qui autoriser, combien et la période de validité, mais ils ne savent pas à quoi sert cette autorisation. « À quoi cela sert-il ? » sera une autre signature (ou transaction). Les dApps normales permettront aux utilisateurs de signer le permis et « à quoi il sert », mais il s’agira toujours de deux signatures différentes, de sorte que lorsqu’on leur demandera de signer le permis, ni l’utilisateur ni le portefeuille ne pourront savoir à quoi servira ce permis.
• Avec EIP-3074, les utilisateurs (1) n’ont pas besoin d’approuver une grosse somme d’argent à dApp à l’avance, mais seulement lorsqu’il y a une opération, qui a le même effet que le permis ; (2) il s’agit simplement d’une simple signature et n’a pas à se soucier de collecter des ETH pour payer les frais de transaction, qui sont les mêmes que le permis ; (3) Chaque approbation est liée à une opération spécifique et signée ensemble, de sorte que les utilisateurs peuvent savoir clairement à quoi sert cette approbation, ce qui sera plus sûr que le permis !
• On espère que EIP-3074 pourra remplacer avec succès les modes d’approbation et d’autorisation actuels et fournir aux utilisateurs une méthode d’autorisation plus sécurisée.

imToken Labs]. Tous les droits d’auteur appartiennent à l’auteur original [Nothing]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.