Als eines der zentralen Designprinzipien von Bitcoin ist das UTXO-Modell seit seiner Einführung ein bedeutendes technisches Paradigma im Blockchain-Bereich. Es spielt eine entscheidende Rolle bei der Gewährleistung der Transaktionssicherheit und Rückverfolgbarkeit und bietet einen alternativen Weg über das traditionelle Kontostandsmodell hinaus. Mit der kontinuierlichen Weiterentwicklung und Erweiterung der Blockchain-Technologie in den letzten Jahren wurde das UTXO-Modell selbst ständig weiterentwickelt und erweitert, wie z. B. eUTXO, Cell, Strict Access List und andere.

Dieser Artikel stellt das UTXO-Modell in einfacher Sprache vor und bietet einen kurzen Überblick über das UTXO-Modell und die Implementierungsmethoden von BTC, Sui, Cardano, Nervos und Fuel.

Was ist UTXO?

Um das UTXO-Modell zu veranschaulichen, verwenden wir ein Beispiel:

Stellen Sie sich zwei Personen vor, Alice und Bob, die anfangs jeweils 5 $ haben. In der Folge kommt es zu einem Konflikt, bei dem Alice von Bob um 2 Dollar gebracht wird. Die endgültigen Bestände für jeden Bestand sind wie folgt:

Es ist offensichtlich, dass Alice am Ende 3 $ hat und Bob schließlich 7 $ hält. Diese elementare arithmetische Buchhaltungsmethode ist in Bankensystemen weit verbreitet und wird als "Konto-/Saldenmodell" bezeichnet. In diesem Modell existiert der Saldo eines Kontos als einzelner numerischer Wert.

Wenn wir einen anderen Ansatz als das Kontomodell wählen würden, z. B. UTXO verwenden, um den Vermögenstransfer zwischen Alice und Bob darzustellen, würde das illustrative Diagramm ein anderes Aussehen annehmen:

Zu diesem Zeitpunkt hat Alice noch 3 $ und Bob noch 7 $, aber diese 7 $ werden nicht durch einen einzigen numerischen Wert dargestellt. Stattdessen werden sie in "5 $" und "2 $" unterteilt. Fühlt sich dieser unkonventionelle Ansatz etwas ungewohnt an? Dies ist die einzigartige Buchhaltungsmethode, die als UTXO bekannt ist.

Das englische Akronym UTXO steht für Unspent Transaction Output. Bei diesem Buchhaltungsansatz manifestiert sich jede On-Chain-Transaktion als Änderungen und Übertragungen in UTXOs. In dem erwähnten Transaktionsereignis dienen beispielsweise Alices anfänglich im Besitz befindliche "$5" als Eingabeparameter, die als UTXO_0 gekennzeichnet sind und als ausgegeben markiert werden. Gleichzeitig erzeugt das System als Ausgabeparameter "$2" (UTXO_1) und "$3" (UTXO_2). UTXO_1 wird auf Bob übertragen, und UTXO_2 wird an Alice zurückgegeben, wodurch der Vermögenstransfer zwischen Alice und Bob abgeschlossen ist.

Im UTXO-Modell gibt es keine expliziten Konzepte von "Konten" und "Salden". UTXO dient als Datenstruktur, die die Ausführung von Transaktionen unterstützt und Informationen wie den Betrag, den sie darstellt, und den zugehörigen Transaktionsindex aufzeichnet. Jeder UTXO stellt eine nicht verbrauchte Transaktionseingabe mit einem bestimmten Besitzer dar. Wenn eine Transaktion stattfindet, können bestimmte UTXOs als Eingaben verwendet werden, und nach ihrer Zerstörung werden neue UTXOs als Transaktionsausgaben generiert.

So führt Bitcoin Konten: Mit jeder Transaktion werden alte UTXOs zerstört und neue geschaffen. Die Gesamtmenge der zerstörten UTXOs entspricht der Anzahl der neu erstellten UTXOs (wobei ein Teil als Transaktionsgebühren an die Miner vergeben wird). Dadurch wird sichergestellt, dass die Mittel nicht willkürlich erhöht werden können.

Vergleich zwischen UTXO-Modell und Konten-/Saldenmodell

Angenommen, eine Gruppe von Benutzern initiiert eine große Anzahl von Transaktionsanforderungen gleichzeitig. Wie würde die Situation mit dem UTXO-Modell im Vergleich zum Konten-/Saldomodell gehandhabt werden?

