Serialisierter Block

Die Serialisierung ist der Weg, auf dem aus einem abstrakten Block etwas wird, das sich hashen, senden und speichern lässt. Der Genesis-Block serialisiert zu 285 Bytes: 80 für den Header, 1 für den Transaktionszähler und 204 für seine einzige Coinbase-Transaktion. Wenn Sie jemals rohen Hex-Code in einen Block-Explorer eingefügt oder getblock mit verbosity 0 ausgeführt haben, dann war das genau das, was Sie vor sich hatten.

So funktioniert es

Drei Teile stehen in einem serialisierten Block direkt hintereinander, und nur der erste hat eine feste Länge.

Der Header ist immer 80 Bytes groß, in dieser Reihenfolge: eine 4 Byte große Version, der 32 Byte große Hash des vorherigen Headers, die 32 Byte große Merkle-Wurzel, ein 4 Byte großer Zeitstempel, die 4 Byte große nBits-Zielkodierung und ein 4 Byte großer Nonce. Danach kommt die Anzahl der Transaktionen, geschrieben in compactSize, einer Ganzzahl variabler Länge, die bei Zählern unter 253 1 Byte belegt und bei sehr großen Werten bis zu 9 Bytes. Dann folgen die Transaktionen selbst, jede vollständig serialisiert, die Coinbase zuerst.

Seit BIP144 hat derselbe Block zwei zulässige Serialisierungen. Die gestrippte Form lässt die Witness-Daten vollständig weg und ist das, was Software vor 2017 erwartet. Die vollständige Form enthält sie und markiert jede Transaktion mit Witness-Daten mit einem 0x00-Byte, gefolgt von einem 0x01-Flag, dort, wo sonst die Anzahl der Eingaben stünde. Beide kodieren denselben Block, und beide erzeugen denselben Block-Hash, weil der Hash nur diese 80 Header-Bytes umfasst und die darin enthaltene Merkle-Wurzel auf die Transaktions-IDs verweist, die aus der gestrippten Kodierung berechnet werden. Diese Trennung ist die wörtliche Bedeutung von Segregated Witness.

Eine Eigenheit erwischt jeden mindestens einmal: Ganzzahlen mit mehreren Bytes werden little endian geschrieben, der Zeitstempel 0x495FAB29 erscheint im Netzwerk also als 29 ab 5f 49, und Hashes werden in der umgekehrten Reihenfolge ihrer serialisierten Bytes angezeigt. Ein Block-Hash, den Sie aus einem Explorer kopieren, ist nicht die Bytefolge, die in der Datei steht.

Wo Sie ihm begegnen

Serialisierte Blöcke wandern im Peer-to-Peer-Netzwerk in einer block-Nachricht. Jede Nachricht trägt zuerst einen 24 Byte großen Umschlag: einen 4 Byte großen Start-String, f9beb4d9 im Mainnet, einen 12 Byte großen Befehlsnamen, eine 4 Byte große Nutzlastlänge und eine 4 Byte große Prüfsumme aus den ersten vier Bytes eines doppelten SHA-256 über die Nutzlast. Bitcoin Core begrenzt die Nutzlast einer einzelnen Nachricht auf 4.000.000 Bytes, eine Grenze des Netzwerks und nicht des Konsenses.

Dieselben Bytes landen auf Ihrer Festplatte. Bitcoin Core hängt Blöcke an Dateien mit den Namen blk00000.dat und aufsteigend an, jede auf 128 MiB begrenzt, mit demselben Start-String und einem Längenpräfix vor jedem Block, damit die Datei linear durchsucht werden kann. Der Genesis-Block ist die Ausnahme: Er ist als Konstante in die Software kompiliert und wird nicht heruntergeladen, was ihn zum Anker macht, an dem ein synchronisierender Node alles andere misst.

Im Alltag zeigt sich die Serialisierung über getblock mit verbosity 0, über den Reiter für Rohdaten oder Hex-Code in den meisten Explorern und in Werkzeugen, mit denen sich ein Block von Hand dekodieren lässt. Wer prüft, ob ein Explorer ihm die Wahrheit gesagt hat, landet hier, denn der Hex-Code ist die einzige Darstellung, die niemand umformatiert hat.

Serialisierter Block vs. Block

Ein Block ist das Objekt; ein serialisierter Block ist eine seiner Kodierungen. Der Unterschied war rein formal bis 2017, als SegWit jedem Block zwei gültige Kodierungen unterschiedlicher Länge gab, sodass die Größe eines Blocks zu einer Frage wurde, die präzisiert werden muss. Bitcoin Core beantwortet sie in einer einzigen RPC-Antwort auf drei Weisen: size für die vollständige Serialisierung, strippedsize für die ohne Witness-Daten und weight für die Zahl, die die Regeln tatsächlich durchsetzen.