Erfahren Sie in einem Artikel das wahre Potenzial des Asset-Issuance-Protokolls RGB

Originaltitel: „The True Potential of RGB“ Originalautor: A Jian
Dieser Artikel versucht, eine prägnante Beschreibung von RGB zu geben, einem Protokoll zur Ausgabe von Vermögenswerten auf Bitcoin (es kann auch als Off-Chain-Smart-Contract-System verstanden werden), und weist darauf hin, dass es sich stark von anderen Protokollen unterscheidet, die das Gleiche erreichen wollen oder ähnliche Funktionen machen das RGB-Protokoll weitaus skalierbarer als diese und lassen einen größeren Programmierraum übrig. Neben der Vorstellung der fertigen RGB-Designs werden wir auch diese Programmiermöglichkeiten erkunden1.
Was ist das RGB-Protokoll?
Die Idee, Vermögenswerte auf Bitcoin auszugeben, gibt es schon seit langem 2 3 . Aber das Bitcoin-Protokoll hat seine eigenen Merkmale 4: Sein Zustand wird durch nur Bitcoin UTXO („nicht ausgegebene Transaktionsausgabe“) ausgedrückt; ein UTXO trägt nur zwei Daten: seinen eigenen Nennwert (Bitcoin-Wert) und einen „öffentlichen Skriptschlüssel“ ( wird auch als „Sperrskript“ bezeichnet und dient zum Programmieren der Bedingungen für die Ausgabe der Gelder, zum Beispiel: Bereitstellung einer Signatur eines bestimmten öffentlichen Schlüssels, der die Programmierung des Sperrskripts ermöglicht, wird durch die Bitcoin-Konsensregeln bereitgestellt ; Sie können nicht zur Implementierung beliebiger Sicherheitsregeln verwendet werden. Daher ist es unmöglich, andere Assets innerhalb von UTXO zu erstellen – Bitcoin-Skripte können keine Sicherheitsprüfungen für diese Assets programmieren. Das bedeutet, dass alle Ideen zur Ausgabe von Vermögenswerten auf Bitcoin im Wesentlichen kreative Nutzungen des Bitcoin-Blockraums sind. Das bedeutet, dass wir ein Off-Chain-Smart-Contract-System entwerfen müssen und Informationen zu den Schritten benötigen, die den Vertragsstatus ändern – zum Beispiel ändert Vertrag A Parameter und B überträgt einen bestimmten Betrag eines Vermögenswerts an C. Hochladen in die Blockchain , damit durch das Sammeln dieser Informationen der aktuelle Stand dieses Smart-Contract-Systems abgerufen werden kann.
Eine grobe Entwurfsidee besteht darin, die Informationen zu den Schritten, die den Vertragsstatus ändern, intakt in die Bitcoin-Blockchain hochzuladen. Dies kann sicherlich funktionieren, es treten jedoch mehrere Probleme auf: (1) Da vollständige Informationen hochgeladen werden, kann es sein, dass mehr Blockplatz verbraucht wird, wenn der Benutzer den Status des Vertrags ändern muss (z. B. Übertragung). Zu diesem Zeitpunkt werden Sie dies auch tun müssen mehr Bearbeitungsgebühren in der Kette zahlen. Insbesondere wenn wir hoffen, dass ein solches Off-Chain-Vertragssystem eine bessere Programmierbarkeit als Bitcoin aufweist, kann die Erhöhung der Programmierbarkeit auf Kosten eines höheren Blockplatzverbrauchs gehen. (2) Bei fast jeder Transaktion innerhalb des Blocks können sich Informationen an einer Stelle ändern Daher müssen Benutzer alle Bitcoin-Blockdaten abrufen, um den neuesten Status des Off-Chain-Vertragssystems zu erhalten, was bedeutet, dass die Überprüfungskosten höher sind (3). Mit einem intelligenten Vertragssystem können Sie möglicherweise nur eine mit Bitcoin vergleichbare oder sogar noch schlechtere Privatsphäre erreichen, und wenn Sie mehr Privatsphäre bieten können, müssen Sie möglicherweise mehr Blockplatz verbrauchen.
In der Vergangenheit hat ein weit verbreitetes Protokoll namens „Omni“ keine vollständigen Informationen über Off-Chain-Vertragstransaktionen hochgeladen, sondern nur den Hash-Wert der Transaktion. Dieser Ansatz löst das oben genannte Problem 1 und entkoppelt die Komplexität von Off-Chain-Vertragstransaktionen von den wirtschaftlichen Kosten. Allerdings müssen Benutzer immer noch die volle Menge an Bitcoin-Blockdaten erhalten, um den neuesten Stand des Omni-Protokolls zu erhalten nicht. Es gibt keine spezifische Verbesserung der Privatsphäre.
RGB verwendet ein neues Paradigma namens „Einwegsiegel“. Die Verwendung ist sehr einfach: RGB erfordert, dass jeder Status jedes Vertrags mit einem bestimmten Bitcoin-UTXO verknüpft werden muss. Sobald Sie diesen Status ändern möchten, müssen Sie diesen UTXO ausgeben und die Transaktion, die ihn ausgibt, von der Blockchain bestätigen lassen Darüber hinaus muss die Bitcoin-Transaktion, die es ausgibt, auch einen Hash des Inhalts des Zustandsübergangs bereitstellen, der das an den geänderten Zustand angehängte UTXO angibt.
Für RGB-Entwickler ähnelt das Design einem nummerierten Kunststoffsiegel: Es ist leicht zu erkennen, ob es entfernt wurde, und wenn es einmal entfernt wurde, kann es nicht wiederverwendet werden. Eine andere Perspektive besteht jedoch darin, das besessene UTXO in diesem Zustand als einen Behälter oder ein Sparschwein aus Keramik zu betrachten – wenn Sie das Geld im Sparschwein herausnehmen möchten, müssen Sie das Sparschwein zerbrechen und dann den Inhalt hineinlegen im neuen Glas.
Dieses Design steht in scharfem Gegensatz zu früheren Protokollen, die den gesamten Block als große Schreibtafel behandelten: Die Verwendung von UTXO als Container bedeutet, dass Transaktionen, die dieses UTXO nicht ausgeben, keinen Einfluss auf den Vertragsstatus im Container haben können. Daher ist eine Überprüfung erforderlich Für einen bestimmten Status eines bestimmten Vertrags müssen wir nicht die Daten aller Blöcke abrufen. Wir benötigen lediglich eine Reihe von Bitcoin-Transaktionen, den Nachweis, dass diese Bitcoin-Transaktionen in einem bestimmten Block vorhanden sind, und die versprochene RGB-Statuskonvertierung der Währungsumtausch (Eins-zu-Eins-Paar mit der entsprechenden Bitcoin-Transaktion) reicht aus. Diese Daten, die zu einer Kette verknüpft werden können, sollen es uns ermöglichen, bis zum Ausgangszustand dieses Vertrags zurückzuverfolgen und so das Wesentliche dieses Zustands zu erkennen.
Für Leser, die mit On-Chain-Smart-Contract-Systemen (wie Ethereum) vertraut sind, ist etwas an diesem Prozess schwer zu verstehen: Wenn er nicht auf dem Konsens der Blockchain beruht (was bedeutet, dass der Anfangszustand der Wie wird die Sicherheit dieses intelligenten Vertragssystems gewährleistet? Wie stellen Sie sicher, dass die Vermögenswerte, die Sie erhalten, die gewünschten sind, und wie stellen Sie sicher, dass die Vermögenswerte nicht illegal ausgegeben wurden?
Die Antwort ist ebenfalls sehr einfach, sie nennt sich „clientseitige Validierung“ – Sie überprüfen sie selbst. Im On-Chain-Vertragssystem überprüfen Knoten jede Zustandsübergangsoperation gemäß den öffentlichen Zustandsübergangsregeln, lehnen ungültige Operationen ab und berechnen dann den neuesten Zustand basierend auf dem Anfangszustand. Solange jedoch die Zustandsübergangsregeln und der Anfangszustand bekannt sind, ist die Überprüfung durch Konsens in der Kette nicht die einzige Möglichkeit. Benutzer können anhand der von bereitgestellten Informationen überprüfen, ob jeder Schritt des Zustandsübergangs dem ursprünglich definierten Zustandsübergang folgt die Zahlerregel. Auf diese Weise kann die verifizierende Partei (vermutlich der Empfänger des Vermögenswerts) auch illegale Zustandsübergänge erkennen und deren Annahme verweigern.
Abschließend demonstrieren wir anhand eines Beispiels die Eigenschaften des RGB-Protokolls:
Jetzt besitzt Alice UTXO A, das X Einheiten des gemäß dem RGB-Protokoll ausgegebenen Vermögenswerts Y hält. Sie möchte Z Einheiten von Y an Bob übertragen. Dieser Stapel von Vermögenswerten durchlief insgesamt fünf Vorbesitzer (einschließlich des Vermögensausgebers), bevor er in Alices Hände gelangte. Daher muss Alice Bob Beweise für diese vier Zustandsübergänge liefern (die ersten drei davon wurden Alice vom Vorbesitzer zur Verfügung gestellt), einschließlich des Anfangszustands des Vertrags und der Zustandsübergangsregeln sowie der für jede Übertragung verwendeten Bits . Bitcoin-Transaktionen, die von jeder Bitcoin-Börse festgeschriebenen RGB-Transaktionen und der Nachweis, dass diese Bitcoin-Transaktionen von einem bestimmten Block bestätigt wurden, werden an Bob gesendet, um sicherzustellen, dass diese vier Übertragungen nicht gegen die Regeln gemäß den staatlichen Übergangsregeln verstoßen des Vertrags und entscheiden Sie dann, ob Sie ihn annehmen. Wenn Alice eine RGB-Transaktion erstellt, arrangiert sie sich auch ein UTXO, um den verbleibenden Teil zu erhalten, da Z kleiner als X ist. Schließlich bettet Alice den Hash-Wert dieser RGB-Transaktion in eine Bitcoin-Transaktion ein, die UTXO A‘ kostet, um die Zahlung abzuschließen.
Schließlich kann aufgrund der Verwendung von UTXO-Containern der neueste Status eines RGB-Vertrags als Punkt auf einem gerichteten azyklischen Graphen dargestellt werden, der keine Nachkommen hat (jeder Punkt stellt einen in einem UTXO-Container gespeicherten Status dar). Darüber hinaus kennt der Eigentümer P in der folgenden Abbildung nur den Prozess, der ihn vom Anfangszustand G des Vertrags erreicht, dh den durch den roten Kreis markierten Prozess, und weiß nichts über die grauen Punkte:
RGB-Vorteile
Leichter nachweisbarer Zustand
Wie oben erwähnt, reduziert RGB im Vergleich zu den früheren Protokollen zur Ausgabe von Vermögenswerten (Off-Chain-Vertragssysteme), die auf Bitcoin erschienen, die Kosten für die Überprüfung (einen bestimmten Zustand eines Vertrags) erheblich. Während der Transaktion muss der Empfänger nicht mehr alle Blöcke durchlaufen, um Informationen über Änderungen im Vertragsstatus zu sammeln, sondern muss lediglich eine Reihe von Bitcoin-Transaktionen sowie die von diesen Börsen versprochenen RGB-Transaktionen und die Blöcke dieser Bitcoin erhalten Wenn Transaktionen Beweise enthalten (basierend auf den Merkle-Beweisen im Blockheader), können Sie sicher sein, dass der Zahler tatsächlich eine bestimmte Menge eines bestimmten Vermögenswerts besitzt.
Diese Reduzierung der Verifizierungskosten verringert auch die Abhängigkeit (das Vertrauen) der Benutzer von großen Infrastrukturanbietern erheblich. In früheren Protokollen war es für Benutzer aufgrund der hohen Verifizierungskosten schwierig, den aktuellen Status des Vertrags selbst zu berechnen, sodass Benutzer einigen Anbietern vertrauen mussten (z. B. dem Vertragsstatusanbieter, den ihr Wallet gleichzeitig verwendete). , weil sie sich solche leisten könnten. Es gibt weniger Lieferanten, um die Kosten zu kalkulieren, was auch eine Zentralisierung der Lieferanten bedeutet. Bei RGB können sich Benutzer dies jedoch selbst leisten, indem sie einfach den Bitcoin Light-Client verwenden, um den Teil zu überprüfen, der mit Bitcoin abgewickelt wird, und das RGB-Protokoll, um den Teil der RGB-Transaktion zu überprüfen.
Im Vergleich zu einigen On-Chain-Vertragssystemen ist RGB auch leichter. Dies spiegelt sich in der Tatsache wider, dass RGB einen bestimmten Status eines Vertrags gezielt überprüfen kann; auf Systemen, die nicht auf UTXO basieren, kann aufgrund des Fehlens eines Mechanismus zur Zugriffskontrolle wie bei UTXO jede Transaktion jeden Status ändern Es ist fast unmöglich, einen bestimmten Zustand spezifisch zu überprüfen, sondern kann nur einen bestimmten Zustand bestimmen, indem alle aktuellen Zustände berechnet werden. In diesem Sinne sollten die als „globaler Zustand“ ausgedrückten Merkmale tatsächlich „einheitlicher Zustand“ genannt werden Bietet die Funktion des Querzugriffs zwischen Verträgen, stellt jedoch auch fest, dass die Überprüfungskosten höher sind und es schwieriger wird, Vertrauenslosigkeit zu erreichen.
Bei diesen On-Chain-Vertragsprotokollen besteht eine wichtige Optimierungsmaßnahme darin, zu verlangen, dass sich der Block-Header auf den neuesten Status („State Root“) festschreibt, wodurch es Light-Clients ermöglicht wird, einen bestimmten Status eines vom vollständigen Knoten erhaltenen Vertrags basierend darauf zu überprüfen diese Verpflichtungen. Dies ist eine Methode zur Wiederverwendung bereits durchgeführter Berechnungen (Berechnungen, die vom vollständigen Knoten ausgeführt wurden) und ist außerdem sehr effizient. Wenn Vertrauenslosigkeit nicht berücksichtigt wird, kann sie als effizienter als RGB angesehen werden. Dies bedeutet jedoch letztendlich, dass Light Nodes für die grundlegende Transaktionsüberprüfung und Vertragsstatusberechnung auf Full Nodes angewiesen sind. In der RGB-Wallet, die den Bitcoin Light-Client verwendet, basiert die Vertrauensannahme darauf, dass die entsprechende Bitcoin-Transaktion eine gültige Transaktion ist und der Teil, der sich auf den Vertragsstatus bezieht, vom Kunden persönlich überprüft wurde, sodass es vertrauenswürdiger ist. frei. . Der Nachteil besteht darin, dass die Überprüfungsverzögerung länger ist und mehr Daten gespeichert werden müssen.
Skalierbarkeit
Die Skalierbarkeit von RGB spiegelt sich in zwei Aspekten wider:
In die Bitcoin-Transaktion ist lediglich ein Hashwert eingebettet, was bedeutet, dass es keine Begrenzung für die Größe der RGB-Transaktion gibt (mit Ausnahme der benutzerdefinierten Regeln des Vertrags) – selbst wenn Sie ein RGB-Asset in 100 Teile aufteilen (die RGB-Transaktion). selbst wird sehr groß sein) und es gibt nur einen Hash-Wert, der in eine Bitcoin-Transaktion eingebettet werden muss. Wie in Anmerkung 6 erwähnt, gibt es zwei Möglichkeiten, einen solchen Hash-Wert einzubetten: Eine besteht darin, die OP_RETURN-Ausgabe zu verwenden, was bedeutet, dass der On-Chain-Speicherplatz eines Hash-Werts verbraucht wird. Die andere besteht darin, die Ausgabe des öffentlichen Schlüssels des Skripts zu verbergen Taproot auf dem festgeschriebenen Skriptbaum – dies verbraucht keinen Platz in der Kette. Dies bedeutet auch, dass Benutzer nicht auf Kosten der Wirtschaftlichkeit zugunsten der Programmierbarkeit verzichten müssen, sondern nur die On-Chain-Gebühren berücksichtigen müssen.
Der neueste Status des RGB-Vertrags ist ein unabhängiger Punkt auf einem gerichteten azyklischen Graphen ohne Nachkommen – das bedeutet, dass diese Zustände unabhängig voneinander geändert werden können, ohne sich gegenseitig zu beeinflussen, was bedeutet, dass Parallelität zulässig ist. Dies ist tatsächlich eine von UTXO geerbte Funktion. Dies bedeutet auch, dass ungültige Änderungen (ungültige Transaktionen), die in einer Filiale auftreten, keine Auswirkungen auf andere Filialen haben, geschweige denn dazu führen, dass der gesamte Vertrag hängen bleibt, sodass dies auch als Sicherheitsvorteil angesehen werden kann.
Ein Punkt, der an der Skalierbarkeit von RGB kritisiert wird, ist, dass der Empfänger bei jeder Übertragung alle beteiligten Transaktionen vom ursprünglichen Zustand bis zum Zahlerstaat überprüfen muss – je häufiger der Vermögenswert den Besitzer wechselt, desto größer wird der Überprüfungsaufwand für nachfolgende Empfänger wird immer schwerer. Diese Kritik ist wahr. Um es zu optimieren, müssen wir auch einen Weg finden, bereits durchgeführte Vorgänge wiederzuverwenden. Proof-System-Technologien wie SNARKs versprechen, eine solche Lösung bereitzustellen 7 .
Unterscheidung zwischen Vermögenswertdefinition und Verwahrungsmechanismus
Der letzte Vorteil hängt immer noch mit UTXO zusammen und hängt davon ab, wie wir den Sperrskriptmechanismus von UTXO verstehen.
Mithilfe eines Sperrskripts können die Entsperrbedingungen für einen Fonds programmiert und somit Verwahrungsregeln implementiert werden. Wenn ein Sperrskript beispielsweise genau einen öffentlichen Schlüssel enthält, bedeutet das, dass nur der Besitzer des entsprechenden privaten Schlüssels ihn kontrollieren kann. Allerdings sind solche Verwahrungsregeln auch die Grundlage für die Programmierung des Bitcoin-Vertragsprotokolls8. Beispielsweise könnte ein UTXO, das ein 2-von-2-Multi-Signatur-Sperrskript verwendet, im Laufe des Kanals ein Lightning-Kanal sein, die beiden Parteien könnten sich nahezu unendlich oft gegenseitig bezahlen, ohne dass sich die On- Kettenform der Mittel. Mit anderen Worten: Zu diesem Zeitpunkt stellt das 2-aus-2-Multisignatur-Sperrskript einen Wertübertragungsmechanismus dar, der es beiden Parteien ermöglicht, Werte zu übertragen, ohne die Form der Gelder in der Kette zu ändern.
Ein solcher Mechanismus kann für den von UTXO übertragenen Bitcoin-Wert verwendet werden. Natürlich kann er auch für die von ihm übertragenen RGB-Assets verwendet werden. Wir können ein RGB-Asset ausgeben und es an ein 2-von-2-UTXO mit mehreren Signaturen anhängen und dabei den Mechanismus des Lightning Channel nutzen, um dieses Asset unbegrenzt oft 9 Mal aneinander zu zahlen. Auf die gleiche Weise können RGB-Assets auch in andere Verträge eingebunden werden, die auf Bitcoin-Skripten basieren.
Dabei bilden das UTXO-Skript und das RGB-Protokoll eine funktionale Unterscheidung: Ersteres ist auf die Umsetzung der Regeln der Wertverwahrung und Wertübertragung ausgerichtet, während sich letzteres auf die Definition von Vermögenswerten konzentriert. Somit können die Verwahrung von Vermögenswerten und die Definition von Vermögenswerten getrennt werden. Dies ist eine wichtige Sicherheitsverbesserung und etwas, das die Menschen in einigen anderen On-Chain-Vertragssystemen angestrebt haben.
Bereits von RGB erstellte Designs
Die oben genannten Eigenschaften gelten für praktisch alle Protokolle, die auf der einmaligen UTXO-Versiegelung und der clientseitigen Überprüfung basieren. Auf dieser Grundlage wurde das RGB-Protokoll jedoch weiterentwickelt.
Bei der Entwicklung des aktuellen RGB-Protokolls sind Entwickler besonders auf die Privatsphäre des Protokolls bedacht, daher stärkt RGB die Privatsphäre in zweierlei Hinsicht:
Blindes UTXO. Bei einer RGB-Transaktion verwendet der Empfänger einfach die verschleierte UTXO-Kennung, um den Vermögenswert zu empfangen, ohne die Merkmale des UTXO preiszugeben, der den Vermögenswert tatsächlich erhalten hat. Dadurch wird die Fähigkeit des Empfängers, gegenüber dem nächsten Eigentümer Beweise vorzulegen, nicht beeinträchtigt, während spätere Empfänger von Vermögenswerten in die Lage versetzt werden, sich gegen die neugierigen Blicke des vorherigen Eigentümers des Vermögenswertes zu wehren.
Kugelsicher. Kann verwendet werden, um den spezifischen Betrag in jeder Transaktion auszublenden. Nachfolgende Eigentümer von Vermögenswerten können jedoch weiterhin überprüfen, dass zuvor keine weitere Emission stattgefunden hat.
Raum zum Erkunden
In diesem Abschnitt werde ich den Raum diskutieren, den das RGB-Protokoll weiterhin erforschen kann, hauptsächlich im Zusammenhang mit der Programmierbarkeit.
Derzeit konzentrieren sich die vorgeschlagenen RGB-Vertragsvorlagen (Schema) auf die Ausgabe von Vermögenswerten. Da RGB jedoch ein Paradigma der „clientseitigen Validierung“ verwendet, können wir tatsächlich jede Funktion hinzufügen, die durch clientseitige Validierung sichergestellt werden kann – nur begrenzt durch die Struktur von UTXO.
Einschränkungen
Auf Basis von UTXO wird ein Konzept, das die Programmierbarkeit erweitern kann, „Covenants“10 genannt. Der ursprüngliche Zweck einer Beschränkungsklausel besteht darin, den Bestimmungsort zu begrenzen, an den ein Geldbetrag überwiesen werden kann. Mit dieser Fähigkeit können wir viele interessante Anwendungen programmieren, wie zum Beispiel:
Fondspool für nicht interaktive Abhebungen. Wir können die Gelder vieler Menschen in demselben UTXO zusammenfassen und durch Beschränkungen sicherstellen, dass jeder von ihnen sein eigenes Geld ohne die Hilfe anderer abheben kann. Dies kann dazu führen, dass Menschen bei hoher Nachfrage nach Blockflächen kostengünstig aus Hochrisikogebieten herauskommen können.
Tresorvertrag. Ein Geldbetrag muss zunächst irgendwo ausgegeben werden und eine Zeitsperre durchlaufen, bevor er während der Zeitsperre frei ausgegeben werden kann; der Tresorbesitzer kann diesen Vorgang mit einem Notschlüssel unterbrechen und den Geldbetrag sofort an einen anderen Ort transferieren. Dieses Gerät kann eine große Hilfe für die autonome Verwahrung sein.
Das aktuelle Bitcoin-Skript verfügt nicht über diese Funktion, sodass die Aktivierung von Einschränkungen für Bitcoin-Skript einen Soft Fork erfordert.
Solange wir jedoch bereit sind, einige der Vorteile zu opfern, die die „Differenzierung der Vermögenswertdefinition und der Verwahrungsmechanismen“ mit sich bringt, können wir mit solchen Funktionen auf RGB-Vermögenswerten experimentieren. Wir können solche Funktionen auf der RGB-Vertragsebene implementieren – obwohl dies möglich ist Funktioniert nur nicht für RGB-Assets, die es verwenden (aber nicht für Bitcoin), wird aber auf jeden Fall einen interessanten Bereich eröffnen.
Bestehende Untersuchungen zu Beschränkungsklauseln zeigen, dass sie den Programmierraum UTXO-basierter Transaktionen erweitern und viele Funktionen bereitstellen können. Aber diese Studien basieren im Wesentlichen auf Bitcoin, und bei Protokollen wie Bitcoin werden wir konservativer sein. Auf RGB können wir die Kernfunktionen von Einschränkungen – die Fähigkeit, Transaktionen zu lesen, die sich auf der Skriptebene ausgeben – kühn verallgemeinern, um eine flexiblere Programmierbarkeit bereitzustellen: die Fähigkeit, auf Verträge quer zuzugreifen.
Querzugriff
Minimal restriktive Bedingungen bedeuten, dass, wenn ein UTXO ausgegeben wird, sein Skript die Ausgabe der ausgebenden Transaktion lesen kann. Eine vollständig verallgemeinerte Einschränkung bedeutet jedoch, dass sie alle Teile der Transaktion lesen kann, die sie ausgegeben hat. Dies bedeutet, dass es auch andere Eingaben der Transaktion lesen kann. Wenn wir andere Eingaben nicht darauf beschränken, aus demselben Vertrag zu stammen, bedeutet dies, dass es den Status anderer Verträge lesen kann.
In RGB ist jeder Vertrag standardmäßig ein unabhängiges Universum mit einem eigenen gerichteten azyklischen Graphen. Es ist jedoch weiterhin möglich, dass ein Benutzer gleichzeitig den Status von zwei verschiedenen Verträgen innehat. Solche Cross-Access-Funktionen könnten Anwendungsfälle haben, wenn RGB-Transaktionen die gleichzeitige Ausgabe von Vermögenswerten aus beiden Verträgen ermöglichen würden (obwohl dies die Überprüfung von Transaktionen möglicherweise komplexer machen könnte).
Tatsächlich gibt es bereits On-Chain-Vertragssysteme, die auf UTXO-ähnlichen Strukturen basieren (zum Beispiel: Nervos Network), die dies nutzen, um Cross-Access-Fähigkeiten von Verträgen zu erreichen 11. Dies ist ein sehr neues Feld, das in Bereiche vordringt, die von der bisherigen Bitcoin-Forschung kaum berührt wurden, und es könnte dort einige Überraschungen geben.
abschließend
In diesem Artikel werden die Leser feststellen, dass es ein Konzept gibt, das häufig erwähnt wird und sich durch alle Denk- und Fantasieprozesse zieht: „UTXO“. Das ist genau meine Absicht. Wenn Sie UTXO nicht verstehen, können Sie weder den Ausgangspunkt des Designs eines Protokolls wie RGB verstehen, noch können Sie die Vorteile des RGB-Protokolldesigns verstehen, noch können Sie sich vorstellen, wie Menschen es verwenden. Die Identität des RGB-Protokolls wird weitgehend durch seine einmalige, versiegelte UTXO-Form geprägt. Dementsprechend kann die im Bereich Bitcoin-Forschung gesammelte Forschung zu UTXO auch auf die Forschung zu RGB angewendet werden.
Dies erklärt auch, warum Menschen, die Bitcoin nicht verstehen, Schwierigkeiten haben werden, RGB zu verstehen. Menschen, die Bitcoin mögen, werden das Design von RGB erkennen.
Da der Artikel zu viele Kommentare enthält, sehen Sie sich bitte den Quelllink unten an.