Publier votre première preuve d'existence sur Cardano

La preuve Label 309 la plus simple est une empreinte ancrée sur Cardano.

Vous prenez un fichier, vous calculez son empreinte cryptographique, vous publiez cette empreinte dans un record Label 309 sous le label de métadonnées Cardano 309, et vous conservez l'empreinte de transaction obtenue. Plus tard, quiconque détient le fichier d'origine peut recalculer l'empreinte et confirmer que l'engagement correspondant était sur la chaîne au plus tard à l'heure du bloc de la transaction. Aucun besoin de votre serveur, de votre domaine ni de votre identité pour le vérifier — seulement la référence de transaction et un explorateur Cardano public.

Voilà le premier niveau de la preuve d'existence. Tout le reste s'appuie dessus. Ce guide vous accompagne dans la publication d'une preuve, principalement depuis l'outil en ligne de commande cardanowall, et se termine par la manière de confirmer qu'elle a bien fonctionné.

Que publiez-vous réellement ?

Lorsque vous créez une preuve élémentaire, vous ne publiez pas le fichier lui-même.

Vous publiez un engagement sur le fichier : son condensé. Un condensé est une empreinte cryptographique de taille fixe. Si le fichier change ne serait-ce que d'un octet, le condensé change entièrement. C'est cette propriété qui fait d'une empreinte un substitut fiable des octets exacts.

Une preuve limitée à une empreinte convient bien à des éléments tels que :

contrats et factures ;
artefacts de version et manifestes de build ;
sorties d'IA et instantanés de jeux de données ;
documents de politique interne et dossiers de pièces ;
sommes de contrôle déjà produites par un autre système.

La preuve ne révèle pas le contenu du fichier. Elle ne révèle que l'empreinte, l'algorithme de hachage que vous avez choisi et les éventuelles métadonnées optionnelles que vous décidez d'inclure dans le record. Pour en savoir plus sur les champs qui finissent sur la chaîne, voyez ce qui va sur la blockchain.

De quoi avez-vous besoin avant de publier ?

La publication nécessite un gateway. La vérification, non.

La vérification s'effectue entièrement à partir des données publiques de la chaîne. La publication, c'est différent : quelque chose doit construire et soumettre la transaction Cardano, payer les frais de réseau, gérer la confirmation et — si vous stockez des fichiers hors chaîne — payer le coût de stockage. Un gateway Label 309 est le service qui prend tout cela en charge. Le gateway open source et l'outillage qui l'entoure sont indépendants du gateway : vous dirigez donc les outils vers le gateway pour lequel vous détenez une clé.

Pour votre première preuve, il vous faut :

un fichier ou un condensé précalculé ;
l'URL de base d'un gateway Label 309 ;
une clé d'API ou un jeton de compte à courte durée de vie pour ce gateway ;
un solde suffisant sur votre compte gateway ;
en option, une graine d'identité, si vous souhaitez signer le record.

Si vous utilisez le gateway CardanoWall hébergé, CardanoWall gère pour vous le compte gateway et le solde prépayé. Si vous exploitez votre propre gateway, vous approvisionnez vous-même ses portefeuilles Cardano et de stockage. Dans les deux cas, publier a un coût, car de vrais frais sont réglés en votre nom — c'est le sujet de pourquoi la publication a un prix.

Pourquoi le déroulé est-il d'abord le devis, puis la publication ?

Un gateway ne devrait jamais publier en silence et vous surprendre avec une facture. C'est pourquoi chaque publication suit la même séquence en deux temps : verrouiller un prix, puis soumettre.

Construire ou estimer le record.
Demander un devis au gateway.
Recevoir un identifiant de devis et un détail du prix (frais de réseau, stockage, marge de service).
Soumettre le record finalisé avec ce devis.
Recevoir immédiatement un identifiant de record du gateway, alors que la transaction est encore en cours de soumission.
Suivre le statut jusqu'à la confirmation de la transaction sur la chaîne.
Vérifier le résultat de façon indépendante.

Un devis verrouille le prix pour une fenêtre limitée — actuellement 15 minutes. S'il expire avant que vous publiiez, vous en demandez un nouveau ; le prix peut évoluer si les taux de change ont bougé, mais rien d'autre ne change.

C'est ce schéma en deux temps qui rend l'automatisation sûre. Votre script peut journaliser le devis, appliquer sa propre politique de dépense et ne publier qu'ensuite — de sorte qu'une flambée de prix ou un lot envoyé par erreur ne puisse jamais épuiser votre solde.

Publier un fichier avec la CLI

Pour un fichier local, le déroulé en ligne de commande est volontairement minimal :

cardanowall submit \
  --file ./contract.pdf \
  --base-url https://your-gateway.example \
  --api-key "$CARDANOWALL_API_KEY"

