EIP-3074

Expérience utilisateur meilleure et plus sûre

EIP-3074 permet aux EOAs de déléguer le contrôle à des contrats spécifiés, leur permettant ainsi d'acquérir des capacités d'exécution riches similaires à celles des contrats. Avant l'EIP-3074, un EOA ne pouvait effectuer qu'une seule opération par transaction, telle qu'approuver un jeton ERC20 ou effectuer un échange sur Uniswap. Après l'EIP-3074, un EOA peut effectuer plusieurs opérations dans une seule transaction, permettant des cas d'utilisation précédemment inimaginables. En essence, l'EIP-3074 améliore considérablement l'expérience utilisateur et remodèle les méthodes d'autorisation familières tout en renforçant la sécurité.

De plus, avec l'EIP-3074, les EOAs n'ont plus besoin d'envoyer des transactions eux-mêmes sur la chaîne, ce qui élimine le besoin d'acquérir d'abord de l'ETH pour payer les frais de transaction.

Contrats Invoker

Les contrats qui peuvent prendre le contrôle des EOAs sont appelés contrats Invoker. Ce n'est pas n'importe quel contrat qui peut prendre le contrôle ; l'EOA doit signer avec sa clé privée, en précisant quel contrat Invoker et quelles opérations il autorise l'Invoker à effectuer.

Le processus implique généralement:

Alice signe avec sa clé privée EOA, en spécifiant le contrat Invoker et les opérations autorisées.

Alice soumet le contenu signé et la signature à un relais.

Le relais soumet la transaction sur la chaîne à contrat Invoker.

L'Invoker vérifie la signature et, une fois validée, exécute les opérations en tant qu'EOA d'Alice, telles que l'approbation de l'USDC, l'échange d'actifs sur Uniswap et l'utilisation de certains USDC pour payer le Relayer en tant que frais.

Remarque : Le Relayer est facultatif ; Alice peut soumettre le contenu signé et la signature sur la chaîne elle-même.

Éviter les attaques de rejeu

L'Invoker exécute des opérations comme s'il avait un contrôle limité sur l'EOA d'Alice. Cependant, le nonce de l'EOA n'augmente pas après l'exécution, ce qui signifie que la même signature pourrait potentiellement être réutilisée tant que le nonce de l'EOA reste inchangé. Par conséquent, l'Invoker doit mettre en œuvre son propre mécanisme de nonce pour prévenir les attaques de rejeu.

En savoir plus

Pour une introduction détaillée au fonctionnement de l'EIP-3074, veuillez vous référer à :https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

Applications de l'EIP-3074

Appel de lot

Batchcall permet aux utilisateurs de combiner plusieurs transactions en une seule, ce qui permet d'économiser le processus de plusieurs signatures d'autorisation et certains coûts de gaz. Notez que cela nécessite que les DApps prennent en charge la fonctionnalité Batchcall, telle que l'EIP-5792 actuellement promue. Sans un tel support, les DApps demanderont une transaction séparée pour chaque opération, traitant l'utilisateur comme un EOA régulier.

Pour plus d'informations sur EIP-5792, veuillez vous référer à : EIP-5792.

Clé de session

Les utilisateurs peuvent déléguer des opérations à un tiers dans des conditions spécifiques en utilisant une clé de session. Dans l'exemple ci-dessous, la clé de délégation représente le tiers autorisé, tandis que la politique d'accès définit les contraintes opérationnelles, telles que la limitation des actions à Uniswap, le plafonnement des transferts à 1 ETH par jour ou la définition d'une date d'expiration de l'autorisation. Ces conditions sont conçues et vérifiées au sein du contrat Invoker. Une fois les vérifications passées, le tiers peut effectuer des opérations en tant qu'EOA de l'utilisateur.

Par exemple, un bot Telegram pourrait se voir accorder des autorisations spécifiques pour exécuter des opérations au nom de l'EOA de l'utilisateur.

Autorisation ETH native

