Header

Was ist ein Block Header?

Der Block Header ist der „Kopf“ eines Bitcoin-Blocks. Er enthält die wichtigsten Informationen über den Block, während die eigentlichen Transaktionen separat gespeichert werden.

Jeder Bitcoin-Block besitzt genau einen Header. Seine Struktur ist fest definiert und hat immer eine Größe von 80 Bytes.

Aus dem Block Header wird der Blockhash berechnet. Er verbindet den Block mit seinem Vorgänger, enthält die Merkle Root der Transaktionen und liefert die Daten, die für Proof-of-Work benötigt werden.

Aufbau eines Block Headers

Ein Block Header besteht aus sechs Feldern mit fester Reihenfolge und Größe.

Gemeinsam enthalten sie alle Informationen, die benötigt werden, um einen Block zu identifizieren, mit seinem Vorgänger zu verknüpfen und Proof-of-Work zu überprüfen. Beim Node laufen diese Prüfungen in der Blockvalidierung.

Der Header wird auf der Netzwerkebene und in der Blockchain nicht als Tabelle gespeichert, sondern als Folge von 80 Bytes serialisiert.

Der Header von Block 825000 sieht beispielsweise so aus:

00e0d020f6d6008880ac145009739b2833412709addcdb255aba010000000000000000000da 9542333c185a8add906acda78de91617a580d5cb8ee16fb74204d0401026092449d6569d803176c52eb4e

Die einzelnen Felder liegen dabei direkt hintereinander im Header. Das folgende Diagramm zeigt, welcher Bereich der Bytefolge zu welchem Feld gehört.

Version

Die Version ist das erste Feld im Block Header und belegt 4 Bytes.

Im Header von Block 825000:

Da Zahlen im Block Header im Little-Endian-Format gespeichert werden, müssen die Bytes zunächst umgedreht werden, bevor der Wert gelesen werden kann.

Auf den ersten Blick wirkt dieser Wert ungewöhnlich. Man könnte erwarten, hier einfach eine Versionsnummer wie 1, 2, 3 oder 4 zu finden.

Tatsächlich wurde das Feld in den frühen Jahren von Bitcoin genau dafür verwendet. Alte Blöcke enthalten daher oft einfache Versionsnummern:

Mit der Zeit erhielt das Feld jedoch eine zusätzliche Aufgabe. Anstatt nur eine Versionsnummer zu speichern, können Miner heute einzelne Bits innerhalb dieses Feldes verwenden, um ihre Unterstützung für neue Konsensregeln zu signalisieren.

Deshalb enthalten moderne Blöcke häufig komplexe Werte statt einer einfachen Versionsnummer:

Die Version wird heute nicht mehr nur als einfache Versionsnummer verwendet. Stattdessen können einzelne Bits innerhalb der 32 Bit genutzt werden, um die Unterstützung neuer Konsensregeln zu signalisieren.

Auf diese Weise konnte das Bitcoin-Netzwerk in der Vergangenheit Änderungen wie SegWit oder Taproot koordinieren, ohne dass alle Teilnehmer gleichzeitig aktualisiert werden mussten.

Wie ein verteiltes Netzwerk neue Regeln einführt und welche Rolle Miner, Nodes und Softforks dabei spielen, betrachten wir später ausführlicher.

Beim Einlesen eines Blocks muss das Feld zusammen mit den übrigen Header-Feldern korrekt deserialisiert werden. Das ist Teil der Blockvalidierung, bevor Header-Regeln und Proof-of-Work greifen.

Previous Block Hash

Der Previous Block Hash ist das zweite Feld im Block Header und belegt 32 Bytes.

Im Header von Block 825000:

Dieses Feld enthält den Blockhash des vorherigen Blocks.

Block 825000 speichert hier also den Blockhash von Block 824999. Dadurch entsteht die Verkettung der Blockchain: Jeder neue Block verweist auf seinen direkten Vorgänger.

Wird ein neuer Block gefunden, übernimmt der Miner den Blockhash des aktuellen Spitzenblocks und speichert ihn als Previous Block Hash im Header des neuen Blocks.

