Blocks-first-Synchronisierung

Niemand synchronisiert heute noch auf diese Weise, und der Grund ist Arithmetik. Ein streng sequenzieller Download kann nicht mehr als die Upload-Geschwindigkeit eines einzigen Peers nutzen, und bis 2015 war die Blockchain bereits zu groß, als dass dies in vertretbarer Zeit abgeschlossen werden könnte. Die Technik überlebt als Rückfalllösung im Protokoll und als Quelle der Verwirrung in alter Dokumentation.

Wie es funktioniert

Status: Die Blocks-first-Synchronisierung wurde durch die Headers-first-Synchronisierung in Bitcoin Core 0.10.0 ersetzt, veröffentlicht am 16. Februar 2015. Die dabei verwendeten Nachrichten sind weiterhin Teil des Peer-to-Peer-Protokolls und werden weiterhin beantwortet, aber kein aktueller Client verlässt sich darauf, um aufzuholen.

Der Austausch war eine Schleife zwischen zwei Maschinen. Ihr Node sendete eine getblocks-Nachricht mit den Hashes der Blöcke, die er bereits hatte. Der Peer antwortete mit einem Inventar, das bis zu 500 Block-Hashes auflistete, die darauf folgten. Ihr Node forderte diese Blöcke mit getdata an, empfing sie, validierte jeden einzelnen vollständig und sendete dann eine weitere getblocks-Nachricht, um zu fragen, was als Nächstes kam. Mehrere tausend Mal wiederholen.

Aus diesem Design ergaben sich drei Probleme. Es gab keine Parallelität, denn man konnte einen zweiten Peer nicht sinnvoll nach Blöcken fragen, von deren Existenz man noch nicht erfahren hatte, sodass die gesamte Synchronisierung mit der Geschwindigkeit des Peers lief, mit dem man gerade sprach. Es gab keine Möglichkeit zu wissen, wie weit man noch musste, da die Blockchain sich 500 Hashes auf einmal offenbarte, weshalb alte Clients keinen aussagekräftigen Fortschrittsbalken anzeigen konnten. Und ein langsamer oder feindseliger Peer konnte einem Daten einfach nur tröpfchenweise liefern, ohne dass der Node eine einfache Möglichkeit hatte zu erkennen, dass anderswo eine bessere Blockchain verfügbar war.

Die Headers-first-Synchronisierung behob alle drei Probleme, indem sie den günstigen Nachweis von dem teuren trennte. Laden Sie zuerst die Kette der Header herunter und verifizieren Sie sie, die im Dezember 2014 für die gesamte Historie 27 Megabytes umfasste, und Sie kennen sowohl die Form der besten Kette als auch ihre Länge, bevor Sie eine einzige Transaktion herunterladen. Anschließend können die Blockkörper von vielen Peers gleichzeitig angefordert werden. Der Nebeneffekt war, dass Blöcke in falscher Reihenfolge ankamen und in falscher Reihenfolge auf die Festplatte geschrieben wurden, weshalb das von Version 0.10.0 erstellte Datenverzeichnis von keiner älteren Software gelesen werden kann.

Wo es auftaucht

Die Blocks-first-Synchronisierung begegnet Ihnen eher in der Dokumentation als in der Software.

Referenzmaterial, das vor 2015 verfasst wurde, einschließlich eines guten Teils des noch kursierenden Entwicklermaterials, beschreibt die sequenzielle Schleife, als ob Bitcoin so funktionieren würde. Das tut es nicht, und Seiten, die eine initiale Synchronisierung als sequenziellen Download von einem einzigen Peer beschreiben, sind schlicht veraltet. Bitcoin Core beantwortet weiterhin getblocks-Anfragen zugunsten sehr alter oder ungewöhnlicher Clients, daher erscheinen die Nachrichten in Paketaufzeichnungen und in Protokollspezifikationen.

Für alle, die heute einen Node betreiben, gibt es nichts zu konfigurieren und nichts auszuwählen. Ihr Client lädt zuerst die Header herunter, weil jede gepflegte Implementierung dies tut.

Blocks-first-Synchronisierung vs. Headers-first-Synchronisierung

Die Blocks-first-Synchronisierung und die Headers-first-Synchronisierung unterscheiden sich darin, was sie zuerst anfordern, und alles Weitere folgt daraus. Die Blocks-first-Synchronisierung forderte vollständige Blöcke nacheinander an und erfuhr die Form der Blockchain im Verlauf, sodass sie die beste Kette entdeckte und sie im selben langsamen Durchgang herunterlud. Die Headers-first-Synchronisierung teilt die Aufgabe auf: Sie ermittelt, welche Kette den größten Proof of Work trägt, mithilfe von 80 Bytes pro Block, und sammelt dann die Blockkörper parallel von jedem, der sie senden will. Die auf jeden Block angewendete Validierung ist bei beiden identisch. Geändert hat sich die Reihenfolge der Vorgänge, und allein das verkürzte eine initiale Synchronisierung von Wochen auf Stunden.