Dans les DApps basés sur EVM, quatre actions apparaissent souvent l'une après l'autre: connecter un portefeuille, signer un message, signer une transaction et accorder l'autorisation d'utiliser des jetons cryptographiques. Ces actions ne fournissent pas le même accès. Une connexion crée un canal de communication entre un compte et un site Web. La signature du message prouve l'identité ou exprime l'intention. La signature de transaction crée une transaction qui peut être diffusée. Une autorisation jeton permet à une partie approuvée (Spender) utiliser les actifs dans des limites définies. Un montant nul ou l'absence de frais de réseau (Gas) ne rend pas une demande sûre ; comprendre chaque demande avant de la confirmer.

Distinction importante : Une autorisation jeton est un état d'autorisation et non un quatrième type de signature parallèle aux trois premières actions. Une transaction chaîne de blocs peut exécuter la fonction approbation (approve) pour créer ou modifier l'autorisation. Alternativement, un message d'autorisation signé (Permit) peut être soumis ultérieurement. La signature seule ne modifie pas le chaîne de blocs ; l'autorisation ne peut être enregistrée qu'une fois le message signé soumis avec succès.

Une connexion de portefeuille utilise normalement l'interface de connexion de portefeuille (Provider). Une demande de connexion standard ne donne pas au site Web un clé privée ou un phrase de départ, et elle ne signe ni ne transfère automatiquement les actifs. Cependant, le site Web peut recevoir l'adresse publique et le réseau sélectionnés par l'utilisateur et envoyer des demandes ultérieures au portefeuille. Une fois que le site Web connaît une adresse publique, il peut continuer à interroger l'historique public chaîne de blocs de cette adresse après la fin de la connexion. Arrêtez-vous immédiatement et vérifiez le point d'entrée officiel si un site Web demande un phrase de départ ou un clé privée.

La signature de messages est couramment utilisée pour connectez-vous, l'acceptation des conditions, les commandes hors chaîne, le vote ou les données structurées définies par EIP-712. Il n'enregistre normalement pas de données sur le chaîne de blocs et le signataire ne paie normalement pas de frais de réseau (Gas). Toutefois, le fait de ne pas payer de frais ne signifie pas que la demande est exempte de risque patrimonial. Lorsque le portefeuille affiche des informations lisibles, examinez chaque champ affiché. Vérifiez le domaine, l'identifiant du réseau (Chain ID), le champ d'adresse du contrat (verifyingContract), la partie agréée (Spender), le montant et le délai d'expiration. Si le portefeuille affiche uniquement des données brutes ou du contenu hexadécimal que vous ne comprenez pas, arrêtez. Ne donnez pas suite à la demande. Voir Qu'est-ce que l'arnaque à la transaction de montant nul avec données hexadécimales ?.

La signature crée une transaction signée ; il ne change pas l'état de chaîne de blocs par lui-même. Le solde d'un compte, l'état du contrat ou l'autorisation ne change qu'une fois la transaction diffusée, incluse dans un bloc et exécutée avec succès. Une transaction signée peut ne pas être envoyée au réseau. Il peut également être remplacé, expirer ou échouer pendant l'exécution. Si l'interface affiche 0 ETH, cela signifie simplement que la transaction n'inclut pas directement ETH. L'utilisateur peut toujours payer des frais de réseau (Gas), et l'opération contractuelle peut toujours créer une autorisation, transférer des jetons cryptographiques ou modifier un autre état chaîne de blocs.

Une opération d'autorisation signée (Permit) crée normalement un message qui peut être soumis ultérieurement. La création de la signature ne modifie pas le montant de l'autorisation sur le chaîne de blocs. Le message signé doit être soumis avec succès. A ce moment-là, sa valeur de séquence (nonce), le délai d'expiration et les autres conditions de validation doivent toujours être valides. Ce n'est qu'alors que l'autorisation pourra être enregistrée sur le chaîne de blocs. Une fois l'autorisation entrée en vigueur, la partie agréée (Spender) peut ensuite utiliser l'autorisation dans le cadre de ses règles, du montant approuvé et du solde du compte. Pour les risques liés au Autorisations à longue durée de vie, voir Qu'est-ce que Unlimited Approval ?.

Un échange crypto-jeton (Swap) peut nécessiter seulement deux actions : connecter le portefeuille et signer une transaction. Dans d'autres cas, le DApp peut d'abord demander une action distincte. Par exemple, il peut demander à l'utilisateur de signer un message connectez-vous. Il peut demander à l'utilisateur de signer une transaction chaîne de blocs qui exécute la fonction approbation (approve). Ou il peut demander à l'utilisateur de signer un message d'autorisation (Permit). Si le compte accorde déjà suffisamment d'autorisations de dépenses, le DApp ne demande normalement pas de nouvelle autorisation. Un échange qui utilise l'actif natif du réseau au lieu d'un ERC-20 jeton ne nécessite normalement pas d'autorisation de dépense ERC-20. Ne jugez pas la sécurité par le nombre de marches ; examinez chaque invite en tant que demande distincte.

La déconnexion du site Web du portefeuille met uniquement fin à la connexion locale. Cela ne modifie pas une autorisation déjà enregistrée sur le chaîne de blocs. Pour savoir où les Autorisations sont stockés, combien de temps ils restent valides et comment fonctionne la révocation, consultez La déconnexion d’une DApp révoque-t-elle les autorisations existantes ?.

Pour une liste de contrôle plus complète, voir Que dois-je vérifier avant de confirmer une transaction sur un portefeuille matériel ?. Pour des informations lisibles sur les transactions et les risques hameçonnage, voir Comment SignGuard et Clear Signing protègent-ils contre le phishing Web3 ?.

Principe clé : Un portefeuille matériel peut protéger les clés de signature, mais il ne peut pas décider si un site Web, un message, une transaction ou une autorisation correspond à la véritable intention de l'utilisateur.