23 / 736HDR

Block Header

Blockkopf

Der kleine Teil eines Blocks, der seinen Inhalt mit der bisherigen Geschichte verbindet und die Prüfung der Rechenarbeit ermöglicht.

Der Block Header ist ein kurzer Datensatz am Anfang eines Bitcoin-Blocks. Er enthält einen Fingerabdruck des vorherigen Blocks, einen gemeinsamen Fingerabdruck der Transaktionen und Angaben zur Prüfung des Proof of Work. Die Zahlungen selbst stehen in einem anderen Teil des Blocks.

Stellen Sie sich einen Block als Paket von Transaktionen vor und den Header als Begleitdatensatz. Empfänger und Beträge sind darin nicht aufgelistet. Stattdessen enthält er kryptografische Fingerabdrücke: kurze, aus Daten berechnete Werte, mit denen sich Änderungen erkennen lassen. Einer verweist auf den vorherigen Block. Ein weiterer Fingerabdruck, Merkle root genannt, fasst die Kennungen der Transaktionen dieses Blocks zusammen. So verknüpft der Header einen bestimmten Inhalt mit einer bestimmten Stelle in der Geschichte. Er ist aber keine verkleinerte Kopie der Transaktionen: Aus dem Fingerabdruck lässt sich deren Inhalt nicht zurücklesen. [1] [4]

Ein Miner stellt einen Blockkandidaten zusammen und sucht einen passenden Hash, also einen als Zahl interpretierten Fingerabdruck. Dieser muss kleiner oder gleich dem vorgegebenen Zielwert sein. Diese Suche heißt Proof of Work: Der Miner ändert immer wieder Daten und berechnet einen neuen Hash, weil sich ein passendes Ergebnis nicht einfach vorhersagen lässt. Die bekannteste Variable ist die nonce, eine Hilfszahl im Header. Für weitere Möglichkeiten kann er etwa Daten der besonderen Coinbase Transaction am Blockanfang ändern. Dadurch ändern sich auch Merkle root und Header. Andere Nodes können das gefundene Ergebnis anschließend schnell nachrechnen. [1] [3] [4]

An einer Kette von Headern lassen sich die Verknüpfungen der Blöcke und die zugehörige Arbeit prüfen, ohne alle Transaktionen herunterzuladen. Stellen Sie sich jedoch einen Block mit gültigem Proof of Work vor, in dem jemand ohne die erforderliche Signatur fremde Mittel ausgeben will. Eine reine Headerprüfung erkennt diesen Fehler nicht. Ein Full Node prüft deshalb auch Transaktionen, Signaturen, verfügbare ungenutzte Ausgänge und die zulässige Belohnung. Ein gültiger Header garantiert also keinen vollständig gültigen Block. [2]

Das Feld nBits gibt den Zielwert an, den der Hash erfüllen muss. Es enthält eine kompakte Kodierung dieses Ziels, nicht die im Blockexplorer angezeigte „difficulty“. Der Node prüft zusätzlich, ob der Zielwert den Regeln für diese Stelle in der Kette entspricht. Auch die Zeit darf der Miner nicht beliebig wählen. Sie muss nach dem Median der vorherigen 11 Blöcke liegen, also dem mittleren Wert ihrer sortierten Zeitangaben, und darf nicht zu weit in der Zukunft liegen. Trotzdem ist sie weder die genaue Uhrzeit jeder Zahlung noch eine Messung der benötigten Miningdauer. [2] [3]

Reihenfolge und Größen sind festgelegt: version 4 Bytes, Hash des vorherigen Headers 32, Merkle root 32, time 4, nBits 4 und nonce 4. Zusammen sind das 80 Bytes, unabhängig von der Transaktionszahl. Die Blockkennung entsteht durch zweimalige Anwendung von SHA-256 auf diesen exakt kodierten Header. Zahlenfelder verwenden little-endian, das niedrigstwertige Byte steht also zuerst; Hashes haben eine interne Bytefolge, die von der üblichen Darstellung einer Kennung abweicht. Für eine eigene Berechnung genügt es daher nicht, die Werte so aneinanderzuhängen, wie ein Explorer sie anzeigt. [1] [4]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Block, Proof of Work, Merkle Tree, Nonce. Auf diesen Eintrag verweisen außerdem Block, Hash, SHA-256, Merkle Tree.

DOC · 001Bitcoin Core v29.0: header serializationPrimärquelle DOC · 002Bitcoin Core v29.0: header validationPrimärquelle DOC · 003Bitcoin Core v29.0: proof of workPrimärquelle DOC · 004Bitcoin Developer Reference: Block HeadersPrimärquelle
Überarbeitet: Quellenbasiert · Keine Anlageberatung