Vorwort

Die Ausgabe von Vermögenswerten auf Basis von BTC war schon immer ein heißes Thema. Von den ersten Colored Coins im Jahr 2011 bis zum kürzlich populären Ordinal-Protokoll war es der BTC-Community immer wieder möglich, neue Spieler zu finden und einen Konsens zu erzielen, aber nur wenige sind dabei geblieben. Lightning Labs hat jedoch ehrgeizige Pläne zur Entwicklung von Stablecoins auf Basis von Taproot Assets vorgestellt. Tether kündigte außerdem an, das RGB-Protokoll zum Prägen von USDT auf der Schicht 1 von Bitcoin zu verwenden.

Das bedeutet, dass der einst berühmte OmniLayer (ehemals Mastercoin) nicht mehr der größte Akteur im BTC-Ökosystem ist. Und Client Side Validation (CSV)-Asset-Protokolle beginnen in jedermanns Vision Einzug zu halten. Diese Protokolle wahren nicht nur die Integrität herkömmlicher Bitcoin-Asset-Protokolle, sondern verbessern auch die Skalierbarkeit. Eine Reihe von Asset-Protokollen innerhalb des Bitcoin-Ökosystems wirft jedoch relevante Fragen auf: Wie unterscheiden sie sich voneinander und wie sollte man sich in dieser Landschaft zurechtfinden und Chancen nutzen?

Ziel dieses Artikels ist es, den Leser durch einen umfassenden Überblick über die verschiedenen Asset-Protokolle zu führen, die in der Geschichte von Bitcoin entstanden sind. Darüber hinaus soll die mögliche Entwicklung Bitcoin-basierter Asset-Protokolle in absehbarer Zukunft untersucht werden.

Farbige Münzen

Das Colored Coins-Konzept wurde erstmals von Yoni Assia, dem heutigen CEO von eToro, in seinem wegweisenden Artikel „ Bitcoin 2.X (auch bekannt als Colored Bitcoin)“ am 27. März 2012 formuliert. In dem Artikel wurde postuliert, dass die zugrunde liegende Technologie von Bitcoin ebenso grundlegend und fehlerlos sei wie HTTP für das Internet. Daher wurde das Colored Coins-Token-Protokoll auf Basis von BTC entwickelt.

Yoni Assia stellte sich die Schaffung einer BTC 2.0-Wirtschaft durch diese Innovation vor, die es jeder Community ermöglichen würde, auf diese Weise mehrere Währungen zu generieren. Die Nutzung der zugrunde liegenden Technologie von Bitcoin zur Transaktionsabwicklung und zur Verhinderung doppelter Ausgaben war damals eine bahnbrechende Idee.

Colored Coins ist ein Protokoll zur Ausgabe von Vermögenswerten auf der Bitcoin-Blockchain. Dabei wird ein bestimmter Teil der Bitcoins „eingefärbt“, um andere Vermögenswerte zu kennzeichnen. Diese gekennzeichneten Bitcoins behalten weiterhin ihre ursprüngliche Funktionalität, stellen aber auch einen anderen Vermögenswert oder Wert dar. Die drängende Frage war jedoch, wie diese Idee im Bitcoin-Netzwerk verwirklicht werden konnte.

Am 3. Juli 2014 machte ChromaWay einen bedeutenden Schritt mit der Entwicklung des Enhanced Colored Coins Order-based Protocol (EPOBC), das den Erstellungsprozess farbiger Münzen für Entwickler erheblich vereinfachte. Dies war das erste Protokoll zur Verwendung der OP_RETURN- Funktion von Bitcoin Script.

Das Ergebnis sah so aus:

Eine solche Implementierung ist sehr prägnant, bringt aber auch viele Probleme mit sich:

1. Fungibilität und Problem des Mindestbindungswerts Durch die Bindung von 1000 Sats in der Genesis-Transaktion für eine farbige Münze wird die Mindesteinheit dieser farbigen Münze zu 1 Sat. Dies bedeutet, dass der Vermögenswert oder Token theoretisch in maximal 1000 Einheiten aufgeteilt werden kann (in der Praxis ist dies jedoch geringer, um Staubangriffe zu verhindern). Beispielsweise wurde der minimale Satoshi-Wert einmal auf 546 SATs festgelegt, und für Ordinalzahlen ist er sogar noch höher.
2. Herausforderungen bei der Validierung Um die Echtheit und den Besitz einer farbigen Münze zu bestimmen, muss ihre Transaktionshistorie von der Entstehungstransaktion bis zum aktuellen UTXO zurückverfolgt und validiert werden. Daher müssen dedizierte Wallets, vollständige Knoten und sogar Scanner entwickelt werden.
3. Potenzielles Risiko einer Miner-Zensur ColoredTransaction weist besondere Merkmale auf, wie z. B. das Schreiben von Metadaten in die Ausgabe, was die Möglichkeit einer Miner-Zensur mit sich bringt.

Bei Colored Coins handelt es sich im Wesentlichen um ein Asset-Tracking-System, das die Validierungsregeln von Bitcoin nutzt, um Asset-Transfers zu verfolgen. Um jedoch nachzuweisen, dass eine bestimmte Ausgabe (txout) einen bestimmten Vermögenswert darstellt, müssen Sie die gesamte Übertragungskette vom Ursprung des Vermögenswerts bereitstellen. Das bedeutet, dass die Validierung der Gültigkeit einer Transaktion möglicherweise eine lange Beweiskette erfordert. Um dieses Problem anzugehen, wurden Vorschläge wie OP_CHECKCOLORVERIFY gemacht, um die Validierung von Colored-Coin-Transaktionen direkt auf BTC zu unterstützen, aber der Vorschlag wurde nicht angenommen.

