Comment vérifier un record Label 309

Vous vérifiez un record Label 309 directement depuis la chaîne Cardano publique, à partir d'une seule donnée d'entrée : une référence de transaction Cardano. Rien dans la réponse ne dépend de CardanoWall, de l'auteur de la publication, ni du maintien en ligne d'un quelconque serveur.

Un vérificateur récupère les octets bruts de la transaction depuis l'infrastructure Cardano publique, extrait le label de métadonnées 309, reconstitue le corps du record, contrôle le CBOR canonique et le schéma, vérifie les éventuelles signatures d'auteur et — lorsque les octets du contenu ou un contenu chiffré sont disponibles — recalcule les empreintes. L'ensemble du contrôle est une suite de comparaisons cryptographiques, et non une requête vers un service de confiance.

Le gateway qui a publié le record n'est pas l'autorité. Le record l'est. C'est tout l'intérêt du standard : une preuve que vous vérifiez une fois reste vérifiable par quiconque, indéfiniment, avec n'importe quel outillage conforme à Label 309.

De quoi avez-vous besoin pour vérifier ?

La donnée d'entrée minimale est une empreinte de transaction Cardano.

Avec cette seule empreinte de transaction, un vérificateur peut répondre aux questions suivantes :

• cette transaction contient-elle un record Label 309 ?
• le record est-il structurellement valide ?
• la transaction est-elle confirmée à une profondeur suffisante ?
• les signatures au niveau du record se vérifient-elles, le cas échéant ?
• quelles empreintes, quelles URI de stockage, quelles racines de Merkle et quelles enveloppes scellées le record revendique-t-il ?

Pour prouver qu'un fichier précis est bien le fichier derrière l'empreinte, le vérificateur a aussi besoin des octets du fichier ou d'un objet de stockage attribuable référencé par le record.

Pour déchiffrer un record scellé, le vérificateur a besoin de la clé privée du destinataire. Cette clé est utilisée localement et n'est jamais renvoyée à l'éditeur ni à CardanoWall — toute la construction est conçue pour que la vérification ne communique jamais avec un serveur d'origine.

Que vérifie réellement un vérificateur ?

Un bon vérificateur doit contrôler le record par couches.

La première couche est le validateur structurel. C'est une fonction pure sur les octets du record. Elle n'effectue aucun appel réseau, aucun déchiffrement et aucune vérification de signature. Elle contrôle le CBOR canonique, les types de champs, le schéma fermé, les noms d'algorithmes enregistrés, les règles d'URI et les contraintes inter-champs, par exemple « il doit y avoir au moins un item ou un engagement Merkle ».

La deuxième couche est le vérificateur public. Il résout la transaction à partir d'une source de données Cardano choisie par le vérificateur, lie les octets récupérés à l'empreinte de transaction, extrait le label 309, vérifie la profondeur de confirmation et vérifie les signatures du record. C'est la couche que peut exécuter un audit public, une tâche CI ou un explorateur.

La troisième couche est le vérificateur du destinataire. Il fait tout ce que fait le vérificateur public, puis tente de déchiffrer les items scellés avec la clé locale du destinataire et recalcule les empreintes du texte en clair après déchiffrement.

Cette stratification compte, car toutes les preuves n'exigent pas tous les contrôles. Un record contenant uniquement une empreinte peut rester valide même sans contenu chiffré. Un vérificateur public peut valider un record signé sans être en mesure de déchiffrer un fichier scellé.

Pourquoi vérifier à partir des octets bruts de la transaction, et non d'une vue JSON ?

La vérification Label 309 s'effectue à partir des données brutes de la chaîne, et non d'une projection JSON commode — et la différence n'est pas cosmétique.

Le record est du CBOR canonique. Les signatures portent sur un CBOR canonique exact à l'octet près. Les métadonnées de transaction Cardano comportent des chaînes d'octets, des chaînes de texte, des tableaux, des maps et des règles d'ordre que JSON ne peut pas préserver sans perte.

Un vérificateur doit donc récupérer le CBOR brut de la transaction, recalculer l'identifiant de transaction, lier les données auxiliaires au corps de la transaction, puis reconstituer le tableau de fragments du label 309 pour retrouver le corps original du record.

Un explorateur peut être une infrastructure utile. Il ne doit pas devenir ce à quoi vous accordez votre confiance. Le vérificateur doit traiter les réponses d'un explorateur comme des données à lier, à contrôler et à recouper.

Que contient un record label 309 ?

Un record Label 309 est porté sous le label de métadonnées de transaction Cardano 309.

