AssumeUTXO

Peter startet seinen ersten Full Node, eine Software, die die Regeln von Bitcoin selbst prüft. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Beim gewöhnlichen Start muss die Software zunächst eine lange Geschichte durcharbeiten. AssumeUTXO erlaubt den Einstieg mit einem vorbereiteten UTXO set: noch nicht ausgegebenen Transaktionsausgängen, die jeweils einen Betrag und dessen Ausgabebedingungen enthalten. Der Snapshot hält den Zustand nach einem bestimmten Block fest. Er ist weder ein Archiv aller Zahlungen noch ein Beleg dafür, dass Peters Computer die gesamte Vergangenheit bereits geprüft hat. [1] [3]

Ein Dateiname macht einen Snapshot nicht verlässlich. Beim Laden über loadtxoutset prüft Bitcoin Core v29.0 das Format, den Basisblock (den Block, auf den sich der Snapshot bezieht) und die unterstützten Parameter. Außerdem berechnet die Software den Hash des UTXO-Inhalts, einen kryptografischen Fingerabdruck, und vergleicht ihn vor der Aktivierung mit dem erwarteten Wert. Geänderter Inhalt besteht die Prüfung also nicht bloß deshalb, weil die Datei einen vertrauenerweckenden Namen trägt. [2] [3] [6]

Nach Annahme des Snapshots baut der Knoten auf dessen Zustand auf, prüft die folgenden Blöcke und kann das aktuelle Ende der Kette erreichen. Er übernimmt sie nicht ungeprüft: Ausgabebedingungen und die zulässige Erzeugung neuer Bitcoins werden weiterhin kontrolliert. Der Vorteil ist, dass dieser Weg zum aktuellen Betrieb nicht auf den Abschluss der älteren Geschichte warten muss. Das bedeutet aber nicht, dass die ältere Geschichte bereits vor Ort geprüft wurde. [1] [6]

Gleichzeitig entsteht ein zweiter Zustand aus historischen Blöcken, vom Anfang bis zur Basis des Snapshots. Das ist eine eigenständige Berechnung aus der Geschichte und keine weitere Kopie des heruntergeladenen Bestands. Die Software führt deshalb zeitweilig zwei Zustände mit unterschiedlichem Fortschritt. Der technische Befehl getchainstates zeigt sie an. Dass der aktive Zustand die neuesten Blöcke erreicht hat, bestätigt noch nicht den Abschluss der Hintergrundarbeit. [1] [8]

Der erwartete Hash und der unterstützte Basisblock gehören zu einer bestimmten Programmversion. Solange Peters Knoten die Geschichte nicht selbst berechnet hat, verlässt er sich auf die Richtigkeit dieser eingebauten Angabe. Durch den Vergleich von Hashes lässt sich prüfen, ob die Inhalte übereinstimmen. Das allein beweist aber nicht, dass sie aus einer gültigen Historie entstanden sind. Wäre der erwartete Zustand falsch, würde die frühere Nutzung des Knotens auf dieser falschen Annahme beruhen. Die spätere historische Prüfung ist deshalb von der Dateiprüfung beim Laden zu unterscheiden. [2] [6]

Die Datei kann von einem anderen Betreiber stammen. Dadurch darf dieser aber nicht entscheiden, welcher Zustand akzeptiert wird. Maßgeblich ist die Übereinstimmung mit dem von der Software unterstützten Wert, nicht sein Versprechen. Auch lässt sich nicht jeder Snapshot aus jedem Block laden: Die Unterstützung hängt von Version und Netzwerk ab. Eine Hashprüfung garantiert weder die Lieferung noch verhindert sie, dass Download und Verarbeitung Zeit, Bandbreite und Speicherplatz beanspruchen. [2] [4] [7]

Erreicht die Hintergrundarbeit denselben Basisblock, berechnet der Knoten den Hash des selbst aufgebauten UTXO set und vergleicht ihn mit dem erwarteten Snapshot-Hash. Es wird nicht der heutige Zustand mit einem alten Foto verglichen: Beide beziehen sich auf denselben Punkt der Geschichte. Bei einer Abweichung fährt die hier beschriebene Implementierung den Knoten herunter und verwendet den aus dem Snapshot abgeleiteten Zustand nicht weiter. Sie verschweigt die Abweichung nicht und meldet keinen erfolgreichen Abschluss. [1] [6]

AssumeUTXO verändert vor allem die Zeit bis zur Nutzbarkeit. Historische Downloads und Prüfungen laufen weiter, während vorübergehend zwei Zustandsdatenbanken bestehen. Das beansprucht Prozessor und Datenträger. Ein Pruned Node spart Platz, indem er ältere, bereits verarbeitete Blockdateien löscht; die Prüfung der Regeln lässt er dabei nicht aus. Auch ein Pruned Node kann einen Snapshot verwenden, doch für die Speicherersparnis gelten eigene Grenzen. Manche zusätzlichen Indizes müssen die Geschichte vom Anfang an verarbeiten. Ein früher nutzbarer Knoten bedeutet daher nicht, dass sämtliche angeschlossenen Anwendungen sofort bereit sind. [5] [7]

Das UTXO set enthält Informationen über noch nicht ausgegebene Ausgänge, nicht die privaten Schlüssel, die Ausgaben autorisieren. 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. Das UTXO set ist kein Wallet-Backup und stellt keine verlorene Seed Phrase wieder her, also die Wiederherstellungswörter einer Wallet, die dieses Verfahren nutzt. Auch ältere Zahlungen erscheinen nicht unbedingt sofort: Ihre Suche kann Blöcke vor dem Snapshot benötigen. Schlüsselsicherung, Suche nach der eigenen Wallet-Geschichte und Prüfung des Netzwerkzustands sind unterschiedliche Aufgaben. [1] [7]

Die ähnlichen Namen können verwirren. AssumeUTXO beginnt mit einem geladenen Zustand und berechnet die ältere Geschichte im Hintergrund nach. assumevalid dagegen kann unter bestimmten Bedingungen einen Teil der historischen Skriptprüfungen überspringen, also Prüfungen der Ausgabebedingungen einschließlich Signaturen. Diese separate Optimierung kann auch die historische Prüfung beeinflussen. Der Abschluss von AssumeUTXO allein sagt nicht, dass sie ausgeschaltet war. Unterscheiden Sie in Anleitungen deshalb den Startpunkt, die tatsächlich ausgeführten Prüfungen und deren jeweilige Fertigstellung. [5] [6]