Der erste ICO in Krypto: Mastercoin

Das Konzept von Mastercoin wurde ursprünglich von JR Willett vorgeschlagen. Im Jahr 2012 veröffentlichte er ein Whitepaper mit dem Titel „ The Second Bitcoin Whitepaper“, in dem er die Idee darlegte, neue Vermögenswerte oder Token auf der bestehenden Bitcoin-Blockchain zu schaffen. Dieses Konzept wurde schließlich als „MasterCoin“ bekannt, das später in Omni Layer umbenannt wurde.

Im Jahr 2013 führte das Mastercoin-Projekt eine frühe Version dessen durch, was wir heute als ICO (Initial Coin Offering) bezeichnen, und sammelte erfolgreich Millionen von Dollar. Dies gilt als der erste ICO in der Geschichte. Eine der bemerkenswertesten Anwendungen von Mastercoin ist Tether (USDT), ein bekannter, mit Fiat besicherter Stablecoin, der ursprünglich auf dem Omni Layer ausgegeben wurde.

Tatsächlich entstand die Idee von Mastercoin schon vor Coloured Coins. Der Grund, warum wir es als Zweites besprechen, ist, dass MasterCoin im Vergleich zu Colored Coins eine relativ umfassendere Lösung ist. MasterCoin hat eine vollständige Knotenschicht eingerichtet, die komplexere Funktionen wie intelligente Verträge bietet. Im Gegensatz dazu ist Colored Coins einfacher und direkter und konzentriert sich hauptsächlich auf das „Färben“ oder Markieren von Bitcoin UTXOs, um andere Vermögenswerte darzustellen.

Der Hauptunterschied zwischen den beiden besteht darin, dass Mastercoin in der Blockchain nur verschiedene Arten von Transaktionsverhalten aufzeichnet und keine zugehörigen Vermögensinformationen speichert. In den Knoten für Mastercoin wird eine Datenbank des Zustandsmodells durch Scannen von Bitcoin-Blöcken verwaltet, und diese Datenbank befindet sich in den Knoten außerhalb der Blockchain.

Im Vergleich zu farbigen Münzen kann Mastercoin eine komplexere Logik ausführen. Da die Zustände in der Blockchain nicht aufgezeichnet oder überprüft werden, müssen die Transaktionen außerdem nicht aufeinanderfolgend (durchgehend gefärbt) sein.

Um die komplexe Logik von Mastercoin zu implementieren, müssen Benutzer jedoch dem Status vertrauen, der in der Off-Chain-Datenbank innerhalb der Knoten verwaltet wird, oder ihre eigenen Omni-Layer-Knoten ausführen, um Überprüfungen durchzuführen.

In Summe:

Der Hauptunterschied zwischen Mastercoin und Coloured Coins besteht darin, dass Mastercoin nicht alle für das Protokoll erforderlichen Daten auf der Blockchain verwaltet. Stattdessen greift es auf das Konsenssystem von Bitcoin zurück, um die Veröffentlichung und Bestellung seiner eigenen Transaktionen zu verwalten, und verwaltet dann den Status in einer Datenbank außerhalb der Kette.

Laut Informationen von OmniBolt schlägt Omni Layer ein neues UBA-Asset-Protokoll (UTXO Based Asset) für Tether vor, das das Taproot-Upgrade nutzen wird. Dieses Protokoll bettet Vermögensinformationen in tapleaf ein und ermöglicht so Funktionen wie bedingte Zahlungen. Gleichzeitig arbeitet OmniBolt an der Integration von Stark in die Lightning Network-Infrastruktur des Omni Layers.

Das Konzept der clientseitigen Validierung

Wenn wir das Konzept der Client Side Validation (CSV) verstehen wollen, müssen wir in das Jahr nach der Entstehung von Colored Coins und Mastercoin zurückblicken, nämlich 2013. In diesem Jahr veröffentlichte Peter Todd, ein früher Bitcoin- und Kryptographieforscher, einen Artikel mit dem Titel „ Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation“. „ Obwohl der Titel die clientseitige Validierung nicht ausdrücklich erwähnt, zeigt eine sorgfältige Lektüre, dass es sich hierbei um eine der frühesten Schriften handelt, in denen das Konzept vorgestellt wird.

Peter Todd hat nach Möglichkeiten gesucht, den Betrieb von Bitcoin effizienter zu gestalten. Er entwickelte ein komplexeres Konzept der clientseitigen Validierung, basierend auf der Idee von Zeitstempeln. Darüber hinaus führte er das Konzept eines „Einwegsiegels“ ein, auf das später noch eingegangen wird.

Um Peter Todds Gedanken zu folgen, müssen wir zunächst verstehen, welches Problem Bitcoin tatsächlich löst. Laut Peter Todd geht Bitcoin drei Probleme an:

