Arbres de Merkle et preuve de réserves : comment un condensat verrouille des millions de soldes

Un arbre de Merkle permet à une plateforme de publier une seule valeur courte qui l’engage d’un coup sur chaque solde d’utilisateur. Chaque utilisateur devient une feuille, les feuilles sont hachées deux à deux vers le haut jusqu’à ce qu’il ne reste qu’une racine, et toute modification en dessous produit une racine entièrement différente. C’est pourquoi une racine publiée est un engagement et non une promesse, et pourquoi vous prouvez votre présence sans voir les données de personne.

Le problème que résout un arbre de Merkle

Une plateforme veut dire quelque chose sur des millions de soldes sans les publier. Publier la liste exposerait chaque client ; publier un total ne prouve rien, car un total peut être assemblé à partir de n’importe quel ensemble de nombres.

Il faut une valeur assez courte pour être publiée, dérivée de chaque solde, et impossible à concilier avec un autre ensemble de soldes. La plateforme s’engage alors publiquement sur l’ensemble entier, tandis que chaque utilisateur vérifie séparément que sa ligne faisait partie de ce sur quoi elle s’est engagée.

C’est exactement le travail d’un arbre de Merkle, et cela explique pourquoi l’on prend cette structure plutôt qu’un simple condensat d’une liste concaténée. Un condensat plat changerait aussi si les données changeaient, mais il vous obligerait à détenir chaque solde pour le vérifier, ce qui ruine l’exigence de confidentialité.

Les pièces, nommées

Lisez deux fois la deuxième ligne. Une feuille est le condensat d’une chaîne précise, et si la chaîne est construite autrement le condensat diffère : c’est pourquoi la version de l’algorithme doit être publiée avec la racine.

Comment se construit une feuille

Une feuille est le condensat d’un court texte décrivant un compte à l’instant de l’instantané. Ce texte nomme la version de l’algorithme, l’identifiant de la publication à laquelle il se rattache, un identifiant d’enregistrement pour le compte, et les soldes dans les actifs couverts.

Deux règles de format font plus de travail qu’il n’y paraît. Les soldes s’écrivent avec un nombre fixe de décimales, si bien qu’un même montant produit toujours le même texte, et les actifs apparaissent dans un ordre fixe plutôt que dans celui qu’un système aurait émis au hasard. Sans l’une ou l’autre, deux implémentations hacheraient le même compte différemment et la vérification indépendante échouerait pour des raisons sans rapport avec l’honnêteté.

Le compte est désigné par un identifiant d’enregistrement et non par quoi que ce soit vous concernant. C’est ce qui permet de publier la structure de l’arbre tout en restant muet sur qui s’y trouve. Les champs publiés autour sont traités dans comment lire un rapport de preuve de réserves.

Comment l’arbre se construit vers le haut

Les feuilles sont combinées deux à deux. Deux condensats sont joints en une chaîne, cette chaîne est hachée et donne un nœud au niveau supérieur ; ces nœuds sont appariés de la même façon, et le processus se répète jusqu’à ce qu’une seule valeur subsiste.

L’ordre compte à chaque jonction, et c’est ce détail qui fait trébucher ceux qui écrivent un vérificateur. Chaque étape a un côté gauche et un côté droit, et les hacher dans le mauvais ordre donne un autre résultat. Un fichier de preuve consigne donc non seulement quel condensat voisin utiliser à chaque niveau, mais de quel côté il se trouve, et votre vérificateur doit respecter cette instruction plutôt que de trier les deux valeurs.

Comme l’arbre se réduit de moitié à chaque niveau, le chemin de n’importe quelle feuille à la racine est court. Un ensemble de millions de comptes produit une preuve de quelques dizaines de condensats, et c’est pourquoi ce contrôle s’exécute instantanément sur un téléphone sans télécharger tout le jeu de données.

Pourquoi une falsification se voit

Les fonctions de hachage ont la propriété qu’une petite modification en entrée produit une sortie sans rapport. Modifiez un solde du plus petit montant représentable et le condensat de sa feuille change entièrement, son parent change, et avec lui chaque nœud du chemin jusqu’à la racine.

C’est ce qui transforme la publication en engagement. Une fois la racine publique, la plateforme ne peut ni corriger un solde, ni insérer un compte, ni en retirer un sans produire une racine différente. Elle ne peut pas le faire en silence, ni le faire pour un utilisateur sans casser la vérification de tous ceux dont le chemin passe par la même branche.

L’engagement ne lie que si la racine a été publiée avant que quiconque ait intérêt à ce qu’elle soit fausse : le moment et la trace publique de la racine pèsent donc autant que les mathématiques. Comment mener la comparaison vous-même est décrit dans comment vérifier une preuve de réserves.

Pourquoi vos voisins restent confidentiels

Votre chemin de preuve contient des condensats d’autres parties de l’arbre, et un condensat ne se renverse pas en les données dont il provient. Vous apprenez qu’un voisin existe et quel est son condensat ; vous n’apprenez rien sur les soldes qui se trouvent en dessous ni sur leur montant.

Cette asymétrie est exactement ce qui rend la structure adaptée au problème. Chaque utilisateur confirme sa propre présence et aucun n’apprend rien d’un autre, sans que la plateforme ait à faire confiance à quiconque ni à publier une liste de clients.

Les implémentations renforcent généralement cela en exécutant le contrôle localement plutôt qu’en renvoyant vos données à un serveur. L’argument de confidentialité et l’argument de vérifiabilité pointent ici dans la même direction, ce qui est rare et mérite d’être noté.

Là où la structure cesse d’aider

Un arbre de Merkle prouve l’appartenance à un ensemble. Il dit que votre ligne figurait dans l’arbre dont la racine a été publiée, et il ne dit strictement rien sur le fait que cet ensemble était le bon.

Trois limites en découlent directement. L’arbre ne peut pas dire si tous les comptes ont été inclus, car un compte omis ne laisse aucune trace pour ceux qui restent. Il ne peut pas dire si les actifs existent, ce qui est une affirmation on-chain distincte et non une propriété de la structure. Et il ne dit rien des engagements au-delà des soldes entrés, ce dont traite preuve de réserves et engagements.

Rien de tout cela n’est un défaut de la cryptographie. C’est la frontière de ce qu’on peut demander à une preuve d’appartenance, et connaître la frontière empêche de survendre la structure.

En résumé

Un arbre de Merkle transforme des millions de soldes en une valeur publiable et donne à chaque utilisateur un court chemin prouvant que sa ligne se trouve dessous. Les feuilles sont des condensats d’enregistrements à format fixe, les nœuds des condensats de paires, et l’ordre de concaténation à chaque niveau fait partie de la spécification plutôt que d’être un détail.

Sa force est qu’une falsification après publication ne peut être cachée et que l’appartenance se prouve sans exposer personne. Sa frontière est qu’il ne prouve que l’appartenance : la complétude de l’ensemble, l’existence des actifs et le montant des engagements se tiennent hors de l’arbre. Poursuivez votre lecture avec Bitbase Academy.

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d’information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.

Sources

[1] Bitbase, Preuve de réserves — publication mensuelle, racine de Merkle et vérificateur open source www.bitbase.com