Introduction
Ce qu’est Label 309, les principes qu’il garantit et comment quiconque peut vérifier un enregistrement sans faire confiance à un serveur.
Label 309 est un standard ouvert de preuve d’existence (Proof of Existence, PoE) sur la blockchain Cardano. Un publicateur calcule l’empreinte cryptographique d’un contenu et l’ancre dans une transaction Cardano sous le label de métadonnées 309. Dès cet instant, quiconque détient la référence de la transaction peut prouver que le contenu existait à l’heure du bloc ou avant — en s’appuyant uniquement sur la blockchain publique, sans avoir à faire confiance au publicateur, à un domaine ou à un quelconque serveur.
Le standard est délibérément réduit en son cœur : l’empreinte du contenu est l’affirmation, et tout le reste n’est que métadonnées optionnelles à son sujet. Par-dessus ce cœur, il définit des signatures de paternité optionnelles et une charge utile chiffrée (« scellée ») optionnelle, adressée à des destinataires précis — sans que rien de tout cela n’exige jamais d’intermédiaire de confiance.
Les cinq invariants
Tout dans Label 309 découle de cinq principes non négociables :
- Priorité au contenu. L’empreinte du contenu est l’affirmation primaire ; tout autre champ n’est que métadonnée à son sujet.
- Indépendant de l’émetteur. N’importe quel portefeuille peut publier un enregistrement. Les vérificateurs ne font jamais confiance au publicateur.
- Indépendant du stockage. Les URI de stockage forment une liste optionnelle
et plurielle (
ar://,ipfs://) ; un enregistrement réduit à l’empreinte est pleinement valide. - Vérifiable de façon autonome. Un vérificateur n’a besoin que des métadonnées de la transaction, facultativement des octets du contenu, et d’un explorateur de blocs public. Aucun serveur de l’émetteur n’est jamais requis.
- Agile en matière d’algorithmes. Les empreintes, les AEAD, les KEM, les KDF et les signatures renvoient tous à des identifiants nommés issus de registres extensibles. La migration vers des algorithmes post-quantiques est additive, et non une rupture de compatibilité.
Profils de conformité
Un enregistrement se situe dans l’un des quatre profils en couches, du simple horodatage jusqu’à une charge utile chiffrée et adressée à des destinataires. Chaque profil est un surensemble strict du précédent.
| Profil | Ajoute | Répond à |
|---|---|---|
| core | une empreinte du contenu sous le label 309 | « ce contenu existait au plus tard à l’instant T » |
| signed | une ou plusieurs signatures d’enregistrement COSE_Sign1 | « ...et cette clé s’en porte garante » |
| sealed | une charge utile chiffrée (phrase secrète ou destinataires) | « ...gardé confidentiel, mais horodaté » |
| recipient-sealed | des emplacements de clé par destinataire (X25519 ou X-Wing) | « ...remis à des clés précises, conservé en privé » |
La paternité et le chiffrement sont toujours optionnels. Un vérificateur qui ne
comprend que core peut tout de même valider l’affirmation d’horodatage de tout
enregistrement.
La vérification en un coup d’œil
Label 309 définit trois rôles de vérification, chacun étant une extension stricte du précédent :
- Validateur structurel — une fonction pure sur les octets de l’enregistrement. Aucun réseau, aucune vérification de signature, aucun déchiffrement ; il se contente de confirmer que l’enregistrement est bien formé au regard du schéma et des règles du standard.
- Vérificateur public — récupère la transaction depuis un explorateur public, exécute la validation structurelle, confirme que l’enregistrement est ancré sur la chaîne et vérifie d’éventuelles signatures de paternité. Il ne déchiffre pas.
- Vérificateur destinataire — un vérificateur public qui, de surcroît, détient une clé privée, déchiffre une charge utile scellée qui lui est adressée et recalcule les empreintes du texte en clair.
Parce que chaque rôle opère à partir de données publiques et d’un explorateur choisi par le vérificateur, la vérification ne dépend jamais de l’infrastructure du publicateur.
La propriété fondamentale
Une preuve Label 309 est une chose que vous pouvez vérifier vous-même. À partir d’une référence de transaction et — pour les affirmations sur un contenu — des octets d’origine, toute implémentation conforme parvient au même verdict à partir de la seule chaîne publique.
Comment cette spécification est organisée
Les chapitres qui suivent définissent le format de sérialisation, ou wire format (l’enregistrement sous le label 309), les registres d’algorithmes, le modèle cryptographique des clés, les signatures de paternité, la remise scellée (chiffrée), le pipeline de vérification et son catalogue d’erreurs, le modèle de sécurité et le contrat de conformité entre langages. Chaque page est autonome et cite les constantes nommées et les règles dont a besoin celui qui implémente le standard.