La CLI hache le fichier, construit le record Label 309, demande au gateway un devis puis la publication, et affiche le résultat. --base-url et --api-key se lisent aussi dans les variables d'environnement CARDANOWALL_BASE_URL et CARDANOWALL_API_KEY, ce qui leur permet de disparaître de la commande en CI.

Pour un usage répété, enregistrez le gateway sous forme de profil nommé plutôt que de transmettre le point d'accès à chaque fois :

cardanowall gateway add prod --base-url https://your-gateway.example
cardanowall gateway use prod
cardanowall submit --file ./contract.pdf

Le binaire cardanowall est un outil natif unique et autonome, sans environnement d'exécution à installer. Installez-le depuis crates.io avec cargo install cardanowall-cli (le crate est cardanowall-cli ; la commande installée est cardanowall), ou compilez-le depuis le dépôt open source sur github.com/cardanowall.

Comment publier une empreinte que vous possédez déjà ?

Parfois, le condensé existe déjà — issu d'une chaîne de build, d'un registre de conteneurs, d'un processus de mise en production ou d'une archive de données. Dans ce cas, publiez le condensé directement, sans aucun fichier en jeu :

cardanowall submit --hash <64-hex-digest>

Le mode de hachage par défaut est sha2-256. Passez --alg blake2b-256 lorsque vous avez besoin de cet algorithme à la place. Le record consigne l'algorithme que vous avez utilisé, afin qu'un vérificateur sache plus tard comment recalculer le condensé.

Publier une empreinte précalculée est également le bon choix lorsque le fichier source est trop volumineux, trop sensible ou trop strictement contrôlé pour transiter par un outil polyvalent. La seule chose qui compte est que les octets exacts et le processus de hachage exact restent reproductibles — sinon, personne ne pourra recalculer un condensé correspondant.

Faut-il signer le record ?

Signez le record lorsque vous voulez prouver qu'une identité Label 309 précise s'est portée garante de celui-ci.

Une preuve limitée à une empreinte affirme : ces octets existaient avant cette date. Une preuve signée ajoute : et cette clé de signature répond de ce record exact. Cette affirmation supplémentaire compte pour les records de version d'une entreprise, les archives officielles, les chaînes CI/CD, les workflows de preuves juridiques, les journaux de provenance d'IA et toute identité d'éditeur public destinée à durer.

Les signatures sont toujours optionnelles. Une preuve non signée reste une preuve d'existence complète et entièrement vérifiable — Label 309 est indépendant de l'émetteur par conception, et un vérificateur n'a jamais à faire confiance à l'éditeur. Signer ne fait que répondre à une question différente : qui se porte garant du record, et non si les octets existaient.

La graine d'identité ne doit jamais être envoyée au gateway. La CLI et le SDK sont conçus pour que la signature se produise localement et que seule la signature terminée circule. Fournissez la graine via --seed-stdin ou --seed-file plutôt que par un simple argument --seed, car les arguments de ligne de commande fuitent à travers l'historique du shell, les listes de processus et les journaux de CI :

cardanowall submit --file ./release-manifest.json --seed-stdin

Faut-il joindre le fichier, ou seulement l'empreinte ?

Vous avez trois choix, par ordre croissant de ce que vous engagez sur la chaîne.

Empreinte seule. La preuve la plus compacte et la plus discrète. Elle suffit lorsque vous savez déjà que le fichier sera conservé quelque part sous votre contrôle. Le record porte le condensé et rien sur la manière de le récupérer.

Empreinte plus un lien adressé par le contenu. Joignez une URI ar:// (Arweave) ou ipfs:// (IPFS) pour que les vérificateurs puissent récupérer les octets plus tard. L'empreinte décide toujours si les octets récupérés correspondent — une URI adressée par le contenu lie les octets au lien lui-même, de sorte qu'un vérificateur n'a jamais à faire confiance au gateway, au DNS ou au TLS pour savoir qu'il a récupéré le bon fichier.

Scellé. Chiffrez le fichier, stockez le texte chiffré hors chaîne et placez l'enveloppe scellée dans le record. C'est la voie pour les records confidentiels, la remise à un destinataire nommé et la récupération ultérieure du contenu si votre copie locale est perdue.

Pour une première preuve, commencez par l'empreinte seule. Ajoutez la signature, le stockage hors chaîne, le regroupement Merkle ou la remise scellée quand un cas d'usage réel l'exige.

Comment savoir si cela a vraiment fonctionné ?

Ne vous arrêtez pas à « le gateway l'a accepté ». La preuve n'est complète que lorsque la transaction est sur la chaîne et qu'elle se vérifie.

Lorsque vous publiez, le gateway renvoie immédiatement un identifiant de record, et l'empreinte de transaction se complète de façon asynchrone une fois la transaction construite et soumise. Ainsi, après la publication, conservez :