Auf diese Weise entsteht eine fortlaufende Kette von Blöcken, bei der jeder Block kryptografisch mit seinem Vorgänger verbunden ist.

Warum ist dieses Feld wichtig?

Da jeder Block den Hash seines Vorgängers enthält, wirkt sich eine Änderung an einem Block auch auf alle nachfolgenden Blöcke aus.

Würde sich beispielsweise der Inhalt von Block 824999 ändern, entstünde ein anderer Blockhash. Der gespeicherte Previous Block Hash in Block 825000 würde dann nicht mehr zum tatsächlichen Hash von Block 824999 passen.

Die Verkettung wäre unterbrochen und der Block würde von den Nodes als ungültig erkannt. In der Blockvalidierung muss hashPrevBlock auf einen bekannten Vorgänger zeigen.

Genau diese kryptografische Verkettung macht nachträgliche Änderungen an der Blockchain so aufwendig.

Merkle Root

Die Merkle Root ist das dritte Feld im Block Header und belegt 32 Bytes.

Im Header von Block 825000:

Dieses Feld enthält einen Hash, der alle Transaktionen des Blocks zusammenfasst.

Anstatt jede Transaktion direkt im Header zu speichern, wird aus allen Transaktionen zunächst ein Merkle Tree aufgebaut. Die oberste Hashsumme dieses Baums wird als Merkle Root im Block Header gespeichert.

Dadurch reichen 32 Bytes aus, um auf sämtliche Transaktionen des Blocks zu verweisen.

Warum ist dieses Feld wichtig?

Die Merkle Root verbindet den Block Header mit den Transaktionen des Blocks.

Bereits die Änderung einer einzigen Transaktion führt zu einer anderen Merkle Root. Da die Merkle Root Teil des Block Headers ist, verändert sich dadurch auch der Blockhash.

Sie ermöglicht es Nodes, effizient zu überprüfen, ob Transaktionen zu einem Block gehören, ohne alle Transaktionen speichern oder übertragen zu müssen.

Jeder Node berechnet den Merkle-Baum aus der Transaktionsliste neu und vergleicht das Ergebnis mit dem Header. Stimmt der Wert nicht, scheitert die Merkle-Root-Prüfung.

Timestamp

Der Timestamp ist das vierte Feld im Block Header und belegt 4 Bytes (32 Bit).

Im Header von Block 825000:

Ein Unix Timestamp ist dabei nichts anderes als eine fortlaufende Zahl, die angibt, wie viele Sekunden seit dem Zeitpunkt Epoch (1970-01-01 00:00:00 UTC) vergangen sind.

Da Zahlen im Block Header im Little-Endian-Format gespeichert werden, müssen die Bytes zunächst umgedreht werden, bevor der Wert gelesen werden kann.

Warum ist der Timestamp wichtig?

Der Timestamp liefert dem Netzwerk einen gemeinsamen zeitlichen Bezugspunkt für Blöcke.

Er wird unter anderem bei der Difficulty-Anpassung verwendet. Alle 2016 Blöcke vergleicht Bitcoin die Zeitstempel des ersten und letzten Blocks eines Difficulty-Zeitraums, um abzuschätzen, wie schnell neue Blöcke gefunden wurden.

Außerdem spielt der Timestamp bei der Blockvalidierung eine Rolle. Nodes akzeptieren nur Zeitstempel, die innerhalb bestimmter Grenzen liegen und mit der bisherigen Blockchain konsistent sind: nicht zu früh gegenüber dem Median Time Past und nicht mehr als zwei Stunden in der Zukunft.

Der Timestamp ist damit ein wichtiger Bestandteil der Konsensregeln und der Difficulty-Anpassung.

Bits

Bits ist das fünfte Feld im Block Header und belegt 4 Bytes (32 Bit).

Im Header von Block 825000:

Das Feld enthält das aktuelle Target in einer kompakten Darstellung.

Da das vollständige Target 256 Bit groß ist, würde seine Speicherung im Block Header viel Platz benötigen. Bitcoin speichert deshalb stattdessen einen verkürzten 32-Bit-Wert, aus dem jeder Node das ursprüngliche Target wieder berechnen kann.

