Faire accepter une proposition d’ERC, le standard Ethereum
EN 30 SECONDES
Un ERC est une règle publique pour les applications Ethereum, par exemple le comportement d’un jeton, proposée et relue au grand jour. Même une bonne idée peut s’enliser si son périmètre reste flou ou si les objections restent sans réponse. L’article suit le chemin de l’idée au statut Final et montre ce que les relecteurs attendent à chaque étape.
À RETENIR
- Rédiger la spécification n’est qu’une partie du travail. Les implémenteurs ont aussi besoin d’un périmètre clair, d’exemples utiles et de réponses à leurs objections.
- Gardez un périmètre étroit. Mieux vaut plusieurs ERC ciblés qu’un seul qui veut tout faire.
- Livrez une implémentation de référence avant la spécification, puis répondez à chaque commentaire de fond dans le fil. EIP-1 rend ce code facultatif ; je le recommande quand même.
- Une interface adoptée permet à des équipes indépendantes de construire des logiciels compatibles. Le statut Final et l’adoption réelle sont deux étapes distinctes.
Sur cette page
Le problème : de bonnes idées qui s’enlisent
EN BREF Une proposition enlisée reçoit un statut, et ce statut ne dit pas pourquoi tout s’est arrêté.
Source : EIP-1. Ce statut est réversible.
Source : le dépôt ethereum/ERCs sur GitHub.
Un ERC La catégorie d’EIP qui fixe des règles pour les applications, par exemple le comportement d’un jeton ou d’un wallet. ERC-20, le standard de jeton, en est un. Voir le glossaire peut porter une idée utile et ne jamais aboutir. Selon EIP-1, une proposition en Draft, Review ou Last Call, inactive depuis six mois ou plus, peut passer au statut Stagnant. Ce statut peut être annulé plus tard.
Ce que l’auteur peut améliorer est concret : bien cadrer la proposition, la rendre simple à construire et garder les questions ouvertes visibles.
Je suis l’un des cinq auteurs nommés d’ERC-3643 (T-REX, désormais Final). Je suis le premier des six auteurs d’ERC-6960 (Dual Layer Token, brouillon) et co-auteur d’ERC-7410 (mise à jour des autorisations de dépense, brouillon).
Je suis aussi co-auteur d’ERC-8203, deuxième sur trois. Il est encore à l’état de brouillon, dans la pull request ouverte n° 1614, et n’est pas Fusionné Ajouté sous forme de fichier au dépôt ethereum/ERCs. Un éditeur fusionne une proposition au statut Draft dès que son format est correct : fusionné ne veut pas dire Final. Voir le glossaire. Ces standards m’ont beaucoup appris sur la procédure.
Les mots à connaître avant la procédure
EN BREF Un ERC est une interface sur laquelle des équipes qui ne se connaissent pas peuvent construire. Les autres mots disent comment on la relit.
LES MOTS À CONNAÎTRE
- EIP
- Ethereum Improvement Proposal : un document de conception public qui propose un changement ou une règle commune pour Ethereum.
- ERC
- La catégorie d’EIP qui fixe des règles pour les applications, par exemple le comportement d’un jeton ou d’un wallet. ERC-20, le standard de jeton, en est un.
- Interface
- La liste des fonctions et des événements qu’un contrat doit exposer pour que d’autres programmes sachent exactement comment l’appeler.
- Éditeur EIP
- Un membre du groupe d’éditeurs qui vérifie qu’une proposition est bien formée, complète et cohérente. Selon EIP-1, les éditeurs ne jugent pas l’idée.
- Fusionné
- Ajouté sous forme de fichier au dépôt ethereum/ERCs. Un éditeur fusionne une proposition au statut Draft dès que son format est correct : fusionné ne veut pas dire Final.
- Last Call
- La dernière période de relecture avant le statut Final, en général 14 jours, ouverte quand l’auteur estime la spécification stable.
Comment un ERC passe de l’idée au statut Final, étape par étape
EN BREF EIP-1 fixe un parcours public unique pour chaque ERC : Idea, Draft, Review, Last Call, puis Final. Toutes les propositions n’arrivent pas au bout.
ÉTAPE PAR ÉTAPE
Étape 1 sur 7. Idea. EIP-1 recommande d’exposer d’abord le problème sur Ethereum Magicians. Le stade Idea n’est pas suivi dans le dépôt. Une absence de réponse n’est pas un refus formel.
- Idea EIP-1 recommande d’exposer d’abord le problème sur Ethereum Magicians. Le stade Idea n’est pas suivi dans le dépôt. Une absence de réponse n’est pas un refus formel.
- Draft Vous ouvrez une pull request dans le dépôt ethereum/ERCs. Un éditeur la fusionne au statut Draft dès que le format est correct.
- Review Vous demandez la relecture par les pairs. Les relecteurs cherchent les cas limites et les conflits. Aucune durée n’est fixée.
- Last Call Une fois la spécification stable, vous ouvrez la dernière période de relecture, en général 14 jours.
- Retour en Review Si le Last Call entraîne un changement normatif, c’est-à-dire une règle nouvelle pour les implémenteurs, la proposition repart en Review.
- Final Final, c’est le standard achevé. Ensuite, il ne devrait recevoir que des corrections d’erreurs et des clarifications non normatives.
- Stagnant Six mois sans activité en Draft, Review ou Last Call la font passer en Stagnant. Auteurs ou éditeurs peuvent la relancer.
Le processus officiel EIP-1 fixe ce chemin pour tout EIP Ethereum Improvement Proposal : un document de conception public qui propose un changement ou une règle commune pour Ethereum. Voir le glossaire. Le travail à chaque étape dépend de la proposition et du nombre de questions encore ouvertes.
Ce que contient le document
EN BREF Le document consigne la conception ; la discussion et le code vérifient si d’autres peuvent s’en servir.
Décrivez l’interface et le périmètre réels. Ne promettez que ce que la spécification définit.
Le problème concret que l’ERC résout.
Signatures de fonctions et événements, assez précis pour écrire du code.
Le compromis retenu et celui écarté. C’est ici que vivent les objections traitées.
Facultatif pour un ERC. Sans eux, je lis une spécification comme un texte dont personne n’a fait tourner le code.
Facultatif dans EIP-1, utile pour rendre le comportement testable.
EIP-1 rejette une proposition qui n’en a pas.
L’Interface La liste des fonctions et des événements qu’un contrat doit exposer pour que d’autres programmes sachent exactement comment l’appeler. Voir le glossaire est le cœur d’un ERC. C’est la partie sur laquelle d’autres équipes écriront leur code : elle doit être exacte.
Une implémentation de référence, c’est-à-dire un code d’exemple qui montre les règles en pratique, est facultative. Elle transforme un texte abstrait en quelque chose qu’un relecteur peut exécuter.
Un exemple concret : une proposition ciblée, une proposition fourre-tout
EN BREF Un relecteur peut tester une interface étroite ; face à une interface qui promet tout, il ne peut qu’attendre.
Les deux esquisses d’interface ci-dessous sont des exemples pédagogiques, et le scénario qui les entoure est fictif. Ce ne sont ni des standards complets ni du code de référence testé, et la première n’est pas l’interface réelle d’ERC-7410. La seconde illustre un périmètre large : ni une vraie proposition ni un résultat mesuré.
UN EXEMPLE CONCRET
Chiffres illustratifs
VALIDÉUne proposition ciblée : ajuster une autorisation de dépense
ENTRÉE
- Périmètre
- un seul problème : modifier une autorisation existante
- Interface
- 3 fonctions
- Code qui tourne
- oui, avec tests (supposés)
CE QUI SE PASSE
- Un relecteur lit vite toute l’interface.
- Elle pose une question précise : que se passe-t-il si la baisse dépasse l’autorisation ?
- L’auteur répond dans le fil et ajoute le cas limite à la section Rationale.
// Teaching sketch. One interface, one problem: adjust an existing
// allowance without a full re-approve. Not ERC-7410's real interface.
interface IAllowanceAdjust {
function increaseAllowance(address spender, uint256 addedValue) external returns (bool);
function decreaseAllowance(address spender, uint256 subtractedValue) external returns (bool);
function allowanceOf(address owner, address spender) external view returns (uint256);
}SORTIE
- Verdict
- relisible : publiez
À DÉCOUPERUne proposition fourre-tout : une interface pour tout
ENTRÉE
- Périmètre
- identité, vérifications multi-chaînes, paiements, clés, litiges
- Interface
- 6 fonctions montrées, 6 autres promises
- Code qui tourne
- aucun
CE QUI SE PASSE
- Un relecteur ne sait pas ce que chaque fonction doit faire, donc il ne peut pas la tester.
- Chaque sujet attire ses propres objections, venues d’experts différents.
- Éditeurs et relecteurs attendent que l’auteur la définisse.
// Teaching sketch. One interface trying to be a whole platform.
// Illustrative broad scope, not a real proposal or measured outcome.
interface IAgentEverything {
function authenticate(bytes calldata proof) external returns (bool);
function verifyAcrossChains(uint256 chainId, bytes calldata data) external returns (bool);
function settlePayment(address to, uint256 amount, bytes calldata terms) external;
function registerIdentity(address agent, bytes calldata credential) external;
function rotateQuantumKey(bytes calldata newKey) external;
function resolveDispute(bytes32 txId, bytes calldata evidence) external returns (bytes32);
// ...and six more the abstract promised
}SORTIE
- Verdict
- à découper
Ce qui rend un standard facile à relire
EN BREF Une proposition utile permet à un développeur de repérer le problème, de tester l’interface et de formuler une objection précise.
L’activité sur le forum ne prouve à elle seule ni la qualité ni l’adoption. Un long fil peut signaler une bonne idée ou une idée confuse.
Ce qui complique la relecture
EN BREF Des promesses larges, sans comportement défini, rendent chaque partie d’une proposition plus difficile à relire.
Un fil silencieux est un signal à creuser, pas la preuve qu’une idée ou un auteur a échoué. Demandez-vous si le problème est clair et si les bonnes équipes l’ont vu.
La relecture publique : répondre aux objections
EN BREF Faire accepter un ERC est un travail social : vous construisez un consensus, vous ne gagnez pas un débat.
ÉTAPE PAR ÉTAPE
Étape 1 sur 5. Objection. Quelqu’un dit que votre spécification est fausse. Ne la défendez pas tout de suite.
- Objection Quelqu’un dit que votre spécification est fausse. Ne la défendez pas tout de suite.
- Demander le cas Demandez le scénario où votre spécification casse. Faites décrire le cas, pas le désaccord.
- Cas limite D’expérience, c’est la plupart du temps un vrai cas limite auquel vous n’aviez pas pensé.
- Corriger Corrigez la spécification et remerciez la personne en public.
- Consigner Écrivez le compromis dans la section Rationale. Le relecteur suivant trouve la question déjà traitée.
Répondez à chaque commentaire de fond. Même quand vous refusez une suggestion, dites pourquoi. « Hors périmètre pour cet ERC », plus deux phrases de contexte, c’est une réponse complète. Le silence, non.
Trouvez des alliés dans l’écosystème. Si l’équipe d’un wallet veut implémenter votre ERC, dites-le dans le fil. D’expérience, cet intérêt concret fait plus avancer une proposition que la théorie : la spécification va se frotter à du vrai code.
Soyez patient sans avoir l’air absent. « Je prends deux semaines pour réfléchir à ces retours » ne se lit pas du tout comme un silence. Un simple point d’avancement fait la différence.
Menez la relecture comme un projet. Consultez votre fil chaque semaine et répondez à tout ce qui date de plus d’une semaine. S’il se tait pendant un mois, publiez un résumé et demandez quelles objections restent.
Ma méthode après trois ERC intégrés au dépôt
EN BREF Ce que je fais autrement aujourd’hui, après ERC-3643, ERC-6960 et ERC-7410.
Commencer par le problème, pas la solution
Avant toute interface, écrivez deux paragraphes sur le cas concret où les standards actuels échouent. Si vous n’y arrivez pas, l’ERC n’est pas prêt.
Livrer l’implémentation de référence avant la spécification
Mon travail sur la suite T-REX et OnchainID m’a donné le contexte d’implémentation d’ERC-3643. Validez la conception sur un cas réel avant de déclarer son interface stable.
Trouver au moins trois équipes qui en ont besoin
Avant de publier, contactez en privé des équipes du domaine. Sans trois réponses « oui, on a ce problème », réfléchissez encore.
Un ERC, un problème d’interface
ERC-3643 définit un cadre de jetons à accès contrôlé. ERC-6960 définit des soldes à deux niveaux. ERC-7410 traite la mise à jour des autorisations de dépense. Aucun ne remplace le reste d’une application.
Co-écrire quand les domaines se recoupent
J’ai conçu une couche de conformité et une structure de jeton à plusieurs niveaux, et j’ai quand même cherché des co-auteurs pour les angles morts.
Traiter les objections comme des relectures
Suivez à chaque fois la boucle des objections ci-dessus. C’est ce qui raccourcit le cycle de relecture.
Pourquoi un standard survit à une fonctionnalité
EN BREF Une fonctionnalité vit dans votre code ; un ERC adopté vit dans chaque base de code qui s’appuie dessus.
Une fonctionnalité livrée
Un ERC adopté
ERC-3643 est arrivé au statut Final parce que nous avons fait le travail ingrat : fils de forum, révisions de la spécification, réponses patientes aux relecteurs sceptiques. Rien de tout cela ne se voit dans le document.
La procédure récompense ceux qui visent juste et restent là, bien après l’élan du début. Éditeur EIP Un membre du groupe d’éditeurs qui vérifie qu’une proposition est bien formée, complète et cohérente. Selon EIP-1, les éditeurs ne jugent pas l’idée. Voir le glossaire vérifient la forme et la complétude. C’est la communauté qui décide du sort de l’idée.
Vous avez une idée qui pourrait régler un problème précis du protocole ? La procédure ERC en vaut la peine. Mais sachez que la politique et le lien avec la communauté font le gros du travail. En comparaison, écrire la partie technique est facile.
Vous préférez bâtir sur un standard existant plutôt qu’écrire le vôtre ? J’ai comparé ERC-3643, ERC-1400 et CMTAT dans l’épisode suivant.
TESTEZ-VOUS
Un éditeur vient de fusionner la première pull request de votre proposition dans le dépôt ethereum/ERCs. Pouvez-vous dire que votre standard est accepté ?
Voir la réponse
TESTEZ-VOUS
Pendant le Last Call, un relecteur signale une coquille dans un commentaire de code. Un autre trouve un bug qui vous oblige à changer la signature d’une fonction. Lequel renvoie la proposition en Review ?
Voir la réponse
Trois idées à garder
- Avant de publier : décrivez le problème en deux paragraphes, trouvez au moins trois équipes qui l’ont, et tenez-vous à un seul problème d’interface.
- Construisez du code qui tourne avant de déclarer l’interface stable. EIP-1 rend la section « implémentation de référence » facultative ; je construis quand même le code en premier, car il révèle les zones floues.
- Une fois le fil ouvert : consultez-le chaque semaine, répondez à chaque commentaire de fond et consignez les objections traitées dans la section Rationale. Six mois de silence en Draft, Review ou Last Call peuvent faire passer la proposition au statut Stagnant.
ÉTAPE SUIVANTEERC-3643, ERC-1400 ou CMTAT
Sources : EIP-1, ERC-3643, ERC-6960, ERC-7410, ERC-8203 (brouillon, PR ouverte n° 1614, non fusionnée).
FAQ
Aucun délai n’est promis. Une proposition passe par les statuts Draft, Review et Last Call avant Final. Le Last Call dure en général 14 jours, et un changement normatif la renvoie en Review. Prévoyez plusieurs cycles de relecture, pas une date.
Non. EIP-1 rend la section « implémentation de référence » facultative. Je recommande quand même du code qui tourne : il révèle les zones floues de l’interface et donne aux relecteurs quelque chose à tester. Il ne garantit pas l’acceptation.
Un EIP (Ethereum Improvement Proposal) est la catégorie générale. Les ERC (Ethereum Request for Comments) sont les EIP qui fixent des règles pour les applications : jetons, contrats, wallets. Vous définissez un standard de jeton ou une interface de contrat ? Vous écrivez un ERC.
Oui. EIP-1 demande une liste d’auteurs, sans exiger de co-auteur. Pour une proposition complexe qui touche plusieurs domaines, des co-auteurs se partagent la relecture et repèrent les angles morts. Pour une proposition étroite et bien cadrée, un auteur seul suffit.
C’est le forum qu’EIP-1 recommande pour discuter d’une proposition. EIP-1 recommande aussi de soumettre l’idée à la communauté avant d’écrire une proposition formelle. Servez-vous du fil pour recueillir les besoins des implémenteurs et garder trace des objections.
Après six mois sans activité, une proposition en Draft, Review ou Last Call passe au statut Stagnant. Elle n’est pas morte pour autant. Ses auteurs ou les éditeurs EIP peuvent la remettre en Draft ou à son statut précédent.
Standards That Ship
Episode 1 · 5 publies
Ancien CTO d'Integra. Auteur nommé (1 sur 5) d'ERC-3643, premier auteur d'ERC-6960, co-auteur d'ERC-7410 et co-auteur d'ERC-8203, encore à l'état de brouillon. Conçoit des systèmes d'IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.