Comment fonctionne Label 309

Label 309 définit la manière dont un record de preuve d'existence est inscrit dans les métadonnées d'une transaction Cardano. En son cœur, un record engage une ou plusieurs empreintes de contenu sur Cardano sous le label de métadonnées 309. L'heure du bloc qui porte cette transaction devient le témoin public que ces octets exacts existaient au plus tard à cet instant. Tout le reste qu'un record peut transporter — signatures, URI de stockage, contenus chiffrés, emplacements de clé par destinataire, racines de Merkle, pointeur vers un record antérieur — n'est qu'une métadonnée portant sur cette unique affirmation.

L'objectif de conception est simple à énoncer : une preuve doit être vérifiable de façon indépendante. Vérifier l'affirmation de base ne doit pas exiger de faire confiance à CardanoWall, au site web d'un éditeur, à une base de données privée ou à une autorité de certification — il suffit de la chaîne publique et, pour les affirmations de contenu, des octets d'origine.

Label 309 est un standard ouvert. Il a été soumis au processus CIP de Cardano en tant que proposition de catégorie Métadonnées et fait l'objet d'un examen par les éditeurs CIP ; c'est le label de métadonnées lui-même qui constitue l'identifiant durable sur la chaîne, et l'application web, le CLI et les SDK en sont des implémentations de référence, et non le standard. Si vous préférez d'abord une vue d'ensemble, commencez par ce qu'est réellement une preuve d'existence.

Qu'est-ce qui est stocké sur la blockchain sous le label 309 ?

Un record Label 309 réside dans les métadonnées d'une transaction Cardano sous le label numérique 309. Exactement un record par transaction ; un vérificateur ignore tous les autres labels de métadonnées.

Le corps du record est encodé en CBOR canonique — un format binaire déterministe, si bien que deux implémentations exprimant le même record logique produisent des octets identiques. Cardano plafonne toute chaîne de métadonnées à 64 octets, et un record sérialisé dépasse généralement cette limite. Le corps est donc transporté sous la forme d'un tableau CBOR de petites chaînes d'octets dont la concaténation dans l'ordre constitue le corps du record. Un vérificateur recolle les fragments avant de valider quoi que ce soit. C'est le seul fractionnement qu'opère le format.

Ce détail de transport compte pour les implémenteurs, mais l'idée sous-jacente est limpide :

La transaction porte le label de métadonnées 309.
La valeur sous ce label se réassemble en un seul record Label 309.
Le record s'engage sur des empreintes de contenu, des racines de Merkle, ou les deux.
Des champs optionnels ajoutent des signatures, du matériel de contenu chiffré, des URI de stockage et un pointeur de remplacement.

Ce n'est pas un champ de note en format libre. Le record a une forme stricte et fermée, et c'est précisément ce qui permet à des implémentations différentes de produire et de vérifier les mêmes octets.

Pourquoi l'empreinte du contenu est-elle l'affirmation principale ?

Parce qu'une preuve d'existence est une affirmation portant sur des octets exacts, et qu'une empreinte (hash) en est précisément la signature à sens unique.

L'empreinte du contenu est l'affirmation principale dans Label 309 ; tout autre champ n'est qu'une métadonnée à son sujet. Pour une simple preuve de fichier, un item porte une table hashes qui associe un algorithme de hachage nommé — par exemple sha2-256 ou blake2b-256 — à un condensé brut de 32 octets. Pour vérifier la preuve, un vérificateur recalcule le condensé à partir du fichier d'origine et le compare à celui contenu dans le record.

Si les octets correspondent, la preuve réussit. Modifiez un seul octet et le condensé change, si bien que la preuve échoue.

C'est pourquoi l'affirmation reste légère même lorsque le contenu est volumineux ou privé. Le record n'a jamais besoin du fichier. Il a besoin de l'empreinte.

Que sont items, uris et enc ?

items sont les engagements par contenu d'un record. Chaque item est une affirmation de contenu. La seule partie obligatoire est une table hashes non vide ; le reste est optionnel.

Un item peut transporter :

hashes — la table obligatoire associant algorithme de hachage et condensé brut ;
uris — des emplacements adressés par le contenu, optionnels, tels que ar://… (Arweave) ou ipfs://… (IPFS) ;
enc — une enveloppe de chiffrement optionnelle pour un record scellé (chiffré).