Im Konten-/Saldomodell verfügt jeder Benutzer über ein Konto mit aufgezeichneten Saldoinformationen. Wenn eine Transaktion stattfindet, muss der entsprechende Kontostand aktualisiert werden, was sowohl Lese- als auch Schreibvorgänge umfasst. Wenn jedoch zwei Transaktionen dasselbe Konto betreffen, führt dies häufig zu Lese-/Schreibkonflikten, die zu Zustandskonflikten führen, eine Situation, die vermieden werden muss.

Herkömmliche Datenbanksysteme behandeln Lese-/Schreibkonflikte in der Regel mit einem "Sperrmechanismus". In einem solchen Szenario müssen Transaktionen, die Konflikte um dieselben Daten verursachen, häufig in die Warteschlange gestellt werden, was die gleichzeitige Ausführung verhindert und die Effizienz der Transaktionsverarbeitung verringert. Wenn eine große Anzahl von Transaktionen auf die Verarbeitung wartet, kann dies zu erheblichen Leistungsengpässen führen, da umstrittene Transaktionen ohne schnelle Verarbeitung mit längeren Wartezeiten konfrontiert sind.

Im Gegensatz zum Kontostandsmodell ist das UTXO-Modell von Bitcoin besser für den Umgang mit Datenkonflikten gerüstet. Bei diesem Ansatz handelt es sich bei der direkten Verarbeitung jeder Transaktion nicht mehr um ein bestimmtes "Konto", sondern um individuelle, unabhängige UTXOs. Da sich verschiedene UTXOs nicht gegenseitig stören, funktioniert jede Transaktion im Bitcoin-Netzwerk unabhängig. Infolgedessen können Bitcoin-Netzwerkknoten mehrere Transaktionen gleichzeitig verarbeiten, ohne dass "Sperren" erforderlich sind, was den Systemdurchsatz und die Gleichzeitigkeitsleistung erheblich verbessert.

Darüber hinaus generieren verschlüsselte Wallets im UTXO-Modell in der Regel eine neue Adresse für den Benutzer, nachdem sie eine Transaktion initiiert haben. Dieser Ansatz verbessert den Datenschutz und macht es schwieriger, eine Transaktion mit einer bestimmten Person in Verbindung zu bringen. Im Gegensatz dazu ist das Konten-/Saldomodell, das feste Adressen verwendet, anfälliger für die Assoziationsanalyse.

Das UTXO-Modell hat jedoch seine Grenzen. Es wurde ursprünglich entwickelt, um einfache Währungsüberweisungen zu erleichtern, und ist für die Handhabung komplexer Geschäftslogik nicht gut geeignet. Während grundlegende Funktionen wie Multi-Signatur und Zeitsperren mit Skriptsprachen implementiert werden können, sind die minimalen Zustandsinformationen, die der UTXO von Bitcoin aufzeichnen kann, weniger in der Lage, kompliziertere Operationen zu verarbeiten.

Die Einschränkungen von Bitcoins UTXO trugen indirekt zur Entstehung von "Ethereum" bei. Vitalik, einer der ersten Mitarbeiter des Bitcoin Magazine, war sich der Unzulänglichkeiten von Bitcoin bewusst. Das Konten-/Saldomodell, das für die meisten Menschen leichter zu verstehen ist, befasst sich mit den Herausforderungen, mit denen UTXO bei der Verarbeitung von Rich-State-Anwendungen konfrontiert ist. Wie Vitalik im Ethereum-Whitepaper feststellte:

UTXO kann entweder ausgegeben oder nicht ausgegeben werden; Es gibt keine Möglichkeit für mehrstufige Verträge oder Skripte, die darüber hinaus einen anderen internen Zustand beibehalten. Dies macht es schwierig, mehrstufige Optionskontrakte, dezentrale Börsenangebote oder zweistufige kryptografische Verpflichtungsprotokolle (notwendig für sichere Computational Bounties) zu erstellen. Es bedeutet auch, dass UTXO nur zum Erstellen einfacher, einmaliger Verträge verwendet werden kann und nicht für komplexere "zustandsbehaftete" Verträge wie dezentrale Organisationen, und erschwert die Implementierung von Metaprotokollen. Binärer Zustand in Kombination mit Wertblindheit bedeutet auch, dass eine andere wichtige Anwendung, die Entnahmelimits, unmöglich ist.