1. Veröffentlichungsnachweis: Der Kern des Veröffentlichungsnachweises besteht darin, das Problem der doppelten Ausgaben zu lösen. Wenn Alice beispielsweise einige Bitcoins an Bob übertragen möchte, obwohl sie eine Transaktion zur Übertragung an Bob unterzeichnet hat, weiß Bob möglicherweise nicht physisch, dass eine solche Transaktion existiert. Daher benötigen wir einen öffentlichen Ort zum Veröffentlichen von Transaktionen, und jeder kann die Transaktionen von dort aus abfragen.
2. Ordnungskonsens: In Computersystemen existiert die physische Zeit, die wir normalerweise erleben, nicht. In verteilten Systemen handelt es sich bei der Zeit häufig um Lamport-Zeitstempel, die kein Maß für unsere physische Zeit darstellen, sondern unsere Transaktionen ordnen.
3. Validierung (optional): Bei der Validierung von Bitcoin werden die Signaturen und die bei BTC-Transaktionen übertragenen Beträge überprüft. Peter Todd glaubt jedoch, dass diese Validierung nicht notwendig ist, um ein Token-System auf Bitcoin aufzubauen; Es ist lediglich eine Optimierungsoption.

An dieser Stelle erinnern Sie sich vielleicht an OmniLayer, das wir zuvor besprochen haben. OmniLayer selbst delegiert die Zustandsberechnung und -validierung nicht an Bitcoin, nutzt jedoch die Sicherheit von Bitcoin wieder. Colored Coins hingegen vertraut Bitcoin die Statusverfolgung an. Die Existenz dieser beiden Systeme hat bereits gezeigt, dass die Validierung nicht unbedingt auf der Blockchain erfolgen muss.

Wie verifiziert die clientseitige Validierung Transaktionen effektiv?

Schauen wir uns zunächst an, was überprüft werden muss:

1. Status (Überprüfung der Transaktionslogik)
2. Stellen Sie sicher, dass die Eingaben (TxIn) gültig sind, um Doppelausgaben zu verhindern.

Es ist leicht zu erkennen, dass für auf Bitcoin ausgegebene Vermögenswerte bei jeder Transaktion eine Überprüfung des gesamten relevanten Transaktionsverlaufs erforderlich ist, um sicherzustellen, dass die referenzierten Eingaben nicht ausgegeben wurden und der Status korrekt ist. Das ist höchst unpraktisch. Wie können wir das also verbessern?

Peter Todd schlägt vor, dass wir diesen Prozess vereinfachen können, indem wir den Schwerpunkt der Überprüfung ändern. Anstatt zu bestätigen, dass die Ausgabe nicht doppelt ausgegeben wurde, konzentriert sich diese Methode darauf, sicherzustellen, dass die Eingaben einer Transaktion veröffentlicht wurden und nicht mit anderen Eingaben in Konflikt stehen. Durch die Reihenfolge der Eingaben in jedem Block und die Verwendung eines Merkle-Baums kann diese Art der Überprüfung effizienter durchgeführt werden, da jedes Mal nur ein kleiner Teil der Daten und nicht der gesamte Kettenverlauf der Eingabe erforderlich ist.

Die von Peter Todd vorgeschlagene Struktur des Verpflichtungsbaums lautet wie folgt:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

Aber wie können wir einen solchen Verpflichtungsbaum auf der Blockchain speichern? An dieser Stelle können wir das Konzept eines „Einwegsiegels“ einführen.

Einwegsiegel

Single Use Seal ist eines der Kernkonzepte zum Verständnis von CSV. Es ähnelt dem physischen, einmal verwendbaren Siegel, das zum Schutz von Frachtcontainern verwendet wird. Ein Einmalsiegel ist ein einzigartiger Gegenstand, der genau einmal auf einer Nachricht verschlossen werden kann. Vereinfacht ausgedrückt handelt es sich bei einem Einmalsiegel um einen abstrakten Mechanismus zur Verhinderung doppelter Ausgaben.

Für das SealProtocol gibt es drei Elemente und zwei Aktionen.

Grundelemente:

1. l: Siegel
2. m: Nachricht, bei der es sich um Informationen oder Transaktionen handelt
3. w: Zeuge, jemand oder etwas, das das Siegel überprüfen kann

Grundlegende Operationen: Es gibt zwei grundlegende Aktionen:

1. Close(l, m) → w: Schließe das Siegel l auf der Nachricht m und erzeuge einen Zeugen w.
2. Verify(l, w, m) → bool: Überprüfen Sie, ob Siegel l bei Nachricht m geschlossen wurde.

Die Sicherheit einer Single-Use-Siegelimplementierung bedeutet, dass ein Angreifer nicht zwei verschiedene Nachrichten m1 und m2 finden kann, sodass die Verify-Funktion für dasselbe Siegel „true“ zurückgibt.

Vereinfacht ausgedrückt stellt ein Single-Use-Siegel sicher, dass ein bestimmter Vermögenswert oder ein bestimmtes Datenelement nur einmal verwendet oder gesperrt wird. Im Zusammenhang mit Bitcoin bedeutet dies normalerweise, dass ein UTXO nur einmal ausgegeben werden kann. Daher können die Ergebnisse von Bitcoin-Transaktionen als einmalige Siegel betrachtet werden, und wenn ein Ausgang als Eingang in einer anderen Transaktion verwendet wird, ist dieses Siegel „gebrochen“ oder „verwendet“.

