Was ist "UTXO"?

Die Implementierung des neuen Ledger-State (dt. Kassenbuchstatus) war einer der letzten Bausteine für den voll funktionsfähigen Prototypen des Tangle ohne Koordinator. Mit dem UTXO-Modell wurde es direkt auf die richtige Art implementiert. UTXO steht für "unspent transaction output", was einfach bedeutet, dass man nicht nur die Guthaben auf der Adresse im Auge behält, sondern auch den Überblick darüber, woher die Guthaben stammen und wohin sie versendet wurden. Jeder Token ist eindeutig identifizierbar und jede Ausgabe benennt genau die spezifischen Token, die sie bewegen möchte.

Das Modell der "nicht verbrauchten Transaktionsausgaben (UTXO)" definiert einen Ledger-Zustand, bei dem die Salden nicht direkt mit Adressen, sondern mit den Ausgaben von Transaktionen verbunden sind. In diesem Modell verwenden Transaktionen die Ausgaben früherer Transaktionen als Eingaben, die für neue Ausgaben verbraucht werden müssen. Eine Transaktion muss also immer die Gesamtheit der Eingaben verbrauchen. Damit wird sichergestellt, dass niemand mehr ausgeben kann, als er hat.

Das alte Modell: Das IOTA 1.0 DLT verwendete ein Guthabenmodell zur Verfolgung von Adressen, bei dem jeder Adresse lediglich ein einziger Wert zugeordnet war, nämlich der aktuelle Guthabenstand. Der Ledger-State kann daher als ein einfaches Verzeichnis von Adressen und ihren entsprechenden Guthaben betrachtet werden:

Adresse1 = Guthaben1

Adresse2 = Guthaben2

Adresse3 = Guthaben3

Probleme: Bei Konflikten wie double-spends (dt. doppelte Ausgaben) ist es schwierig herauszufinden, bei welcher von mehreren Transaktionen tatsächlich eine doppelte Ausgabe erfolgt ist und bei welcher Transaktion legitime Gelder verwendet werden.

Dies soll anhand des unten stehenden Bildes verdeutlicht werden:

Gehen wir von der ersten Tranksaktion, der Genesis aus. Es wurden auf Adresse A in zwei Transaktionen jeweils 5 IOTA gesendet. Das Gesamtguthaben auf Adresse A auf der zweiten Ebene beträgt also insgesamt 10 IOTA. Danach werden 3 Transaktion von Adresse A ausgeführt, die jeweils -5 MIOTA versenden, also insgesamt -15 IOTA von einer Adresse, die insgesamt nur 10 MIOTA Guthaben aufweist. Der Saldo ist nicht mehr korrekt. Schaut man sich die Transaktionshistorie aus Sicht der letzten 3 Transaktionen an (siehe Farbcodierung), ist jedoch jede Kette bis zur Genesis gültig. Wie kann man nun entscheiden, welche Transaktionen im Konfikt miteinander sind und welche akzeptiert werden kann?

!-----> hier stattdessen Bild mit farbigen Pfeilen einfügen (siehe 1a.jpg)? <----

Bild: Bei welcher dieser drei Transaktionen handelt es sich um double spending? Bei einem Guthabenmodell ist dies unklar, daher müssten alle 3 als double spending betrachtet werden.

Im IOTA 1.0 Netzwerk trat dieses Problem nicht auf, da der implementierte Konsensus nach der Regel "heaviest subtangle wins" (das schwerste Sub-Tangle bekommt den Vorzug) nur sicherstellen musste, dass die Adressen eines bestimmten Sub-Tangles niemals negativ werden. Dazu wurden die Stimmen vor der Tip-Auswahl "gezählt". Dieses Zählen der Stimmen war eine extrem aufwändige Operation, weil dafür ein Random Walk durchgeführt werden musste und somit ein massiver Engpass für die Skalierbarkeit des Protokolls geschaffen wurde.

Mit der neuen, auf Abstimmungen (voting) basierenden, Coordicide-Lösung ist es notwendig, die Konflikte bei Transaktionen bereits beim Auftreten so schnell und so genau wie möglich zu identifizieren, also bevor darüber abgestimmt wird. Das reduziert die Anzahl der Stimmabgaben, die ausgetauscht werden müssen, um einen Konsens zu bilden, massiv.

