Dans le monde de la blockchain, les utilisateurs ont souvent besoin d'accorder des autorisations (autorisations) permettant aux contrats intelligents de dépenser des jetons en leur nom. Par exemple, lors de l'utilisation d'un échange décentralisé (DEX) pour échanger des jetons, un utilisateur doit d'abord autoriser le contrat d'échange à transférer un montant spécifique de jetons depuis leur portefeuille. Dans le cadre du ERC-20Selon la norme, ce processus nécessite deux transactions distinctes sur la chaîne : une pour l'approbation et une autre pour le transfert réel des jetons. Ce processus en deux étapes est non seulement fastidieux, mais entraîne également des frais de gaz supplémentaires. Afin d'améliorer à la fois l'expérience utilisateur et la sécurité, la communauté Ethereum a introduit un mécanisme d'autorisation basé sur la signature.Permis(comme l'EIP-2612), et a ensuite développé une version avancée appelée Permit2. Ces nouveaux mécanismes permettent aux utilisateurs d'accorder des autorisations de jetons grâce à des signatures hors chaîne, évitant ainsi le besoin de transactions supplémentaires sur la chaîne.

Dans cet article, nous commencerons par les bases en expliquant le fonctionnement traditionnel des approbations ERC-20 et leurs limites. Ensuite, nous plongerons dans le fonctionnement de Permit et Permit2, en mettant en avant leurs avantages et compromis, et en discutant de la manière dont ils améliorent à la fois l'efficacité et la sécurité. Nous examinerons également les risques potentiels en matière de sécurité, en particulier attaques de phishing impliquant des signatures malveillantes, et offrir des conseils pour rester en sécurité. Que vous soyez nouveau dans la blockchain ou que vous commenciez tout juste votre parcours d'investissement dans la cryptomonnaie, ce guide vise à vous aider à comprendre ces importantes innovations techniques.

Fondamentaux du modèle d'autorisation ERC-20

Avant de plonger dans Permit, regardons d'abord comment fonctionne le modèle traditionnel d'autorisation de jeton ERC-20 et les limitations qu'il présente.

Comment fonctionnent les approbations traditionnelles ERC-20

ERC-20 est la norme pour les jetons sur Ethereum. Il définit des fonctions comme approuver et transferFrom, qui permettent ensemble l'autorisation de jeton. L'autorisation signifie ici qu'un détenteur de jeton (le propriétaire) permet à un autre compte, généralement un contrat intelligent (le dépensier), de transférer un certain montant de jetons en leur nom. Le processus de base fonctionne comme suit :

1. Le détenteur de jetons appelle la fonction approve(spender, montant) du contrat de jetons. Cela enregistre l'autorisation dans la table de hachage interne du contrat, généralement exprimée comme allowance[owner][spender] = montant. Par exemple, si l'utilisateur A autorise le contrat Uniswap à dépenser jusqu'à 100 jetons, le contrat enregistrera allowance[A][Uniswap] = 100. Cette étape nécessite une transaction sur chaîne et des frais de gaz payés par A.
2. DeleGate.iod Transférer (transferFrom): Plus tard, lorsque Uniswap (ou une autre application décentralisée) a besoin de dépenser des jetons au nom de A, elle appelle transferFrom(A, B, montant) sur le contrat de jeton. Le contrat vérifie si l'autorisation[A][Uniswap] est suffisante. Si c'est le cas, le contrat transfère le montant spécifié de A à B et déduit ce montant de l'autorisation.

Limitations and Challenges of the Approve Model

Le modèle en deux étapes ci-dessus permet aux utilisateurs d'autoriser les contrats à gérer leurs fonds, sans jamais partager leurs clés privées. Cependant, cette approche traditionnelle comporte également plusieurs problèmes pratiques :

