Analyse détaillée de l'impact d'EIP-3074 sur les portefeuilles et les DApp
TechFlow SélectionTechFlow Sélection
Analyse détaillée de l'impact d'EIP-3074 sur les portefeuilles et les DApp
EIP-3074 permet aux EOA d'obtenir des capacités d'exécution aussi étendues que celles des contrats, ouvrant ainsi de nombreux nouveaux cas d'utilisation.
Dédié à des analyses Web3 approfondiesRédaction : Nic @ imToken Labs
EIP-3074
Une expérience utilisateur meilleure et plus sécurisée
L’EIP-3074 permet aux comptes d’objets externes (EOA) de transférer leur contrôle à un contrat spécifique, leur offrant ainsi des capacités d’exécution aussi riches que celles des contrats intelligents.
Avant l’EIP-3074, chaque transaction envoyée par un EOA ne pouvait accomplir qu’une seule opération, comme approuver un jeton ERC20 ou effectuer un échange sur Uniswap. Après l’introduction de l’EIP-3074, un EOA peut désormais réaliser plusieurs opérations en une seule fois, voire exécuter des cas d’usage auparavant inimaginables.
En résumé, l’EIP-3074 améliore considérablement l’expérience utilisateur tout en redéfinissant les méthodes d’autorisation actuelles, renforçant la sécurité sans compromettre l’ergonomie.
De plus, grâce à l’EIP-3074, un EOA n’a plus besoin d’envoyer lui-même les transactions sur la blockchain, évitant ainsi le problème de devoir préalablement obtenir des ETH pour payer les frais de gaz.
Contrat Invoker
Un contrat capable d’obtenir le contrôle d’un EOA est appelé « contrat Invoker ». Cependant, tout contrat ne peut pas acquérir ce contrôle : le EOA doit signer numériquement avec sa clé privée, spécifiant explicitement quel contrat Invoker est autorisé, ainsi que les opérations qu’il peut effectuer.
Le contenu signé par le EOA indique clairement l’adresse du contrat Invoker et les actions autorisées (commit).
Le flux d'exécution concret ressemblera approximativement à ceci :
-
Alice utilise la clé privée de son EOA pour signer, puis transmet le contenu signé et la signature à un Relayer.
-
Le Relayer soumet ces données sur la blockchain afin qu’elles soient exécutées par le contrat Invoker.
-
L’Invoker vérifie la signature ; si celle-ci est valide, il peut alors agir au nom du EOA pour exécuter diverses actions, telles qu’approuver USDC, effectuer un échange d’actifs sur Uniswap, puis utiliser une partie des USDC pour rémunérer le Relayer en frais de transaction.
Note 1 : Le Relayer n’est pas obligatoire ; Alice peut également soumettre elle-même le contenu signé et la signature sur la blockchain.
Après vérification de la signature par l’Invoker et démarrage des opérations, toutes les actions sont réalisées au nom du EOA d’Alice, comme s’il avait temporairement transféré un contrôle limité de son compte.
Toutefois, notez que cette exécution n’incrémente pas la valeur de nonce du EOA. Par conséquent, tant que le nonce reste inchangé, la même signature pourrait être réutilisée, rendant indispensable pour l’Invoker de mettre en œuvre un mécanisme anti-rejeu (anti-replay).
Si le contrat Invoker ne dispose pas d’une protection contre les rejeux, la même autorisation pourrait être exécutée indéfiniment.
En savoir plus sur le fonctionnement technique de l’EIP-3074 : https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234
Applications possibles
Batchcall
Permet aux utilisateurs de regrouper plusieurs opérations initialement séparées en une seule transaction, économisant ainsi plusieurs signatures d'autorisation et réduisant les coûts en gaz.
Note : cela nécessite que les DApp prennent en charge la fonctionnalité Batchcall, comme celle proposée par l’EIP-5792 actuellement promue par la communauté. Sinon, si le DApp traite l’utilisateur comme un EOA standard, il continuera à demander une signature pour chaque opération individuelle.
Pour en savoir plus sur l’EIP-5792, copiez ce lien dans votre navigateur : https://eips.ethereum.org/EIPS/eip-5792
Session Key
Les utilisateurs peuvent autoriser un tiers à agir en leur nom sous certaines conditions. Dans le schéma ci-dessous, la « delegate key » représente le tiers autorisé ; la « access policy » définit les restrictions d’usage, par exemple : uniquement interagir avec Uniswap, transférer au maximum 1 ETH par jour, durée maximale de validité, etc.
Ces règles sont définies et vérifiées directement dans le contrat Invoker. Tant que les conditions sont remplies, le tiers peut exécuter des opérations au nom du EOA de l’utilisateur.
Un bot Telegram peut se voir accorder des permissions spécifiques pour agir au nom du EOA de l'utilisateur.
Native ETH Permit
Dès lors que les conditions sont remplies (c’est-à-dire que la signature Permit est valide), un transfert d’ETH peut être effectué au nom du propriétaire du EOA, reproduisant ainsi l'effet d’un « Permit » natif pour ETH.
Ordres à cours limité (Limit Order)
L’utilisateur configure les conditions d’un ordre à cours limité. Lorsque ces conditions sont satisfaites, l’exécution peut avoir lieu au nom de son EOA, incluant notamment l’approbation des actifs numériques auprès du DEX puis l’échange proprement dit. Comparé aux ordres limités natifs proposés par certains DEX, l’utilisateur n’a plus besoin d’envoyer préalablement une transaction d’approbation au DEX.
Lorsqu’Alice conclut une transaction, l’approbation est effectuée en même temps, éliminant la nécessité d’une approbation préalable.
En généralisant davantage les conditions, on aboutit à un contrat d’intention (Intent Contract) : dès lors que les conditions prédéfinies par l’utilisateur sont remplies, n’importe qui peut exécuter l’intention au nom de son EOA.
Dès que les conditions de l’intention sont remplies, toute personne peut déclencher l’exécution au nom du EOA de l’utilisateur.
Récupération sociale (Social Recovery)
Permet à un utilisateur ayant perdu la clé privée de son EOA de récupérer ses actifs via une autorisation EIP-3074 préalablement signée, combinée aux signatures des personnes autorisées (comme le conjoint ou un agent de confiance). En réalité, ce sont les actifs transférables qui sont récupérés, pas le contrôle du compte. Une fois la clé privée perdue, le EOA ne peut plus être utilisé.
Lorsqu’un utilisateur perd sa clé privée, les personnes préautorisées peuvent signer pour autoriser le transfert des actifs du EOA.
Impact de l’EIP-3074
Améliorer la méthode d’autorisation des actifs, voire remplacer approve/permit ?
Actuellement, les DApp sont conçus en supposant que l’utilisateur utilise un EOA : il doit « approuver à l’avance » et « approuver un montant suffisamment élevé » d’actifs au contrat du DApp, afin de ne pas avoir à rester connecté en permanence, ni à répéter constamment les approbations. Cela améliore grandement l’expérience utilisateur.
Par exemple, pour des applications basées sur des déclencheurs conditionnels comme les ordres à cours limité ou le DCA (Dollar-Cost Averaging), l’utilisateur n’est pas nécessairement en ligne lorsque la condition est remplie. Il doit donc pré-approuver un montant important d’actifs, parfois pour des exécutions répétées.
L’utilisateur doit préalablement approuver un montant suffisant d’actifs au DApp pour permettre à celui-ci d’agir en son nom.
Mais cela implique de faire confiance au DApp, d’éviter les faux DApp, et de pouvoir retirer rapidement l’autorisation.
Des alternatives comme le modèle Permit ont ensuite émergé — par exemple EIP-2612 ou le Permit2 non natif — afin d’améliorer à la fois l’expérience utilisateur et la sécurité par rapport au simple « approve » : l’utilisateur n’a plus besoin d’approuver de gros montants auprès de chaque contrat DApp (ni d’approuver chaque actif individuellement), mais simplement de « signer un message » pour autoriser le DApp à retirer un montant précis d’actifs pendant une période définie. Cela réduit fortement la surface d’attaque tout en améliorant l’expérience utilisateur.
En savoir plus sur l’EIP-2612 : https://eips.ethereum.org/EIPS/eip-2612
Sur Permit2 : https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18
L’utilisateur signe hors chaîne, en précisant le montant et la durée de validité, offrant ainsi une meilleure sécurité et ergonomie que l’approbation classique.
Cependant, malgré ces progrès, le modèle Permit continue d’être fréquemment exploité dans des attaques frauduleuses : des victimes signent par erreur un Permit destiné à un DApp légitime, mais qui en réalité bénéficie à un attaquant.
Au moment de signer un Permit, l’utilisateur ne voit que l’adresse bénéficiaire, sans savoir quelles opérations seront exécutées en aval.
Note : De plus, le design actuel de Permit n’est pas compatible avec les applications à opérations répétitives comme le DCA ou les paiements réguliers. En effet, Permit intègre un mécanisme anti-rejeu : après un transfert, le même Permit ne peut plus être utilisé. L’utilisateur devrait donc pré-signer autant de Permits qu’il y aura d’opérations futures.
En savoir plus sur les cas d’arnaques exploitant le modèle Permit :
https://x.com/realScamSniffer/status/1783027808723435727
https://x.com/realScamSniffer/status/1784932506174967970
https://x.com/realScamSniffer/status/1786738218962223226
Mais l’EIP-3074 ouvre la voie à un changement majeur : lorsque les développeurs de DApp comprennent que les EOA peuvent désormais réaliser des opérations complexes via un Invoker, ils n’ont plus besoin de sacrifier la sécurité pour améliorer l’expérience utilisateur, comme avec « l’approbation préalable d’un gros montant » ou « la signature d’un message Permit autorisant un retrait ».
À la place, l’utilisateur lie l’opération du DApp à l’approbation, exécutée de manière atomique via l’Invoker : soit les deux réussissent ensemble (approve + action), soit les deux échouent. Il est impossible que l’approbation réussisse seule. L’utilisateur sait donc avec certitude que cette approbation concerne uniquement cette opération précise.
Et comme l’autorisation se fait par signature hors chaîne, l’expérience utilisateur reste identique à celle du Permit ! Cela signifie que les DApp n’auront bientôt plus besoin du modèle Permit. À l’avenir, les portefeuilles pourront bloquer ou examiner strictement les requêtes de signature Permit, sans craindre de briser la compatibilité avec certains DApp (et ainsi réduire le risque d’arnaques).
L’utilisateur n’autorise plus seulement une adresse, mais une adresse et une action spécifique, voire peut visualiser une simulation du résultat d’exécution.
Note : cela ne garantit pas une protection totale contre les arnaques ! Un utilisateur peut toujours être trompé sur un site frauduleux, où un faux site peut construire une opération d’approbation ou de transfert à signer. Mais désormais, l’utilisateur voit au moins quelle opération est en cours, et le portefeuille peut même simuler et afficher le résultat final, montrant clairement qui perdra de l’argent et qui en gagnera. Comparé au Permit, où ni l’action ni le résultat n’étaient visibles, l’utilisateur dispose désormais d’informations cruciales pour décider. Ce n’est pas une solution parfaite, mais une nette amélioration par rapport à l’état actuel.
Comment les portefeuilles doivent gérer le nonce du EOA
La conception actuelle de l’EIP-3074 inclut la valeur du nonce du EOA dans le contenu signé. Ainsi, dès qu’un EOA envoie une transaction modifiant son nonce, toutes les autorisations EIP-3074 précédentes deviennent immédiatement invalides.
Si l’utilisateur a autorisé une tierce partie à agir en son nom (comme dans les cas de Session Key ou de Social Recovery), il faut absolument éviter toute modification du nonce du EOA. Sinon, toutes les autorisations devraient être renouvelées et transmises à nouveau aux mandataires, ce qui nuit gravement à l’expérience utilisateur et à la robustesse du système.
En revanche, si l’utilisateur gère lui-même ses autorisations, il n’est pas nécessaire d’éviter la modification du nonce, car comme pour une transaction classique, l’EIP-3074 est censé être exécuté dans un délai défini. Le portefeuille devra simplement gérer les transactions EIP-3074 du EOA : s’il existe une signature EIP-3074 en attente de publication, toute transaction envoyée directement par le EOA devra attendre.
Note : Le contrat Invoker doit (et devrait) maintenir son propre mécanisme de nonce, donc même après utilisation, une nouvelle signature sera nécessaire, indépendamment de toute modification du nonce du EOA.
Les fonctionnalités comme Session Key ou Social Recovery ne seront probablement adoptées à grande échelle que si l’EIP-3074 est modifié pour retirer le nonce du EOA du contenu signé. Pour l’instant, les portefeuilles peuvent se concentrer sur les scénarios où l’utilisateur autorise lui-même ses propres opérations, en traitant les signatures EIP-3074 comme des transactions ordinaires, sans se soucier de modifier le nonce du EOA.
Toutefois, attention : si l’utilisateur publie lui-même sa signature EIP-3074 sur la blockchain, deux inconvénients apparaissent :
-
L’utilisateur doit signer deux fois : une fois pour la signature EIP-3074, une autre pour la transaction d’envoi.
-
Comme la transaction incrémente le nonce du EOA avant même le début de l’exécution, la signature EIP-3074 doit anticiper cet incrément : le nonce inclus dans la signature doit déjà être augmenté de +1 pour correspondre à la nouvelle valeur après publication.
Car l’envoi de la transaction incrémente d’abord le nonce du EOA, la vérification de la signature EIP-3074 échouera ensuite en raison d’une inadéquation du nonce.
Si l’utilisateur augmente préalablement de +1 le nonce dans la signature EIP-3074 avant l’envoi, la vérification réussira.
Résumé et points clés
-
L’EIP-3074 donne aux EOA des capacités d’exécution comparables à celles des contrats, ouvrant la porte à de nouveaux cas d’usage innovants.
-
Cela améliore considérablement l’expérience utilisateur et transformera les méthodes d’autorisation actuelles, en les rendant plus sûres sans altérer l’ergonomie.
-
L’EIP-3074 repose uniquement sur une signature : l’utilisateur n’a pas besoin de publier lui-même la transaction, évitant ainsi la nécessité de disposer d’ETH pour payer les frais.
-
Les usages de l’EIP-3074 incluent Batch Call, Session Key, Native ETH Permit, Limit Order, Social Recovery. Beaucoup de ces fonctionnalités étaient auparavant impossibles pour un EOA, et certaines (comme Limit Order) nécessitaient des approbations préalables risquées.
-
L’EIP-3074 va transformer les pratiques d’autorisation actuelles. L’« approve » accorde à une adresse le droit illimité de retirer des actifs numériques, nécessite une transaction préalable du EOA, et offre une mauvaise expérience et sécurité. Le « permit » ne demande qu’une signature, avec montant et durée précisés, offrant une bien meilleure sécurité et ergonomie.
-
Mais le « permit » reste fréquemment utilisé dans des arnaques : lors de la signature, l’utilisateur connaît l’adresse, le montant et la durée, mais ignore totalement « à quoi servira cette autorisation ». Cette information est dans une autre signature (ou transaction). Un DApp légitime demande normalement de signer le permit ET l’action, mais ce sont deux signatures distinctes. Ainsi, lorsqu’on demande une signature de permit, ni l’utilisateur ni le portefeuille ne savent à quoi elle servira.
-
Avec l’EIP-3074, (1) l’utilisateur n’a plus besoin d’approuver un gros montant à l’avance, mais approuve uniquement au moment de l’action, avec un effet similaire au permit ; (2) il signe simplement hors chaîne sans se soucier des frais en ETH, comme avec permit ; (3) chaque approbation est liée à une action spécifique, signée ensemble, permettant à l’utilisateur de savoir exactement « à quoi sert cette approbation », ce qui est bien plus sûr que le permit !
-
Nous espérons que l’EIP-3074 pourra remplacer efficacement les modèles approve et permit actuels, offrant aux utilisateurs une méthode d’autorisation plus sûre.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@imTokenOfficial