Bei Vermögenswerten auf Bitcoin fungiert Bitcoin selbst als „Zeuge“ (w) für das Single-Use-Siegel. Dies liegt daran, dass Knoten zur Überprüfung einer Bitcoin-Transaktion prüfen müssen, ob jede Eingabe der Transaktion auf ein gültiges und nicht ausgegebenes UTXO verweist. Wenn eine Transaktion versucht, ein bereits verwendetes UTXO doppelt auszugeben, lehnen die Konsensregeln von Bitcoin und das Netzwerk ehrlicher Knoten diese Transaktion ab.

Um es noch einfacher auszudrücken:

Ein Einmal-Siegel behandelt jede Blockchain wie eine Datenbank, in der wir eine Verpflichtung zu einer bestimmten Nachricht speichern und ihren Status als entweder ausgegeben oder nicht ausgegeben beibehalten.

Zusammenfassend weisen Assets, die eine clientseitige Validierung nutzen, die folgenden Merkmale auf:

1. Datenspeicherung außerhalb der Kette: Der Transaktionsverlauf, der Besitz und andere relevante Daten von Vermögenswerten, die eine clientseitige Validierung verwenden, werden größtenteils außerhalb der Kette gespeichert. Dies reduziert den Bedarf an Datenspeicherung in der Kette erheblich und trägt zur Verbesserung der Privatsphäre bei.
2. Commitment-Mechanismus: Obwohl Asset-Daten außerhalb der Kette gespeichert werden, werden Änderungen oder Übertragungen dieser Daten durch Commitments in der Kette aufgezeichnet. Diese Verpflichtungen ermöglichen es On-Chain-Transaktionen, auf Off-Chain-Zustände zu verweisen, wodurch die Integrität und Unveränderlichkeit von Off-Chain-Daten gewährleistet wird.
3. On-Chain-Zeugen (nicht unbedingt BTC): Auch wenn die meisten Daten und Validierungen außerhalb der Kette erfolgen, können Vermögenswerte, die eine clientseitige Validierung nutzen, dennoch die Sicherheit der zugrunde liegenden Blockchain (Veröffentlichungsnachweis, Transaktionsbestellung) durch darin eingebettete Verpflichtungen nutzen -Kette.
4. Auf der Clientseite durchgeführte Validierungsarbeiten: Der Großteil der Validierungsarbeiten wird auf dem Gerät des Benutzers durchgeführt. Das bedeutet, dass nicht jeder Knoten im Netzwerk an der Validierung jeder Transaktion teilnehmen muss; Lediglich die beteiligten Parteien müssen die Gültigkeit der Transaktion überprüfen.

Für diejenigen, die Assets mit clientseitiger Validierung verwenden, ist noch ein weiterer Punkt zu beachten:

Bei der Transaktion und Validierung von Vermögenswerten mit clientseitiger Validierung außerhalb der Kette ist es notwendig, nicht nur den privaten Schlüssel vorzulegen, der den Vermögenswert enthält, sondern auch einen vollständigen Merkle-Pfadnachweis für den entsprechenden Vermögenswert bereitzustellen.

RGB, der Pionier von CSV

Das Konzept von RGB wurde nach 2015 von Giacomo Zucco, einer bekannten Persönlichkeit in der Community, vorgeschlagen. Dies war eine Zeit, in der Ethereum auf dem Vormarsch war, ICOs (Initial Coin Offerings) zunahmen und viele Versuche unternommen wurden, Projekte über Bitcoin hinaus zu schaffen, wie etwa Mastercoin und Coloured Coins.

Giacomo Zucco war von diesen Entwicklungen enttäuscht. Er glaubte, dass keines dieser Projekte dem Potenzial von Bitcoin entsprach und dass frühere Versuche, Token auf Bitcoin zu implementieren, unzureichend waren. Während dieser Zeit lernte er Peter Todd kennen und war von dessen Ideen zur Client-Side-Validation (CSV) fasziniert. Dies veranlasste ihn, die Idee von RGB vorzuschlagen.

Abgesehen von den zuvor erwähnten Merkmalen von Assets, die eine clientseitige Validierung verwenden, besteht der Hauptunterschied zu RGB und früheren Asset-Protokollen in der Hinzufügung einer Ausführungs-VM (Virtual Machine) für die Turing-vollständige Vertragsausführung. Um die Sicherheit der Vertragsdaten zu gewährleisten, wurden Schema und Schnittstelle entwickelt. Das Schema deklariert, ähnlich wie bei Ethereum, den Inhalt und die Funktionen eines Vertrags, während die Schnittstelle für die Implementierung spezifischer Funktionen verantwortlich ist, ähnlich wie bei Schnittstellen in Programmiersprachen.

Die Schemata dieser Verträge sind dafür verantwortlich, Verhaltensweisen einzuschränken, die während der VM-Ausführung die Erwartungen übertreffen. Beispielsweise sind RGB20 und RGB21 dafür verantwortlich, bei Transaktionen bestimmte Beschränkungen für fungible und nicht fungible Token aufzuerlegen.

Der in RGB verwendete Commitment-Mechanismus ist Pedersen Hash