Anwendung, Optimierung und Erweiterung des UXTO-Modells

Bevor wir uns mit verschiedenen Anwendungen und Optimierungen des UTXO-Modells befassen, analysieren wir die Bereiche, in denen Verbesserungen möglich sind, während die Vorteile beibehalten werden. Diese lassen sich wie folgt zusammenfassen:

1. Abstrahieren der Bedeutung des in UTXOs gespeicherten Zustands.

2. Abstrahierung des Eigentums am Staat.

3. Beheben von Problemen mit Statuskonflikten beim Freigeben von UTXOs.

Bei BTC ist die einzige Bedeutung des Staates die Token-Menge, das Eigentum wird in der Regel mit öffentlichen Schlüsseln definiert, und staatliche Konflikte werden nicht umfassend behandelt, da BTC nicht für dApps entwickelt wurde.

Sui

Sui bietet Entwicklern zwei Arten von Objekten: OwnedObject und SharedObject. Ersteres ähnelt UTXO (insbesondere eine erweiterte Version), während letzteres mit dem Konto-/Saldomodell vergleichbar ist. Beides kann gleichzeitig verwendet werden.

Ein Objekt kann freigegeben werden, d. h. jeder kann dieses Objekt lesen oder schreiben. Im Gegensatz zum veränderlichen OwnedObject (mit nur einem Writer) erfordert SharedObject einen Konsens zum Sortieren von Lese- und Schreibvorgängen.

In anderen Blockchains wird jedes Objekt geteilt. Sui-Entwickler können jedoch in der Regel OwnedObject, SharedObject oder eine Kombination aus beiden verwenden, um bestimmte Anwendungsfälle zu implementieren. Diese Auswahl kann sich auf die Leistung, Sicherheit und Komplexität der Implementierung auswirken.

In Sui ähneln Owned Objects UTXOs, und nur ihr Besitzer kann sie bearbeiten. Objekte haben auch Versionsnummern, und eine Version eines Objekts kann nur einmal von seinem Besitzer ausgegeben werden. Daher entspricht eine Version eines Objekts im Wesentlichen einem UTXO.

Probleme mit Zustandskonflikten löst Sui diese durch eine spezielle Behandlung (lokale Reihenfolge, ähnlich wie bei Fuel) in SharedObjects.

Cardano

Cardano verwendet ein erweitertes UTXO-Modell, das als eUTXO bekannt ist. eUTXO unterstützt eine erhöhte Programmierbarkeit unter Beibehaltung der Vorteile des Bitcoin-UTXO-Modells.

In Cardano wird die Bedeutung des Staates durch Skripte weiter ausgebaut und das Eigentum am Staat wird allgemeiner definiert. UTXO-Sätze werden verwendet, um Probleme mit Statuskonflikten zu minimieren. Konkret wird eUTXO in zwei Aspekten verbessert:

1. Das eUTXO-Modell enthält verallgemeinerte Adressen. Diese Adressen basieren nicht nur auf dem Hash öffentlicher Schlüssel, sondern können auf der Grundlage einer beliebigen Logik definiert werden, die die Bedingungen angibt, unter denen eUTXO ausgegeben werden kann, was die Programmierbarkeit des Staatseigentums ermöglicht.

2. Zusätzlich zu Adressen und Werten können die Ausgaben (fast) beliebige Daten enthalten, so dass die Bedeutung des Zustands durch Skripte programmiert werden kann.

Genauer gesagt ermöglicht eUTXO den Benutzern, beliebige Daten in einem JSON-ähnlichen Format zu UTXOs hinzuzufügen, das als Datum bezeichnet wird. Datum ermöglicht es Entwicklern, zustandsähnliche Funktionen für Skripte bereitzustellen, die mit bestimmten UTXOs verknüpft sind.

Darüber hinaus können Transaktionen auf Cardano Parameter enthalten, die sich auf bestimmte Benutzer beziehen, die als Einlöser bezeichnet werden. Redeemer ermöglicht es dem Initiator der Transaktion, zu definieren, wie UTXOs verwendet werden und von dApp-Entwicklern für verschiedene Zwecke eingesetzt werden können.

Wenn eine Transaktion validiert wird, arbeitet das Validierungsskript mit Datum, Redeemer und dem Kontext, der Transaktionsdaten enthält. Dieses Skript enthält die Logik für die Verwendung von UTXOs, wenn Bedingungen erfüllt sind.