L'idée maîtresse est que uris n'est pas la preuve. L'empreinte est la preuve. Une URI est un indice de récupération ou un engagement de stockage qui aide un vérificateur à trouver des octets à vérifier. Un record qui ne contient qu'une empreinte, sans URI, est une preuve complète et valide. Un record avec une URI peut aider à récupérer du contenu public ou du texte chiffré. Un record scellé maintient le texte en clair chiffré hors de la chaîne tout en prouvant à quel moment il existait.

Pourquoi seulement `ar://` et `ipfs://` ?

La version 1 de Label 309 restreint les URI de stockage aux schémas adressés par le contenu — Arweave et IPFS — et rejette tout le reste, y compris https://. Cette restriction est délibérée, et non temporaire.

Une URL https:// ordinaire dépend du DNS, de TLS, du comportement du serveur, des redirections et de ce qui finit par être hébergé à cette adresse plus tard. Une URI adressée par le contenu est différente : l'adresse elle-même dérive du contenu (un CID IPFS est un multihash des octets ; un identifiant de transaction Arweave s'engage sur les données sous le consensus Arweave). Un vérificateur peut donc confirmer que « les octets que j'ai récupérés sont les octets sur lesquels le producteur s'est engagé » sans faire confiance au gateway de stockage, au DNS ou à une autorité de certification. Les octets récupérés doivent toujours correspondre à l'engagement sur la chaîne ; la couche de stockage n'est jamais à elle seule une source de vérité.

Que prouvent les signatures — et que ne prouvent-elles pas ?

Un record Label 309 peut transporter un tableau sigs optionnel de premier niveau. Chaque entrée est une signature COSE_Sign1 détachée portant sur le corps du record auquel on a retiré le champ sigs. En clair, un signataire se porte garant de l'ensemble du record d'un seul coup : chaque item, chaque empreinte, chaque URI, chaque enveloppe scellée, chaque racine de Merkle, le pointeur de remplacement et tout champ d'extension.

Signer est additif. Un record sans signature prouve toujours l'existence. Un record avec une signature valide montre en outre qu'une clé précise se tient derrière le record :

empreinte seule : ces octets existaient à cette heure publique ;
signé : ces octets existaient à cette heure publique, et cette clé s'est portée garante du record.

La précision compte, car une signature prouve moins que ce que l'on suppose souvent. Une signature vérifiée ne prouve pas que la même clé a payé ou soumis la transaction Cardano, qu'elle a choisi l'heure du bloc, ou qu'elle appartient à une personne réelle identifiée. Elle prouve que la clé a signé le corps du record — rien de plus. Formulez-la comme « signé par cette clé », jamais comme « publié par cette clé ». C'est ce sens étroit et honnête qui rend une preuve signée portable entre différentes applications et différents gateways. L'attribution d'auteur est toujours optionnelle, et une signature qu'un vérificateur ne peut pas contrôler (un algorithme non pris en charge, une clé non résoluble) n'invalide jamais l'affirmation d'existence — les signatures échouent en douceur ; l'existence, non.

Qu'est-ce qu'un record scellé ?

Un record scellé garde le contenu confidentiel tout en prouvant à quel moment il existait.

Dans un record Label 309 scellé, l'item s'engage toujours sur l'empreinte du texte en clair — jamais sur le texte chiffré. Le texte en clair est chiffré, et le texte chiffré réside à une URI adressée par le contenu (ar://… ou ipfs://…), jamais sur la chaîne. Le record sur la chaîne transporte une enveloppe de chiffrement contenant le matériel dont un détenteur de clé choisi a besoin pour récupérer la clé de chiffrement du contenu. La chaîne ne contient pas le texte en clair, et elle ne publie pas de liste de destinataires.

Pour un destinataire, la vérification ajoute quelques étapes :

Récupérer le record depuis Cardano.
Récupérer le texte chiffré depuis le stockage adressé par le contenu.
Tenter d'ouvrir localement un emplacement de clé correspondant.
Déchiffrer le texte chiffré si un emplacement s'ouvre.
Recalculer l'empreinte du texte en clair et la comparer à l'engagement inscrit sur la chaîne.