Si les conditions sont remplies (c'est-à-dire que la signature du permis est valide), les opérations peuvent être exécutées en tant qu'EOA autorisant, permettant ainsi la fonctionnalité de permis ETH native.

Ordre à cours limité

Les utilisateurs peuvent définir des conditions d'ordre limite, qui, une fois remplies, permettent aux opérations d'être exécutées en tant que EOA de l'utilisateur. Cela inclut l'approbation des actifs numériques pertinents pour un DEX et l'échange d'actifs sur le DEX. Par rapport à la fonctionnalité d'ordre limite fournie par les DEX eux-mêmes, les utilisateurs n'ont pas besoin d'approuver préalablement les actifs pour le DEX.

Par exemple, lorsque Alice termine un ordre limite, l'approbation est exécutée simultanément, éliminant ainsi le besoin d'une approbation préalable.

En concevant les conditions de manière plus générale, un contrat d'intention peut être créé : tant que les conditions spécifiées sont remplies, n'importe qui peut exécuter l'intention au nom du compte utilisateur EOA.

Récupération sociale

Si un utilisateur perd sa clé privée EOA, il peut utiliser l'autorisation précédemment signée EIP-3074, ainsi que les signatures des parties autorisées (par exemple, le mari et l'agent de confiance), pour transférer tous les actifs de l'EOA. Cela récupère les actifs (transférables), pas le contrôle du compte. Une fois la clé privée EOA perdue, l'EOA ne peut plus être utilisée.

Amélioration des méthodes d'autorisation des actifs

L'EIP-3074 a le potentiel d'améliorer ou même de remplacer les méthodes actuelles d'approbation/autorisation. Les DApps opèrent actuellement en partant du principe que les utilisateurs sont des EOAs : les utilisateurs doivent pré-approuver une quantité suffisamment importante d'actifs au contrat DApp pour éviter de rester en ligne constamment et d'approuver à plusieurs reprises les transactions. Cela améliore considérablement l'expérience utilisateur.

Par exemple, des applications conditionnelles telles que des ordres limités ou DCA demandent aux utilisateurs d'approuver préalablement une grande quantité d'actifs afin que le DApp puisse exécuter des opérations lorsque les conditions sont remplies, potentiellement plusieurs fois.

Cependant, cela nécessite que les utilisateurs fassent confiance au DApp ou évitent d'approuver des faux DApps, et ils doivent être en mesure de retirer les approbations en temps réel.

Les modèles de permis récents tels que l'EIP-2612 ou le Permit2 non natif visent à améliorer l'expérience utilisateur du modèle d'approbation et la sécurité. Les utilisateurs n'ont pas besoin d'approuver de grandes quantités d'actifs pour chaque contrat DApp ; au lieu de cela, ils peuvent autoriser les DApps à retirer une quantité spécifiée d'actifs dans un délai spécifié en signant une fois. Cela réduit considérablement la surface d'attaque et améliore l'expérience utilisateur.

△ Les utilisateurs n'ont besoin de signer que hors chaîne et peuvent spécifier le montant d'actif et la période de validité, offrant une meilleure expérience utilisateur et une sécurité supérieure à l'approbation.

Cependant, en réalité, non seulement approuver, le mode de permis est encore souvent exploité comme une méthode d'escroquerie. Les victimes signent par erreur des permis qu'elles croient être destinés à une utilisation de DApp mais qui donnent en réalité une autorisation aux attaquants.

△ Lorsque les utilisateurs signent une autorisation, ils ne peuvent voir que qui ils autorisent mais ne savent pas quelles opérations seront effectuées en lien avec cela.

Remarque:La conception actuelle du permis est incompatible avec les DApps nécessitant des opérations répétitives, telles que DCA ou d'autres applications de paiement périodique. Cela est dû au fait que le permis possède un mécanisme anti-rejeu, de sorte qu'une fois une transaction terminée, le même permis ne peut être réutilisé. En gros, les utilisateurs doivent pré-signer des permis pour chaque opération répétitive future.

En savoir plus :

Pour en savoir plus sur les incidents où le mode de permis a été exploité comme méthode d'escroquerie, veuillez copier les liens suivants dans votre navigateur pour plus d'informations :

• Lien 1

• Lien 2

• Lien 3

Cependant, l'EIP-3074 apporte une chance de changement : lorsque les développeurs de DApp réalisent que l'EOA peut effectuer diverses opérations complexes grâce à Invoker, la conception des interactions de DApp n'aura plus besoin de sacrifier la sécurité pour une meilleure expérience utilisateur, telle que "les utilisateurs approuvant à l'avance une grande quantité d'actifs" ou "les utilisateurs signant un message d'autorisation pour autoriser les retraits".

