Un seul record pour des milliers de fichiers : le regroupement Merkle

Un seul record Label 309 peut prouver que des milliers, voire des millions de fichiers existaient à un instant donné.

Plutôt que de publier une transaction blockchain par fichier, vous calculez l'empreinte de chaque fichier, vous repliez ces empreintes dans un arbre de Merkle et vous publiez une seule racine de Merkle de 32 octets. Vous pouvez ensuite prouver qu'un fichier précis faisait partie de ce lot grâce à une petite preuve d'inclusion — sans révéler les autres, et sans inscrire chaque élément sur la chaîne.

C'est ainsi que la preuve d'existence passe d'un seul document à un ensemble arbitrairement grand.

Quel problème le regroupement Merkle résout-il ?

Les blockchains sont de mauvais endroits où stocker de longues listes. Chaque octet a un coût, et une transaction Cardano est soumise à un plafond de taille strict.

Si un système produit un flux régulier d'artefacts — journaux, sorties de modèles, builds de version, factures, rapports, pièces probantes —, publier chaque empreinte dans son propre record sur la chaîne devient vite coûteux et encombrant.

Le regroupement Merkle compresse une liste ordonnée d'empreintes en un seul engagement sous forme de racine. Cette racine est de taille fixe (32 octets), le lot peut être illimité, et la preuve d'un élément quelconque reste petite — elle ne croît qu'avec le logarithme de la taille du lot. Les engagements réguliers deviennent ainsi praticables pour les flux de travail à fort volume.

Qu'est-ce qu'une racine de Merkle ?

Une racine de Merkle est une empreinte unique qui s'engage sur toute une liste ordonnée.

Commencez par une liste de feuilles. Dans un flux de preuve d'existence, chaque feuille est généralement l'empreinte d'un fichier, d'un événement ou d'une entrée de manifeste. Les feuilles sont combinées deux par deux le long d'un arbre binaire, et l'empreinte au sommet est la racine de Merkle.

L'engagement est exact de trois façons :

si une feuille change, la racine change ;
si l'ordre des feuilles change, la racine change ;
l'engagement enregistre aussi le nombre de feuilles, de sorte qu'une liste de taille différente ne peut pas se faire passer pour le même lot.

Publier la racine revient à publier une empreinte de l'ensemble de la liste ordonnée.

Qu'est-ce qui se retrouve concrètement sur la chaîne ?

La racine, et rien d'autre. La liste complète des feuilles reste hors de la chaîne.

Un record Label 309 porte l'engagement dans un champ merkle dédié, distinct des empreintes ordinaires fichier par fichier. Chaque engagement est une structure compacte et de taille fixe :

l'algorithme d'engagement (Label 309 v1 enregistre rfc9162-sha256 : le Merkle Tree Hash de la RFC 9162 avec SHA-256) ;
la racine de 32 octets ;
le nombre de feuilles, qui lie la racine à la taille de la liste hors chaîne ;
des URI optionnelles adressées par le contenu (ar:// ou ipfs://) pointant vers le fichier de la liste de feuilles.

Le record sur la chaîne reste minuscule — une seule racine s'engage sur une liste illimitée pour un coût fixe de 32 octets. Le détail réside hors de la chaîne, dans la liste ordonnée de feuilles. (Pour savoir où réside le reste d'un record, voir ce qui se retrouve sur la blockchain.)

Comment prouver un seul fichier par la suite ?

Vous produisez une preuve d'inclusion.

Une preuve d'inclusion est la courte liste des empreintes voisines le long du chemin qui mène d'une feuille jusqu'à la racine. Un vérificateur replie la feuille et ces voisines en remontant l'arbre et n'accepte la preuve que si la racine recalculée est exactement égale à la racine publiée.

En pratique, la vérification a quatre entrées :

l'empreinte du fichier ou de l'élément que vous prouvez ;
la preuve d'inclusion (le chemin des voisines) ;
la racine de Merkle dans le record Label 309 ;
l'horodatage de bloc Cardano de la transaction qui l'a portée.

Si le repliement reproduit la racine publiée, l'élément figurait dans la liste engagée — et l'horodatage de bloc atteste du moment où cette liste existait. Le vérificateur n'a besoin que de l'élément concerné et de sa preuve ; il n'a jamais besoin des autres fichiers du lot.

Deux détails méritent d'être bien distingués. La construction est sensible à l'ordre : les feuilles doivent donc être conservées dans la même séquence que celle de leur publication. Et un « arbre » à une seule feuille n'est pas un horodatage utile : la racine d'un arbre à une feuille n'est pas la feuille elle-même ; pour prouver un fichier unique, vous publiez donc une simple empreinte de contenu, et non un engagement Merkle à un seul élément.

