ERC-7779 : Le nouveau standard est en ligne

/14 oct. 2025

Points clés

• L'ERC-7779 introduit des approbations de transaction plus sûres et granulaires.

• Les utilisateurs bénéficieront de confirmations plus claires grâce à l'encodage de métadonnées.

• L'intégration de l'ERC-7779 dans les portefeuilles et dapps est essentielle pour une expérience utilisateur améliorée.

• La rétrocompatibilité avec les standards existants est une priorité pour les développeurs.

Le rythme du développement des standards Ethereum ne ralentit jamais. Avec l'ERC-7779 désormais en ligne, les utilisateurs, les développeurs et les fournisseurs de portefeuilles se posent la même question : qu'est-ce qu'un nouvel ERC qui passe en production change réellement pour l'expérience quotidienne de la crypto et de la DeFi ? Cet article explique pourquoi les nouveaux ERC sont importants, comment ils parviennent en production, les implications pratiques pour les approbations et l'expérience utilisateur des transactions, et ce que les utilisateurs de OneKey peuvent attendre à mesure que les écosystèmes adoptent les dernières interfaces.

Premièrement, un rapide rappel : qu'est-ce qu'un ERC ?

Un ERC (Ethereum Request for Comments) est un standard de niveau application, piloté par la communauté, qui définit le comportement des contrats et des applications afin qu'ils puissent interagir de manière fiable (pensez à ERC‑20 ou ERC‑721). Les ERC émergent par le biais du processus EIP, de la brouillon à la finale, avec discussion ouverte et revue par les pairs. Si vous êtes nouveau sur la façon dont les standards sont créés, le processus EIP est documenté en détail dans la spécification officielle. Voir le cycle de vie des EIP et leur justification dans les documents de standards Ethereum et le méta-processus des EIP :

Apprenez comment fonctionnent les standards Ethereum sur le portail officiel des développeurs (voir Standards Ethereum)
Plongez dans le cycle de vie des EIP et les définitions de statut (voir EIP‑1)

Pour maintenir l'alignement entre les portefeuilles, les dapps et les Layer 2, les ERC s'appuient souvent sur des EIP fondamentaux tels que :

EIP‑712 pour la signature de données structurées et lisibles par l'homme (voir EIP‑712)
EIP‑165 pour la détection d'interface et les vérifications de compatibilité (voir EIP‑165)
EIP‑2771 pour les méta-transactions via des forwarders de confiance (voir EIP‑2771)

Ce que l'ERC‑7779 vise à améliorer

Bien que chaque nouvel ERC soit unique, les standards récents tendent vers deux objectifs :

Des approbations et des permissions de transaction plus sûres et plus granulaires. Les utilisateurs souhaitent autoriser précisément ce qu'une dapp peut faire, pendant combien de temps, et avec des confirmations claires sur l'appareil. Cette direction suit les leçons tirées du flux approve/transferFrom de l'ERC‑20 et l'évolution vers des signatures de type "permit". Voir l'historique des pièges de approve et les modèles plus sûrs (voir notes sur approve d'OpenZeppelin).
Une meilleure expérience utilisateur des portefeuilles grâce à un contexte plus riche. Les standards encodent de plus en plus de métadonnées afin que les portefeuilles puissent afficher des confirmations compréhensibles plutôt que du bytecode opaque, conformément aux conventions de signature lisibles par l'homme. Lisez les données structurées typées pour des confirmations plus sûres (voir EIP‑712).

En pratique, l'ERC‑7779 "en ligne" signifie que les premiers adoptants (dapps, SDK et portefeuilles) ont commencé à intégrer une interface conçue pour offrir des approbations plus sûres, un meilleur décodage et moins de signatures confuses, sans rompre la compatibilité avec les tokens et protocoles existants.

Pourquoi c'est important maintenant

Le calendrier est significatif. Les récentes mises à niveau d'Ethereum ont réduit les frais L2 et élargi l'activité on-chain, tandis que l'abstraction de compte et les nouveaux modèles de portefeuilles arrivent à maturité :

Dencun sur le mainnet a débloqué une disponibilité des données moins chère pour les rollups et a stimulé l'adoption des L2 (voir annonce Dencun)
L'abstraction de compte passe de la théorie à la mise en œuvre, permettant des portefeuilles programmables (voir EIP‑4337)
Un modèle de transaction proposé (EIP‑7702) introduit de nouvelles façons d'autoriser des actions avec des compromis améliorés en termes d'expérience utilisateur et de sécurité (voir EIP‑7702)
La feuille de route à long terme d'Ethereum continue de privilégier la scalabilité et la sécurité, ce qui affecte l'évolution des portefeuilles et des standards (voir Feuille de route Ethereum)

Dans ce contexte, tout ERC qui renforce la sécurité des approbations et améliore la clarté des confirmations peut avoir un impact disproportionné dans le monde réel.

Pour les utilisateurs de tous les jours : ce qui change dans votre portefeuille

Des confirmations plus claires, moins de signatures à l'aveugle. Les portefeuilles implémentant les métadonnées de type ERC‑7779 peuvent vous montrer ce qu'un contrat demande, et pourquoi, en utilisant des données structurées lorsque cela est possible (voir EIP‑712).
Des permissions plus granulaires. Attendez-vous à ce que des contrôles par fonction ou par montant deviennent plus courants à mesure que les écosystèmes convergent vers des flux de type "permit" et des bonnes pratiques (voir extension de permit ERC‑20 EIP‑2612 et modèles Permit2).
Une gestion plus facile des allowances. Continuez à utiliser un scanner d'allowances pour repérer et révoquer les approbations risquées, en particulier lors de la migration vers de nouveaux standards (voir Etherscan Token Approval Checker).
Une charge cognitive réduite sur les L2. À mesure que les standards adoptent des interfaces cohérentes, votre expérience devient plus uniforme sur les réseaux.