Sein Vorteil liegt in der Fähigkeit, sich auf einen Wert festzulegen, ohne ihn preiszugeben. Durch die Verwendung von Pedersen Hash zum Aufbau eines Merkle-Baums können Sie einen datenschutzschützenden Merkle-Baum erstellen, der seine Werte verbergen kann. Diese Struktur ist in bestimmten Protokollen zum Schutz der Privatsphäre nützlich, beispielsweise bei einigen anonymen Kryptowährungsprojekten. Es ist jedoch möglicherweise nicht für CSV-Assets geeignet, was später im Vergleich zu Taproot Assets erwähnt wird.

Virtuelles Maschinendesign für RGB-Einfachheit → AluVM

Ziel von RGB war nicht nur die Implementierung eines clientseitig validierten Asset-Protokolls, sondern auch die Ausweitung auf Turing-vollständige virtuelle Maschinenausführung und Vertragsprogrammierung. Ursprünglich behauptete RGB, eine Programmiersprache namens Simplicity zu verwenden, die einen Ausführungsnachweis generiert und eine formelle Überprüfung (um Fehler zu vermeiden) der darin geschriebenen Verträge ermöglicht. Die Entwicklung dieser Sprache verlief jedoch nicht wie geplant, was zu Komplikationen führte, die letztendlich das gesamte RGB-Protokoll behinderten. Schließlich begann RGB, eine von Maxim entwickelte VM namens AluVM zu verwenden, mit dem Ziel, undefiniertes Verhalten zu vermeiden, ähnlich wie beim ursprünglichen Simplicity. Das neue AluVM soll in Zukunft durch eine Programmiersprache namens Contractum ersetzt werden und sich von der derzeitigen Verwendung von Rust abwenden.

RGB-Layer2-Skalierungsrichtung: Lightning-Netzwerk oder Sidechain?

Clientseitig validierte Vermögenswerte können nicht kontinuierlich sicher außerhalb der Kette gehandelt werden, da sie für die Veröffentlichung und Bestellung von Transaktionen immer noch auf L1 angewiesen sind. Das bedeutet, dass ihre Transaktionsgeschwindigkeit ohne eine Layer-2-Skalierungslösung immer noch durch die Blockproduktionsgeschwindigkeit ihres L1-Zeugen begrenzt ist. Das bedeutet, dass, wenn RGB-Transaktionen direkt auf Bitcoin durchgeführt werden, unter strengen Sicherheitsanforderungen die Zeit zwischen zwei zusammengehörigen Transaktionen mindestens zehn Minuten auseinander liegen müsste (die Blockzeit von BTC), was oft unannehmbar langsam ist.

RGB und das Lightning Network

Vereinfacht ausgedrückt funktioniert das Lightning Network dadurch, dass die Parteien einer Transaktion eine Reihe von Verträgen (Commitment-Transaktionen) außerhalb der Kette unterzeichnen. Diese Verträge stellen sicher, dass im Falle eines Verstoßes einer Partei gegen die Vereinbarung die geschädigte Partei den Vertrag (Verpflichtungstransaktion) zur Abwicklung an BTC übermitteln, ihre Gelder zurückfordern und den Verletzer bestrafen kann. Mit anderen Worten: Das Lightning Network gewährleistet die Sicherheit von Off-Chain-Transaktionen durch Protokoll und spieltheoretisches Design.

RGB könnte seine eigene Lightning-Netzwerk-Infrastruktur aufbauen, indem es Vertragsdetails für Zahlungskanäle entwirft, die für RGB selbst geeignet sind. Allerdings ist der Aufbau einer solchen Infrastruktur aufgrund der hohen Komplexität des Lightning-Netzwerks nicht einfach, insbesondere angesichts der jahrelangen Arbeit von Lightning Labs in diesem Bereich und des Marktanteils von LND von über 90 %.

RGBs Sidechain Prime

LNP-BP, der derzeitige Betreuer des RGB-Protokolls, veröffentlichte im Juni 2023 einen Vorschlag von Maxim für eine clientseitig validierte Asset-Skalierungslösung namens Prime. Darin kritisierte Maxim bestehende Sidechain- und Lightning Network-Skalierungslösungen als zu komplex in der Entwicklung. Er brachte seine Überzeugung zum Ausdruck, dass außer Prime auch die anderen Erweiterungsmethoden, darunter NUCLEUS-Multi-Node-Lightning-Kanäle und Ark/Enigma-Kanalfabriken, mehr als zwei Jahre Entwicklungszeit erfordern würden. Allerdings könnte Prime bereits in einem Jahr fertiggestellt sein.

Prime ist nicht als traditionelle Blockchain konzipiert. Stattdessen handelt es sich um eine modulare Proof-Publishing-Schicht, die speziell für die clientseitige Validierung erstellt wurde. Es besteht aus vier Hauptkomponenten:

1. Zeitstempeldienst: Dieser Dienst kann eine Transaktionssequenz in nur 10 Sekunden abschließen.
2. Beweise: Diese werden in Form von Partial Merkle Trees (PMTs) gespeichert und zusammen mit Blockheadern erstellt und veröffentlicht.
3. Einmalsiegel: Dabei handelt es sich um ein abstraktes Protokoll für Einmalsiegel, das Doppelausgaben verhindern soll. Bei der Implementierung auf Bitcoin kann es ähnlich wie das aktuelle RGB-Design an UTXOs gebunden werden.
4. Smart Contract Protocol: Shard-Verträge für RGB (die ersetzt werden können)