Es ist erwähnenswert, dass eUTXO immer noch Erweiterungsaufgaben durch Skripte erfüllt und sich deutlich von der traditionellen Vorstellung von "Smart Contracts" unterscheidet (Charles Hoskinson, der Gründer, schlägt vor, es als "programmierbaren Validator" zu bezeichnen, aber der Begriff "Smart Contracts" ist auf dem Markt weiter verbreitet).

Nervos

In Nervos (CKB) wird die Bedeutung des Zustands durch TypeScript abstrahiert, und der Besitz des Zustands wird durch ein Lockscript abstrahiert. Ein einfaches UTXO-Optimierungsmodell in Form eines Zellcodes sieht wie folgt aus:

pub struct CellOutput {

    Pub-Kapazität: Kapazität,

Pub-Daten: Vec,

Pub-Sperre: Skript,

pub type_: Option,

}

Was die Frage des Zustandskonflikts betrifft, so treibt CKB derzeit die Forschung zu offenen Transaktionen voran, bei denen Benutzer einen Teil-UTXO vorschlagen können, der den Zweck der Transaktion angibt, und diese dann zu einer vollständigen Transaktion zusammenfassen können.

Das Zellmodell von Nervos ist eine "verallgemeinerte" Version von UTXO, und Jan hat eine detaillierte Erklärung im Nervos-Forum gegeben:

Der Fokus von Layer1 liegt auf dem Zustand, und mit Layer1 als Entwurfsziel konzentriert sich CKB natürlich auf den Zustand.

Ethereum trennt die Transaktionshistorie und die Zustandshistorie in zwei Dimensionen, wobei Blöcke und Transaktionen Ereignisse darstellen, die Zustandsübergänge auslösen, und nicht den Zustand selbst. Im Gegensatz dazu führt das Bitcoin-Protokoll Transaktionen und Zustände zu einer einzigen Dimension zusammen – Transaktionen sind der Zustand, und der Zustand ist die Transaktion. Es ist eine Architektur, die sich um den Staat dreht.

Gleichzeitig zielt CKB darauf ab, nicht nur nValue als Zustand, sondern auch alle Daten, die als wertvoll erachtet und im Konsens für die langfristige Aufbewahrung genehmigt wurden, zu verifizieren und zu bewahren. Die Transaktionsausgabestruktur von Bitcoin ist für diesen Zweck unzureichend, aber sie hat uns reichlich Inspiration geliefert. Durch die Verallgemeinerung von nValue und die Umwandlung von einem Raum, in dem ganze Zahlen gespeichert werden, in einen Raum, der beliebige Daten enthalten kann, erhalten wir ein allgemeineres "CTxOut" oder eine Zelle.

In einer Zelle wird nValue zu zwei Feldern: Kapazität und Daten. Diese Felder stellen zusammen einen Speicherplatz dar, wobei die Kapazität eine ganze Zahl ist, die die Größe des Speicherplatzes in Byte angibt, und die Daten sind der Ort, an dem der Zustand gespeichert wird und eine beliebige Bytesequenz aufnehmen kann. Der scriptPubKey wird zu lock, nur eine Namensänderung, die ausdrückt, wer der Besitzer dieses Konsensbereichs ist – nur die Person, die Parameter (z. B. eine Signatur) bereitstellen kann, damit das Sperrskript erfolgreich ausgeführt wird, kann den Status in dieser Zelle "aktualisieren". Die Gesamtanzahl der Bytes, die von der gesamten CellOutput belegt werden, muss kleiner oder gleich der Kapazität sein. CKB verfügt über zahlreiche Zellen, und ihre Sammlung bildet den vollständigen aktuellen Stand von CKB und speichert geteiltes Wissen und nicht nur eine bestimmte digitale Währung.

Transaktionen stellen nach wie vor Änderungen/Migrationen des Zustands dar. Die Zustandsänderung oder die "Aktualisierung" des Zellinhalts wird tatsächlich durch Zerstörung und Schöpfung erreicht (nicht durch direkte Veränderung des Inhalts der ursprünglichen Zelle). Jede Transaktion zerstört effektiv einen Stapel von Zellen und erstellt gleichzeitig einen neuen Stapel von Zellen. Die neu erstellten Zellen haben neue Besitzer und speichern neue Daten, aber die zerstörte Gesamtkapazität ist immer größer oder gleich der geschaffenen Gesamtkapazität, wodurch sichergestellt wird, dass niemand die Kapazität willkürlich erhöhen kann. Da Kapazität übertragen, aber nicht beliebig erhöht werden kann, ist der Besitz von Kapazität gleichbedeutend mit dem Besitz einer entsprechenden Menge an Konsenszustandsraum. Die Kapazität ist das native Asset im CKB-Netzwerk. Die Zerstörung einer Zelle markiert sie lediglich als "zerstört", ähnlich wie nicht verbrauchte Bitcoin-UTXOs verbraucht werden und nicht physisch aus der Blockchain entfernt werden. Jede Zelle kann nur einmal zerstört werden, genauso wie jeder UTXO nur einmal ausgegeben werden kann.

