Glossar / Nodes und Software
Headers-First-Synchronisierung
- Was ist Headers-First-Synchronisierung?
- Bei der Headers-First-Synchronisierung lädt und prüft ein Node die gesamte Kette aus 80-Byte-Headern, bevor er Blockinhalte anfordert, und ruft diese Inhalte anschließend parallel ab.
Die Aufteilung des Downloads in zwei Schritte macht eine erste Synchronisierung überhaupt praktikabel. Bitcoin Core arbeitet seit Version 0.10.0, veröffentlicht im Februar 2015, auf diese Weise; damals wurde der Blockabruf von einer einzigen geordneten Warteschlange in eine Aufgabe umgewandelt, die auf alle verbundenen Peers verteilt wird. Wenn Sie einen eigenen Node betreiben, um Ihr eigenes Guthaben zu prüfen, ist dies der Grund, warum die Erstsynchronisierung in Stunden statt in Tagen abgeschlossen ist.
So funktioniert es
Die Headers-First-Synchronisierung beginnt damit, Peers nach Headern zu fragen, nicht nach Blöcken.
Der Node sendet eine getheaders-Nachricht mit einem Block Locator, einer kompakten Liste von Hashes, die beschreibt, wo er sich derzeit zu befinden glaubt. Ein Peer antwortet mit einer headers-Nachricht, die bis zu 2.000 Header zu je 80 Byte enthält, sodass eine Antwort etwa zwei Wochen der Kette abdeckt. Für jeden Header prüft der Node, ob er auf einen Elternblock zeigt, den er bereits hat, und ob sein Hash die Schwierigkeit erfüllt, die sein nBits-Feld angibt; dann fragt er erneut ab der neuen Spitze, bis kein Peer mehr etwas Neueres anzubieten hat.
Erst wenn dieses Gerüst steht, beginnt der Download der Blockinhalte. Da der Node den Hash jedes gewünschten Blocks bereits kennt, kann er verschiedene Abschnitte gleichzeitig bei mehreren Peers anfordern, statt sich hinter einer einzigen Verbindung anzustellen. Bitcoin Core begrenzt, wie viele Blockanfragen er bei einem einzelnen Peer offen lässt, sechzehn im aktuellen Code, und trennt einen Peer, der das Fenster ins Stocken bringt. Blöcke, die vor ihren Elternblöcken eintreffen, werden einfach zurückgehalten, was die alte Angewohnheit abgeschafft hat, ungeprüfte Daten auf der Festplatte zwischenzulagern.
Zwei Schutzvorkehrungen gehen mit den Headern einher. Die Software übernimmt eine Kette erst, wenn die Header, die sie hält, mehr kumulierten Proof of Work ergeben als ein Mindestwert, der in die Version einkompiliert ist; so kann ein Peer einen frischen Node nicht auf eine billige Seitenkette aus leichten Blöcken locken. Daneben benennt die Einstellung assumevalid einen aktuellen Block-Hash, der mit jeder Version ausgeliefert wird: Signaturen in Blöcken, die unter ihm begraben liegen, werden nicht erneut geprüft, was Stunden elliptischer Kurvenmathematik erspart, während jede Regel, die vom aktuellen Zustand der Kette abhängt, weiterhin durchgesetzt wird.
Wo Sie das sehen
Die Headers-First-Synchronisierung zeigt sich als zwei Zähler, die nicht übereinstimmen, während ein Node aufholt.
Rufen Sie getblockchaininfo während einer ersten Synchronisierung auf, liegt das Feld headers weit vor dem Feld blocks, oft um Hunderttausende. Der grafische Client sagt dasselbe in einfachen Worten: Er kann eine voraussichtliche Endzeit erst schätzen, nachdem die Header eingetroffen sind, weil er bis dahin nicht weiß, wie weit er noch zurücklegen muss. Das Zusammenlaufen dieser beiden Zahlen zu beobachten, ist der ehrliche Fortschrittsbalken.
Leichtgewichtige Software hält bewusst nach der ersten Hälfte an. Eine SPV-Wallet, ein Kompaktfilter-Client oder ein Lightning-Node, der ohne eigenes Chain-Backend läuft, speichert nur Header und legt Merkle-Beweise oder Filter darüber. Das ist der ganze Grund, warum eine Wallet auf dem Smartphone ihre eigene Historie über mobile Daten prüfen kann: Header sind klein und haben eine feste Größe, Blockinhalte sind weder das eine noch das andere.
Headers-First-Synchronisierung vs. Blocks-First-Synchronisierung
Die Headers-First-Synchronisierung lernt die Form der Kette kennen, bevor sie deren Inhalte herunterlädt, während die Blocks-First-Synchronisierung beides zugleich versuchte. Die ältere Methode sendete eine getblocks-Nachricht, erhielt eine inv-Auflistung mit nicht mehr als 500 Block-Hashes und zog sie einzeln von dem Peer, der antwortete, sodass eine einzige langsame Verbindung alles dahinter ausbremste. Was in falscher Reihenfolge ankam, hatte keinen anderen Platz als einen Haltepuffer im Arbeitsspeicher, den ein Angreifer mit Müll füllen konnte. Bitcoin Core synchronisiert seit 0.10.0 nicht mehr auf diese Weise, versteht die Nachrichten aber weiterhin, damit ältere Software mit ihm kommunizieren kann.