Initial Block Download

Neugier

1. Warum lädt ein neuer Node die Block-Header herunter, bevor er überhaupt Blöcke herunterlädt?
2. Welche konkreten Prüfungen werden übersprungen, wenn „assumevalid“ aktiviert ist, und warum ist das sicher?
3. Wenn die Bandbreite ausreicht, um ein Laufwerk in Minuten zu füllen, warum kann die initiale Synchronisation dann trotzdem Tage dauern?

Erkunden

1. Eine frische Bitcoin-Core-Instanz enthält nur den Genesis-Block, der fest im Quellcode verankert ist. Sie weiß nichts über die Länge oder Gültigkeit der Chain. Sobald sie sich mit Peers verbindet, startet sie den Initial Block Download (IBD), einen Prozess, der die gesamte Historie vom 3. Januar 2009 bis zur aktuellen Spitze der Chain rekonstruiert. Das ist keine passive Kopie, sondern eine aktive Rekonstruktion, bei der jeder Block – abgesehen von den unten beschriebenen Abkürzungen – anhand der Konsensregeln geprüft wird, bevor er akzeptiert wird.
2. Seit Version 0.10 (2015) folgt der IBD einer zweiphasigen Strategie. Zuerst lädt der Node alle Block-Header herunter, die kompakt und schnell zu übertragen sind. Er prüft den Proof of Work dieser Header, um sicherzustellen, dass sie das Difficulty-Target erfüllen, und baut so eine Kette der Arbeit auf, ohne bereits die Gültigkeit der Transaktionen zu prüfen. Steht die Header-Kette, fordert der Node vollständige Blöcke parallel von mehreren Peers an und validiert sie der Reihe nach, sobald sie eintreffen.
3. Die Validierung von Transaktionen ist wegen der kryptografischen Signaturprüfungen rechenintensiv. Um die Synchronisation zu beschleunigen, führte Version 0.14 (2017) „assumevalid“ ein. Dieser Parameter überspringt die Signaturprüfung für alle Blöcke, die unterhalb eines fest codierten Hashes eines breit geprüften Blocks liegen. Der Node prüft weiterhin alles andere, einschließlich Proof of Work, Beträgen und UTXO-Set; nur Skript- und Signaturprüfungen entfallen für diese tief liegende Historie. Nutzer können diese Option deaktivieren, um jede einzelne Signatur ab dem Genesis-Block zu prüfen, zum Preis deutlich längerer Synchronisationszeiten.
4. Neuere Versionen bieten „assumeUTXO“, eine experimentelle Funktion, mit der ein Node von einem vorab berechneten Snapshot des aktuellen UTXO-Sets aus starten kann. Der Node ist schnell nutzbar, während er im Hintergrund die vollständige Historie überprüft. Bis diese Prüfung abgeschlossen ist, vertraut er einem Snapshot, dessen Hash fest in der Software hinterlegt ist (die Datei selbst kann von überall stammen); danach ist er vollständig unabhängig.
5. Die Dauer des IBD hängt stark von der Hardware ab. Auf einem modernen Rechner mit schneller SSD und 8 GB RAM kann die Synchronisation einige Stunden dauern. Auf leistungsschwachen Geräten wie einem Raspberry Pi kann sie mehrere Tage oder länger dauern. Der Engpass ist selten die Bandbreite, sondern die Schreibgeschwindigkeit des Laufwerks für den UTXO-Cache (dbcache) und die CPU-Zyklen für die Skriptvalidierung. Eine langsame Festplatte bremst den Prozess selbst bei Gigabit-Internet aus, da der Node ständig Zustandsdaten lesen und schreiben muss.
6. Sobald der Node synchronisiert ist, erreicht er die Spitze der gültigen Chain mit der meisten Arbeit. Er wird vom Beobachter zum vollwertigen Teilnehmer, der Transaktionen und Blöcke an seine Peers weiterleiten kann. Der Befehl `bitcoin-cli getblockchaininfo` zeigt diesen Fortschritt im Feld `verificationprogress`, das sich 1,0 annähert, während die historische Chain validiert wird. Dann besitzt der Node eine vollständige, unabhängig überprüfte Kopie der Geschichte des Geldes.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Bitcoin Core Release Notes 0.10.0 (2015)
• Bitcoin Core Release Notes 0.14.0 (2017)
• Bitcoin Core Documentation: 'assumeutxo.md'
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)