Deux transactions sont nécessaires, une mauvaise expérience utilisateur
Chaque fois qu'un utilisateur souhaite utiliser un nouveau jeton sur une dApp, il doit d'abord envoyer une transaction d'approbation séparée avant de pouvoir effectivement effectuer l'action désirée (comme l'échange ou la mise en jeu). Cela signifie que leur portefeuille leur demandera deux fois une confirmation et facturera des frais de gaz supplémentaires. Pour les débutants, cette étape supplémentaire peut être déroutante et gênante.

Gestion fragmentée des approbations
Lorsque les utilisateurs interagissent avec plusieurs dAppsen utilisant le même jeton (par exemple, en échangeant sur Uniswap puis en le déposant dans un autre protocole DeFi), chaque dApp nécessite une approbation séparée, même s'il s'agit du même jeton dans le même portefeuille. Cela entraîne des approbations répétitives, ce qui fait perdre du temps et du gaz.

De plus, puisque chaque dApp gère ses propres autorisations indépendamment, les utilisateurs ont peu de contrôle centralisé sur leurs approbations. Certains outils, comme Revoke.cashetDeBankPermet aux utilisateurs de consulter et de gérer les autorisations de jetons, mais de nombreux utilisateurs n'en sont pas conscients. Et même s'ils le sont, révoquer les autorisations nécessite toujours une transaction on-chain, ce qui ajoute des coûts. Par conséquent, de nombreuses approbations anciennes ou inutilisées sont simplement oubliées.

Les risques des approbations illimitées
Pour éviter les transactions d'approbation fréquentes, de nombreuses dApps suggèrent aux utilisateurs d'accorder une approbation illimitée, permettant au contrat de dépenser l'intégralité du solde de jetons de l'utilisateur, sans expiration. Bien que cette approche économise des efforts ultérieurement, elle introduit de graves risques de sécurité : si la dApp ou le contrat est compromis, un attaquant pourrait vider tous les jetons approuvés.

Ces défis ont incité les développeurs à chercher de meilleures alternatives. Idéalement, les utilisateurs ne devraient avoir à signer qu’une seule fois (de préférence hors chaîne et sans gaz) pour terminer à la fois l’approbation et l’action. La portée et la durée de l’approbation devraient également être limitées afin de minimiser les risques potentiels. C’est la motivation derrière l’introduction du permis ERC-20.

Autorisation : Autorisation ERC-20 basée sur la signature (EIP-2612)

Le concept de Permit a été introduit pour la première fois par leDAIcontrat stablecoin et plus tard normalisé en tant que EIP-2612. En bref, Permit permet aux utilisateurs d'autoriser les transferts de jetons en utilisant des signatures hors chaîne, éliminant ainsi la nécessité d'envoyer une transaction d'approbation distincte sur chaîne. Examinons de plus près comment cela fonctionne et ses caractéristiques distinctives.

Comment fonctionne le permis

Le Permit est un mécanisme d'autorisation basé sur des signatures numériques. Conformément à la norme EIP-2612, les contrats de jetons ERC-20 qui prennent en charge le Permit ajoutent une fonction appelée permit() qui ressemble à ceci :

fonction autoriser(
propriétaire de l'adresse, dépensier de l'adresse,
valeur uint256, échéance uint256,
uint8 v, bytes32 r, bytes32 s
) externe;

Ici, le propriétaire, le dépensier et la valeur spécifient qui donne la permission, qui reçoit la permission et le montant autorisé. la date limite indique quand la signature expire. Les paramètres v, r et s forment le ECDSAsignature numérique. En utilisant Permit, les utilisateurs contournent l'approbation distincte on-chain - ils signent simplement le message (sans payer de gaz) et incluent cette signature avec leur transaction pour compléter l'autorisation en une seule étape.

Flux de travail de permis

Par rapport à l'approbation traditionnelle, Permit élimine le besoin d'une transaction supplémentaire on-chain, économisant à la fois du temps et des frais de gaz. Il permet également un contrôle fin sur les approbations. Par exemple, un utilisateur pourrait signer un Permit permettant de dépenser exactement 50 USDC, valide uniquement pendant 5 minutes. Même si la signature est exposée, elle devient inutilisable après la date limite, réduisant ainsi les risques. Aujourd'hui, de nombreux protocoles DeFi, tels que les échanges décentralisés et les plateformes de prêt, prennent déjà en charge Permit. Des exemples bien connus incluent Uniswap V2/V3jetons LP, DAI, etUSDC, qui ont mis en œuvre la norme EIP-2612, permettant des approbations en une étape basées sur des signatures.

Cependant, la plus grande limite de Permit est qu'elle doit être implémentée directement dans le contrat de jeton. Si le développeur d'un jeton n'a pas ajouté la méthode permit() — ce qui signifie qu'il ne prend pas en charge l'EIP-2612 — alors Permit ne peut tout simplement pas être utilisé. Étant donné que l'EIP-2612 n'a été introduit qu'en 2020, de nombreux jetons plus anciens ne l'incluent pas, et même les jetons plus récents ne l'adoptent pas toujours. Cela limite l'applicabilité de Permit : les jetons non pris en charge nécessitent toujours le flux d'approbation traditionnel.

Un autre problème est que le logiciel de portefeuille doit gérer et afficher correctement les signatures de Permit, qui sont généralement formatées à l'aide de l'EIP-712. La plupart des portefeuilles majeurs prennent en charge cela maintenant, mais certains affichent toujours des données brutes au lieu de messages lisibles par l'homme, ce qui rend difficile pour les utilisateurs de comprendre ce qu'ils signent. Sans une interface claire pour l'EIP-2612, les portefeuilles peuvent entraver la compréhension des utilisateurs des approbations basées sur les signatures. De plus, dans les cas de déploiements parallèles (comme des contrats avec des adresses identiques sur différentes chaînes), les signatures pourraient potentiellement être réutilisées dans d'autres environnements. Par conséquent, les utilisateurs doivent vérifier que l'ID de chaîne et l'adresse de contrat dans leurs signatures correspondent à leur environnement actuel pour éviter que les autorisations accordées pour des jetons sur la chaîne A ne soient utilisées de manière abusive par des adresses de contrat identiques sur la chaîne B.

En essence, Permit améliore considérablement l'efficacité et la flexibilité des approbations ERC-20, marquant une étape importante dans les mécanismes d'approbation sans gaz. Cependant, ce n'est pas une solution parfaite : elle nécessite un support au niveau du jeton et introduit de nouveaux risques. Ensuite, nous examinerons comment le Permit2 d'Uniswap s'appuie sur et étend les bases posées par Permit.

Permis2: Contrat de Gestion d'Autorisation Universelle

Avec la popularité du mécanisme d'autorisation, un nouveau défi est apparu: comment étendre la commodité de l'autorisation basée sur une signature aux jetons qui ne prennent pas en charge l'autorisation? Pour résoudre ce problème et optimiser les expériences d'autorisation dans divers scénarios, l'équipe Uniswap a introduit Permit2 en 2022. Contrairement à une fonctionnalité spécifique à un jeton, Permit2 est un contrat intelligent de gestion des autorisations autonome. Il agit comme un intermédiaire pour les autorisations de jetons, offrant une fonctionnalité d'autorisation unifiée et améliorée. Analysons les principes et les fonctionnalités de Permit2.

Comment fonctionne Permit2

Permit2 fonctionne comme un service de relais d'autorisation. Son concept de base est simple : les utilisateurs accordent une approbation unique au contrat Permit2, qui gère ensuite les sous-autorisations ultérieures à diverses applications. Voici comment cela fonctionne :

1. Autorisation unique Permit2 : les utilisateurs approuvent Permit2 pour chaque jeton en utilisant la méthode traditionnelle approve(Permit2, max_amount). Une grande quantité ou une quantité illimitée est recommandée, car il s'agit de l'approbation principale. Une fois terminé, le contrat Permit2 acquiert la capacité d'appeler transferFrom au nom de l'utilisateur pour ce jeton. Cela nécessite une transaction on-chain, mais ne doit être effectué qu'une seule fois.
2. Signature hors chaîne pour la sous-autorisation : Lorsque les utilisateurs souhaitent interagir avec une DApp (par exemple, en utilisant Uniswap Universal Router pour des échanges multi-tokens), ils signent un message d'autorisation hors chaîne suivant les spécifications de Permit2. Cette signature inclut des détails comme le jeton autorisé, le montant, le dépensier cible (comme un contrat DApp spécifique) et l'heure d'expiration.
3. Demande de transfert de DApp utilisant une signature : Lorsqu'une DApp reçoit la signature de l'utilisateur et a besoin d'utiliser des jetons, au lieu d'appeler directement le contrat de jeton, elle appelle les fonctions de Permit2 (comme permitTransferFrom). Cette fonction vérifie les données de la signature de l'utilisateur et confirme que l'opération est autorisée (jeton, montant, délai). Après vérification, Permit2 utilise son approbation principale pour appeler transferFrom, transférant des jetons de l'utilisateur au destinataire spécifié. Point clé : Le contrat Permit2 lui-même agit en tant que dépensier, utilisant sa propre autorité pour transférer des jetons, avec une étape supplémentaire de vérification de signature.
4. Validation de l'opération : Une fois que Permit2 exécute avec succès le transfert depuis, les fonds se déplacent sans heurts de l'utilisateur vers l'application décentralisée (DApp) ou l'adresse spécifiée. Du point de vue de l'utilisateur, il ne fournit qu'une signature dans la transaction, tandis que le contrat gère toutes les actions ultérieures.

Le flux d'autorisation Permit2 est simple : les utilisateurs n'ont besoin d'accorder qu'une seule fois une approbation maximale à Permit2 par jeton. Ensuite, lorsqu'ils interagissent avec des applications (comme Uniswap Universal Router ou d'autres protocoles), ils incluent simplement une signature Permit2 dans leur transaction pour compléter l'autorisation et le transfert, sans approbations supplémentaires on-chain. Le contrat Permit2 vérifie la signature et exécute le transfert en utilisant son approbation principale. (Source:Présentation de Permit2 & Universal Router)