La valeur sur la chaîne n'est pas un objet JSON libre. Le corps du record est sérialisé une fois en CBOR canonique, puis transporté sous la forme d'un tableau de fragments en chaîne d'octets, car les chaînes d'octets et les chaînes de texte des métadonnées Cardano sont plafonnées à 64 octets.

Après reconstitution, le corps du record est une unique map CBOR. Ses clés de premier niveau sont :

• v, la version du schéma (actuellement 1) ;
• items, un tableau optionnel d'engagements par contenu — chaque item porte une map hashes obligatoire, et facultativement sa propre liste uris pour le stockage adressé par le contenu (ar://, ipfs://) ainsi qu'une enveloppe enc pour le contenu scellé ;
• merkle, des engagements de liste optionnels qui lient une racine sur la chaîne à une liste de feuilles hors chaîne — la manière dont les grands lots sont ancrés ;
• sigs, des signatures d'auteur optionnelles au niveau du record ;
• supersedes, un pointeur de remplacement optionnel, en ajout seul, vers un record antérieur ;
• crit, plus des clés d'extension à espace de noms, pour des ajouts compatibles avec les versions futures.

Un record conforme doit s'engager sur au moins une entrée items ou un engagement merkle. Les URI de stockage et l'enveloppe scellée vivent à l'intérieur d'un item, et non au niveau supérieur — un détail à ne pas négliger quand vous analysez le record vous-même.

L'affirmation centrale donne toujours la primauté au contenu : ces empreintes, ou cette racine de Merkle, ont été ancrées dans cette transaction au plus tard à l'heure du bloc.

Quels verdicts l'automatisation doit-elle attendre ?

La vérification ne doit pas réduire chaque problème à « valide » ou « invalide ».

Le modèle de vérificateur Label 309 emploie quatre verdicts exploitables par une machine :

• valid : tous les contrôles requis ont réussi.
• failed : le record lui-même a échoué à un contrôle structurel, de signature ou d'intégrité attribuable.
• unverifiable : un contrôle requis n'a pas pu être mené à terme pour des raisons non attribuables au record, comme une infrastructure indisponible ou un contenu impossible à récupérer.
• pending : la transaction est sur la chaîne mais en dessous du seuil de confirmation du vérificateur.

Cette distinction est importante dans les systèmes réels.

Si un gateway de stockage est hors service, le record ne doit pas être condamné. Si des octets récupérés sont attribuables à une URI engagée et que leur empreinte ne correspond pas, le record doit échouer. Si la transaction n'a qu'une seule confirmation, le vérificateur doit indiquer qu'elle est en attente plutôt que de faire comme si la finalité était déjà acquise.

La CLI open source cardanowall associe directement ces états à des codes de sortie, de sorte que le verdict survit dans un script shell sans qu'il faille analyser le moindre JSON :

cardanowall verify <tx-hash> --json

Cette distinction est exactement ce qu'on attend en intégration continue : le script peut faire la différence entre « la preuve est mauvaise » (sortie 1, qu'un explorateur défaillant ne peut jamais fabriquer) et « réessayez plus tard » (sortie 2). Le même vérificateur est livré dans les SDK TypeScript, Python et Rust, de sorte qu'une application peut lire le rapport structuré complet plutôt qu'un code de sortie. Pour les schémas d'intégration de tout cela dans un pipeline, voir utiliser la CLI dans l'automatisation.

Comment vérifier un fichier ?

Pour une simple preuve de fichier, le flux est le suivant :

1. Prenez l'empreinte de transaction.
2. Récupérez et vérifiez le record Label 309.
3. Identifiez l'algorithme de hachage engagé et le condensé.
4. Hachez les octets du fichier en local.
5. Comparez votre condensé à celui figurant dans le record.
6. Vérifiez la profondeur de confirmation et l'heure du bloc.
7. Vérifiez les éventuelles signatures du record, le cas échéant.

Si le fichier diffère d'un seul octet, l'empreinte diffère.

C'est la force d'une preuve par empreinte de contenu. Elle ne prouve pas que le fichier est vrai, légal, original ou de valeur. Elle prouve que les octets exacts correspondant à l'empreinte existaient au plus tard à l'heure du bloc ancré, sous réserve de la politique de finalité du vérificateur.

Comment vérifier un record scellé ?

Un record scellé ajoute du contenu chiffré.

Le record public s'engage toujours sur l'empreinte du texte en clair. Le texte chiffré peut être stocké hors chaîne, par exemple via Arweave ou IPFS. L'enveloppe sur la chaîne contient les informations nécessaires pour qu'un destinataire prévu récupère la clé du contenu en local.

Le vérificateur du destinataire doit :