Daraus können wir ersehen, dass Prime zur Lösung des Problems der Transaktionsbestätigungszeiten in RGB einen Zeitstempeldienst nutzt, um Off-Chain-Transaktionen schnell zu bestätigen und sie mit IDs in Blöcke zu packen. Gleichzeitig können Transaktionsnachweise auf Prime durch PMTs weiter konsolidiert und dann checkpointartig auf BTC verankert werden.

Taproot-basiertes CSV Assets-Protokoll: Taproot Assets

Taproot Assets ist ein auf Taproot basierendes CSV-Asset-Protokoll, das für die Ausgabe von Assets auf der Bitcoin-Blockchain entwickelt wurde. Diese Vermögenswerte können über das Lightning Network sofort, in großen Mengen und zu geringen Kosten gehandelt werden. Der Kern von Taproot Assets ist die Nutzung der Sicherheit und Stabilität von Bitcoin zusammen mit der Geschwindigkeit, Skalierbarkeit und den niedrigen Kosten des Lightning Network. Das Protokoll wurde von Roasbeef, dem CTO von Lightning Labs, entworfen und entwickelt. Roasbeef ist wahrscheinlich die einzige Person auf dem Planeten, die persönlich die Entwicklung sowohl eines Bitcoin-Clients (BTCD) als auch eines Lightning Network-Clients (LND) geleitet hat und damit ein profundes Verständnis von BTC demonstriert.

Taproot-Transaktionen übertragen nur den Root-Hash des Asset-Skripts, was es für externe Beobachter schwierig macht, zu erkennen, ob es sich um Taproot-Assets handelt, da der Hash selbst generisch ist und beliebige Daten darstellen kann. Mit dem Taproot-Upgrade erhielt Bitcoin die Möglichkeit, Smart Contracts (TapScript) auszuführen. Darauf aufbauend erstellt die Asset-Kodierung von Taproot Assets im Wesentlichen eine Token-Definition ähnlich ERC20 oder ERC721. Damit erhält Bitcoin nicht nur die Fähigkeit, Vermögenswerte zu definieren, sondern auch die Fähigkeit, intelligente Verträge zu schreiben, und legt damit den Grundstein für eine Token-Smart-Contract-Infrastruktur für Bitcoin.

Die Kodierungsstruktur von Taproot Assets ist wie folgt:

von roasbeef, CTO von Lighting Labs

Auch als CSV-Asset-Protokoll weist Taproot Assets im Vergleich zu RGB ein prägnanteres Design auf. Der größte Unterschied zwischen Taproot Assets und RGB in Bezug auf die Anwendungsskalierbarkeit liegt in der Ausführungs-VM. Taproot Assets verwendet dieselbe TaprootScript-VM wie der native Standard von BTC. In den letzten Jahren basierten viele Infrastrukturforschungen für BTC auf TapScript, aber aufgrund der langsamen Aktualisierung von BTC kann es nicht in kurzer Zeit angewendet werden Man kann vorhersagen, dass Taproot Assets in Zukunft ein Testgelände für diese neuen Ideen sein wird.

Unterschiede zwischen Taproot Assets und RGB

1. Transaktionsvalidierung und Light Node-Freundlichkeit

Taproot Assets weist aufgrund der Implementierung eines Summenbaums eine hohe Verifizierungseffizienz und Sicherheit auf. Es ermöglicht die staatliche Überprüfung und die Durchführung von Transaktionen einfach durch den Besitz eines Nachweises, ohne dass die gesamte Transaktionshistorie durchsucht werden muss. Im Gegensatz dazu macht es die Verwendung von Pedersen-Verpflichtungen durch RGB schwierig, die Gültigkeit von Eingaben effektiv zu überprüfen. Daher erfordert RGB die Rückverfolgung der Transaktionshistorie der Eingaben, was zu einer erheblichen Belastung werden kann, da sich die Transaktionen im Laufe der Zeit anhäufen. Das Design des Merkel-Summenbaums ermöglicht es Taproot Assets außerdem, die Light-Node-Verifizierung einfach zu ermöglichen, eine Funktion, die bisher in auf Bitcoin basierenden Asset-Protokollen nicht verfügbar war.

2. Ausführungs-VM

Taproot Assets wurde als Reaktion auf das Taproot-Upgrade des Bitcoin-Netzwerks entwickelt. Es nutzt TaprootScriptVM, die Skriptausführungs-Engine, die nach dem Taproot-Upgrade mit Bitcoin geliefert wird. Darüber hinaus verwendet es vPSBT, eine Variante von Bitcoins PSBT, was darauf hinweist, dass es nach der Entwicklung des Lightning-Channel-Mechanismus von Taproot Assets sofort die gesamte aktuelle Infrastruktur von LND (Lightning Network Daemon) sowie frühere Produkte von Lightning Labs (LND) wiederverwenden kann hält derzeit über 90 % Marktanteil im Lightning-Netzwerk). Darüber hinaus basiert der jüngste beliebte BitVM-Vorschlag auf TaprootScript, was theoretisch bedeutet, dass alle diese Verbesserungen letztendlich Taproot Assets zugute kommen könnten.