Au lieu de cela, les utilisateurs lieront l'opération DApp avec l'action d'approbation, les exécutant de manière atomique via Invoker : soit l'approbation et l'opération DApp réussissent ensemble, soit échouent ensemble. Il n'y a aucune possibilité que l'action d'approbation réussisse seule, donc les utilisateurs peuvent être certains que cette action d'approbation est spécifiquement pour l'opération en cours.

De plus, les utilisateurs autorisent l'utilisation de signatures hors chaîne, de sorte que l'expérience utilisateur est la même qu'avec le permit! Cela signifie que les DApps n'auront plus besoin du mode permit! À l'avenir, les portefeuilles pourront bloquer directement ou examiner plus strictement les demandes de signature de permit sans craindre d'empêcher les utilisateurs d'accéder à certaines DApps (mais plutôt d'être exploités par des escroqueries).

△ Les utilisateurs ne se contenteront plus d'autoriser une certaine adresse, mais spécifieront également les actions qui peuvent être entreprises, et ils pourront même voir les résultats d'exécution simulés.

Note :Cela ne signifie pas que les escroqueries peuvent être complètement empêchées! Les utilisateurs peuvent encore être trompés par des sites Web d'escroquerie, et les sites Web d'escroquerie peuvent toujours élaborer des opérations d'approbation ou de transfert pour que les utilisateurs les signent. Cependant, à ce stade, les utilisateurs peuvent au moins voir quelles opérations la signature autorise. Les portefeuilles peuvent même simuler et afficher les résultats de l'exécution, montrant clairement aux utilisateurs qui perdra de l'argent et qui en gagnera. Comparé aux autorisations où les utilisateurs ne peuvent pas connaître les opérations ou les résultats de l'exécution, les utilisateurs ont maintenant plus d'informations pour décider s'ils doivent autoriser. Bien que ce ne soit pas une solution parfaite, c'est quand même une amélioration significative par rapport à la situation actuelle.

Comment les portefeuilles gèrent-ils le nonce EOA

Actuellement, la conception de l'EIP-3074 inclut la valeur de hachage EOA dans le contenu de la signature. Par conséquent, dès que l'EOA soumet une transaction sur la chaîne qui modifie la valeur de hachage, toutes les autorisations EIP-3074 existantes deviennent invalides.

Si un utilisateur autorise d'autres personnes à exploiter son EOA en son nom, comme par le biais de la clé de session ou des méthodes de récupération sociale mentionnées ci-dessus, le nonce de l'EOA doit rester inchangé. Sinon, toutes les autorisations doivent être resignées et remises au fiduciaire, ce qui affecte considérablement à la fois l'expérience utilisateur et la robustesse du mécanisme.

Si l'utilisateur s'autorise à opérer, alors il n'est pas nécessaire d'éviter de changer le nonce de l'EOA. Les signatures EIP-3074, comme les transactions, doivent être exécutées dans un certain délai. Cependant, les portefeuilles doivent gérer les transactions EIP-3074 pour l'EOA : s'il y a une signature EIP-3074 en attente d'être sur la chaîne, toutes les transactions EOA doivent attendre.

Remarque :Le contrat Invoker lui-même doit maintenir un mécanisme de nonce séparé, de sorte que chaque signature doit être renouvelée indépendamment des modifications apportées au nonce de l'EOA.

La clé de session et la récupération sociale sont susceptibles d'être largement adoptées uniquement après que l'EIP-3074 modifie les règles pour supprimer le nonce de l'EOA du contenu de la signature. Par conséquent, les portefeuilles devraient se concentrer sur le scénario où les « utilisateurs s'autorisent à fonctionner » et traiter les signatures EIP-3074 comme des transactions, en évitant les préoccupations concernant les transactions EOA modifiant le nonce.

Cependant, si les utilisateurs souhaitent soumettre eux-mêmes leur signature EIP-3074 sur la chaîne, il y a deux inconvénients :

1. Les utilisateurs doivent signer deux fois : une fois pour la signature de l'EIP-3074 et une fois pour la signature de la transaction sur la chaîne.

