MSG_BLOCK

Vier Byte Typ-Tag entscheiden, welches von mehreren Blockformaten ankommt. Typ 2 bezeichnet das ursprüngliche: einen 80 Byte großen Header, gefolgt von jeder Transaktion vollständig, ohne die Witness-Daten, bis zu den vier Millionen Gewichtseinheiten, die ein Block fassen darf. Ein Node, der mit der Kette aufholt, sendet Tausende solcher Anfragen und kaum etwas anderes.

So funktioniert es

MSG_BLOCK ist eine Zahl und keine Nachricht, und Bedeutung hat sie nur innerhalb der 36 Byte großen Einträge, aus denen inv- und getdata-Nachrichten aufgebaut sind.

Ein Eintrag besteht aus einem vier Byte großen Typ, gefolgt von einem 32 Byte großen Hash, und der Typ sagt dem Empfänger, was der Hash benennt. Eine getdata-Nachricht mit einem Eintrag des Typs 2 zu senden heißt: Ich habe den Hash dieses Blocks, senden Sie mir den Block. Der Peer antwortet mit einer block-Nachricht oder mit notfound, wenn er ihn nicht liefern kann. Ein beschnittener Node gibt notfound für alles zurück, was er bereits gelöscht hat, weshalb ein beschnittener Peer für jemanden, der von Grund auf synchronisiert, nutzlos ist.

Typ 2 allein bedeutet heute etwas Engeres als früher. Seit Segregated Witness 2017 aktiviert wurde, kommt ein so angeforderter Block in der alten Serialisierung ohne Witness-Daten zurück, was nötig war, um ältere Software weiterhin bedienen zu können. Jeder Node, der den Block validieren will, braucht diese Witnesses, also setzt er das Bit 0x40000000 und fordert stattdessen die Witness-Variante an. Zwischen zwei modernen Peers taucht der einfache Code vor allem in Anfragen von Software auf, die niemand aktualisiert hat.

Auch die Ankündigung hat sich weiterentwickelt. BIP130 führte die direkte Header-Ankündigung ein, und seit Bitcoin Core 0.12.0 wird ein neuer Block normalerweise mit einer headers-Nachricht statt mit einer inv-Nachricht angekündigt, sodass dieser Typcode heute überwiegend auf der anfordernden Seite des Gesprächs lebt.

Bitcoin Core rast beim Herunterladen nicht unbegrenzt voraus. Der Node hält ein Fenster von 1.024 Blöcken über dem letzten, den er validiert hat, damit ein einzelner stockender Peer den Node nicht mit einer unbegrenzten Warteschlange von Blöcken zurücklässt, die er nicht verbinden kann.

Wo er auftritt

Blockanfragen dominieren den Datenverkehr eines Nodes genau einmal, während seiner ersten Synchronisierung, und danach fast nie wieder.

Die Kette überschritt am 20. April 2024 beim Halving die Marke von 840.000 Blöcken und wächst um rund 144 Blöcke pro Tag, sodass eine frisch startende Maschine nahezu eine Million davon abruft, bevor sie auf dem aktuellen Stand ist. Sie können das mit getpeerinfo beobachten, das die Bytes pro Nachrichtentyp für jeden Peer zählt, oder im Protokoll mit -debug=net. Sobald der Node die Spitze erreicht, verstummen diese Zähler und der Verkehr für kompakte Blöcke übernimmt.

MSG_BLOCK vs. MSG_CMPCT_BLOCK

MSG_BLOCK und MSG_CMPCT_BLOCK unterscheiden sich ebenso darin, wo sie zulässig sind, wie darin, was sie abrufen. Typ 2 ist in einer inv- und in einer getdata-Nachricht zulässig, darf ohne vorherige Absprache an jeden Peer gesendet werden und funktioniert für einen Block jeden Alters. Typ 4 ist nur in einer getdata-Nachricht zulässig, darf nur an einen Peer gesendet werden, der bereits mit einer sendcmpct-Nachricht kompakte Blöcke angeboten hat, und wird in Bitcoin Core nur für die fünf jüngsten Blöcke bedient. Fragen Sie mit Typ 4 etwas Tieferes an, kommt trotzdem eine vollständige block-Nachricht zurück.