Parce que le condensé sur la chaîne lie le texte en clair, une preuve scellée préserve le fichier d'origine exact et le garde privé. Cela s'accompagne de quelques limites honnêtes : un record scellé prouve la temporalité et l'intégrité, non l'anonymat, et un destinataire qui déchiffre peut toujours choisir de divulguer le texte en clair ensuite.

Comment les destinataires fonctionnent-ils sans champ destinataire ?

Les destinataires fonctionnent au moyen de clés de réception et d'un déchiffrement à l'essai, et non d'un champ destinataire lisible.

Si un expéditeur connaît l'adresse de réception d'un destinataire (une clé publique X25519, éventuellement une clé hybride post-quantique), il peut construire un record scellé doté d'un emplacement de clé que ce destinataire peut ouvrir. La clé publique du destinataire n'apparaît jamais comme un champ lisible dans le record. Le logiciel du destinataire surveille le flux public des records Label 309 et tente localement de déchiffrer les emplacements candidats ; si un emplacement s'ouvre, le record relève de la boîte de réception de ce destinataire.

C'est pourquoi une boîte de réception CardanoWall n'est pas une messagerie serveur ordinaire. Le gateway expose un flux de records aveugle au destinataire ; le client trouve ceux qu'il peut déchiffrer. Le serveur n'a jamais besoin de savoir qui est le destinataire ni de déchiffrer quoi que ce soit en son nom. (Voir comment recevoir des records scellés pour le côté destinataire en pratique.)

Il subsiste des limites de métadonnées qu'il faut énoncer clairement. Le record ne publie jamais de texte en clair ni de colonne destinataire, et l'ordre des emplacements est mélangé avant publication afin de ne porter aucun signal. Mais le nombre d'emplacements est visible, et la temporalité, les traces de paiement et les erreurs opérationnelles peuvent révéler des informations que le format de record lui-même ne peut pas masquer.

Comment un seul record couvre-t-il des milliers de fichiers ?

Si vous devez prouver que mille fichiers existaient, vous ne devriez pas avoir besoin de mille transactions Cardano. Label 309 prend en charge le regroupement Merkle : hachez les fichiers, construisez un arbre de Merkle sur la liste ordonnée des empreintes, et publiez une seule racine de 32 octets dans le tableau merkle du record. À côté de la racine, le record porte un nombre de feuilles, qui lie la racine sur la chaîne à la taille exacte de la liste hors chaîne.

Plus tard, vous pourrez prouver qu'un fichier ou un événement précis figurait dans le lot en présentant :

le fichier (ou son empreinte de feuille) ;
une preuve d'inclusion — les empreintes sœurs le long du chemin jusqu'à la racine ;
la racine de Merkle ancrée dans le record Label 309.

Le vérificateur replie la preuve d'inclusion jusqu'à une racine et ne l'accepte que si la racine recalculée est égale à la racine publiée, octet par octet. Chaque feuille non divulguée reste privée — la racine ne révèle rien sur les feuilles sur lesquelles elle s'engage.

C'est la couche de mise à l'échelle pour les artefacts CI/CD, les journaux de conformité, les sorties d'IA, les manifestes de jeu de données, les dossiers de version et les ensembles de pièces. Le sujet est traité à part dans un seul record pour des milliers de fichiers.

À quoi sert le pointeur supersedes ?

supersedes est un pointeur optionnel de 32 octets vers un record Label 309 antérieur, désigné par son empreinte de transaction. Il permet à un record plus récent de dire « ceci remplace ou met à jour ce record antérieur ».

Le record antérieur n'est ni supprimé ni invalidé. Cardano fonctionne en ajout seul, si bien que les deux records restent vérifiables de façon indépendante pour toujours. Le pointeur n'est qu'un lien ; il ne porte aucun champ de motif. Le sens humain du remplacement — une correction, un manifeste révisé, un dossier de pièces mis à jour — relève du nouveau contenu ou de la couche applicative, et non des métadonnées. La valeur du pointeur tient à ce qu'il fonctionne sans aucune ligne de base de données propriétaire et sans aucun identifiant de record propriétaire.

Comment fonctionne la vérification ?