Ein weiteres Problem bei der Verwendung eines Guthabenmodells hängt mit den s.g. "reattachments" (das wieder Anfügen von Transaktion) zusammen. Wenn man einmal Tokens für eine Adresse erhalten hat, von der bereits Ausgaben getätigt wurden, konnte man die vorherige Ausgabe einfach wieder anfügen und die Adresse erneut leeren (auch ohne Zugriff auf den privaten Schlüssel der Adresse). In der Vergangenheit ist es vorgekommen, dass Nutzer den Hinweis, Adressen nur einmalig zu verwenden, nicht beachtet haben und somit Opfer eines Angriffes auf ihre Konten wurden.

Die Lösung: Wenn das UTXO-Modell verwendet wird, um die Guthaben zu verfolgen, enthält jede Adresse nicht nur ihr Gesamtguthaben, sondern auch mehrere Unter-Guthaben, die mit einer Markierung versehen sind. Diese zeigt an, durch welche Transaktion genau dieses Guthaben entstanden ist. Jeder Token auf einer Adresse wäre daher eindeutig identifizierbar und jede Ausgabe würde genau den Token referenzieren, den sie bewegen möchte. Dies hilft, Konflikte zu erkennen und auch böswillige Akteure davon abzuhalten, sich Guthaben zu erschleichen, indem sie eine alte Transaktion wieder anfügen.

In dem Beispiel-Bild ist durch die grüne Markierung erkennbar, welche Transaktionen sich aufeinander beziehen. Man sieht sofort, dass nur die gelb markierten Transaktionen sich im Konflikt zueinander befinden, die grün markierten können ohne weiter Abstimmung genehmigt werden.

Bild: Bei einem UTXO-Modell identifiziert jede getätigte Ausgabe eindeutig, welche Gelder ausgegeben wurden. Auf diese Weise kann direkt festgestellt werden, welche Transaktionen widersprüchlich sind (die gelben Gelder werden zweimal verwendet).

Die Verwendung eines UTXO-basierten Modells bietet mehrere Vorteile:

• Parallele Validierung von Transaktionen.
• Einfachere Erkennung von Doppelausgaben, da widersprüchliche Transaktionen auf dieselbe UTXO verweisen würden. Das bedeutet eine schnellere und genauere Konfliktbehandlung, dementsprechend wird die Belastbarkeit sowie die Sicherheit des Protokolls verbessert.
• Wiederholungsschutz für das Wiederverwenden von Adressen. Die Wiederholung einer gleichen Transaktion würde sich als bereits angewandt oder vorhanden manifestieren und somit keine Auswirkungen haben.
• Das UTXO-Modell ermöglicht auch, auf einfache Weise Features wie "Digital Assets" zu implementieren, bei denen Benutzer IOTA-Token so markieren können, dass sie eine vorher festgelegt "Bedeutung" haben (und behalten). Wenn man bedenkt, dass 99% der bestehenden "Smart Contracts" eigentlich nur dazu verwenden werden, Tokens zu kreieren, die sich auf einen bestimmten Anwendungsfall beziehen, ist dies ein interessantes Feature, welches einen großen Mehrwert für das IOTA-Ökosystem darstellt.

Technisch gesehen können Salden nicht mehr mit Adressen verknüpft werden, was den Abstraktionsgrad erhöht und somit andere Arten von Ausgaben ermöglicht. Man könnte bspw. einen Ausgabetyp definieren, der das Guthaben erst freigibt, wenn eine bestimmte Bedingung (PoW oder ein anderes Entsperrkriterium) erfüllt ist.

Innerhalb einer Transaktion, die UTXOs verwendet, bilden Eingänge und Ausgänge die zu signierenden Daten der Transaktion. Der Abschnitt, der die Eingänge entsperrt, wird Unlock-Block genannt. Ein Unlock-Block kann eine Signatur enthalten, die das Eigentum an der Adresse eines bestimmten Eingangs nachweist und/oder andere Unlock-Kriterien (Entsperrkriterien).

Das folgende Bild zeigt den Geldfluss mit UTXO: