Initial Block Download

Du startest zu Hause einen Full Node: ein Programm, das Bitcoin-Blöcke und Transaktionen eigenständig prüft. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Andere Teilnehmer kennen bereits eine lange Vorgeschichte; deinem neuen Knoten fehlt sie noch. Zunächst beschafft er Block-Header, kurze Datensätze, die Blöcke miteinander verbinden. Sie enthalten auch den Proof of Work, den Nachweis geleisteter Rechenarbeit. Miner suchen diesen Nachweis durch wiederholte Berechnungen; andere können das gefundene Ergebnis schnell prüfen. Die Liste der Header ähnelt dem Inhaltsverzeichnis eines Buchs: Es hilft bei der Orientierung, bedeutet aber nicht, dass du alle Seiten gelesen und geprüft hast. [1] [7]

Bieten Nachbarn unterschiedliche Zweige der Geschichte an, zählt der Knoten keine Stimmen. Mithilfe der Header vergleicht er die angesammelte Rechenarbeit und wählt einen vielversprechenden Kandidaten für die weitere Prüfung. Mehr Blöcke bedeuten nicht zwangsläufig mehr Arbeit. Selbst sehr viel Arbeit befreit ungültige Transaktionen nicht von den Regeln; der Inhalt des gewählten Zweigs muss weiterhin geprüft werden. [1] [2] [6]

Der Knoten kann Blöcke gleichzeitig von mehreren Nachbarn beziehen und ist damit nicht auf die Geschwindigkeit eines einzigen Absenders angewiesen. Um sie seiner geprüften Geschichte hinzuzufügen, braucht er jedoch den vorherigen Zustand. Die Inputs einer Zahlung verweisen auf frühere Beträge, die sie ausgeben soll. Der Knoten muss feststellen, dass diese Beträge existieren und noch nicht ausgegeben wurden. Ein bereits heruntergeladener späterer Block kann deshalb auf die Verarbeitung eines früheren warten. Heruntergeladene Daten sind also noch keine abgeschlossene Synchronisierung. [1] [2]

Der Knoten vergleicht den Blockinhalt mit dem Fingerabdruck der Transaktionen im Header, den ein Merkle Tree erzeugt. Er prüft außerdem beispielsweise die Abfolge der Ausgaben und ob die Belohnung des Miners den zulässigen Betrag überschreitet. Dabei gelten die Regeln, die an der jeweiligen Stelle der Geschichte aktiv waren. Eine digitale Signatur weist die Berechtigung zur Zahlung nach. Sie wird mit einem privaten Schlüssel erzeugt, also einem geheimen Zahlenwert, der dabei nicht offengelegt wird. Für alte Signaturprüfungen und weitere Ausgabebedingungen gibt es die unten erklärte Einstellung assumevalid. Header oder Dateien eines vertrauenswürdig wirkenden Nachbarn ersetzen diese Prüfungen nicht insgesamt. [2] [3]

Bei jedem verarbeiteten Block entfernt der Knoten ausgegebene Outputs und fügt neue hinzu. Ein Output ist ein bestimmter Betrag mit Bedingungen für eine spätere Ausgabe. Solange er nicht ausgegeben wurde, heißt er UTXO. Ihr Bestand erlaubt es, die nächste Zahlung zu prüfen, ohne jedes Mal die ganze Geschichte erneut durchzugehen. Er ist weder eine Liste von Bankkonten noch eine Kopie aller früheren Transaktionen. [2] [3]

Unter bestimmten Bedingungen kann Bitcoin Core alte Skriptprüfungen überspringen, also Prüfungen von Signaturen und weiteren Ausgabebedingungen. assumevalid benennt einen bekannten Block mit extern geprüfter Vorgeschichte; auch seine Einordnung in die Blockkette, ausreichende Arbeit und die darüber aufgebaute Kette sind entscheidend. Andere notwendige Prüfungen bleiben bestehen, doch ein Teil des Prüfergebnisses wird vorausgesetzt. Eine falsche Annahme ist daher nicht risikolos. assumevalid=0 schaltet diese Optimierung aus, verlangt deinem Rechner dafür aber mehr Arbeit ab. [2]

Ein Pruned Node löscht alte Blockdateien nach der Verarbeitung und behält den aktuellen UTXO-Bestand sowie weitere notwendige Daten. Beim gewöhnlichen IBD beschafft und verarbeitet er die Geschichte weiterhin; er speichert sie nur nicht vollständig auf Dauer. Das spart Speicherplatz, nicht automatisch Daten beim ersten Download. Benötigt eine spätere Aufgabe bereits gelöschte Blöcke, müssen diese gegebenenfalls erneut beschafft werden. [2] [7]

Bitcoin Core v29.0 berücksichtigt unter anderem das Alter des zuletzt akzeptierten Blocks, eine Mindestmenge angesammelter Arbeit und den Ladezustand. Sobald dieses Betriebsmerkmal auf false (also „Erstsynchronisierung beendet“) wechselt, wird es im selben Programmlauf nicht wieder true (also „Erstsynchronisierung läuft noch“). Es steuert das Verhalten der Software und beweist nicht, dass nirgendwo ein neuerer Block existiert. Auch ein späterer Verbindungsverlust macht daraus keinen verlässlichen Aktualitätsnachweis. [2] [5]

Eine schnelle Verbindung hilft, doch der Rechner muss auch rechnen und auf den Datenträger schreiben. Prozessor, Arbeitsspeicher, Speichermedium und erreichbare Nachbarn beeinflussen die Dauer. In der technischen Ausgabe von getblockchaininfo schätzt verificationprogress den Prüfungsfortschritt. Der Wert verspricht weder eine bestimmte Restzeit noch zeigt er bloß den Anteil geladener Bytes. Nach ordnungsgemäßem Beenden kann ein Neustart an den gespeicherten Fortschritt anknüpfen, statt wieder ganz von vorn zu beginnen. [5] [7]

AssumeUTXO ermöglicht einen unterstützten UTXO-Snapshot, also einen gespeicherten Zustand zu einem bestimmten Block. Die Software vergleicht seinen Inhalt mit einem erwarteten Fingerabdruck und kann von dort früher zur Gegenwart aufschließen, während sie die Geschichte im Hintergrund verarbeitet. Anschließend vergleicht sie auch den Zustand aus dieser historischen Prüfung. Das ist weder eine beliebige Datenbank eines Fremden noch ein Weg, die Vergangenheit nie zu prüfen. Frühere Nutzbarkeit und abgeschlossene historische Prüfung sind zwei verschiedene Etappen. [4] [8]