Grâce à ce modèle, Permit2 étend le concept d’autorisation basé sur la signature de l’EIP-2612 à tous les jetons ERC-20, qu’ils implémentent ou non la méthode permit() eux-mêmes. Tant que les utilisateurs autorisent initialement le contrat Permit2, ils peuvent utiliser des signatures pour les opérations ultérieures. Uniswap a notamment conçu Permit2 comme un contrat sans propriétaire et non évolutif déployé avec la même adresse sur le réseau principal Ethereum et plusieurs réseaux de couche 2. Cela signifie que toutes les applications utilisent en fait la même instance Permit2, ce qui permet d’obtenir une véritable fonctionnalité « approuver une fois, utiliser partout ».

Caractéristiques clés de Permit2

En tant que système d'autorisation de nouvelle génération, Permit2 permet non seulement des approbations basées sur des signatures pour tous les jetons, mais offre également des fonctionnalités supplémentaires pour améliorer la sécurité et la convivialité. Voici ses principales caractéristiques :

Expiration automatique
Toutes les autorisations Permit2 peuvent inclure un horodatage d'expiration. Les utilisateurs peuvent spécifier quand leur sous-autorisation doit expirer lors de la signature. Une fois la date limite dépassée, Permit2 rejettera la signature, même si l'approbation principale est toujours active. Cela adresse efficacement le risque d'approbations indéfinies qui restent inutilisées.

