---
title: "Arbre de Merkle"
description: "Un arbre de Merkle engage des données ordonnées avec un seul hash racine et permet des preuves d'inclusion compactes sans transférer tout l'ensemble."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Arbre de Merkle
> À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Investir peut entraîner des pertes.
## Réponse directe
Un arbre de Merkle hache chaque donnée en une feuille, combine les hashes voisins à plusieurs reprises et produit une racine de Merkle. Cette racine engage les feuilles ainsi que les règles d'ordre et de hachage utilisées.
Une preuve de Merkle contient le hash frère de chaque niveau pour une feuille. Le vérificateur recalcule le chemin vers la racine et n'accepte l'inclusion que si le résultat correspond à une racine de confiance. Il n'a donc pas besoin des autres feuilles.
L'engagement porte sur la représentation des données, pas sur leur vérité. Une racine correspondante ne prouve ni l'exactitude de la source, ni la disponibilité des données, ni la sécurité d'un contrat, pont, oracle ou marché. Le vérificateur doit obtenir la racine et la feuille via un protocole authentifié et comprendre la séparation de domaine, l'ordre et les règles des feuilles impaires.
Les arbres de Merkle apparaissent dans plusieurs conceptions. Bitcoin place la racine des transactions dans chaque en-tête de bloc ; Ethereum utilise un Trie de Merkle-Patricia modifié pour l'état et d'autres structures authentifiées. Les encodages, formats de preuve, règles de mise à jour et hypothèses de sécurité diffèrent.
## Fonctionnement
Le système définit un encodage déterministe des feuilles et une fonction de hachage. Il hache chaque feuille, hache les paires d'enfants pour créer les parents, puis répète jusqu'à obtenir une racine. La preuve doit fournir la position ou la direction de la feuille si le protocole ne permet pas de la déduire.
Dans un arbre binaire équilibré, une preuve pour une feuille parmi 1024 nécessite environ 10 hashes frères, car chaque niveau double la plage couverte. La taille exacte dépend de la forme, de la longueur du hash, de la politique de duplication et des preuves multiples ou compressées.
La relation centrale s'écrit `parent = Hash(left || right)` et `root = fold(parent, leaves)`. C'est une notation schématique : un protocole peut préfixer les hashes, employer une autre arité ou encoder des clés dans un trie. La preuve établit la cohérence avec la construction prévue, pas l'authenticité d'une racine que le vérificateur n'a pas approuvée séparément.
Dans une blockchain, la racine est engagée par un en-tête, un enregistrement d'état ou un contrat. Un client léger demande une feuille et son chemin, recalcule la racine, puis applique les règles de confirmation, finalité, fraîcheur et disponibilité. Vérifier les hashes ne remplace pas ces règles.
## Exemple
Supposons un bloc contenant 1024 transactions dans un arbre binaire. Une transaction peut être accompagnée d'environ 10 hashes frères au lieu de transmettre les 1023 autres. Le vérificateur a tout de même besoin de l'en-tête et des règles d'encodage et de position.
En cas d'échec, examinez les octets de la feuille, l'ordre des octets, le remplissage, la source de la racine et l'état du bloc avant de conclure à l'absence. Une preuve valide pour une racine non finalisée ou ancienne peut être techniquement correcte sans représenter l'état canonique.
Pour un solde ou une récompense affichés, séparez la validité de la preuve du résultat économique. Frais, variation de prix, glissement, permissions du contrat, limites de retrait ou indisponibilité de la source peuvent encore modifier le montant. La preuve établit une appartenance, pas un montant rachetable.
## Risques
Les risques techniques principaux sont les encodages ambigus, le mauvais usage du hash, les faiblesses de seconde préimage ou de collision, l'ordre erroné des frères et l'acceptation d'une racine non fiable ou périmée. La séparation de domaine doit être appliquée uniformément.
Les risques opérationnels dépassent le calcul. Un pont, un oracle, un séquenceur, une plateforme ou un administrateur peut publier, retarder, censurer ou remplacer la racine ; une panne de disponibilité peut empêcher d'obtenir la feuille ou la preuve ; une réorganisation peut invalider une preuve liée à un bloc ancien.
Avant de faire confiance à une preuve, identifiez qui authentifie la racine, comment sont vérifiées fraîcheur et finalité, comment sont traitées les feuilles manquantes ou impaires et si les utilisateurs peuvent récupérer leurs données. Limitez autorisations et exposition lorsque la perte potentielle ne peut être bornée.
## Idées reçues
### Mythe 1 : Une racine correspondante prouve la vérité des données
Elle prouve seulement que la feuille fournie est cohérente avec la racine engagée selon la construction. Un oracle qui engage une valeur erronée fera donc vérifier cette valeur erronée.
### Mythe 2 : Une preuve de Merkle rend le système entièrement sans confiance
Le vérificateur fait encore confiance au hash, aux encodages, au chemin d'authentification et au système qui fournit les données. Consensus, finalité, disponibilité et gouvernance restent distincts.
### Mythe 3 : Toutes les blockchains utilisent le même arbre
Les arbres de transactions de Bitcoin, le Trie de Merkle-Patricia d'Ethereum et les arbres applicatifs ont des formats et règles différents. Une preuve ne se transpose pas automatiquement.
### Mythe 4 : Une preuve courte garantit une transaction bon marché et sûre
La taille réduit le transfert, mais le gas de vérification, les lectures, la congestion, les bugs et les risques de retrait ou de liquidation peuvent dominer.
## Sujets associés
- [Blockchain](/fr/crypto/blockchain/)
- [Hash cryptographique](/fr/crypto/cryptographic-hash/)
- [Client léger](/fr/crypto/light-client/)
- [Ethereum](/fr/crypto/ethereum/)
- [Disponibilité des données](/fr/crypto/data-availability/)
## Sources
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté le 2026-08-21)
- [Merkle Trees](https://developer.bitcoin.org/devguide/block_chain.html#merkle-trees) - Bitcoin.org (consulté le 2026-08-21)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation (consulté le 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/merkle-tree/index.mdx