Die Merkmale dieses Modells sind:

1. Der Staat ist von vorrangiger Bedeutung.

2. Eigentum ist ein Attribut des Staates, wobei jeder Staat einen einzigen Eigentümer hat.

3. Ständig werden Staaten zerstört und neu geschaffen.

Daher ist eine Zelle eine verallgemeinerte Version von UTXO.

Brennstoff

Fuel verwendet das Strict Access List-Modell, bei dem es sich um eine UTXO-Optimierung handelt, die auf dem Konzept von Contract UTXO basiert.

Wie bereits erwähnt, hat der traditionelle UTXO in BTC nur zwei Attribute: Coin-Menge und Besitzer. Im Gegensatz dazu bietet Contract UTXO zusätzliche grundlegende Eigenschaften, einschließlich Coin-Menge, Vertrags-ID, Vertragscode-Hash und Speicherstamm.

Wenn Sie ein zustandsloses Ausführungsmodell verwenden, erfordert nur Contract UTXO einen Vertragscode-Hash und einen Speicherstamm. In einem zustandsbehafteten Ausführungsmodell können diese Felder in Vertrags-UTXO weggelassen werden, es wird jedoch ein separater Speicherelement-UTXO-Typ benötigt. Die UTXO-ID, eine eindeutige Kennung für jeden UTXO, die als Schlüssel in einer Schlüssel-Wert-Speicherdatenbank dient, wird aus dem Ausgabepunkt des UTXO oder seiner Variante (z. B. Hash des Ausgabepunkts und seiner Felder) generiert.

In diesem Modell kann Contract UTXO, ähnlich wie Smart Contracts, von jedem aufgerufen werden.

Es ist wichtig zu beachten, dass Fuel Funktionen bietet, die eher Smart Contracts als Skripten ähneln. Die Einschränkungen des UTXO-Modells selbst machen die Anwendungsentwicklung mit einer VM zu einer Herausforderung, insbesondere bei der Behandlung von UTXO-Konfliktproblemen. Im Allgemeinen gibt es drei Lösungen: Erstens, Off-Chain-Prozess, z. B. beim Rollup; zweitens die Vorsequenzierung zusätzlicher Arbeiten, die Fuel einsetzt; drittens die oben erwähnte Open Transaction in CKB, bei der jeder Benutzer Teiltransaktionen vorschlagen kann und ein Matchmaker (ähnlich einem Sequenzer) diese zu vollständigen Transaktionen zusammenfasst. Die entsprechende Lösung in BTC ist PBST.

Schlussfolgerung

Aus diesem Artikel haben wir ein Verständnis für die Grundprinzipien von UTXO gewonnen, die Stärken und Schwächen seines Modells im Vergleich zum Konto-/Saldomodell von Ethereum erkannt und einen klareren Einblick in das Konzept von UTXO und seinen verwandten Erweiterungen erhalten.

Als eines der zentralen Designprinzipien von Bitcoin spielt das UTXO-Modell eine entscheidende Rolle bei der Gewährleistung der Sicherheit und Rückverfolgbarkeit von Transaktionen. Mit der kontinuierlichen Weiterentwicklung und Erweiterung der Blockchain-Technologie hat sich das UTXO-Modell weiterentwickelt (z. B. EUTXO, Zelle, Strict Access List), das mehr Möglichkeiten für die Transaktion und Verwaltung digitaler Vermögenswerte bietet. Durch eingehende Forschung und Verständnis des UTXO-Konzepts und der damit verbundenen Erweiterungen können wir das Wesen der Blockchain-Technologie besser erfassen und eine solidere Grundlage für zukünftige Innovationen und Anwendungen schaffen.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [极客 Web3], Alle Urheberrechte liegen beim ursprünglichen Autor [0xAyA]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.