Outils et références utiles :

Etherscan Token Approval Checker pour les révocations et la surveillance
Flux de type "permit" et modèles de révocation adoptés dans les DEX modernes (voir aperçu Permit2)
Guide d'OpenZeppelin sur les approbations ERC‑20 et les mises en garde de sécurité (voir notes sur approve d'OpenZeppelin)

Pour les développeurs : guide d'intégration

La rétrocompatibilité avant tout. Maintenez la compatibilité ERC‑20 tout en superposant de nouvelles interfaces derrière la détection EIP‑165 afin que les anciens portefeuilles ne soient pas affectés (voir EIP‑165).
Préférez les données typées aux octets bruts. Déplacez les signatures destinées aux utilisateurs vers EIP‑712 lorsque c'est possible pour permettre une signature claire dans les portefeuilles matériels et des confirmations de risque améliorées (voir EIP‑712).
Envisagez les flux "permit". Si votre cas d'utilisation accorde des permissions de dépense, adoptez des modèles de type "permit" (EIP‑2612) ou des bibliothèques éprouvées qui réduisent la surface d'attaque des approbations (voir EIP‑2612 et aperçu Permit2).
Soutenez les méta-transactions lorsque cela est approprié. Avec EIP‑2771, permettez les flux sponsorisés par le gaz tout en maintenant les protections contre le rejeu et la séparation des domaines (voir EIP‑2771).
Utilisez des bibliothèques auditées. Appuyez-vous sur des primitives et des interfaces maintenues plutôt que de créer les vôtres (voir OpenZeppelin Contracts).
Modélisez les menaces pour les nouveaux chemins de code. Tout nouveau hook ou surface de permission introduit des risques potentiels de réentrance et d'abus d'approbation – cartographiez-les aux catégories SWC connues et testez minutieusement (voir SWC Registry).

Références développeurs :

EIP‑2612 (permit pour ERC‑20)
Aperçu Permit2 et bonnes pratiques pour les approbations
OpenZeppelin Contracts 5.x pour les implémentations conformes aux standards
SWC Registry pour les classes de vulnérabilités

Intégration des portefeuilles et considérations matérielles

Lorsqu'un nouvel ERC est déployé, la sécurité réelle des utilisateurs dépend de la façon dont les portefeuilles l'implémentent :

Décodage précis des méthodes : Les portefeuilles doivent décoder les interfaces via EIP‑165 lorsque cela est applicable et afficher l'intention lisible par l'homme au lieu des sélecteurs de fonction.
Signature claire sur l'appareil : Lorsque des données structurées sont disponibles, les portefeuilles matériels doivent afficher des champs lisibles par l'homme afin que les utilisateurs puissent vérifier ce qu'ils signent (voir EIP‑712).
Simulation et indicateurs de risque : La simulation avant signature, les différences d'allowances et les indices de provenance du contrat aident à détecter les approbations malveillantes avant qu'elles n'atterrissent on-chain.

Ce que les utilisateurs de OneKey peuvent attendre :

Signature axée sur les standards : OneKey prend en charge les standards Ethereum grand public, y compris la signature de données structurées, vous aidant à éviter les confirmations de bytecode ambiguës (voir EIP‑712).
Revue transparente des transactions : L'application OneKey affiche les détails de la méthode, de l'actif et du montant avant que vous ne confirmiez sur l'appareil.
Ethos open-source : Avec une base de code ouverte, les examinateurs indépendants et la communauté peuvent examiner comment les nouveaux standards sont intégrés – ce qui est vital lorsque les ERC introduisent de nouveaux chemins de permission.

À mesure que l'adoption de l'ERC‑7779 s'étend, OneKey continuera de privilégier une signature claire et la compatibilité sur les réseaux L1 et L2 tout en maintenant des pratiques de sécurité rigoureuses.

Hygiène de sécurité : les essentiels ne changent pas

Utilisez des allowances par dapp, minimales chaque fois que possible ; évitez les allowances illimitées sauf nécessité absolue.
Révocquez périodiquement les allowances obsolètes, surtout après avoir essayé de nouvelles dapps ou migré vers de nouveaux standards (utilisez Etherscan Token Approval Checker).
Traitez les nouveaux flux comme de nouvelles surfaces d'attaque. Les kits de phishing évoluent pour imiter les nouvelles confirmations de portefeuille – vérifiez les domaines, les adresses de contrat et les identifiants de chaîne.
Privilégiez les contrats et les bibliothèques auditées et bien entretenues (voir OpenZeppelin Contracts) et comprenez les classes courantes de faiblesses des smart contracts (voir SWC Registry).

Perspectives

L'ERC‑7779 fait partie d'un cycle plus large de mise à niveau des portefeuilles et de l'UX couvrant l'abstraction de compte (voir EIP‑4337), des modèles d'autorisation de transaction proposés (voir EIP‑7702) et la cadence régulière des améliorations réseau sur la feuille de route d'Ethereum. À mesure que les standards mûrissent et convergent, les utilisateurs devraient voir moins de confirmations confuses, des approbations plus sûres par défaut et une expérience plus cohérente sur les L2.

Si vous gérez une valeur on-chain significative, envisagez d'associer votre portefeuille logiciel préféré à un portefeuille matériel. OneKey met l'accent sur la signature claire pour les standards comme EIP‑712, la transparence open-source et la compatibilité multi-chaînes – des garde-fous pratiques à mesure que de nouveaux ERC sont déployés et que la surface de transaction évolue.

Références et lectures complémentaires :