Comment mettre en œuvre EIP-712 pour la vérification sécurisée des signatures ?

Présentation de l'EIP-712 et objectif principal

1. EIP-712 définit une norme pour le hachage et la signature de données structurées typées dans les applications Ethereum.

2. Il permet aux portefeuilles d'afficher des champs de domaine et de message lisibles par l'homme au lieu de chaînes hexadécimales brutes lors des demandes de signature.

3. La spécification introduit la séparation des domaines via un hachage de séparateur de domaine , empêchant la relecture des signatures sur différentes dApps ou chaînes.

4. Chaque charge utile signée inclut une définition de type qui doit être explicitement déclarée avant la sérialisation et le hachage.

5. Cette structure garantit un codage déterministe, éliminant toute ambiguïté des champs facultatifs ou de l'ordre dynamique des tableaux.

Construction de séparateur de domaine

1. Le séparateur de domaine est calculé à l'aide de keccak256(encodeType(domainType) || encodeData(domainValue)) .

2. Les champs de domaine obligatoires incluent name , version , chainId , verifyContract et éventuellement salt .

3. Le champ de nom doit correspondre au nom de marque enregistré de la dApp, souvent vérifié par rapport aux métadonnées ENS ou contractuelles.

4. chainId applique la validité spécifique à la chaîne : les signatures générées sur Ethereum Mainnet ne sont pas valides sur Polygon ou Arbitrum sans recalcul.

5. Un séparateur de domaine incompatible entraîne un échec de la vérification de la signature même si toutes les autres entrées sont correctes.

Processus de codage des données typées

1. Chaque déclaration de type spécifie les noms de champs, les types et les dépendances imbriquées, par exemple Person(address wallet, string name) .

2. Les tableaux sont codés sous forme de hachages concaténés d'éléments individuels avec un préfixe de longueur, et non sous forme de pointeurs ou de références.

3. Les chaînes subissent une conversion d'octets UTF-8 avant le hachage ; aucune troncature ou normalisation n’est appliquée automatiquement.

4. Les champs d'adresse sont complétés par des zéros à 32 octets et traités comme des octets20 en interne avant le hachage.

5. Le résumé final combine le séparateur de domaine, le hachage de type principal et les données de message codées en une seule sortie keccak256 utilisée pour la signature ECDSA.

Modèles d'intégration front-end

1. Les portefeuilles modernes comme MetaMask exposent la méthode RPC eth_signTypedData_v4 , qui accepte les charges utiles JSON-RPC conformes à EIP-712.

2. Les développeurs doivent pré-déclarer tous les types dans les objets JavaScript avant d'invoquer la demande de signature : la génération de types dynamiques lors de l'exécution rompt la compatibilité.

3. Les bibliothèques telles que @ethersproject/hash fournissent des utilitaires pour calculer les séparateurs de domaine et les hachages typés côté client.

4. Les couches d'interface utilisateur doivent restituer chaque étiquette et valeur de champ exactement comme défini dans le schéma de type : tout écart confond les utilisateurs et mine la confiance.

5. Les charges utiles de signature ne doivent jamais être modifiées après la signature ; même les modifications d'espaces invalident la preuve cryptographique.

Mécanismes de vérification en chaîne

1. Les contrats intelligents vérifient les signatures à l'aide d' ecrecover avec le résumé reconstruit dérivé des paramètres d'entrée et des valeurs de domaine.

2. Les bibliothèques Solidity comme ECDSA.recover d'OpenZeppelin simplifient la logique de récupération mais nécessitent une reconstruction exacte du résumé correspondant au comportement du frontend.

3. Les paramètres de domaine transmis au contrat doivent être identiques à ceux utilisés lors de la signature : les discordances génèrent des adresses récupérables incorrectes.

4. Les données des messages doivent être désérialisées à l'intérieur du contrat en utilisant les mêmes définitions de type ; les écarts provoquent des inadéquations de hachage.

5. Les signatures vérifiées peuvent déclencher des actions critiques, notamment les transferts de jetons basés sur des permis, les propositions de gouvernance et le règlement des commandes hors chaîne.

Foire aux questions

Q : Les signatures EIP-712 peuvent-elles être réutilisées sur différents domaines avec des noms et des versions identiques ? R : Non. Même des différences mineures dans chainId ou verifyContract produisent des séparateurs de domaine distincts, rendant impossible la réutilisation entre domaines.

Q : Est-il prudent d'omettre le champ salt dans la structure du domaine ? R : Oui, l'omission est autorisée, mais cela réduit les garanties d'unicité lors du déploiement de contrats identiques sur des forks ou des réseaux de test.

Q : EIP-712 prend-il en charge les définitions de types récursifs ? R : Non. Les types circulaires ou autoréférentiels violent les exigences de codage déterministe et échoueront lors du calcul du hachage.

Q : Comment gérer les tableaux de longueur variable dans les définitions de type EIP-712 ? R : Utilisez une syntaxe comme Person[] people ; l'encodeur calcule automatiquement la longueur du tableau et hache chaque élément individuellement avant de concaténer.