Aller au contenu
Financial Context Wiki

Une signature de délégation de gouvernance est-elle sûre ?

Découvrez ce qu'autorise une signature de délégation de gouvernance, comment la séparation de domaine EIP-712, les nonces et l'expiration réduisent le risque de rejeu, et les points à vérifier avant de signer.

Mis à jour

À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Les transactions et signatures d’actifs numériques peuvent entraîner des pertes irréversibles.

Réponse directe

Une signature de délégation de gouvernance n’est sûre que si le message décodé correspond exactement à la délégation voulue et si le contrat de gouvernance applique une protection adéquate contre le rejeu. Dans une conception classique de jeton de vote, la délégation change la personne qui peut exercer le pouvoir de vote du signataire ; elle ne transfère pas le solde de jetons et n’accorde aucune autorisation de dépense. Le contrat déployé reste toutefois l’autorité ultime quant à l’effet réel de la signature.

Une signature hors chaîne peut être soumise par un relais : le signataire peut donc ne payer aucun gas tout en autorisant une modification d’état sur la chaîne. Considérez la signature comme une instruction exécutable, et non comme une connexion ou une demande anodine de connexion du portefeuille.

Fonctionnement

Un flux delegateBySig courant comporte quatre étapes :

  1. L’application prépare des données typées EIP-712 contenant l’adresse d’un délégué, un nonce et une expiration.
  2. Le portefeuille signe un condensat lié au message typé et à un domaine EIP-712.
  3. N’importe quel compte peut transmettre la signature au contrat du jeton ou de gouvernance.
  4. Le contrat récupère ou valide le signataire, vérifie le nonce et l’expiration, puis enregistre le nouveau délégué.

Le domaine EIP-712 peut inclure name, version, chainId et verifyingContract. Ces champs distinguent des messages qui seraient autrement identiques entre applications, versions, réseaux et contrats. EIP-712 ne fournit explicitement aucune protection contre le rejeu : le contrat doit consommer un nonce ou rendre chaque autorisation à usage unique par un autre moyen, et une expiration ne limite la période de validité que si le contrat la vérifie effectivement.

Avant de signer, vérifiez tous les éléments suivants au moyen d’une interface de gouvernance officielle, de la documentation ou de données contractuelles vérifiées de manière indépendante :

  • primaryType et les noms des champs décrivent une délégation, et non un permis, un transfert de jetons, un ordre ou une autorisation de gestion de compte.
  • verifyingContract est bien le contrat de jeton ou de gouvernance prévu sur le chainId actif.
  • delegatee est l’adresse du représentant choisi, contrôlée dans son intégralité plutôt qu’au moyen d’un nom affiché.
  • nonce correspond au nonce actuel du contrat pour le signataire, et expiry est suffisamment proche pour le flux prévu.
  • Le portefeuille affiche l’intégralité des données typées. Refusez toute demande de signature aveugle ou tout condensat brut dont vous ne pouvez pas reproduire indépendamment la signification.

Les implémentations diffèrent. Le contrat COMP de Compound, par exemple, hache le délégué, le nonce et l’expiration, exige que le nonce corresponde à celui enregistré pour le signataire, incrémente ce nonce et rejette une signature expirée. L’interface Votes d’OpenZeppelin expose également delegateBySig, la gestion des nonces et les contrôles d’expiration. Ne supposez pas qu’une fonction portant un nom similaire dans un autre contrat offre les mêmes protections.

Exemple

Mira souhaite déléguer 10,000 voix à l’adresse 0xAB...1234. Son portefeuille affiche primaryType: Delegation, le contrat vérifié du jeton de vote, l’identifiant de la chaîne active, delegatee: 0xAB...1234, le nonce actuel et une expiration dans 20 minutes. Après avoir contrôlé l’adresse auprès d’une deuxième source fiable, elle signe ; un relais soumet le message et le contrat émet l’événement de délégation. Son solde de jetons reste dans son portefeuille, tandis que le représentant reçoit le pouvoir de vote associé selon les règles du protocole.

Modifions maintenant un seul détail : la page demande primaryType: Permit et désigne un opérateur autorisé à dépenser les jetons, ou bien verifyingContract correspond à un contrat sans rapport. Il ne s’agit pas de la même instruction de délégation. Elle peut autoriser la dépense de jetons, même si le bouton de la page porte la mention « Déléguer » et que le signataire ne paie aucun gas. Mira doit la refuser.