Allerdings funktioniert RGB etwas anders. Seine virtuelle Maschine und seine Validierungsregeln (SCHEMA) sind Teil eines in sich geschlossenen Systems und bilden ein gewissermaßen abgeschlossenes Ökosystem. RGB operiert innerhalb seines eigenen Ökosystems und seine Beziehung zum breiteren Bitcoin-Ökosystem ist nicht so eng, wie manche vielleicht denken. Im Hinblick auf das Taproot-Upgrade besteht die einzige echte Interaktion von RGB beispielsweise darin, Commitment-Daten in der Blockchain im Witness TapLeaf zu kodieren. Dies zeigt, dass RGB und das Taproot-Upgrade nur minimal miteinander verbunden sind.

3. Intelligente Verträge

In der aktuellen RGB-Implementierung werden Verträge und die VM stark betont. Allerdings scheint es bei Taproot Assets keinen Fokus auf Smart Contracts zu geben, zumindest noch nicht. Die aktuelle RGB-Implementierung hat noch nicht erklärt, wie Änderungen am Global State mit einzelnen Vertrags-Shards (UTXO) synchronisiert werden. Darüber hinaus können Pedersen-Verpflichtungen zwar den Gesamtbetrag der Vermögenswerte sicherstellen, es ist jedoch unklar, wie andere Staaten vor Manipulationen geschützt werden könnten, da es hierzu keine ausführlichen Erklärungen gibt.

Auf der anderen Seite hat Taproot Assets ein einfacheres Design, speichert aber derzeit nur Vermögensbestände und verarbeitet keine komplexeren Zustände, was die Diskussion über intelligente Verträge verfrüht macht. Allerdings gibt es laut Lightning Labs Pläne, sich im nächsten Jahr auf die intelligente Vertragsgestaltung für Taproot Assets zu konzentrieren.

4. Synchronisierungszentrum

Das zuvor erwähnte Grundprinzip in Bezug auf Vermögenswerte, die auf Kundenseite überprüft werden, zeigt, dass der Besitz des Nachweises genauso wichtig ist wie der Besitz des privaten Schlüssels. Es besteht jedoch die Gefahr, dass der Beweis verloren geht, da er auf der Clientseite aufbewahrt wird. Wie kann dies angegangen werden? In Taproot Assets kann dieses Problem durch die Verwendung eines „Universums“ vermieden werden. Ein Universum ist ein öffentlich überprüfbarer, spärlicher Merkle-Baum, der einen oder mehrere Vermögenswerte abdeckt. Im Gegensatz zu einem Standard-Taproot-Vermögensbaum wird ein Universum nicht zur Aufbewahrung von Taproot-Vermögenswerten verwendet. Stattdessen wird eine Teilmenge einer oder mehrerer Anlagenhistorien übernommen.

Im RGB-System wird diese Rolle von Storm übernommen, das Off-Chain-Proof-Daten über ein Peer-to-Peer-Netzwerk (p2p) synchronisiert. Aus historischen Gründen im Zusammenhang mit dem RGB-Entwicklungsteam verwenden diese Teams derzeit jedoch inkompatible Proofformate. Das RGB-Ökosystemteam DIBA hat angedeutet, dass es „ Carbonado“ entwickeln wird, um dieses Problem anzugehen, aber die Fortschritte sind unklar.

5. Technische Umsetzung

Alle von Taproot Assets verwendeten Bibliotheken sind gut getestet, da Lightning Labs über einen eigenen Bitcoin-Client (BTCD), Lightning Network-Client (LND) und eine breite Palette von Wallet-Bibliotheksimplementierungen verfügt. Im Gegensatz dazu sind die meisten für die RGB-Implementierung verwendeten Bibliotheken selbstdefiniert. Aus Sicht der Industriestandards befindet sich die Implementierung von RGB noch im experimentellen Stadium.

Ein kurzer Blick auf die Zukunft der BTC-Skalierung

Wenn man die Diskussion fortsetzt, wird deutlich, dass kundenvalidierte Asset-Protokolle über den Rahmen traditioneller Protokolle hinausgegangen sind und sich nun auf die rechnerische Skalierung zubewegen.

Viele Menschen behaupten, dass Bitcoin in Zukunft als „digitales Gold“ existieren wird, während andere Blockchains Anwendungsökosysteme schaffen werden. Allerdings bin ich anderer Meinung. Wie aus vielen Diskussionen in Bitcoin-Foren hervorgeht, wird viel über verschiedene Altcoins und ihre kurze Lebensdauer gesprochen. Der rasche Niedergang dieser Altcoins hat dazu geführt, dass sich das Kapital und die Anstrengungen, die sie umgeben, in Blasen verwandelt haben. Wir haben Bitcoin bereits als starke Grundlage des Konsenses; Es besteht keine Notwendigkeit, neue Layer-1-Lösungen (L1) nur für Anwendungsprotokolle zu entwickeln. Was wir tun sollten, ist Bitcoin, diese robuste Infrastruktur, zu nutzen, um langfristig eine dezentralere Welt aufzubauen.

Weniger On-Chain-Berechnungen, mehr On-Chain-Verifizierung

Aus der Perspektive des Anwendungsdesigns wählte Bitcoin schon früh eine Philosophie, die sich nicht auf die Berechnung in der Kette, sondern auf die Verifizierung (Turing-Vollständigkeit und -Status für intelligente Verträge) konzentrierte. Das Wesen einer Blockchain ist eine replizierte Zustandsmaschine. Wenn sich der Konsens einer Blockchain auf On-Chain-Berechnungen konzentriert, lässt sich kaum argumentieren, dass es ein vernünftiger oder skalierbarer Ansatz ist, wenn jeder Knoten im Netzwerk diese Berechnungen wiederholt. Liegt der Schwerpunkt auf der Verifizierung, dann könnte die Validierung von Off-Chain-Transaktionen der am besten geeignete Ansatz für die Skalierbarkeit von Bitcoin sein.