La vérification est en couches. 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 du record. Il confirme le CBOR canonique, la forme du schéma, les types de champs, les champs obligatoires, les identifiants d'algorithme et les règles d'URI. Il n'effectue aucune E/S réseau, ne vérifie aucune signature et ne déchiffre rien.
Vérificateur public — il part d'une référence de transaction Cardano. Il récupère la transaction brute depuis un explorateur qu'il choisit lui-même, lie ces octets à l'empreinte de transaction demandée, confirme la présence du label 309, réassemble le record, exécute la validation structurelle, vérifie la profondeur de confirmation et contrôle les signatures qu'il prend en charge. Si les octets du contenu sont disponibles, il peut recalculer les empreintes du contenu public. Il ne déchiffre pas.
Vérificateur du destinataire — tout ce que fait le vérificateur public, plus sa propre clé privée pour ouvrir les contenus scellés et recalculer les empreintes du texte en clair.

Une subtilité maintient la vérification honnête : un vérificateur public lit le CBOR brut de la transaction, et non la vue JSON des métadonnées proposée par un explorateur. Une projection JSON entraîne une perte d'information — elle écarte l'ordre des clés de table et la distinction octets/texte — si bien qu'un réencodage à partir d'elle casserait chaque signature d'un record conforme. Et comme le règlement sur Cardano est probabiliste, un record qui n'a qu'un bloc ou deux de profondeur est signalé comme pending plutôt que valid tant qu'il n'a pas suffisamment de confirmations derrière lui.

Cette structure garde le modèle de confiance propre. Un vérificateur de base n'a besoin d'aucun compte CardanoWall ; une preuve publique se contrôle sans serveur d'éditeur ; une preuve scellée se déchiffre localement, entre les mains du détenteur de clé. Le guide pas à pas vérifier un record Label 309 montre le chemin du vérificateur public de bout en bout.

Où s'insère le gateway ?

Le gateway publie les records. Il n'est pas la racine de confiance.

Un gateway Label 309 prend en charge les parties réellement difficiles à faire tourner soi-même : il établit le devis, téléverse le texte chiffré vers le stockage, construit et soumet la transaction Cardano, attend la confirmation, indexe les records, gère les soldes et expose une API. CardanoWall s'appuie sur ce modèle de gateway pour rendre la publication praticable pour les utilisateurs ordinaires et les développeurs.

Mais une preuve n'est pas digne de confiance parce qu'un gateway affirme qu'elle existe. Elle l'est parce que le record est sur la chaîne, que les octets sont valides, que les signatures sont contrôlées et que les empreintes se recalculent. Voilà la ligne qui sépare un service hébergé d'un standard de preuve : le service vous aide à publier ; le standard permet à quiconque de vérifier, le gateway étant entièrement hors du chemin de confiance.

Le modèle mental minimal

Voyez Label 309 comme un petit record en couches :

items prouve que des octets de contenu exacts existaient à une heure publique.
sigs permet à des clés de se porter garantes du record, en option.
enc permet à du contenu chiffré de rester privé mais récupérable.
les emplacements de clé par destinataire permettent à des détenteurs de clé précis d'ouvrir un contenu scellé.
merkle permet à un seul record de représenter un très grand lot.
la vérification s'appuie sur des données publiques et des clés locales — jamais sur la confiance envers un fournisseur.

C'est cette superposition qui permet à CardanoWall d'être une application web, une API, un CLI, une application de bureau ou un gateway auto-hébergé — tandis que le format de preuve reste le même. Le produit peut changer ; la preuve, elle, reste vérifiable.

Une chose qu'il vaut la peine d'énoncer honnêtement de bout en bout : une preuve Label 309 montre que des octets précis existaient à une heure publique, et qu'ils n'ont pas changé depuis. Elle ne prouve pas qui a rédigé le contenu, qui le détient, ni si ce qu'il affirme est vrai. Pour savoir où passe cette limite, voir ce qu'une preuve ne prouve pas.

Pour aller plus loin

Qu'est-ce qu'une preuve d'existence ?
Vérifier un record Label 309
Un seul record pour des milliers de fichiers
Ce qu'une preuve ne prouve pas
Le standard Label 309 : label309.org
Les SDK et le CLI open source : github.com/cardanowall
La soumission au CIP de Cardano (en cours d'examen) : PR #1205 des CIPs