Transferts de signature à usage unique
Permit2 offre un mode de transfert de signature directe où les utilisateurs peuvent autoriser un transfert de jetons spécifique à un destinataire en utilisant simplement une signature, sans avoir besoin de définir d'abord une autorisation. C'est parfait pour les scénarios de paiement ponctuel : les utilisateurs peuvent signer un message autorisant le transfert de 100 jetons à l'adresse d'un ami, et l'ami ou l'intermédiaire peut exécuter le transfert en utilisant cette signature. Une fois utilisée, la signature devient invalide, ne laissant aucune autorisation persistante.

Approbations par lots et transferts
Permit2 priorise l'efficacité en permettant le traitement par lots de plusieurs approbations ou transferts. Les utilisateurs peuvent autoriser différents montants de plusieurs jetons à un seul protocole avec une seule signature, ou exécuter des transferts de plusieurs jetons en une seule transaction. Cela permet d'économiser du gaz et réduit les étapes pour les utilisateurs avancés.

Révocation par lot
Au-delà des approbations par lots, les utilisateurs peuvent révoquer les autorisations pour plusieurs jetons/applications dans une seule transaction. Cela rend le nettoyage des approbations historiques beaucoup plus pratique.

Témoignage de données supplémentaires
Permit2 inclut des interfaces commeautoriserTransferFromTémoin qui permettent d’inclure des données de vérification supplémentaires dans les signatures. Cela prend en charge des scénarios plus complexes, tels que l’inclusion de détails de transaction spécifiques dans les signatures de commande afin d’empêcher la réutilisation des signatures dans différents contextes.

Grâce à ces fonctionnalités, Permit2 reproduit non seulement tous les avantages de Permit, mais renforce également la flexibilité et les contrôles de sécurité. L'expiration automatique et les transferts de signature à usage unique, en particulier, rendent la nécessité minimale d'autorisation la norme, réduisant ainsi les risques à long terme.

En résumé, Permit2 fonctionne à la fois comme une extension et une amélioration du mécanisme de Permit traditionnel. Examinons les principales différences entre ces deux approches:

Adoption et mise en œuvre de l'écosystème Permit2

Depuis qu’Uniswap a introduit Permit2, de nombreux projets ont intégré ce mécanisme, accélérant ainsi la normalisation de l’industrie. D’après les dernières données de l' Dune Analytics, en avril 2025, plus de 3,1 millions d'adresses du réseau principal d'Ethereum ont accordé une autorisation au contrat Permit2, démontrant son adoption généralisée.

Permis2 Écosystème et Statut de Mise en œuvre. Source:Dune Analytics

Par exemple, Uniswap a intégré Permit2 dans son routeur universel, permettant des échanges multi-tokens et NFT en une seule transaction. Grâce à Universal Router, les utilisateurs peuvent enchaîner plusieurs opérations en une seule transaction, telles que l’échange de trois jetons contre deux jetons cibles et l’achat de NFT, toutes les exigences d’autorisation étant gérées par des signatures Permit2. Cela rationalise considérablement le processus et réduit les coûts totaux de gaz, ce qui met en évidence l’impact direct de Permit2 sur l’amélioration de l’expérience utilisateur.