Das daraus berechnete Target lautet:

Ein Block ist nur gültig, wenn sein Blockhash kleiner oder gleich dem aus Bits berechneten Target ist. Diese Prüfung ist Teil der Proof-of-Work-Regeln und wird von jedem Node bei der Blockvalidierung durchgeführt.

Zusätzlich muss nBits dem für die Blockhöhe erwarteten Schwierigkeitsziel entsprechen. Das prüft der Node in den Header-Regeln (bad-diffbits).

Bits dient daher als kompakte Repräsentation der aktuellen Mining-Schwierigkeit und ermöglicht jedem Node die Überprüfung des Proof-of-Work.

Die genaue Umrechnung von Bits zum Target und zur Difficulty behandeln wir später ausführlich.

Nonce

Die Nonce ist das sechste Feld im Block Header und belegt 4 Bytes (32 Bit).

Im Header von Block 825000:

Die Nonce ist ein frei veränderbarer Zähler, den Miner während des Proof-of-Work verändern, um neue Blockhashes zu erzeugen.

Da die Nonce 32 Bit groß ist, existieren insgesamt 2³² = 4.294.967.296 mögliche Werte.

Für jeden Nonce-Wert wird ein neuer Blockhash berechnet. Bereits die Änderung eines einzelnen Bits der Nonce führt zu einem vollständig anderen Hashwert.

Sind alle 4.294.967.296 Nonce-Werte ausprobiert, verändert der Miner weitere Daten des Blockkandidaten, beispielsweise den Zeitstempel oder die Coinbase-Transaktion.

Dadurch entsteht ein neuer Block Header, dessen Nonce erneut von 0 bis 4.294.967.295 durchgezählt werden kann.

Ein Block ist nur gültig, wenn sein Hash kleiner oder gleich dem aktuellen Target ist. Ob das erfüllt ist, prüft der Node in der Proof-of-Work-Validierung.

Wie Miner dabei Milliarden von Hashversuchen erzeugen und welche Rolle die sogenannte Extra Nonce spielt, betrachten wir später im Detail auf der Seite Proof-of-Work.

Wie entsteht der Blockhash?

Der Blockhash entsteht durch zweimaliges SHA256-Hashing des vollständigen Block Headers.

Im folgenden Beispiel wird der serialisierte Header von Block 825000 gehasht. Die Eingabe der Hashfunktion ist dabei die 80 Byte lange Bytefolge des Headers, dargestellt als Hexadezimalwert.

Der Blockhash ist nicht direkt im Block gespeichert.

Er entsteht erst durch das zweimalige SHA256-Hashing des Block Headers und wird von jedem Node selbst berechnet.

Der oben gezeigte Blockhash ist daher das Ergebnis der Metadaten im Header von Block 825000.

Warum werden nur 80 Bytes gehasht?

Der Block Header ist immer genau 80 Bytes groß.

Die eigentlichen Transaktionen können dagegen mehrere Megabyte umfassen.

Da die Merkle Root bereits alle Transaktionen des Blocks kryptografisch zusammenfasst, genügt es, ausschließlich den Header zu hashen.

Bereits eine Änderung an einer einzigen Transaktion verändert die Merkle Root, den Header und damit auch den Blockhash. Für die Chainwork zählt deshalb der Hash über genau diese 80 Bytes.

Weiterführende Themen

Der Block Header verbindet viele zentrale Bestandteile des Bitcoin-Protokolls.

Wenn du die einzelnen Felder und den Blockhash verstanden hast, sind diese Themen die nächsten logischen Schritte:

• Merkle Tree
• SHA256
• Proof-of-Work
• Difficulty
• Blockvalidierung
• Header-Regeln
• Proof-of-Work-Validierung
• Merkle-Root-Prüfung
• Konsensregeln
• Chainwork
• Softforks

Live-Beispiel

Die folgenden Daten stammen von meiner eigenen Full Node und zeigen einen aktuellen Bitcoin-Block in Echtzeit.