1. Exécuter d'abord le chemin de vérification publique.
2. Essayer la clé privée fournie sur les emplacements scellés.
3. Si un emplacement s'ouvre, déchiffrer le texte chiffré.
4. Recalculer l'empreinte du texte en clair.
5. La comparer à l'engagement d'empreinte sur la chaîne.

Ce contrôle final d'empreinte est le pont entre « j'ai déchiffré quelque chose » et « voici le contenu exact qui a été horodaté ». Déchiffrer les octets ne suffit pas à lui seul ; l'empreinte du texte en clair recalculée doit correspondre à l'engagement pris par le record avant tout chiffrement.

La clé du destinataire reste locale. La vérification ne requiert aucun compte CardanoWall de confiance, aucun serveur d'émetteur et aucun rappel vers la personne qui a publié le record. Un record scellé garde son texte en clair confidentiel pour les détenteurs de clé — mais notez ses limites : il ne garantit pas l'anonymat, et une fois qu'un destinataire a déchiffré le contenu, il peut en faire ce que bon lui semble.

Comment vérifier un engagement Merkle ?

Les engagements Merkle servent pour les lots.

Plutôt que de publier des milliers d'empreintes directement dans un seul record, un producteur peut publier une seule racine de Merkle et conserver hors chaîne la liste ordonnée de feuilles et les preuves d'inclusion.

Pour vérifier un item du lot :

1. Hachez l'item ou obtenez le condensé de feuille engagé.
2. Vérifiez la preuve d'inclusion par rapport à la racine de Merkle.
3. Vérifiez que la racine et leaf_count figurent dans le record Label 309.
4. Vérifiez la transaction Cardano et la profondeur de confirmation.

La racine ne suffit pas à elle seule. Le producteur ou l'archive doit conserver la liste de feuilles et les preuves d'inclusion. Label 309 fournit au lot un ancrage public ; les éléments opérationnels qui entourent le lot doivent quand même être conservés. C'est ainsi qu' un seul record prouve des milliers de fichiers à un coût fixe sur la chaîne.

À quoi ne faut-il pas se fier ?

Ne vous fiez pas au site web de l'éditeur comme source de vérité.

Ne vous fiez pas à une capture d'écran d'une transaction.

Ne vous fiez pas à une vue JSON d'explorateur comme entrée cryptographique.

Ne vous fiez pas à un gateway de stockage simplement parce qu'il a renvoyé des octets.

Ne vous fiez pas aux badges « vérifié » qui ne précisent pas ce qui a été contrôlé.

Le vérificateur doit pouvoir produire un rapport : empreinte de transaction, sources de données Cardano utilisées, profondeur de confirmation, heure du bloc, condensé du record, résultats des signatures, résultats des empreintes de contenu, résultats des récupérations de stockage, contrôles Merkle et tout contrôle ignoré.

Ce rapport est ce qui rend la preuve exploitable dans les audits et l'automatisation.

Que ne prouve pas la vérification ?

La vérification est précise. Il ne faut pas la survendre.

Un record Label 309 valide ne prouve pas, à lui seul :

• la propriété juridique du contenu, ni des droits exclusifs sur celui-ci ;
• que le contenu est vrai ;
• que l'éditeur avait l'autorisation de le publier ;
• qu'une personne réelle contrôle une clé de signature ;
• qu'un tribunal, un régulateur ou un client acceptera la preuve sans pièces à l'appui — la recevabilité dépend de la juridiction, et une preuve peut étayer un dossier mais ne remplace pas un conseil juridique ;
• que le stockage hors chaîne restera disponible pour toujours, à moins que la durabilité du stockage ne soit maintenue séparément.

Elle prouve l'affirmation que le record formule réellement : une empreinte ou une racine de Merkle a été ancrée sur Cardano, toutes les signatures portant sur le record se sont vérifiées, et tous les contrôles de contenu ou de déchiffrement ont correspondu aux engagements. Autrement dit, elle établit la datation et l'intégrité — pas la vérité, la propriété ni les droits.

C'est précisément cette affirmation plus restreinte qui la rend utile. Pour connaître toute la frontière de ce qu'un horodatage peut et ne peut pas faire, voir ce qu'une preuve ne prouve pas.

Pour aller plus loin

• Le standard Label 309, y compris le pipeline de vérification complet, les états de verdict et le catalogue d'erreurs typées : label309.org.
• Le vérificateur open source — la CLI cardanowall plus les SDK TypeScript, Python et Rust qui exécutent tous les mêmes contrôles : github.com/cardanowall.
• Label 309 est soumis au processus CIP de Cardano et en cours d'examen par les éditeurs CIP en tant que proposition de catégorie Metadata : la pull request ouverte.