Ralph Merkle

Vous voulez envoyer un message chiffré. Son destinataire a besoin d’une clé secrète pour le lire, mais comment la lui transmettre si quelqu’un observe tous les échanges ? Dans son article de 1978, Ralph Merkle décrit une méthode surprenante : l’expéditeur prépare de nombreuses énigmes chiffrées ; le destinataire en résout une choisie au hasard et renvoie publiquement l’identifiant caché à l’intérieur. Tous deux connaissent alors une clé commune. L’espion voit aussi l’identifiant, mais ignore quelle énigme le contenait. Dans le modèle décrit, son travail augmente de façon quadratique avec la taille du problème, tandis que celui des participants augmente de façon linéaire. Cet écart est quadratique, pas exponentiel. Cette avancée historique n’est pas une recommandation actuelle pour chiffrer ses messages. [1]

Il faut comprendre ce que l’adversaire peut faire dans l’article de 1978. Il peut écouter, mais les modifications et les falsifications restent supposées détectables. Imaginez une personne qui lit vos lettres, puis une autre qui les réécrit et signe à votre place. Le second cas exige une protection supplémentaire : vérifier l’identité de votre interlocuteur. L’écart de travail informatique ne répond pas à cette question. Les énigmes ne garantissent donc pas la sécurité de n’importe quelle communication passant par un intermédiaire actif. Elles montrent qu’un accord sans clé secrète préalablement partagée est possible, sous les hypothèses énoncées. [1]

Le Merkle Tree répond à une autre question. Cet arbre d’authentification figure dans la thèse de Merkle de 1979. Imaginez des archives de contrats : vous voulez vérifier un contrat précis sans télécharger toutes les archives. On calcule pour chaque élément un hash, une courte empreinte numérique. Les empreintes sont regroupées par paires et hachées à nouveau, jusqu’à obtenir une racine commune. Le hachage ne chiffre pas le contenu ; il permet d’en vérifier la correspondance. Il faut disposer d’une racine préalablement authentifiée, c’est-à-dire d’une empreinte confirmée des bonnes archives. Si un fraudeur fournit à la fois son document et une racine de son choix, leur correspondance ne prouve rien sur les archives originales. [2]

Prenons un arbre binaire équilibré contenant 8 éléments. Pour vérifier une feuille choisie, il faut 3 hash voisins : à chaque niveau, l’empreinte de la branche adjacente. À partir de votre feuille et de ces empreintes, vous recalculez la racine, puis la comparez à la racine authentifiée. La feuille elle-même et la racine ne sont pas comptées parmi ces hash auxiliaires. Il faut aussi connaître la structure de l’arbre et l’ordre d’assemblage : le voisin se place-t-il à gauche ou à droite ? L’économie ne vient pas d’une astuce avec des données cachées. Les parties éloignées des archives sont représentées par leurs empreintes ; leurs documents complets sont inutiles pour cette vérification précise. [2]

Un Merkle Tree établit le lien entre un élément et un ensemble de données donné. Il ne rend pas vraie une information fausse. Nos archives peuvent contenir un contrat avec un nom erroné ; une preuve peut confirmer correctement sa présence sans repérer cette erreur. De même, une empreinte ne prouve pas que l’auteur avait le droit de rédiger le document. Il faut distinguer les questions : cet élément correspond-il à cette racine, d’où vient la racine, et selon quelles règles accepte-t-on le contenu ? Cette distinction aide à comprendre ce que la même technique permet dans Bitcoin et ce que les autres composantes doivent assurer. [2]

Bitcoin utilise un Merkle Tree pour relier les transactions à l’en-tête du bloc, son enregistrement compact. La racine figure dans l’en-tête ; modifier les transactions incluses affecte leur empreinte commune. Satoshi Nakamoto décrit cette construction dans la section 7 du whitepaper et cite les travaux de Merkle. Cela atteste une influence technique, pas la création de Bitcoin par Merkle. L’arbre ne choisit pas l’historique valide et ne vérifie pas les signatures des transactions à la place des nœuds. Bitcoin l’associe à d’autres règles, dont la vérification des transactions et Proof of Work, une preuve de travail informatique. Comprendre une composante suppose de ne pas lui attribuer les capacités du système entier. [3]

La section 8 du whitepaper décrit SPV, la vérification simplifiée des paiements. Un client léger utilise les en-têtes de blocs et une branche reliant une transaction à un bloc donné. Il économise des données, mais repose sur des hypothèses concernant la chaîne au travail cumulé le plus élevé et le comportement des mineurs. Une preuve d’inclusion ne contrôle pas à elle seule toutes les règles des transactions comme le fait un Full Node, un nœud qui les vérifie intégralement. Elle ne dit pas non plus si une sortie a été dépensée par la suite : cela nécessite de connaître les événements ultérieurs. Pour débuter, retenez que « ce paiement est dans ce bloc » ne constitue pas une vérification complète des fonds disponibles maintenant. [3]

La thèse de 1979 utilise également un arbre d’authentification pour un ensemble fini de signatures numériques à usage unique. Une signature numérique permet de vérifier qu’un message a été approuvé par le détenteur d’une clé secrète ; ce n’est pas l’image d’une signature manuscrite. L’arbre peut relier de nombreuses valeurs de vérification à une seule racine connue. Dans cette construction, le nombre de signatures est toutefois limité et la racine doit finir par être renouvelée. Cela n’autorise pas à réutiliser indéfiniment la même clé à usage unique. Cette partie plus avancée des travaux de Merkle illustre une idée récurrente : vérifier ce dont on a besoin avec une petite preuve, tout en connaissant précisément ses conditions de validité. [2]