Pourquoi la construction et la vérification entièrement hors ligne sont-elles un atout ?

Parce que la seule étape qui touche un serveur est la publication de la racine.

Construire l'arbre, dériver les preuves d'inclusion et les vérifier relèvent du pur calcul. Quiconque détient la liste ordonnée de feuilles peut recalculer la racine et redériver n'importe quelle preuve — sans compte, sans gateway, sans réseau et sans coopération de celui qui a initialement publié. L'éditeur n'intervient jamais au moment de la vérification.

C'est important pour des preuves qui doivent survivre aux outils et aux fournisseurs. Une preuve que vous pouvez vérifier hors ligne, face à un explorateur Cardano public, continue de fonctionner longtemps après la disparition de tel ou tel service. Vous pouvez vérifier l'engagement d'un lot de la même manière que vous vérifieriez n'importe quel record Label 309, et vous pouvez brancher le contrôle d'inclusion directement dans votre CI avec l'outil en ligne de commande open source cardanowall (merkle-build pour replier un dossier en une racine, merkle-verify pour confirmer qu'un élément en fait partie).

Pourquoi est-ce utile pour les flux de travail à fort volume ?

Parce que beaucoup de preuves réelles ont une forme de lot, et non de fichier unique. Une équipe peut avoir besoin de montrer :

ce qu'un pipeline CI/CD a produit et quels artefacts ont été livrés dans une version ;
quelle nomenclature logicielle (SBOM) existait avant la divulgation d'une vulnérabilité ;
quelles sorties d'IA ont été produites un jour donné ;
quel instantané de jeu de données existait avant un entraînement ;
quels journaux de conformité existaient avant un audit ;
quels fichiers de pièces juridiques ont été conservés avant une obligation de conservation ;
quelles réserves un bilan engageait à un instant donné.

Aucun de ces cas ne s'accommode bien d'un modèle « un fichier, une transaction ». Le regroupement Merkle vous permet de publier un seul engagement par lot — sans exposer chaque élément privé, et sans métadonnées sur la chaîne qui croissent linéairement avec la taille du lot.

La liste de feuilles peut-elle rester privée ?

Oui. La racine publiée ne révèle rien sur les feuilles sur lesquelles elle s'engage.

Vous pouvez conserver la liste de feuilles à l'intérieur de votre propre système de preuves, archive de versions, salle de données ou magasin de conformité, et ne révéler ensuite que le strict nécessaire :

un fichier et sa preuve d'inclusion ;
une ligne de jeu de données, un document ou un artefact de version ;
une entrée de journal d'audit ;
un sous-ensemble de la liste ;
ou la liste de feuilles entière.

C'est le schéma à adopter lorsque vous voulez un engagement public et horodaté sans rendre publiques les données sous-jacentes — un cas étroitement lié à la divulgation confidentielle sans fichiers publics et à la preuve de réserves avec des racines de Merkle.

Le compromis tient à la responsabilité. Une racine prouve qu'une liste de taille connue existait à un moment connu ; elle ne permet pas à elle seule de prouver quels éléments précis en faisaient partie. Si vous gardez la liste de feuilles privée, vous devez la préserver. Perdez à la fois la liste de feuilles et toutes les preuves d'inclusion enregistrées, et vous conservez l'horodatage mais perdez la capacité de prouver qu'un élément donné a bien été engagé.

Que doit représenter une feuille ?

Une feuille doit représenter exactement ce que vous pourriez avoir besoin de prouver plus tard.

Pour des fichiers, la feuille est l'empreinte des octets du fichier. Pour des données structurées, c'est généralement l'empreinte d'une entrée de manifeste canonique. Pour la CI/CD, une feuille peut être un condensé d'artefact, un condensé de SBOM, un condensé de journal de build, une référence de commit ou une entrée de manifeste de version signée. Pour la provenance d'IA, une feuille peut être l'empreinte d'un fichier de sortie, une entrée de manifeste prompt/sortie, un engagement sur un élément de jeu de données ou l'empreinte d'un manifeste de provenance de contenu.

La discipline qui compte, c'est la cohérence. Si les feuilles sont générées de façons différentes d'une exécution à l'autre, les preuves d'inclusion ultérieures deviennent difficiles à tenir pour fiables. Fixez une fois pour toutes la définition de la feuille et la mise sous forme canonique, puis appliquez-les de la même manière à chaque fois.

Faut-il publier la liste de feuilles ou la garder privée ?

Cela dépend de ce que vous prouvez et de qui doit le voir.

Publier la liste de feuilles rend la vérification par un tiers triviale : n'importe qui peut récupérer la liste, recalculer la racine et inspecter l'ensemble engagé. La garder privée vous offre confidentialité et divulgation sélective — vous ne révélez les preuves d'inclusion qu'en cas de besoin. De nombreux flux de travail font les deux : une liste de feuilles publique pour les versions open source, une liste privée pour les journaux de conformité internes, une liste scellée pour les pièces sensibles.

La racine est l'engagement public. La politique de liste de feuilles est un choix distinct, qui s'y superpose.

À quelle fréquence faut-il publier des racines ?

Adaptez la cadence au flux de travail.

Un système CI/CD pourra publier une racine par version, par build ou par fenêtre de déploiement. Un système de conformité pourra publier une racine par heure, par jour ou par période de contrôle. Une plateforme d'IA pourra publier des racines par lot de contenu généré, par instantané d'entraînement ou par événement de version de modèle. Un système de pièces juridiques pourra publier une racine par dossier d'affaire, par fenêtre de réception ou par jalon de chaîne de possession.

La bonne cadence concilie le coût, la simplicité opérationnelle et la précision de la chronologie que vous pourriez avoir à prouver par la suite.

Que ne prouve pas une racine de Merkle ?

Une racine de Merkle prouve l'engagement sur une liste à un instant donné. Elle ne prouve pas les affirmations métier qui entourent cette liste. Comme toute preuve d'existence, elle montre que des octets précis existaient avant une date publique — non qu'ils sont vrais, licites, attribuables à quelqu'un en particulier ou détenus par quiconque (voir ce qu'une preuve ne prouve pas).

Concrètement :

elle ne prouve pas qu'un build logiciel était sûr. Elle peut prouver quels artefacts ou manifestes ont été inclus dans une version.
elle ne prouve pas qu'un jeu de données a été collecté licitement. Elle peut prouver qu'un engagement sur un jeu de données existait avant une date donnée.
elle ne prouve pas qu'une entrée de journal est vraie. Elle peut prouver que l'entrée faisait partie d'un lot engagé.
elle ne prouve pas la paternité — sauf si le record ou le processus qui l'entoure ajoute des signatures et des contrôles d'identité.

Dans Label 309, la paternité est optionnelle et explicite : un record peut porter des signatures détachées, mais elles ne sont jamais obligatoires, et un engagement Merkle à lui seul n'affirme rien sur l'auteur de la liste. La racine fournit l'engagement horodaté ; le processus qui l'entoure lui donne son sens métier.

Comment Label 309 s'inscrit-il là-dedans ?

Label 309 est le standard ouvert et indépendant des fournisseurs pour la preuve d'existence sur Cardano ; il 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. Le regroupement Merkle n'est pas un produit distinct — c'est la couche de mise à l'échelle intégrée au standard.

L'engagement d'un lot utilise le même record et le même chemin de vérification qu'une preuve sur un seul fichier. Un seul record sous le label de métadonnées 309 peut porter une racine de Merkle, et à ses côtés les mêmes éléments optionnels que tout record prend en charge : des empreintes ordinaires fichier par fichier, des URI de stockage adressées par le contenu, un pointeur de remplacement vers un record antérieur et des signatures de paternité. Une preuve de lot hérite ainsi de tout ce dont dispose une preuve unique :

un témoin d'horodatage de bloc Cardano ;
une structure de record standard et fermée ;
une vérification autonome et hors ligne face à un explorateur public ;
les mêmes outils, bibliothèques et CLI open source dans tous les langages.

Calculez l'empreinte de chaque élément, construisez un arbre de Merkle ordonné, publiez une racine dans un record Label 309, et conservez la liste de feuilles ainsi que toutes les preuves dont vous pourriez avoir besoin. Plus tard, prouvez qu'un élément quelconque faisait partie du lot engagé — sans inscrire chaque élément sur la chaîne. C'est ce qui rend la preuve d'existence praticable pour la CI/CD, la provenance d'IA, les jeux de données, la conformité, les pièces juridiques et d'autres flux de travail à fort volume.

Pour aller plus loin

Comment fonctionne Label 309 — la structure de record dans laquelle s'insère l'engagement d'un lot.
Prouver des données d'entraînement sans les révéler — la divulgation sélective à partir d'une liste de feuilles privée, de bout en bout.
Comment Label 309 se compare à OpenTimestamps — un autre protocole qui agrège de nombreuses empreintes en un seul ancrage.
Le standard, les SDK et la CLI open source, ainsi que le texte de la spécification : label309.org et github.com/cardanowall.
RFC 9162 — la construction Merkle Tree Hash que Label 309 utilise pour les engagements de lots.