Comment le protocole évolue.

01

Ouvrir une RFC

Toute personne peut proposer un changement. Les RFC sont ouvertes en issues GitHub sur le dépôt de la spec, puis promues en fichier markdown sous rfcs/ une fois le triage initial passé. Le nommage suit RFC-NNNN-short-title.md, où NNNN est attribué au triage. Chaque RFC utilise le même template.

• Summary — description du changement en un paragraphe
• Motivation — quel problème résolu, pour qui
• Detailed design — texte normatif, modifications du data model, exemples
• Backwards compatibility — ce qui casse, ce qui migre
• Security considerations — modèle de menace, nouvelles surfaces d’attaque
• Alternatives considered — ce qui a été essayé, pourquoi rejeté

02

Période de commentaires

Une fois la RFC déposée, elle entre dans une période de commentaires publique d’au moins 4 semaines. La période est ouverte à toute personne : développeurs, journalistes, citoyens, fournisseurs d’identité, opérateurs de blockchain, société civile. Tous les commentaires sont archivés sur GitHub et restent lisibles dans le dossier historique, que la RFC soit acceptée ou non.

03

Revue technique

Les contributeurs core lisent chaque RFC de bout en bout, demandent des clarifications, proposent des amendements. Les décisions reposent sur des critères techniques, pas sur un vote majoritaire.

• Alignement avec la vision du protocole : identité vérifiée, contenu, registre infalsifiable
• Compatibilité ascendante : casse-t-elle des signatures ou vérificateurs existants
• Sécurité : introduit-elle de nouvelles surfaces d’attaque ou affaiblit-elle des garanties existantes
• Simplicité : le même problème peut-il être résolu avec moins de mécanisme

04

Décision et merge

Chaque RFC se termine par l’un de trois résultats, avec rationale écrit publié dans le même fil.

• Accepted — mergée dans la spec, intégrée à la version v0.x+1
• Rejected — avec rationale explicite, archivée pour référence future
• Deferred — laissée ouverte pour réexamen quand le contexte change (nouvelle chaîne, nouveau standard, nouveau cas d’usage)

05

Implémentation

Une fois la RFC mergée, elle devient partie intégrante de la spécification canonique. Les implémentations de référence (signcheck et autres) sont mises à jour. Les vérificateurs PEUVENT adopter le changement immédiatement ou attendre la prochaine version mineure. Le changelog de spec recense toutes les RFC mergées dans chaque version.