Alexander Neitzel · geprüft 25.10.2026 · aktualisiert 25.10.2026 · 8 Min. Lesezeit
In Kürze
Ein Merkle Tree (Hashbaum) fasst viele Einträge Stufe für Stufe zu Hashwerten zusammen, bis ein einziger Wert übrig bleibt, die Wurzel.
In Bitcoin steht diese Wurzel als Merkle Root im Block Header; keine Transaktion des Blocks lässt sich ändern, ohne den Header zu ändern.
Ein Merkle Proof (Beweis über einen Merkle-Baum) zeigt, dass ein Eintrag im Baum liegt; er besteht aus den fehlenden Knoten auf dem Weg vom Blatt zur Wurzel, nicht aus allen anderen Einträgen.
Zusammen mit den Block Headern der längsten Proof-of-Work-Kette kann ein Light Client so Zahlungen prüfen, ohne einen Full Node zu betreiben; die Transaktion selbst prüfen kann er damit nicht.
NiveauAufbauStufe 2 von 3
Baut auf1Hash Function
Ein Merkle Tree (Hashbaum) stellt eine prüfbare Beziehung zwischen vielen einzelnen Daten her; am Ende steht ein einziger Wurzelwert, mit dem sich Aussagen über diese Daten beweisen lassen. Dieser Artikel erklärt, wie der Baum entsteht, wie man mit ihm zeigt, dass ein Eintrag enthalten ist, und wo er eingesetzt wird. Vorausgesetzt wird nur, was eine Hash Function (Hashfunktion) ist.
01Wozu braucht man einen Merkle Tree?
Im Block Header (Blockkopf) eines Bitcoin-Blocks steht der Merkle Root (Wurzelhash): ein einziger Wert, abgeleitet aus den Hashwerten aller Transaktionen des Blocks. Keine dieser Transaktionen lässt sich deshalb ändern, ohne auch den Header zu ändern.
Laut Bitcoin Developer Reference wird ein Block Header in einem Format von 80 Byte serialisiert. Wie dieser eine Wert entsteht und wie man mit ihm einzelne Transaktionen nachweist, zeigen die nächsten Abschnitte.
02Wie entsteht ein Merkle Tree?
In der Beschreibung von RFC 6962 ist die Eingabe eine Liste von Dateneinträgen: Jeder Eintrag wird gehasht und bildet ein Leaf (Blatt), und heraus kommt ein einziger Hashwert. Darüber wächst der Baum Stufe für Stufe, denn jeder Knoten ist entweder ein Blatt oder wird aus den zwei Knoten direkt unter ihm berechnet.
In Bitcoin wird der Merkle Root aus den TXIDs (Transaktionskennungen) aller Transaktionen des Blocks gebaut, nachdem sie in die von den Konsensregeln verlangte Reihenfolge gebracht wurden. Ab drei Transaktionen werden die TXIDs der Reihe nach gepaart; jedes Paar wird zu 64 Byte aneinandergehängt und mit SHA256(SHA256()) gehasht, so entsteht die zweite Reihe. Das wiederholt sich Reihe für Reihe, bis nur noch zwei Hashwerte übrig sind; diese beiden werden aneinandergehängt und gehasht, und das Ergebnis ist der Merkle Root.
Die Abbildung im Bitcoin-Whitepaper beschriftet die Blätter mit Hash0 bis Hash3, die Stufe darüber mit Hash01 und Hash23 und die Wurzel mit Root Hash.
Grafik 1 · Der Baum nach der Abbildung im Bitcoin-Whitepaper. Jeder innere Knoten entsteht aus den zwei Knoten darunter; hell hervorgehoben ist der Weg von Hash3 zur Wurzel; die Wurzel ist als Ergebnis gold. Die Hashwerte Hash2 und Hash01 (Marke „Beweis“) werden für den Nachweis von Tx3 mitgeliefert, die Transaktion Tx2 nicht.Grafik 1 in Worten
Die Grafik zeigt einen Merkle Tree mit vier Blättern. Im Querformat und im Hochformat ist der Aufbau gleich; im Hochformat sind die Kästen schmaler. Unten stehen nebeneinander die Blätter Hash0, Hash1, Hash2 und Hash3. In jedem Blatt steht klein die Transaktion, zu der es gehört: Tx0, Tx1, Tx2 und Tx3. Pfeile führen von Hash0 und Hash1 nach oben zu Hash01 und von Hash2 und Hash3 nach oben zu Hash23. Von Hash01 und Hash23 führen Pfeile zur Wurzel ganz oben, dem Root Hash mit der Zweitzeile „Merkle Root“. Hash3 und Hash23 sind hell umrandet, der Root Hash ist als Ergebnis gold umrandet, und die Pfeile von Hash3 zu Hash23 und von Hash23 zum Root Hash sind hell und dicker: Das ist der Weg von Tx3 zur Wurzel. Über den Kästen von Hash2 und Hash01 steht links die Marke „Beweis“: Diese beiden Hashwerte werden für den Nachweis von Tx3 mitgeliefert, die Transaktion Tx2 selbst nicht. Die Grafik zeigt keine echten Hashwerte.
Für Fortgeschrittene: Bitcoin im Detail: sehr kleine Blöcke und eine ungerade Anzahl
Enthält ein Block nur eine einzige Transaktion, die Coinbase-Transaktion, dient deren TXID direkt als Merkle Root. Kommt genau eine weitere Transaktion hinzu, werden die beiden TXIDs der Reihe nach zu 64 Byte aneinandergehängt und mit SHA256(SHA256()) direkt zum Merkle Root gehasht. Ist die Zahl der TXIDs ungerade, wird die letzte TXID mit einer Kopie ihrer selbst aneinandergehängt und gehasht.
03Wie beweist man, dass eine Transaktion enthalten ist?
Ein Merkle Proof (Beweis über einen Merkle-Baum) ist die kürzeste Liste zusätzlicher Knoten, mit der sich der Hashwert der Wurzel berechnen lässt; RFC 6962 nennt ihn Audit Path (Prüfpfad). Geprüft wird von unten nach oben: Auf jeder Stufe wird ein Knoten aus dem Pfad mit dem bisher berechneten Knoten kombiniert. Stimmt die so berechnete Wurzel mit der echten Wurzel überein, ist der Pfad der Beweis, dass das Blatt im Baum liegt.
Das Bitcoin-Whitepaper zeigt dazu einen Merkle Branch (Merkle-Zweig) für die Transaktion Tx3. Nach RFC 9162 besteht ein solcher Beweis aus den fehlenden Knoten, die man für den Weg vom Blatt zur Wurzel braucht. Wendet man diese Regel auf das Beispiel an, braucht der Prüfer neben Hash3 nur Hash2 und Hash01, aber keine der anderen Transaktionen. Vergleichbar ist das mit einer Wegbeschreibung, die nur die Abzweigungen auf dem einen Weg nennt und nicht die ganze Karte zeigt.
In einem Beispiel der NIST-Empfehlung SP 800-208 mit acht Blättern sind es drei zusätzliche Hashwerte, nämlich h3, h01 und h4−7.
04Wie prüft ein Light Client eine Zahlung?
Laut Bitcoin-Whitepaper lassen sich Zahlungen prüfen, ohne einen Full Node (Teilnehmer, der alles prüft) zu betreiben. Ein solcher Prüfer, hier Light Client (leichter Client) genannt, braucht nur die Block Header der längsten Proof-of-Work-Kette und den Merkle-Zweig, der die Transaktion mit ihrem Block verbindet.
Im Bitcoin-Netzwerk liefert ihm eine merkleblock-Nachricht die TXIDs der Transaktionen, die zu einem Filter passen, und die Teile des Merkle Tree, die sie mit dem Merkle Root verbinden. Übertragen werden dabei Hashwerte von Transaktionen und Merkle-Knoten, jeder 32 Byte groß. Außerdem enthält die Nachricht eine vollständige Kopie des Block Headers, damit der Client ihn hashen und den Proof of Work (Arbeitsnachweis) prüfen kann. Die merkleblock-Nachricht wurde mit der Protokollversion 70001 eingeführt, wie BIP 37 sie beschreibt. Laut den Release Notes zu Bitcoin Core 0.19 ist die Bedienung von BIP-37-Bloom-Filtern und das Ausliefern von Merkle-Blöcken dort standardmäßig abgeschaltet. Als neueres Verfahren beschreibt BIP 157, wie Light Clients kompakte Filter des Blockinhalts von Full Nodes holen und ganze Blöcke laden, wenn der Filter zu relevanten Daten passt. Die ersten Filtertypen legt BIP 158 fest.
Grafik 2 · Der Nachweis im Bitcoin-Netzwerk nach dem Verfahren BIP 37 in der Darstellung der Bitcoin Developer Reference. ② bis ④ sind Teile derselben merkleblock-Nachricht, keine zeitliche Folge; diese Nachricht ist nur ein Teil der Antwort. Aus ihr rechnet der Light Client die Wurzel nach und vergleicht sie mit dem Merkle Root im Header.Grafik 2 in Worten
Zwei Linien stehen für den Light Client und den Full Node. Im Querformat verläuft die Linie des Light Client oben und die des Full Node unten, im Hochformat steht der Light Client links und der Full Node rechts. Vier nummerierte Pfeile zeigen Anfrage und Antwort in der Darstellung der Bitcoin Developer Reference. ① Anfrage vom Light Client zum Full Node, gefilterter Block. ② TXID-Liste (merkleblock) vom Full Node zum Light Client, Filter-Treffer. ③ Merkle-Knoten (merkleblock) vom Full Node zum Light Client, Hashwerte, je 32 Byte. ④ Block Header (merkleblock) vom Full Node zum Light Client, zum Nachrechnen. Die Pfeile zwei bis vier tragen alle den Zusatz „(merkleblock)“: Sie sind Teile derselben merkleblock-Nachricht, ihre Nummern zählen die Teile und sind keine zeitliche Folge. Die merkleblock-Nachricht ist nur ein Teil der Antwort.
Die Grenze: Der Light Client kann die Transaktion nicht selbst prüfen, sieht aber an ihrer Stelle in der Kette, dass ein Netzwerkknoten sie akzeptiert hat. Laut Bitcoin-Whitepaper ist diese Prüfung zuverlässig, solange ehrliche Knoten das Netzwerk kontrollieren, aber verwundbarer, wenn ein Angreifer das Netzwerk überwältigt.
05Wo wird der Merkle Tree außerhalb von Bitcoin eingesetzt?
Certificate Transparency (Zertifikatstransparenz) ist ein Protokoll, das die Existenz von TLS-Serverzertifikaten öffentlich protokolliert. Die Eigenschaft, dass jedes Log von Certificate Transparency nur ergänzt wird (append-only), wird technisch mit Merkle Trees erreicht: Mit ihnen lässt sich zeigen, dass jede Version eines Logs eine Obermenge jeder früheren Version ist. So muss man einem Log nicht blind vertrauen: Zeigt es verschiedenen Personen Verschiedenes, lässt sich das durch den Vergleich der Wurzeln und durch Consistency Proofs (Konsistenzbeweise) effizient feststellen.
Ethereum kodiert seinen Zustand, also alle Konten, Guthaben und Smart Contracts (auf der Blockchain gespeicherter Programmcode), in einer Sonderform des Merkle Tree. Alle Merkle-Bäume in Ethereums Ausführungsschicht sind Merkle Patricia Tries (Präfixbäume mit Hashverkettung), und aus einem Block Header gehen drei Wurzeln aus drei dieser Bäume hervor.
Für Fortgeschrittene: Certificate Transparency: Blätter und Knoten getrennt hashen
In Certificate Transparency muss die Zahl der Einträge keine Zweierpotenz sein; der Baum kann dann unausgeglichen sein, seine Form ist aber durch die Zahl der Blätter eindeutig bestimmt. Blätter und innere Knoten werden dort unterschiedlich gehasht, und laut RFC 6962 ist diese Domain Separation (Domänentrennung) nötig, um Second Preimage Resistance (Zweit-Urbild-Resistenz) zu erreichen. In RFC 9162 entsteht der Hashwert eines inneren Knotens aus einem vorangestellten Byte 0x01 und den aneinandergehängten Hashwerten seiner beiden Teilbäume.
Für Fortgeschrittene: Merkles Signaturbaum und hash-basierte Signaturen
Laut der NIST-Empfehlung SP 800-208 nutzen die Signaturverfahren XMSS und LMS Merkle-Hashbäume; dadurch bleibt der langfristige Public Key (öffentlicher Schlüssel) sehr kurz, dafür braucht jeder Einmal-Schlüssel etwas Zusatzinformation. Für den Baum werden die Public Keys der One-Time Signatures (Einmal-Signaturen) einmal gehasht und bilden die Blätter; diese Hashwerte werden dann paarweise zur nächsten Ebene gehasht. Für „Merkle hash trees“ verweist NIST auf Merkles Dissertation an der Stanford University aus dem Jahr 1979.
In seinem Beitrag zur Konferenz CRYPTO '87 beschreibt Merkle einen Authentication Tree (Beglaubigungsbaum) für Signaturen, keinen Baum aus Transaktionen: Ein öffentlich bekannter Wert beglaubigt dort die Wurzel des Baums. Nach Merkle kann dieses Verfahren beliebig viele Nachrichten signieren, und die Signaturgröße wächst nur logarithmisch mit der Zahl der signierten Nachrichten.
06Speichert ein Merkle Tree die Daten?
Der Merkle Tree von Bitcoin speichert nicht die Transaktionen selbst: Sie werden darin gehasht, und nur die Wurzel geht in den Hash des Blocks ein. Die Transaktionen stehen im Block nacheinander im Rohformat. Laut Bitcoin-Whitepaper können, sobald die jüngste Transaktion einer Münze unter genügend Blöcken liegt, die davor ausgegebenen Transaktionen verworfen werden, um Speicherplatz zu sparen. Alte Blöcke lassen sich dann verkleinern, indem man Äste des Baums abschneidet; die inneren Hashwerte müssen nicht gespeichert werden.
In Ethereums Merkle Patricia Trie besteht ein Blattknoten aus zwei Teilen, einem kodierten Pfad und einem Wert. Nach Darstellung der Ethereum-Entwicklerdokumentation liegen die Knoten dieses Baums in einer Schlüssel-Wert-Datenbank, mit ihrem Hash als Schlüssel; diese Inhaltsadressierung sichert die Integrität der gespeicherten Daten.
Welche Narrative gerade breit besprochen werden, zeigt der Orbit.
07Häufige Missverständnisse
Beweist ein Merkle Proof, dass eine Transaktion gültig ist?
Nein. Er zeigt, dass ein Blatt im Baum liegt, die Transaktion also zu diesem Block gehört. Ein Light Client kann die Transaktion damit nicht selbst prüfen. Er sieht an der Verknüpfung mit der Kette, dass ein Netzwerkknoten sie akzeptiert hat.
Braucht man für den Nachweis alle Transaktionen eines Blocks?
Nein. Es genügt die kürzeste Liste zusätzlicher Knoten, mit der sich der Hashwert der Wurzel berechnen lässt. Im Bitcoin-Netzwerk liefert eine merkleblock-Nachricht dafür die TXIDs der passenden Transaktionen und die nötigen Teile des Baums.
Funktioniert ein Merkle Tree nur mit einer geraden Zahl von Einträgen?
Nein. In Bitcoin wird bei einer ungeraden Zahl von TXIDs die letzte TXID mit einer Kopie ihrer selbst aneinandergehängt und gehasht. Bei Certificate Transparency muss die Zahl der Einträge keine Zweierpotenz sein; der Baum darf dort unausgeglichen sein, seine Form ergibt sich eindeutig aus der Zahl der Blätter.
