La norme de signature claire de la Fondation Ethereum vise à éliminer le risque de signature aveugle sur Ethereum

En matière de sécurité cryptographique, le maillon le plus faible n'est souvent pas la cryptographie elle-même, mais l'approbation. Pendant des années, de nombreux utilisateurs d'Ethereum ont été invités à confirmer des transactions qui apparaissaient comme des calldata illisibles, des avertissements génériques ou des invites de messages opaques. Ce schéma est largement connu sous le nom de Signature Aveugle : autoriser quelque chose que vous ne pouvez pas vérifier de manière significative sur l'écran de signature.

Pour combler cette faille systémique en matière de sécurité de l'UX, l'écosystème Ethereum s'est rallié à la Signature Claire — une approche ouverte conçue pour faire de "Ce que vous voyez, c'est ce que vous signez" (WYSIWYS) la norme. Cette initiative est supervisée par l'effort Sécurité à mille milliards de dollars (1TS) de la Fondation Ethereum, qui identifie explicitement la signature aveugle et l'incertitude des transactions comme un obstacle critique à l'adoption pour la prochaine phase de croissance d'Ethereum. Vous pouvez en savoir plus sur 1TS dans l'annonce de la Fondation Ethereum sur son blog concernant cette initiative et sur le travail plus large relatif à la sécurité dans le hub officiel Sécurité à mille milliards de dollars : Annonce de l'initiative Sécurité à mille milliards de dollars et Aperçu des défis de sécurité.

Pourquoi la "Signature Aveugle" est devenue un risque de premier plan en 2025-2026

Les transactions Ethereum ne se limitent plus à "envoyer de l'ETH". Les demandes de signature d'aujourd'hui incluent régulièrement :

• Des approbations DeFi avec des paramètres complexes (y compris des allocations illimitées)
• Des opérations multisig et des actions de compte basées sur des contrats
• Des flux inter-chaînes et L2 dont les résultats peuvent ne pas être évidents au moment de la signature
• Des messages de données typées EIP-712 qui peuvent encoder des permissions puissantes

Les attaquants se sont adaptés en conséquence. De nombreux incidents à fort impact présentent une forme familière : un utilisateur (ou un opérateur) approuve quelque chose qui semble bénin dans une interface utilisateur web, mais la charge utile réelle signée autorise autre chose.

Un exemple largement discuté est l'incident Bybit, où les analyses soulignent comment un signataire peut être induit en erreur lorsque l'expérience de signature ne communique pas de manière fiable ce qui est réellement autorisé. Pour une analyse technique de la façon dont ces décalages entre l'interface utilisateur et la signature peuvent se traduire par des issues catastrophiques, consultez l'analyse technique de NCC Group.

La leçon clé est simple : une invite de portefeuille qui ne peut pas être lue ne peut pas être auditée par un humain, ce qui rend l'ingénierie sociale considérablement moins coûteuse que le piratage de la cryptographie.

Signature Claire : Une couche d'affichage conçue pour la vérification humaine

La Signature Claire ne modifie pas la sémantique des transactions Ethereum. Au lieu de cela, elle ajoute une couche d'interprétation standardisée et vérifiable afin que les portefeuilles puissent afficher :

• Une étiquette d'action structurée (par exemple, "Échanger", "Staker", "Révoquer l'allocation")
• Des montants lisibles par l'homme avec les décimales et métadonnées de jeton correctes
• Des informations claires sur le contrepartie / le destinataire
• Un contexte qui aide les utilisateurs à reconnaître le protocole et l'intention

L'initiative Signature Claire est documentée publiquement sur Signature Claire : Voyez ce que vous signez, avec un aperçu pratique du problème et de l'approche sur Des calldata bruts à l'intention lisible.

Le bloc de construction essentiel : les descripteurs ERC-7730