De plus, avec le déploiement open-source de Permit2 sur différentes chaînes, un nombre croissant de portefeuilles et d'outils DApp ont commencé à le prendre en charge. Des outils de sécurité comme Revoke.cash ont mis à jour leurs services pour permettre aux utilisateurs de consulter et de révoquer les enregistrements d'autorisation de Permit2. Matcha a également mis en œuvre le module SignatureTransfer de Permit2, permettant un mécanisme d'autorisation “une fois”.

Malgré ces progrès, l'adoption généralisée de Permit2 rencontre des défis. D'une part, les développeurs ont besoin de temps supplémentaire pour l'intégration : comparé à l'approbation directe des ERC-20, la mise en œuvre de Permit2 nécessite la gestion de la logique de signature, ce qui augmente les coûts de développement. Cela pourrait dissuader les petites équipes. D'autre part, l'éducation des utilisateurs est cruciale : de nombreux DApps utilisant Permit2 doivent apprendre aux utilisateurs l'importance des signatures. Actuellement, les avantages unifiés de Permit2 semblent l'emporter sur ces points de friction, mais une pénétration complète du marché prendra encore du temps.

Comparer Permit2 avec de nouvelles solutions : clés de session et ERC-4337

Au cours des 8 dernières années, les mécanismes d'autorisation ERC-20 ont évolué de transactions multiples à des signatures sans gaz, et maintenant à des comptes intelligents. Chaque avancée a cherché à optimiser l'équilibre entre l'expérience utilisateur (réduire les exigences de transaction et de signature) et les coûts en gaz. Voici une comparaison de ces technologies :

Outre Permit2, deux solutions d'autorisation émergentes qui méritent d'être notées sont Session Keys etERC-4337 Abstraction de compte, chaque offrant des approches distinctes du problème.

Les clés de session sont particulièrement uniques, car il ne s’agit pas d’un modèle d’autorisation strict, mais plutôt d’un mécanisme de clé temporaire au niveau du portefeuille ou du compte. Au lieu de modifier les contrats de jetons, ils permettent aux portefeuilles de générer des clés privées temporaires limitées dans le temps et limitées dans le temps pour des opérations spécifiques. Cela les rend idéales pour les achats d’articles de jeu et les micropaiements ponctuels. L’accent est mis sur la réduction des risques liés à l’autorisation unique, conçue spécifiquement pour les interactions temporaires avec les utilisateurs, contrairement à l’approche de modification de contrat de Permit/Permit2.

ERC-4337 adopte une approche différente en intégrant directement la logique d'autorisation dans les comptes intelligents, permettant aux utilisateurs de personnaliser les conditions d'autorisation et éventuellement de passer les étapes d'approbation traditionnelles. Grâce à des mécanismes d'UserOperation et de Paymaster flexibles, il garantit une sécurité renforcée et une meilleure expérience utilisateur.

Si l’on regarde les tendances futures, ces différentes solutions sont susceptibles de coexister. À court terme, Permit2 continuera d’être la norme pour les DApps émergentes, améliorant l’expérience utilisateur grâce à des autorisations uniques tout en promouvant l’éducation à la sécurité et le support d’outils pour réduire les risques d’hameçonnage. À moyen terme, à mesure que l’ERC-4337 et l’abstraction des comptes se généraliseront dans les couches 2 et les réseaux principaux, les utilisateurs seront en mesure de s’affranchir des limitations d’approbation ERC-20 traditionnelles, en gérant les autorisations de manière plus précise et plus intelligente, ce qui pourrait réduire le besoin de Permit2.

La vision à long terme est de créer une expérience d'autorisation aussi fluide et intuitive que Web2, où les utilisateurs peuvent simplement cliquer sur un bouton et toutes les approbations nécessaires se déroulent automatiquement en arrière-plan, avec des invites claires n'apparaissant que dans des situations à haut risque. Pour atteindre cette vision, une collaboration et une innovation continues seront nécessaires à travers les protocoles sous-jacents, les portefeuilles et les dApps. Permit2 représente une étape importante dans ce voyage de transition, mais il reste encore beaucoup de chemin à parcourir avant d'atteindre l'état idéal. En cours de route, la communauté et les développeurs doivent adopter une approche pragmatique, en comprenant pleinement les forces et les limites de chaque solution et en travaillant ensemble pour construire un environnement d'autorisation plus sûr et convivial pour l'utilisateur.

Dans l’ensemble, Permit2 offre une solution pratique qui peut être mise en œuvre immédiatement, tandis que des technologies telles que Session Keys et ERC-4337 indiquent des améliorations plus fondamentales et à long terme dans la façon dont l’autorisation est gérée.

