Tous les articles

11 min de lecture

Preuve d'existence ou OpenTimestamps : quel horodatage convient à votre travail ?

OpenTimestamps excelle pour des horodatages nus, ancrés sur Bitcoin. Label 309 ajoute un record de preuve natif de Cardano, avec signatures, scellement, destinataires et regroupement Merkle — voici comment choisir.

Si vous avez seulement besoin d'un horodatage compact et portable que n'importe qui peut vérifier face à une blockchain publique, OpenTimestamps est un choix excellent et ciblé. Si vous avez besoin d'un record de preuve sur la chaîne plus riche — capable de porter aussi des signatures, des contenus scellés (chiffrés), une remise à des destinataires, des pointeurs de stockage adressés par le contenu et un regroupement Merkle —, Label 309 est conçu pour cela. Les deux se recoupent sur l'affirmation centrale (« ces octets existaient avant l'instant T ») et divergent sur tout le reste.

Tous deux prouvent l'existence à une date donnée sans vous demander de faire confiance au serveur d'une entreprise. La différence tient à la forme : OpenTimestamps produit un petit fichier de preuve externe ; Label 309 publie un record structuré sur Cardano. Cet article précise les cas où chacun trouve sa place.

Qu'est-ce qu'OpenTimestamps ?

OpenTimestamps est un protocole et un ensemble d'outils d'horodatage par blockchain, le plus souvent ancré sur Bitcoin. L'idée est simple : vous hachez vos données, construisez une preuve d'horodatage, et l'engagement finit par atterrir dans une transaction Bitcoin. À partir de là, n'importe qui peut vérifier que les données existaient avant l'instant de ce bloc.

Pour maîtriser les coûts, OpenTimestamps recourt à des serveurs de calendrier qui agrègent les empreintes de nombreux utilisateurs dans une seule transaction Bitcoin : vous n'avez donc pas besoin d'une transaction par fichier. Le client produit un fichier de preuve .ots portable qui voyage aux côtés de vos données.

C'est à la vérification que le modèle de confiance se révèle : vous vérifiez la preuve .ots face au fichier d'origine et à une vue de la chaîne Bitcoin, sans aucun serveur de confiance dans la boucle. Le client officiel précise que la vérification locale exige un nœud Bitcoin Core — un nœud élagué suffit.

C'est une conception élégante et éprouvée, dédiée à des horodatages minimaux et vérifiables de façon indépendante.

Qu'est-ce que Label 309 ?

Label 309 est un standard ouvert et indépendant du fournisseur, dédié aux records de preuve d'existence sur Cardano. Le record réside dans les métadonnées d'une transaction Cardano sous le label 309, et l'instant du bloc de cette transaction est le témoin que les octets engagés existaient au plus tard à ce moment-là. Le standard est l'artefact durable ; l'application web, l'outil en ligne de commande et les SDK de CardanoWall en sont des implémentations de référence, situées en aval.

Le standard a été soumis au processus CIP de Cardano et est en cours d'examen par les éditeurs CIP, en tant que proposition de catégorie Metadata (la pull request ouverte apparaît actuellement sous un numéro provisoire). Notez que l'identifiant sur la chaîne — le label de métadonnées 309 — est distinct de tout numéro CIP qui lui sera finalement attribué.

Pour vérifier une preuve Label 309, chacun récupère la transaction Cardano depuis un explorateur public, reconstitue le record canonique, en valide la structure, vérifie la profondeur de confirmation, contrôle les éventuelles signatures et recalcule les empreintes de contenu engagées ou les preuves d'inclusion Merkle. Au plus simple, il répond à la même question qu'OpenTimestamps. Mais ce n'est pas un fichier de preuve unique — c'est un format de record sur la chaîne conçu pour porter plusieurs couches de preuve à la fois. Pour une présentation plus complète, voyez comment fonctionne Label 309 et ce qui se retrouve réellement sur la blockchain.

Quelle est la véritable différence entre les deux ?

OpenTimestamps est taillé pour l'horodatage. Label 309 est conçu pour un record complet de preuve d'existence.

OpenTimestamps convient mieux lorsque la question est :

  • ce fichier existait-il avant cet instant attesté par Bitcoin ?
  • puis-je conserver un petit fichier de preuve et le vérifier plus tard ?
  • puis-je horodater sans révéler le contenu du fichier ?
  • les serveurs de calendrier peuvent-ils regrouper de nombreuses requêtes pour que je ne paie pas par fichier ?

Label 309 convient mieux lorsque la question est :

  • ce fichier, ce manifeste ou cette racine de Merkle existait-il à cet instant de bloc Cardano ?
  • une clé d'identité spécifique a-t-elle signé le record ?
  • le fichier lui-même peut-il être scellé (chiffré) puis récupéré plus tard ?
  • le record peut-il être chiffré pour des destinataires précis ?
  • un seul record peut-il s'engager sur des milliers ou des millions de feuilles à la fois ?
  • le public peut-il le vérifier sans compte CardanoWall et sans accès à nos serveurs ?

Tous deux sont des systèmes de preuve enracinés dans un consensus public. Leur forme — et donc les flux de travail qu'ils ouvrent — diffère.

Que fait OpenTimestamps particulièrement bien ?

OpenTimestamps donne le meilleur de lui-même pour un horodatage public et minimal, articulé autour d'un objet de preuve externe. Vous horodatez un fichier, gardez la preuve .ots à ses côtés, puis enrichissez la preuve une fois l'engagement confirmé dans Bitcoin. Le modèle de calendrier permet à de nombreux utilisateurs de partager le coût de l'ancrage.

Sa portée volontairement restreinte est aussi une qualité. Il ne cherche pas à devenir un système de remise confidentielle, un standard de provenance des médias, un écosystème de signature logicielle ni un notaire juridique. Il horodate, et il fait ce seul travail proprement. Pour qui veut des horodatages adossés à Bitcoin à partir d'un outil éprouvé, cette concentration est un atout.

Qu'ajoute Label 309 par-dessus l'horodatage ?

Label 309 enveloppe de structure l'affirmation d'horodatage. Un seul record peut inclure :

  • une ou plusieurs empreintes de contenu par élément ;
  • des pointeurs de stockage adressés par le contenu (ar:// pour Arweave, ipfs:// pour IPFS) ;
  • des signatures facultatives au niveau du record, portant sur l'ensemble du record ;
  • une enveloppe de chiffrement pour un élément scellé, le texte chiffré étant conservé hors de la chaîne ;
  • des emplacements de clé par destinataire qui enveloppent la clé de contenu à l'intention des destinataires choisis ;
  • des engagements Merkle qui lient une racine sur la chaîne à une liste de feuilles hors chaîne de taille arbitraire ;
  • un pointeur de remplacement vers un record antérieur (en mode ajout uniquement — il ne révoque jamais le record précédent) ;
  • des clés d'extension à espaces de noms, réservées à de futures spécifications complémentaires.

Cela compte dès qu'un flux de travail a besoin de plus que « j'ai un fichier de preuve d'horodatage ». Par exemple, un expéditeur peut sceller un fichier, l'adresser à un destinataire, publier le texte chiffré à une URI adressée par le contenu et conserver malgré tout un record public vérifiable de façon indépendante — voyez hacher, signer, sceller, partager. Un service d'IA à fort volume peut publier une seule racine de Merkle qui tient lieu de nombreuses sorties générées, et un pipeline CI/CD peut signer un record de preuve de version couvrant tout un ensemble de manifestes — voyez un record pour des milliers de fichiers. Ces flux de travail réclament un record plus riche que ce que porte une simple preuve .ots.

Lequel est le plus décentralisé ?

Ce n'est pas le lieu des slogans : soyons donc précis sur ce que chaque modèle vous demande de tenir pour acquis.

OpenTimestamps s'ancre sur Bitcoin, dont l'historique de preuve de travail est une base très solide pour l'horodatage. La preuve se vérifie de façon indépendante dès que les données dont elle a besoin sont disponibles — une preuve .ots complète se vérifie intégralement face à un nœud Bitcoin local, tandis qu'une preuve incomplète a encore besoin d'un serveur de calendrier pour fournir le chemin vers l'en-tête de bloc.

Label 309 s'ancre sur Cardano. Sa vérification ne se fie qu'à la chaîne Cardano publique, aux octets du record et à l'empreinte du contenu — rien d'autre. Elle n'exige aucune confiance envers CardanoWall ni envers un serveur exploité par l'éditeur pour la preuve centrale ; un vérificateur n'a besoin que de la référence de transaction, éventuellement des octets du contenu, et d'un explorateur public qu'il choisit lui-même.

Aucun des deux n'est « plus décentralisé » dans l'absolu. La vraie question est de savoir quelle chaîne, quel outillage, quelle forme de preuve, quel modèle de coût et quel écosystème conviennent à votre flux de travail.

Et la confidentialité — l'un ou l'autre divulgue-t-il le fichier ?

Tous deux peuvent horodater sans publier le fichier privé, et tous deux ont des limites assumées.

Les serveurs de calendrier d'OpenTimestamps reçoivent des engagements, pas des fichiers en clair. Mais le projet reconnaît franchement que l'horodatage divulgue des métadonnées : créer plusieurs horodatages en succession rapprochée permet à un adversaire de les relier, regrouper des fichiers en une seule commande produit des opérations d'engagement quasi identiques qui suggèrent un auteur commun, et l'API REST du calendrier ne cherche pas actuellement à offrir de confidentialité. Les nonces empêchent le calendrier d'apprendre ce qui a été horodaté, mais les métadonnées environnantes ne sont pas dissimulées.

Label 309 garde le texte en clair hors de la chaîne pour les preuves limitées à l'empreinte ; pour les preuves scellées, il chiffre le texte en clair et ne stocke que le texte chiffré à une URI adressée par le contenu. Par conception, la chaîne ne révèle aucune clé publique de destinataire — un destinataire ne reconnaît un message qu'en parvenant à déchiffrer à l'essai l'un de ses emplacements, de sorte qu'il n'y a aucun champ de destinataire à lire. Ce qu'elle ne peut toujours pas cacher, c'est la temporalité, le paiement des frais, l'accès au gateway, le comportement du compte et les erreurs opérationnelles ordinaires. Un record scellé garde le texte en clair lisible uniquement par les détenteurs de la clé ; il ne garantit pas l'anonymat, et un destinataire peut toujours divulguer le texte en clair après l'avoir déchiffré.

Dans les deux systèmes, la confidentialité est une propriété de l'ensemble du flux de travail, et non du seul format de preuve.

Peut-on utiliser les deux ensemble ?

Oui — et pour les records à fort enjeu, cela peut en valoir la peine. Pour disposer de deux voies temporelles publiques indépendantes, ancrez le même manifeste avec les deux :

  1. Créez votre manifeste de version, de jeu de données, de média ou de pièces.
  2. Hachez le manifeste.
  3. Créez une preuve OpenTimestamps pour l'empreinte ou le fichier.
  4. Publiez une preuve Label 309 pour le même manifeste, ou pour une racine de Merkle qui le contient.
  5. Conservez les deux références de preuve aux côtés des pièces d'origine.

Vous obtenez ainsi une voie orientée Bitcoin et une voie native de Cardano, structurée selon Label 309. Utilisez les deux lorsque la redondance supplémentaire vaut la charge opérationnelle ; pour la plupart des travaux, une seule suffit largement.

Quand choisir OpenTimestamps ?

Choisissez OpenTimestamps lorsque le travail consiste en un horodatage nu et qu'une preuve ancrée sur Bitcoin est exactement ce que vous voulez. Il convient bien pour :

  • les horodatages de fichiers simples ;
  • les flux de travail d'horodatage Git ou PGP ;
  • les équipes qui font déjà tourner la vérification Bitcoin et lui font confiance ;
  • les flux de travail qui préfèrent transporter un fichier de preuve .ots externe ;
  • les engagements minimaux qui n'ont besoin d'aucun record plus riche sur la chaîne.

Il est volontairement ciblé, et cette concentration est précisément son intérêt.

Quand choisir Label 309 ?

Choisissez Label 309 lorsque le record de preuve lui-même demande plus qu'un horodatage. Il convient bien pour :

  • une preuve d'existence native de Cardano ;
  • des records signés qui lient la paternité à la preuve ;
  • des fichiers scellés (chiffrés) engagés sur la chaîne ;
  • une remise confidentielle à des destinataires précis ;
  • le regroupement Merkle pour des ensembles volumineux ou récurrents ;
  • des pointeurs de stockage adressés par le contenu ;
  • les voies web, API, CLI, SDK ou gateway auto-hébergé de CardanoWall ;
  • des protocoles applicatifs qui veulent un format de preuve partagé sous le label de métadonnées 309.

L'ensemble est open source sous github.com/cardanowall, si bien que vous n'êtes jamais prisonnier de l'outillage d'un seul fournisseur pour lire ou écrire un record. Voyez Label 309 est open source et comment vérifier un record vous-même.

Que ne prouve aucun des deux systèmes ?

Ni l'un ni l'autre ne prouve à lui seul la vérité, la propriété, la paternité, la légalité ou la qualité. OpenTimestamps prouve un engagement horodaté. Label 309 prouve un engagement horodaté, plus toutes les couches facultatives qu'un record porte. Dans les deux cas, une preuve montre que des octets exacts existaient à une date publique — pas qui a raison, qui possède quoi, ni si le contenu est licite. Les affirmations qui l'entourent réclament toujours des signatures, un contexte d'identité, des preuves de processus, une analyse juridique et un jugement humain. Nous détaillons ce point dans ce qu'une preuve ne prouve pas.

En bref

OpenTimestamps est un système d'horodatage solide, ciblé et ancré sur Bitcoin. Label 309 est un format de record de preuve d'existence natif de Cardano, avec de la place pour les signatures, la préservation scellée, la remise à des destinataires, le stockage adressé par le contenu, le regroupement Merkle et de futures extensions. Choisissez celui dont la forme de preuve correspond à la question à laquelle vous avez réellement besoin de répondre — ou utilisez les deux lorsque la redondance en vaut la peine.

Pour l'ensemble de comparaisons plus large, voyez Preuve d'existence ou autorité d'horodatage et l'article fondateur qu'est-ce qu'une preuve d'existence.

Pour aller plus loin

proof-of-existenceopentimestampstimestamping