Utreexo

Anna möchte Peter Bitcoin schicken, die sie zuvor erhalten hat. Ihre Transaktion verweist deshalb auf diesen früheren Eingang. Ein einzelner Datensatz über einen Betrag und seine Ausgabebedingungen heißt Output; solange er nicht ausgegeben wurde, ist er ein UTXO. Ein Input der neuen Transaktion enthält einen Verweis auf diesen früheren Output und die zum Ausgeben nötigen Daten. Der Knoten muss prüfen, ob der Datensatz tatsächlich existiert und Anna ihn nicht bereits ausgegeben hat. Üblicherweise führt er dafür das UTXO Set, eine Datenbank sämtlicher aktuell nicht ausgegebener Outputs statt persönlicher Konten und Salden. Mit ihr wachsen die Datenträgerzugriffe. Thaddeus Dryja stellte Utreexo 2019 als Möglichkeit vor, diese lokale Belastung zu verringern. [1] [6] [8]

Zunächst wird aus jedem Datensatz ein Hash berechnet, ein kurzer Fingerabdruck seiner Daten. In einem Merkle-Baum werden Fingerabdrücke paarweise verbunden und erneut gehasht, bis der oberste Fingerabdruck, die Wurzel, entsteht. Utreexo verwendet mehrere solcher Bäume; ein prüfender Knoten kann statt der gesamten Liste deren Wurzeln speichern. Zu Annas Output erhält er die Daten und einen Nachweis mit den benötigten benachbarten Fingerabdrücken. Damit berechnet er den Weg zur Wurzel und vergleicht das Ergebnis mit dem bereits verfolgten Zustand. Die Behauptung des Senders allein genügt also nicht. Diese Anordnung heißt kryptografischer Akkumulator: Sie weist die Zugehörigkeit eines Datensatzes zu einer Menge nach. Die Wurzeln sind jedoch keine komprimierte Sicherung. Aus ihnen lassen sich nicht sämtliche ursprünglichen Datensätze wiederherstellen. [1] [2]

Aus den übermittelten Daten wird ein Hash berechnet. Der Nachweis erlaubt die Prüfung, ob die Daten zum verfolgten Zustand gehören. 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. Ein Skript legt Bedingungen fest, die beim Ausgeben eines Outputs erfüllt sein müssen. Ein ungültiger Nachweis darf nicht allein deshalb akzeptiert werden, weil er von einem bekannten Server kommt. Auch ein gültiger Zugehörigkeitsnachweis ersetzt nicht die Prüfung von Signaturen, Skripten, Beträgen und weiteren Transaktions- und Blockregeln. Utreexo verändert die Zustandsspeicherung, erlaubt aber kein Überspringen dieser Prüfungen. [2] [5] [8]

Jemand muss weiterhin genügend Daten aufbewahren, um Nachweise zu erstellen. Die Bibliotheksdokumentation unterscheidet den prover, der den gesamten Baumwald hält, vom verifier, dem die Wurzeln genügen. Ein Prüfer kann einige Nachweise zwischenspeichern; aus den Wurzeln allein kann er aber nicht beliebige Nachweise erzeugen. Die Daten verschwinden also nicht. Ihre Verteilung zwischen den Beteiligten ändert sich. [2]

Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Ein ausgegebener Ausgang wird aus der erfassten Menge entfernt, neue, noch nicht ausgegebene Outputs kommen hinzu. Damit ändern sich auch die Nachweise. Ein Nachweis für einen früheren Zustand lässt sich nach weiteren Blöcken unter Umständen nicht unverändert verwenden. Bei einer Reorganisation übernimmt das Netzwerk einen anderen gültigen Zweig der Kette und ersetzt damit einen Teil der bisherigen Blockhistorie. Die Implementierung muss Nachweise aktualisieren, gleichzeitige Transaktionen verarbeiten und bei einer Reorganisation der Kette zurückgehen können. Es handelt sich nicht um ein einmal heruntergeladenes, dauerhaft gültiges Zertifikat. [2] [3]

Ein Pruned Node verwirft nach der Prüfung ältere Blockdaten, behält traditionell aber die aktuelle UTXO-Datenbank. Utreexo zielt auf diese Datenbank. Das sind unterschiedliche Einsparungen, die sich kombinieren lassen. Weder Pruning noch ein kleiner Akkumulator bedeuten allein, dass ein Knoten die Vergangenheit geprüft hat, ohne sie zu verarbeiten. Blockhistorie, aktueller Zustand und anfängliches Prüfverfahren sind drei verschiedene Dinge. [6] [5]

Angenommen, ein neuer Knoten beginnt mit einer fremden Zustandsübersicht, statt die Blöcke von Anfang an zu prüfen. Damit setzt er voraus, dass dieser Ausgangszustand stimmt. Ein kleiner Akkumulator beseitigt dieses Vertrauen nicht: Spätere Nachweise werden gerade gegen den übernommenen Zustand geprüft. Bei AssumeUTXO ist daher die Übernahme eines Snapshots, einer Momentaufnahme des Zustands, von der anschließenden historischen Prüfung im Hintergrund zu unterscheiden. Die Dokumentation von utreexod beschreibt den Standardstart mit einem im Programm festgelegten Zustand. Das allein ist keine eigene Prüfung aller früheren Blöcke. Der Startmodus ist eine gesonderte Entscheidung, keine inhärente Eigenschaft von Utreexo. [7] [3]

Die Implementierung utreexod verwendet Utreexo zur Validierung des Bitcoin-Netzwerks. Bei der Prüfung am 17. Oktober 2026 bezeichnet ihre Dokumentation sie als Beta und rät von der Nutzung mit nicht vernachlässigbaren Mainnet-Beträgen ab. Sie nennt außerdem --noassumeutreexo, um den Start mit angenommenem Zustand abzuschalten. Das ist keine Installationsempfehlung: Vor der Nutzung sind aktuelle Version, Betriebsmodus, Softwarequelle und Wiederherstellungsmöglichkeiten zu prüfen. [3]

Der grundlegende Entwurf erfordert weder eine Neufassung der Bitcoin-Geldregeln noch Änderungen bestehender Blöcke. Nachweise müssen aber erstellt, übertragen und aktualisiert werden. Beteiligte Knoten benötigen daher passende Software und Kommunikation. Ein kleinerer lokaler Zustand kann günstigeren Geräten helfen. Er bedeutet nicht automatisch mehr Transaktionen pro Block, niedrigere Gebühren für alle oder die Umstellung sämtlicher Knoten auf ein neues Format. [1] [4]

Weniger Daten auf dem Datenträger können mehr Netzwerkverkehr und Abhängigkeit von rechtzeitig verfügbaren Daten bedeuten. Ein korrekt prüfender Knoten lehnt gefälschte Nachweise ab. Ein Anbieter kann notwendige Daten dennoch zurückhalten und die Prüfung verzögern. Betreiber vergleichen deshalb den gesamten Betrieb: Speicher, Übertragung, Cache, Prüfung des Anfangszustands und Ausfallverhalten. Utreexo kann die eigene Validierung günstiger machen; fehlende Daten werden dadurch nicht unwichtig. [3] [4]