Risques de sécurité de l'autorisation basée sur la signature

Comme pour toute nouvelle technologie, Permit et Permit2 introduisent non seulement de nouvelles efficacités, mais également de nouveaux risques, notamment en ce qui concerne les attaques d'autorisation basées sur les signatures.

Dans des schémas basés sur des signatures comme Permit2 et EIP-2612 Permit, les conceptions de contrat de base incluent plusieurs couches de protection pour se prémunir contre les abus et les attaques de rejeu :

1. Protection contre la relecture basée sur le nonce

Permit2 maintient un compteur de nonce séparé pour chaque tuple (propriétaire, jeton, dépensier). Chaque fois qu'un utilisateur signe une nouvelle autorisation, le nonce correspondant est incrémenté. Si un attaquant tente de réutiliser une ancienne signature, cela échouera car le contrat vérifie si le nonce a déjà été utilisé.

2. Application des délais

Chaque signature doit inclure un champ de date limite. Lorsque le contrat vérifie la signature, il s'assure que le temps du bloc actuel est inférieur ou égal à la date limite. Si la signature a expiré, même si elle est par ailleurs valide, elle sera rejetée. Cela empêche les autorisations de longue durée d'être exploitées ultérieurement.

3. Contrôle de la surépaisseur à grain fin

Les signatures Permit2 peuvent spécifier une autorisation maximale. Avant tout transfert de jetons, le contrat vérifie que le montant demandé est dans cette limite. Le contrat ne dépense pas automatiquement le montant approuvé complet, permettant aux utilisateurs d'utiliser leur autorisation par parties et réduisant le risque d'une exploitation complète du fonds.

4. Modes d'utilisation unique et par lots

En plus des approbations basées sur les autorisations en cours, Permit2 prend également en charge les signatures à usage unique via SignatureTransfer. Ces signatures ne sont valables que pour une seule transaction et deviennent invalides immédiatement après l'exécution. Cela est idéal pour les paiements ponctuels et empêche la signature d'être réutilisée ou exploitée ultérieurement.

Ces protections en couches aident les schémas d'autorisation de style Permit à améliorer l'expérience utilisateur et à économiser du gaz tout en minimisant les risques classiques tels que les "attaques de rejeu", la "sur-autorisation" et la "validité de signature indéfinie".

Cependant, même avec des protections sécurisées au niveau du contrat, l'ingénierie sociale (en particulier le phishing) reste la menace la plus difficile à contrer. Dans la section suivante, nous examinerons les tactiques de phishing courantes et comment les attaquants trompent les utilisateurs pour qu'ils signent involontairement des approbations malveillantes qui abusent de Permit2. Nous offrirons également des conseils sur la manière de rester en sécurité.

Comment se produisent les attaques de phishing par signature ?

L’hameçonnage par signature se produit lorsque les attaquants incitent les victimes à signer des messages spécifiques pour prendre le contrôle de leurs actifs. Alors que les attaques traditionnelles peuvent impliquer l’exécution de contrats ou de transactions malveillants, à l’ère des permis, une seule autorisation de signature malveillante suffit à drainer des fonds. Voici comment ces attaques se déroulent généralement :

