Proposition d’ERC : ce que les relecteurs doivent y trouver
Une relectrice ouvre votre proposition d’ERC. Que doit-elle y trouver pour la tester, et qu’est-ce qui la fait attendre ?
EN 30 SECONDES
Le document d’un ERC est la spécification écrite que testent les relecteurs : une interface exacte, une justification et des considérations de sécurité, avec tests et code facultatifs. Cette partie montre son contenu et ce qui aide ou gêne la relecture.
À RETENIR · 3
- L’interface est le cœur d’un ERC : elle doit être exacte.
- Gardez un périmètre étroit. Mieux vaut plusieurs ERC ciblés qu’un seul qui veut tout faire.
- EIP-1 rend l’implémentation de référence facultative. Du code qui tourne rend quand même l’interface testable.
Sur cette page
Ce que contient le document d’un ERC
EN BREF Le document consigne la conception ; la discussion et le code vérifient si d’autres peuvent s’en servir.
LES MOTS À CONNAÎTRE
- Interface
- La liste des fonctions et des événements qu’un contrat doit exposer pour que d’autres programmes sachent exactement comment l’appeler.
- Implémentation de référence
- Un code d’exemple qui montre les règles d’une proposition en pratique. EIP-1 la rend facultative.
- Autorisation de dépense
- Le montant de vos jetons qu’une autre adresse peut dépenser.
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.
ÉTAPE PAR ÉTAPE
Étape 1. Abstract. Décrivez l’interface et le périmètre réels. Ne promettez que ce que la spécification définit. La Motivation, facultative, énonce le problème concret.
- Abstract Décrivez l’interface et le périmètre réels. Ne promettez que ce que la spécification définit. La Motivation, facultative, énonce le problème concret.
- Specification Signatures de fonctions (nom et paramètres de chaque fonction) et événements, assez précis pour écrire du code.
- Rationale Le compromis retenu et celui écarté. C’est ici qu’on consigne les objections traitées.
- Tests et code Facultatifs pour un ERC. Sans cas de test, je lis une spécification comme un texte dont personne n’a fait tourner le code.
- Sécurité Obligatoire. EIP-1 rejette une proposition sans section Security Considerations.
EN CLAIR
Une Implémentation de référence Un code d’exemple qui montre les règles d’une proposition en pratique. EIP-1 la rend facultative. Voir le glossaire est facultative dans EIP-1. Elle transforme un texte abstrait en quelque chose qu’un relecteur peut exécuter.
Dans la section suivante : Alors, à quoi ressemble une proposition prête pour la relecture, face à une autre qui ne l’est pas ?
Un exemple concret : une proposition ciblée, une autre fourre-tout
EN BREF Un relecteur peut tester une interface au périmètre restreint ; face à une interface qui promet tout, il ne peut qu’attendre.
ATTENTION
Les deux esquisses sont des exemples pédagogiques, et le scénario 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é.
L’esquisse ciblée résout un seul problème : ajuster une Autorisation de dépense Le montant de vos jetons qu’une autre adresse peut dépenser. Voir le glossaire existante. L’esquisse fourre-tout veut couvrir à la fois identité, paiements et litiges.
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
- Une relectrice 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.
SORTIE
- Verdict
- prête pour la relecture : 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
- Une relectrice ne sait pas ce que chaque fonction doit faire, donc elle 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
OBJET OBTENU
Un ERC, un problème
Ce qui facilite ou complique la relecture
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 fil silencieux est un signal à creuser, pas la preuve qu’une idée ou un auteur a échoué.
Un long fil de forum peut signaler une bonne idée ou une idée confuse.
Demandez-vous donc si le problème est clair et si les bonnes équipes l’ont vu.
Source : EIP-1.
FAQ
Non, EIP-1 rend cette section 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.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Vous savez citer les principales sections qu’un ERC devrait avoir selon EIP-1, et lesquelles sont facultatives.
- Vous savez pourquoi un relecteur peut tester une interface au périmètre restreint, mais ne peut qu’attendre face à une interface qui promet tout.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Une proposition couvre les transferts de jetons et l’identité multi-chaîne dans une seule interface. Que suggérerait un relecteur ?
Sans doute de la découper. D’expérience, chaque sujet attire ses propres objections, venues d’experts différents : chaque partie peut mériter son propre ERC.
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.