2. Étant donné que la transaction on-chain incrémentera le nonce EOA avant l'exécution, le nonce EOA de la signature EIP-3074 doit être pré-incrémenté pour correspondre au changement de nonce causé par la transaction on-chain.

△ Parce que la transaction sur chaîne incrémente le nonce EOA, la vérification de la signature EIP-3074 échouera si les nonces ne correspondent pas.

△ Les utilisateurs doivent pré-incrémenter le nonce EOA dans la signature EIP-3074 pour réussir la vérification.

En comprenant ces nuances, les fournisseurs de portefeuilles peuvent mieux gérer le traitement des EOA nonce, garantissant une expérience utilisateur plus fluide et plus sécurisée avec les autorisations EIP-3074.

Résumé et points saillants

• EIP-3074 accorde aux EOAs (External Owned Accounts) les mêmes capacités d'exécution riches que les contrats, débloquant de nombreux nouveaux scénarios d'application.
• Cela améliore non seulement considérablement l'expérience utilisateur, mais transforme également les méthodes d'autorisation actuelles, les rendant plus sûres sans compromettre la facilité d'utilisation.
• De plus, l'EIP-3074 implique des signatures simples, de sorte que les utilisateurs n'ont pas nécessairement à exécuter ces signatures eux-mêmes on-chain, éliminant ainsi le besoin de rassembler de l'ETH pour payer les frais de transaction.
• Les utilisations de l'EIP-3074 comprennent Batch Call, Session Key, Autorisation ETH Native, Ordre Limité et Récupération Sociale. Beaucoup d'entre elles sont initialement impossibles à réaliser avec EOA, et certaines, comme l'Ordre Limité, nécessitent une pré-autorisation et d'autres méthodes moins sécurisées pour être utilisées.
• Ces actions étaient auparavant impossibles pour les EOAs. Par exemple, l'utilisation d'un ordre à cours limité nécessitait des méthodes moins sécurisées comme la pré-autorisation.
• EIP-3074 modifiera également les méthodes d'autorisation actuelles. La méthode d'approbation autorise directement une adresse spécifiée à retirer indéfiniment des actifs numériques illimités, exigeant que l'EOA de l'utilisateur envoie une transaction pour exécuter l'approbation, ce qui entraîne une mauvaise expérience utilisateur et une sécurité insuffisante. La méthode de permis ne nécessite que la signature de l'utilisateur, et chaque signature spécifie le montant d'actifs et la période de validité, améliorant considérablement l'expérience utilisateur et la sécurité par rapport à l'approbation.
• Cependant, la méthode de l'autorisation est encore fréquemment exploitée dans les escroqueries. Lors de la signature, les utilisateurs ne voient que l'adresse, le montant d'actifs et la période de validité qu'ils autorisent, mais pas le but de l'autorisation. Le but serait défini dans une autre signature (ou transaction). Une DApp légitime demanderait à l'utilisateur de signer à la fois l'autorisation et le but, mais ce sont deux signatures distinctes. Par conséquent, lorsqu'on leur demande de signer une autorisation, les utilisateurs et les portefeuilles ne peuvent pas déterminer l'utilisation prévue de l'autorisation.
• Avec l'EIP-3074, les utilisateurs (1) n'ont pas besoin d'approuver une grande quantité d'actifs pour le DApp à l'avance, mais seulement d'approuver lorsqu'il y a une opération, et l'effet est le même que l'autorisation ; (2) signez simplement et n'avez pas besoin de vous inquiéter de collecter de l'ETH pour payer la procédure. Les frais sont les mêmes que l'autorisation ; (3) Chaque approbation est liée à l'opération spécifiée et signée ensemble. L'utilisateur peut savoir clairement "à quoi sert l'approbation" cette fois. Ce sera plus sûr que l'autorisation !
• On espère que l'EIP-3074 remplacera avec succès les méthodes actuelles d'approbation et de permission, offrant aux utilisateurs une méthode d'autorisation plus sécurisée.

Avertissement：

1. Cet article est repris de [imToken Labs]. Tous les droits d'auteur appartiennent à l'auteur original [Nic]. Si des objections sont formulées à ce sujet, veuillez contacter le Portail Apprendrel'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.