1. La victime clique sur une fausse version d'un site Web DEX bien connu (site d'hameçonnage). Lorsque l'utilisateur essaie d'interagir, le site demande une signature de portefeuille, prétendant qu'il s'agit d'une "confirmation de connexion" ou d'autres motifs en apparence légitimes. Cependant, cette demande est en réalité une signature d'autorisation Permit2, accordant à l'attaquant un accès illimité au contrat pour retirer les USDC de la victime avec une période de validité prolongée.
2. La victime, manquant de vigilance, signe directement la demande. À ce stade, aucun gaz n'est dépensé et aucune activité on-chain ne se produit, ne laissant aucune trace suspecte.
3. Une fois que l'attaquant obtient la signature, il appelle immédiatement la fonction permit() du contrat Permit2 pour la soumettre. Après que le contrat Permit2 a validé la signature, il enregistre l'autorisation pour le contrat de l'attaquant sous l'adresse de la victime (équivalent à l'exécution d'une approbation par la victime, mais réalisée par l'attaquant). Cette opération pourrait passer inaperçue pour la victime car son portefeuille ne montre aucune dépense - seule sa correspondance d'autorisation de jetons est mise à jour sur la blockchain.
4. Par la suite, l'attaquant lance immédiatement une transaction transferFrom(victim, attacker_address, amount) depuis son adresse, transférant avec succès les USDC de la victime en utilisant l'autorisation Permit2 récente. La victime ne réalise le vol que lorsqu'il est trop tard.

Dans ces attaques, les utilisateurs n'exécutent jamais d'évidentes transactions de « transfert » ou d'« autorisation », pourtant leurs actifs disparaissent mystérieusement. La clé réside dans la signature devenant elle-même l'autorisation. Les attaquants déguisent soigneusement les demandes de signature pour qu'elles apparaissent comme des opérations normales, abaissant la vigilance des utilisateurs. Cependant, une fois signé, c'est comme remettre les clés de vos actifs.

Pire encore, certains attaquants utilisent des méthodes techniques pour augmenter la furtivité. Par exemple, ils utilisent le mécanisme CREATE2 d’Ethereum pour générer des adresses de contrat malveillantes uniques pour chaque victime. Cela rend les listes noires traditionnelles inefficaces puisque chaque attaque utilise une adresse différente.

La plupart des récents incidents de phishing cryptographique impliquent une autorisation de signature. Par exemple, Scam Sniffer’sstatistiquesà partir du début de 2024 montrent plus de 55 millions de dollars d'actifs volés par hameçonnage de signature en juste un mois. Depuis l'activation de Permit2, les attaquants sont devenus plus agressifs pour inciter les utilisateurs à signer des autorisations Permit/Permit2, entraînant de nombreuses victimes en peu de temps. Clairement, lorsqu'une autorisation de signature est abusée, elle peut être dévastatrice et difficile à détecter.

Pourquoi les risques de phishing basés sur la signature sont-ils plus élevés que les méthodes traditionnelles ?

Les autorisations malveillantes traditionnelles obligent les utilisateurs à exécuter une transaction sur la chaîne, où les portefeuilles affichent généralement des avertissements clairs du type « Vous autorisez XXX à utiliser vos jetons » et exigent des frais de gaz. Les utilisateurs expérimentés ont tendance à être plus prudents à cet égard. Cependant, les demandes de signature dans les interfaces de portefeuille sont souvent simplement décrites comme des « demandes de signature de données » plutôt que des actions financières, ce qui amène les utilisateurs à baisser leur garde. De plus, comme les signatures ne coûtent pas de gaz, les attaquants peuvent lancer des tentatives de phishing à grande échelle sans se soucier des dépenses - ils réalisent un profit même avec quelques tentatives réussies seulement.

De plus, les portefeuilles différents affichent les messages EIP-712 de différentes manières. Certains portefeuilles modernes (comme le dernierMetaMask ) analyser et afficher clairement les champs, en affichant des messages tels que "autoriser le contrat à dépenser X montant de vos jetons". Cependant, de nombreux portefeuilles ne montrent que des données hexadécimales ou des descriptions simples, ce qui rend difficile pour les utilisateurs moyens de vérifier l'authenticité. Les attaquants exploitent cela en intégrant des descriptions trompeuses dans les messages (comme prétendre être des signatures de création NFT) pour tromper les utilisateurs en signant.

Parce que les autorisations de signature n'impactent pas immédiatement les actifs, les victimes peuvent ne pas détecter immédiatement la menace. Les attaquants peuvent choisir stratégiquement le moment de leurs attaques. Plutôt que d'exécuter immédiatement, ils peuvent attendre que le portefeuille de la victime contienne plus d'actifs ou attendre un moment spécifique, ce qui complique les efforts de suivi. Avec des signatures ayant des périodes de validité prolongées, les attaquants peuvent également exploiter les mouvements de prix pour maximiser leurs gains, leur offrant ainsi efficacement une option de trading gratuite. Ce risque explique pourquoi les signatures de type Permit imposent généralement des délais courts.

La capacité de Permit2 à autoriser plusieurs jetons avec une seule signature rend particulièrement difficile pour les utilisateurs de comprendre pleinement les implications. Par exemple, un site de phishing pourrait demander une signature Permit2 tout en mettant en évidence des autorisations pour un ou deux jetons seulement, mais intégrer secrètement des autorisations étendues pour des jetons supplémentaires dans la même signature. Les utilisateurs peuvent facilement négliger ces autorisations cachées si leurs portefeuilles ne affichent pas tous les détails clairement. De plus, les attaquants utilisent souvent des noms de contrat trompeurs comme "WalletGuard" dans leurs signatures, masquant des contrats malveillants conçus pour voler des autorisations de jetons.

Comment les utilisateurs peuvent-ils se protéger des attaques de signature ?

Rappelez-vous que signer équivaut à donner son consentement, ne laissez jamais l'absence de frais de gaz vous rendre négligent. Lorsque votre portefeuille demande une signature, lisez attentivement les détails du message. Assurez-vous que le site Web ou le DApp demandant la signature est légitime et que le contenu du message correspond à vos actions prévues. Par exemple, si vous vous connectez simplement à un site Web, la signature doit contenir un texte de connexion lisible (comme la plupart des DApps l'utilisent), pas une série d'adresses et de chiffres de jetons.