Au centre de la poussée de standardisation se trouve ERC-7730, un format structuré qui permet aux protocoles (et à d'autres contributeurs) de définir comment les interactions de contrat spécifiques ou les types de messages doivent être affichés à un signataire.

En termes simples, ERC-7730 transforme les octets bruts en un "modèle d'explication de transaction" cohérent. Les portefeuilles peuvent ensuite appliquer ce modèle au moment de la signature pour afficher un écran de confirmation que les utilisateurs peuvent réellement comprendre.

Vous pouvez consulter la spécification ici : ERC-7730: Format de signature claire de données structurées. Notamment, ERC-7730 est conçu pour fonctionner avec les modèles Ethereum modernes, y compris les flux de signature de données typées (voir EIP-712) et les opérations utilisateur d'abstraction de compte (voir EIP-4337) comme référencé dans la spécification ERC-7730.

Soumission ouverte, examen indépendant, confiance locale au portefeuille

Un système mondial de descripteurs soulève une question évidente : et si quelqu'un soumettait des métadonnées trompeuses ?

La Signature Claire aborde cela en séparant la publication de la confiance :

1. Les descripteurs peuvent être rédigés et soumis ouvertement (afin que la couverture puisse dépasser une petite liste blanche).
2. Des signaux d'examen indépendant peuvent être ajoutés par-dessus via des attestations.
3. Les portefeuilles restent souverains : chaque portefeuille choisit les sources et les signaux d'examen auxquels il fait confiance, et comment il se comporte lorsque les métadonnées sont manquantes ou non fiables.

Cette conception est mise en évidence dans le modèle de gouvernance du projet : Principes de gouvernance de la Signature Claire.

Côté implémentation, l'écosystème standardise également la manière dont les métadonnées d'intégrité / de vérification peuvent être attachées aux descripteurs, afin que les portefeuilles puissent prendre de meilleures décisions de confiance sans centraliser le contrôle. Un exemple est la discussion sur la vérification d'intégrité autour des descripteurs ERC-7730 : Discussion sur la vérification d'intégrité ERC-8176.

Pourquoi les "métadonnées séparées de la transaction" sont importantes

Un choix architectural subtil mais important est que les métadonnées de la Signature Claire (descripteurs, attestations, entrées de registre) sont séparées de la transaction elle-même.

Cette séparation présente deux avantages majeurs :

• Compatibilité ascendante : les contrats et dApps existants peuvent bénéficier du support de la signature claire sans avoir à être redéployés.
• Résilience future : à mesure que l'UX d'Ethereum évolue (abstraction de compte, appels par lots, nouveaux types de signatures), la couche d'affichage peut évoluer sans affecter la validité de la transaction.

Ce cadrage "ajouter une couche d'affichage vérifiable" est au cœur de l'approche décrite dans l'aperçu de la Signature Claire : Aperçu de l'architecture de la Signature Claire.

Ce que cela change pour les utilisateurs quotidiens

La Signature Claire n'est pas un bouclier magique, mais elle augmente considérablement le coût de nombreuses attaques courantes en réduisant l'ambiguïté au moment précis où l'approbation a lieu.

À mesure que l'adoption croît, les utilisateurs devraient s'attendre à un flux de travail par défaut plus sain :

• Si une transaction est bien décrite et révisée indépendamment, les portefeuilles peuvent afficher un écran d'intention clair et structuré.
• Si les métadonnées sont manquantes ou non fiables, les portefeuilles peuvent présenter des avertissements explicites et des solutions de repli plus sûres (au lieu d'entraîner silencieusement les utilisateurs à cliquer sur des invites illisibles).

En attendant, les meilleures pratiques du côté utilisateur restent importantes :

• Traitez toute demande de signature illisible comme un risque élevé, en particulier les approbations et les demandes de signature.
• Privilégiez les flux où le périphérique de signature affiche des détails significatifs (montants, destinataires, actions).
• Examinez et révoquez régulièrement les allocations de jetons lorsqu'elles ne sont plus nécessaires.

Ce que les développeurs devraient faire ensuite (dApps, Protocoles et Équipes de Portefeuilles)

Si vous développez sur Ethereum, la Signature Claire fait partie de la base de sécurité — tout comme les contrats vérifiés, les audits et la conception d'allocations sécurisées sont devenus attendus au fil du temps.

Étapes pratiques :

• Protocoles / dApps : publiez des descripteurs ERC-7730 pour les contrats principaux et les flux à volume élevé, et maintenez-les à jour à mesure que les contrats évoluent (en particulier les mises à niveau de proxy).
• Équipes de sécurité : traitez les descripteurs comme des artefacts de sécurité — ils peuvent prévenir les pertes, mais des descripteurs incorrects peuvent également induire les utilisateurs en erreur.
• Équipes de portefeuilles : implémentez la consommation d'ERC-7730 ainsi qu'une politique de confiance claire pour les registres et les attestations.

Le site Signature Claire comprend un chemin concret de soumission et d'implémentation ici : Implémenter ERC-7730 (Guide de développement).

La place de OneKey dans l'avenir du "Voyez ce que vous signez"

La Signature Claire s'aligne sur ce que les portefeuilles matériels sont censés fournir : un environnement de signature de confiance où l'utilisateur peut vérifier l'intention avant d'autoriser des actions irréversibles.

À mesure que des normes ouvertes comme ERC-7730 mûrissent, les portefeuilles peuvent converger vers une expérience de signature plus cohérente et plus sûre dans tout l'écosystème, réduisant ainsi le nombre de situations où les utilisateurs sont contraints à la signature aveugle juste pour "faire passer la transaction".

Si votre modèle de menace inclut le phishing, le compromis frontal ou les activités DeFi de grande valeur, l'utilisation d'un portefeuille matériel tel que OneKey — et la priorisation des flux qui fournissent des confirmations lisibles par l'homme et structurées — est une étape pratique vers des opérations on-chain plus sûres.