Risques et mesures de contrôle

  • Mauvais délégué : l’empoisonnement d’adresse, les messages privés et les noms d’affichage copiés peuvent substituer à delegatee une adresse contrôlée par un attaquant. Vérifiez l’adresse complète au moyen d’une proposition officielle ou du profil du délégué.
  • Mauvaise action : une interface malveillante peut demander un autre type EIP-712, tel qu’un permis. Lisez primaryType, chaque champ et le contrat de vérification ; le libellé du bouton n’apporte aucune sécurité.
  • Rejeu : des contrôles de nonce faibles ou absents peuvent permettre la réutilisation d’une signature. Un domaine qui n’est pas lié à la chaîne ou au contrat prévus peut aussi permettre son utilisation dans un contexte non souhaité. Vérifiez le code de validation réel, car EIP-712 seul ne protège pas contre le rejeu.
  • Signature à longue durée de vie : un message signé mais inutilisé peut rester exécutable jusqu’à son expiration ou jusqu’à l’invalidation de son nonce. Préférez une expiration proche, ne publiez pas la signature et, si une annulation est nécessaire, utilisez uniquement la méthode d’invalidation documentée par le protocole.
  • Affichage trompeur du portefeuille : des champs tronqués, un domaine inconnu ou une signature aveugle empêchent tout consentement éclairé. Annulez et examinez la demande de données typées avec un portefeuille ou un décodeur qui affiche le message complet.
  • Différences propres aux comptes de contrat : les portefeuilles de contrats intelligents peuvent valider les signatures via ERC-1271, dont la validité peut dépendre de l’état et de la politique d’autorisation du portefeuille. Confirmez la compatibilité du portefeuille et du contrat de gouvernance au lieu de supposer une récupération propre aux EOA.
  • Conséquences sur la gouvernance : la délégation peut concentrer le pouvoir de vote ou permettre à un délégué indigne de confiance de voter contre vos intérêts. Examinez son identité, son historique de vote, ses conflits d’intérêts et la procédure de redélégation du protocole.

Après la soumission, vérifiez la transaction sur la bonne chaîne : contrôlez le contrat de destination, la fonction décodée, le signataire récupéré ou indiqué par l’événement, le nouveau délégué et le nonce. Le succès de la transaction du relais prouve uniquement que le contrat a accepté l’appel ; il ne prouve pas que l’intention signée était sûre.

Si vous avez signé sans avoir constaté de soumission, cessez de partager la signature et consultez la procédure documentée par le protocole pour annuler ou invalider le nonce. Si une délégation non souhaitée a été exécutée, redéléguez via le contrat officiel et vérifiez le nouvel état. Une délégation seule ne crée normalement pas d’autorisation de dépense de jetons : ne confondez donc pas redélégation et révocation d’autorisations. Si vous avez également signé un permis ou exposé une phrase de récupération ou une clé privée, traitez la situation comme un incident de portefeuille distinct et plus grave.

Idées reçues courantes

  • « Sans gas, il n’y a pas d’autorisation. » Le relais peut payer le gas tandis que la signature fournit l’autorisation du signataire.
  • « EIP-712 sécurise toutes les signatures. » La norme standardise le hachage des données typées et la séparation de domaine, mais elle n’inclut aucune protection contre le rejeu et ne peut pas vérifier que l’utilisateur voulait effectuer l’action affichée.
  • « La délégation transfère mes jetons. » Une délégation de vote classique déplace ou attribue le pouvoir de vote, et non la propriété des jetons ; seuls le contrat déployé et le message décodé peuvent toutefois établir l’effet réel.
  • « Je peux toujours révoquer une signature hors chaîne. » Il n’existe aucune transaction universelle de révocation des signatures. L’expiration, la consommation ou l’invalidation du nonce et la redélégation sont des mécanismes propres à chaque contrat.
  • « Changer de délégué efface les votes précédents. » La redélégation modifie le pouvoir de vote futur ou actuel selon les règles du protocole ; elle peut ne pas annuler les votes déjà exprimés ni modifier les instantanés historiques.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...