l'empreinte de la transaction Cardano ;
l'identifiant de record du gateway, si vous avez utilisé un gateway ;
le fichier ou le condensé d'origine ;
l'identité publique de la clé de signature, si vous avez signé ;
toute liste de feuilles Merkle ou preuve d'inclusion, si vous avez regroupé ;
tout élément de récupération, si la preuve est scellée.

Ensuite, vérifiez la transaction exactement comme le ferait n'importe quel tiers — depuis la chaîne publique, sans aucun gateway impliqué :

cardanowall verify <tx-hash> --json

Un verdict valid est la ligne d'arrivée. Les autres verdicts vous indiquent quoi faire ensuite :

pending — la transaction ne s'est pas encore assez profondément ancrée. Attendez davantage de confirmations, puis réessayez.
unverifiable — aucune faute dans le record, mais une vérification requise n'a pas pu s'exécuter. Contrôlez vos sources de données, la disponibilité du stockage hors chaîne et la politique réseau.
failed — un problème réel, imputable au record. Examinez le record lui-même.

La distinction entre failed et unverifiable est délibérée : failed signifie que le record est erroné, tandis que unverifiable signifie que le vérificateur n'a pas pu mener une vérification à son terme. Pour le déroulé complet de la vérification, voyez vérifier un record Label 309.

Que devrait afficher une interface après la publication ?

Une bonne interface montre plus que le mot « publié ». Pour une première preuve, faites apparaître :

l'empreinte de transaction abrégée, avec un bouton de copie ;
l'empreinte de transaction complète dans la vue détaillée ;
l'algorithme de hachage et le condensé ;
le statut de publication ;
l'heure du bloc, une fois la transaction confirmée ;
le verdict de vérification ;
si le record a été signé ou non ;
si des fichiers ont été joints ou scellés ;
si des vérifications ont été ignorées.

Cela rend la preuve compréhensible sans obliger quiconque à lire la spécification.

Qu'est-ce qui peut mal tourner à la publication ?

La plupart des échecs de publication sont d'ordre opérationnel, et non mystérieux. Le compte peut être à court de solde. Le devis peut avoir expiré. Le record peut être trop volumineux pour une transaction Cardano. Un fichier téléversé peut échouer à se stocker. La transaction Cardano peut échouer définitivement — auquel cas un gateway bien conçu annule lui-même la charge, de sorte que vous n'êtes facturé que pour ce qui se grave sur la chaîne. Ou bien le portefeuille approvisionné du gateway peut tout simplement réclamer de l'attention.

Un workflow de publication sérieux gère les nouvelles tentatives de manière idempotente. Un gateway dédoublonne une nouvelle tentative de publication d'après les octets exacts du record — resoumettre le record identique renvoie le résultat existant au lieu de dépenser deux fois — et accepte une clé d'idempotence sur les lots de téléversement, afin qu'un téléversement renvoyé soit insensible aux rejeux. Dans un produit destiné aux utilisateurs, concevez le chemin de nouvelle tentative avant que votre premier vrai client ne rencontre un dépassement de délai réseau, et non après.

Si vous intégrez cela dans une chaîne de traitement, utiliser la CLI en automatisation approfondit la sortie JSON, les codes de sortie et la gestion sûre des secrets.

Qu'est-ce que votre première preuve ne prouve pas ?

Une preuve d'existence est précise sur ce qu'elle affirme, ce qui veut dire qu'elle l'est aussi sur ce qu'elle n'affirme pas.

Elle ne prouve pas la propriété.
Elle ne prouve pas la paternité — sauf si vous la signez et pouvez relier la clé de signature à l'identité revendiquée.
Elle ne prouve pas que le fichier est véridique, licite ou original.
Elle ne conserve pas le fichier, à moins que vous ne le stockiez dans un lieu durable.

Ce qu'elle prouve, en revanche, est exact et durable : les octets précis correspondant à l'empreinte engagée existaient au plus tard à l'heure du bloc de la transaction, et toute signature optionnelle, vérification de stockage ou vérification de contenu scellé s'est vérifiée selon la politique du vérificateur.

C'est suffisant pour être réellement utile, et assez précis pour inspirer confiance. Pour cerner plus largement ce qu'un horodatage peut et ne peut pas établir, voyez ce qu'une preuve ne prouve pas.

Pour aller plus loin

Vérifier un record Label 309 — l'autre moitié du déroulé, sans confiance et sans compte.
Pourquoi la publication a un prix — ce que paient les frais.
Utiliser la CLI en automatisation — sortie JSON, codes de sortie et secrets en CI.
Ce qui va sur la blockchain — les champs qu'un record porte réellement.
Le standard ouvert et les implémentations de référence : label309.org et le code source sur github.com/cardanowall.