Assurez-vous que votre logiciel de portefeuille prend en charge l'affichage des données EIP-712. Les principaux portefeuilles comme MetaMask,TrustWallet, etLedger Live améliorent l’expérience d’affichage de leur contenu signature. Par exemple, MetaMask peut désormais analyser les messages d’autorisation courants dans un langage simple. Si votre portefeuille n’affiche que de longues données hexadécimales lors de la signature, envisagez de changer ou de mettre à jour. Les utilisateurs de portefeuilles matériels doivent également maintenir leur micrologiciel à jour pour prendre en charge les nouveaux formats, sinon ils risquent de ne pas voir correctement les informations à l’écran.

Que vous utilisiez des signatures Permit ou Permit2, vous pouvez généralement ajuster les paramètres d'autorisation. Ne signez pas des montants illimités (valeur = 2^256-1) à moins que ce ne soit absolument nécessaire - autorisez plutôt uniquement le montant dont vous avez besoin plus un petit tampon. De plus, ne fixez pas de délais trop lointains. De cette façon, même si votre signature tombe entre de mauvaises mains, les pertes potentielles sont limitées et la signature expirera finalement.

Prenez l’habitude de vérifier régulièrement le statut d’autorisation de votre adresse à l’aide d’outils tels que Revoke.cash, Etherscan Token Approval ou les fonctionnalités intégrées de votre portefeuille. Cela inclut à la fois les approbations traditionnelles et les allocations Permit2. Si vous repérez des autorisations suspectes ou inutiles, révoquez-les immédiatement. Pour Permit2, tenez compte de deux niveaux de révocation : premièrement, l’autorisation principale (votre approbation du contrat Permit2 lui-même, que vous voudrez peut-être définir à 0 lorsqu’il n’est pas utilisé) ; deuxièmement, les sous-autorisations (les allocations de Permit2 à diverses DApps, qui expirent généralement automatiquement, mais peuvent être résiliées plus tôt si elles ont de longues périodes de validité). Si vous pensez avoir signé un permis suspect, l’action la plus sûre est d’ajuster immédiatement le nonce : signez un nouveau permis au même dépensier (même avec une allocation de 0) pour invalider l’ancienne signature en possession de l’attaquant.

Soyez toujours prudent lorsque vous visitez des sites Web inconnus ou que vous téléchargez des applications. Ne cliquez pas sur des liens inconnus, en particulier des « offres promotionnelles » ou des « événements de mint » partagés par le biais de publicités sur les réseaux sociaux ou de messages privés. De nombreuses tentatives d’hameçonnage se produisent par le biais de faux comptes officiels qui publient des liens d’activités frauduleuses, ce qui entraîne des demandes de signature. Prenez l’habitude de taper directement les URL officielles des DApp ou d’utiliser des signets pour éviter de tomber dans le piège des faux sites Web.

En conclusion, trouver un équilibre entre la commodité et la sécurité est crucial. Bien que les technologies de permis soient pratiques, les utilisateurs doivent rester vigilants en matière de prévention des risques. À mesure que l'écosystème mûrit, les produits de portefeuille et les extensions de navigateur développent une protection contre le hameçonnage de signature, tels que des avertissements pour les signatures impliquant des montants importants. Nous visons à atténuer de telles attaques sur Gate.io grâce à des améliorations techniques et éducatives dans le futur.

Conclusion

Des limites des modèles d’autorisation ERC-20 traditionnels à la naissance de Permit, puis à l’innovant Permit2 d’Uniswap, nous avons été témoins des efforts de l’écosystème Ethereum pour améliorer l’expérience utilisateur et la sécurité. Permit2 simplifie considérablement le processus d’autorisation des jetons grâce à des signatures hors chaîne, réduisant ainsi les risques d’approbations répétées et d’autorisations illimitées, tout en introduisant des fonctionnalités utiles telles que les mécanismes d’expiration et les opérations par lots. Cependant, ces nouveaux mécanismes s’accompagnent de nouvelles responsabilités : les utilisateurs doivent renforcer leur sensibilisation à la sécurité, tandis que les portefeuilles et les DApps doivent travailler ensemble pour protéger les utilisateurs contre les attaques de signature. À l’avenir, avec d’autres développements technologiques, tels que l’abstraction des comptes, la gestion des autorisations de jetons devrait devenir plus transparente et plus sûre.