Wo findet die Verifizierung statt? Das ist entscheidend.

Für Entwickler, die Protokolle auf Basis von Bitcoin erstellen, ist die Frage, wie man Bitcoin für kritische Verifizierungen verwendet oder sogar Verifizierungen außerhalb der Kette platziert und wie man sichere Schemata entwirft, Sache der Protokolldesigner selbst. Sie sollten und müssen nicht mit der Kette selbst verbunden sein. Die Implementierung der Verifizierung wird zu unterschiedlichen Skalierungslösungen für BTC führen.

Aus Sicht verifizierungsbasierter Implementierungen haben wir drei Richtungen für die Skalierung:

1.Verifizierung in der Kette (OP-ZKP)

Durch die direkte Implementierung von OP-ZKP in TaprootScriptVM würde Bitcoin selbst die Möglichkeit erhalten, eine ZKP-Verifizierung durchzuführen. In Verbindung mit einigen Covenant-Design-Abwicklungsprotokollen könnte dadurch eine Zk-Rollup-Skalierungslösung entstehen, die die Sicherheit von Bitcoin übernimmt. Anders als bei der Bereitstellung eines Verifizierungsvertrags auf Ethereum sind die Upgrades von Bitcoin jedoch von Natur aus langsam, und das Hinzufügen eines solchen speziellen, möglicherweise upgradebedürftigen Op-Codes wird mit Sicherheit eine Herausforderung darstellen.

2.Verifizierung auf Semi-on-Chain (BitVM)

Das Design von BitVM stellt sicher, dass es nicht für gewöhnliche Transaktionslogik gedacht ist. Robin Linus hat auch darauf hingewiesen, dass die Zukunft von BitVM in der Schaffung eines kostenlosen Cross-Chain-Marktes für verschiedene SideChains liegt. Der Ansatz von BitVM gilt als Semi-on-Chain, da die meisten Verifizierungsberechnungen nicht in der Kette, sondern außerhalb der Kette erfolgen. Der wesentliche Grund für die Entwicklung rund um Bitcoins Taproot besteht darin, bei Bedarf TapScriptVM zur rechnerischen Verifizierung zu nutzen und dabei theoretisch die Sicherheit von Bitcoin zu übernehmen. Dieser Prozess generiert auch eine Verifizierungs-Vertrauenskette, sodass beispielsweise nur ein ehrlicher Verifizierer unter n Prüfern erforderlich ist, was als optimistische Rollups bekannt ist.

BitVM verursacht einen erheblichen On-Chain-Overhead, aber kann es ZK-Betrugsnachweise für Effizienzsteigerungen nutzen? Die Antwort lautet „Nein“, denn die Implementierung von ZK-Betrugsnachweisen hängt von der Fähigkeit ab, eine ZKP-Verifizierung in der Kette durchzuführen, was uns zurück zu den Schwierigkeiten des OP-ZKP-Ansatzes führt.

3.Verifizierung außerhalb der Kette (Clientseitige Validierung, Lightning Network)

Die vollständige Off-Chain-Verifizierung bezieht sich auf die zuvor besprochenen CSV-Asset-Protokolle und das Lightning Network. Wie in den vorherigen Diskussionen gezeigt, können wir Absprachen bei CSV-Designs nicht vollständig verhindern. Was wir tun können, ist, mithilfe von Kryptografie und Protokolldesign den Schaden durch böswillige Absprachen in kontrollierbaren Grenzen zu halten und solche Maßnahmen unrentabel zu machen.

Die Vor- und Nachteile der Off-Chain-Verifizierung liegen gleichermaßen auf der Hand. Der Vorteil besteht darin, dass es nur minimale On-Chain-Ressourcen verbraucht und ein enormes Skalierbarkeitspotenzial bietet. Der Nachteil besteht darin, dass es fast unmöglich ist, die Sicherheit von Bitcoin vollständig zu übernehmen, was die Arten und Methoden von Transaktionen außerhalb der Kette, die durchgeführt werden können, stark einschränkt. Darüber hinaus bedeutet die Off-Chain-Verifizierung auch, dass die Daten außerhalb der Kette gehalten und von den Benutzern selbst verwaltet werden, was höhere Anforderungen an die Sicherheit der Software-Ausführungsumgebung und die Stabilität der Software stellt.

Trend der Skalierungsentwicklung

Derzeit validieren beliebte Layer-2-Lösungen auf Ethereum paradigmatisch gesehen Layer-2-Berechnungen über Layer 1, was bedeutet, dass die Zustandsberechnung auf Layer 2 verlagert wird, die Überprüfung jedoch weiterhin auf Layer 1 erfolgt. In Zukunft könnten wir die Verifizierungsberechnung auf ähnliche Weise außerhalb der Kette vorantreiben und so die Leistung der aktuellen Blockchain-Infrastruktur weiter steigern.

Haftungsausschluss:

1. Dieser Artikel wurde von [Mirror] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Ben77]. Wenn Sie Einwände gegen diesen Nachdruck haben, 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.