Autor: Faust, Geek web3 & BTCEden.org Lianchuang

Mit der Popularität der Ausgabe von RGB++ und zugehörigen Vermögenswerten ist die Diskussion über die Prinzipien der RGB- und RGB++-Protokolle nach und nach für immer mehr Menschen zu einem Thema geworden, das sie beschäftigt. Aber jeder ist sich darüber im Klaren, dass man, um RGB++ zu verstehen, zunächst das RGB-Protokoll verstehen muss.

Das ursprüngliche RGB-Protokoll ist hinsichtlich der technischen Struktur etwas unklar und die Referenzmaterialien sind verstreut. Es gibt bisher nicht viele systematische und leicht verständliche Referenzmaterialien, obwohl Geek Web3 bereits zwei systematische Interpretationsartikel zu RGB und RGB++ veröffentlicht hat (Sie können den Verlauf unseres offiziellen Kontos einsehen), aber laut Feedback von Community-Mitgliedern ist der oben genannte Artikel zu lang und zu aufwändig.

Um es mehr Menschen zu ermöglichen, die RGB- und RGB++-Protokolle schneller zu verstehen, hat der Autor dieses Artikels während der Veranstaltung in Hongkong beeilt, eine kurze volkssprachliche Interpretation von RGB und RGB++ fertigzustellen. Sie kann in wenigen Minuten gelesen werden und hofft, dabei zu helfen mehr Community-Interessen. Leser können RGB und RGB++ besser und intuitiver verstehen.

RGB-Protokoll: Benutzer müssen die Datenüberprüfung selbst durchführen

Das RGB-Protokoll ist ein spezielles P2P-Asset-Protokoll und ein Computersystem außerhalb der Bitcoin-Kette. Es ähnelt in einigen Aspekten einem Zahlungskanal: Benutzer müssen den Client selbst ausführen und ihr eigenes Übertragungsverhalten überprüfen (Verify by yourself). Selbst wenn Sie nur ein Vermögensempfänger sind, müssen Sie zunächst sicherstellen, dass die Übertragungserklärung des Vermögenssenders keine Fehler enthält, bevor die Übertragungserklärung wirksam werden kann. Offensichtlich unterscheidet sich dies völlig von der herkömmlichen Form des Sendens und Empfangens von Vermögenswerten. Wir nennen es „interaktive Übertragung“.

Warum ist das so? Der Grund dafür ist, dass das RGB-Protokoll zur Gewährleistung der Privatsphäre nicht das „Konsensprotokoll“ in traditionellen Blockchains wie Bitcoin und Ethereum übernimmt (sobald die Daten das Konsensprotokoll durchlaufen, werden sie von fast allen Knoten im Netzwerk beobachtet). , und die Privatsphäre ist nicht gewährleistet. Wie kann sichergestellt werden, dass Asset-Änderungen ohne einen Konsensprozess mit einer großen Anzahl von Knoten sicher sind? Hier kommt die Idee namens „Client-Verifizierung“ (Selbst überprüfen) zum Einsatz. Sie müssen den Client selbst ausführen und die mit Ihnen verbundenen Asset-Änderungen persönlich überprüfen.

Angenommen, es gibt einen RGB-Benutzer namens Bob, der Alice kennt, und Alice möchte 100 TEST-Token an Bob übertragen. Nachdem Alice die Übertragungsinformationen von „Alice an Bob“ generiert hat, muss sie zunächst die Übertragungsinformationen und die zugehörigen Vermögensdaten an Bob senden und ihn persönlich überprüfen lassen, um sicherzustellen, dass sie korrekt sind, bevor sie in den nachfolgenden Prozess eintritt eine gültige RGB-Übertragung. Daher ermöglicht das RGB-Protokoll Benutzern die persönliche Überprüfung der Datengültigkeit und ersetzt den herkömmlichen Konsensalgorithmus.

Es besteht jedoch kein Konsens und die von verschiedenen RGB-Clients empfangenen und gespeicherten Daten sind nicht konsistent. Jeder speichert nur seine eigenen Asset-Daten und kennt nicht den Asset-Status anderer. Dies schützt gleichzeitig die Privatsphäre und bildet gleichzeitig eine „Dateninsel“. Wenn jemand behauptet, 1 Million TEST-Token zu haben und Ihnen 100.000 überweisen möchte, wie können Sie ihm dann glauben?

Wenn Ihnen im RGB-Netzwerk jemand Geld überweisen möchte, muss er zunächst einen Vermögensnachweis vorlegen, die historische Quelle des Vermögens von der Erstausgabe bis zu mehreren Besitzerwechseln zurückverfolgen und sicherstellen, dass der Token an Sie übertragen werden soll Dies ist in Ordnung, wenn Sie nicht identifizierte Banknoten erhalten. Sie bitten die Gegenpartei, den historischen Ursprung dieser Banknoten zu erläutern und zu erklären, ob sie vom angegebenen Emittenten hergestellt wurden, um gefälschte Währungen zu vermeiden.

Die oben genannten Prozesse finden außerhalb der Bitcoin-Kette statt und diese Prozesse allein ermöglichen keine direkte Verbindung von RGB mit dem Bitcoin-Netzwerk. In diesem Zusammenhang übernimmt das RGB-Protokoll eine Idee namens „Single-Use-Seal“, um RGB-Assets an UTXO in der Bitcoin-Kette zu binden. Solange das Bitcoin-UTXO nicht doppelt verbraucht wird, werden die gebundenen RGB-Assets nicht verdoppelt dass das Bitcoin-Netzwerk genutzt werden kann, um eine „Neuorganisation“ von RGB-Assets zu verhindern. Dies erfordert natürlich die Ausgabe einer Verpflichtung für die Bitcoin-Kette und die Verwendung des OP_Return-Opcodes.

Lassen Sie uns den Workflow des RGB-Protokolls klären:

1. RGB-Assets sind an Bitcoin UTXO gebunden und Bob besitzt bestimmte Bitcoin UTXOs. Alice möchte 100 Token an Bob übertragen, bevor Bob Alice vorab mitteilt, welche Bitcoin UTXO von Bob zum Binden dieser RGB-Assets verwendet werden sollen.

1. Alice erstellt RGB-Asset-Übertragungsdaten „Alice an Bob“ zusammen mit den historischen Quellen dieser Assets und gibt sie Bob zur Überprüfung.

2. Nachdem Bob vor Ort bestätigt hat, dass die Daten in Ordnung sind, sendet er eine Quittung an Alice und teilt ihr mit, dass die Transaktion durchgeführt werden kann.

3. Alice baut die RGB-Übertragungsdaten von „Alice an Bob“ in einen Merkle-Baum ein und veröffentlicht die Merkle-Wurzel als Commitment in der Bitcoin-Kette. Wir können das Commitment einfach als Hash der Übertragungsdaten verstehen.

4. Wenn jemand in Zukunft bestätigen möchte, dass die oben erwähnte „Alice to Bob“-Übertragung tatsächlich stattgefunden hat, muss er zwei Dinge tun: die vollständigen Übertragungsinformationen von „Alice to Bob“ unter der Bitcoin-Kette einholen und dann prüfen, ob diese vorhanden sind ist eine entsprechende Transaktion auf der Bitcoin-Kette Commitment (Hash der Übertragungsdaten), das war’s.

Bitcoin fungiert hier als historisches Protokoll des RGB-Netzwerks, aber nur der Hash/Merkle-Root der Transaktionsdaten wird im Protokoll aufgezeichnet, nicht die Transaktionsdaten selbst. Aufgrund der Verwendung von Client-Verifizierung und einmaliger Versiegelung verfügt das RGB-Protokoll über eine extrem hohe Sicherheit. Da das RGB-Netzwerk aus dynamischen Benutzer-Clients in einer P2P-Form ohne Konsens besteht, können Sie die Gegenpartei jederzeit ändern Transaktionsanfragen werden an eine begrenzte Anzahl von Knoten gesendet, sodass das RGB-Netzwerk äußerst zensurresistent ist. Diese Organisationsform ist zensurresistenter als große öffentliche Ketten wie Ethereum.

Natürlich liegt auch der Preis für extrem hohe Sicherheit, Zensurresistenz und Datenschutz auf der Hand: Benutzer müssen den Client ausführen, um die Daten selbst zu überprüfen, wenn die andere Partei einige Vermögenswerte sendet, die zehntausende Male den Besitzer gewechselt haben eine lange Geschichte, Sie müssen auch unter Druck alles überprüfen;

Darüber hinaus erfordert jede Transaktion mehrere Kommunikationen zwischen den beiden Parteien. Die empfangende Partei muss zunächst die Quelle der Vermögenswerte des Absenders überprüfen und dann eine Quittung senden, um den Übertragungsantrag des Absenders zu genehmigen. Dabei müssen mindestens drei Nachrichten zwischen den beiden Parteien ausgetauscht werden. Diese Art der „interaktiven Überweisung“ steht im krassen Widerspruch zu der „nicht-interaktiven Überweisung“, an die die meisten Menschen gewöhnt sind. Können Sie sich vorstellen, dass jemand, der Ihnen Geld überweisen möchte, Ihnen die Transaktionsdaten zur Überprüfung und zum Empfang senden muss? Ihre Quittung? Kann der Überweisungsvorgang erst nach Erhalt der Nachricht abgeschlossen werden?

Darüber hinaus haben wir erwähnt, dass es im RGB-Netzwerk keinen Konsens gibt und jeder Kunde eine Insel ist, was der Migration komplexer Smart-Contract-Szenarien auf traditionellen öffentlichen Ketten zum RGB-Netzwerk nicht förderlich ist, da die Defi-Protokolle auf Ethereum oder Solana alle auf A basieren global sichtbares und datentransparentes Ledger. Wie kann das RGB-Protokoll optimiert, die Benutzererfahrung verbessert und die oben genannten Probleme gelöst werden? Dies ist für das RGB-Protokoll zu einem unvermeidbaren Problem geworden.

RGB++: Client-Validierung wird zu optimistischem Hosting

Das Protokoll namens RGB++ stellt eine neue Idee dar. Es kombiniert das RGB-Protokoll mit öffentlichen Ketten, die UTXO unterstützen, wie CKB, Cardano und Fuel. Letzteres dient als Verifizierungsschicht und Datenspeicherschicht für RGB-Assets und konvertiert ursprünglich verarbeitete Daten durch Benutzer Die Verifizierungsarbeit wird an Drittplattformen/öffentliche Ketten wie CKB übergeben. Dies entspricht dem Ersetzen der Client-Verifizierung durch eine „dezentrale Drittplattform zur Verifizierung“, solange Sie öffentlichen Ketten wie CKB oder Cardano vertrauen , und Fuel, wenn Sie ihnen nicht vertrauen, können Sie auch wieder in den herkömmlichen RGB-Modus wechseln.

RGB++ und das ursprüngliche RGB-Protokoll sind theoretisch miteinander kompatibel.

Um die oben genannten Effekte zu erzielen, müssen Sie eine Idee namens „isomorphe Bindung“ verwenden. Öffentliche Ketten wie CKB und Cardano verfügen über ihr eigenes erweitertes UTXO, das programmierbarer ist als das UTXO auf der BTC-Kette. „Isomorphe Bindung“ besteht darin, das erweiterte UTXO auf den CKB-, Cardano- und Fuel-Ketten als „Container“ für RGB-Asset-Daten zu verwenden, die Parameter von RGB-Assets in diese Container zu schreiben und sie direkt auf der Blockchain anzuzeigen. Immer wenn eine RGB-Asset-Transaktion stattfindet, kann der entsprechende Asset-Container ähnliche Merkmale aufweisen, genau wie die Beziehung zwischen Entitäten und Schatten. Dies ist die Essenz der „isomorphen Bindung“.

Wenn Alice beispielsweise 100 RGB-Token und UTXO A in der Bitcoin-Kette besitzt und auch ein UTXO in der CKB-Kette hat, ist dieses UTXO mit „RGB Token Balance: 100“ gekennzeichnet und die Entsperrbedingungen beziehen sich auf UTXO A.

Wenn Alice Bob 30 Token geben möchte, kann sie zunächst eine Verpflichtung generieren. Die entsprechende Anweisung lautet: Übertragen Sie 30 der mit UTXO A verbundenen RGB-Token an Bob und übertragen Sie 70 an andere von ihr kontrollierte UTXOs.

Anschließend gibt Alice UTXO A in der Bitcoin-Kette aus, veröffentlicht die obige Anweisung und initiiert dann eine Transaktion in der CKB-Kette, um den UTXO-Container mit 100 RGB-Tokens zu verbrauchen und zwei neue Container zu generieren, einen mit 30 Token (für Bob), einen enthält 70 Token (kontrolliert von Alice). In diesem Prozess wird die Aufgabe, die Gültigkeit von Alices Vermögenswerten und die Gültigkeit der Transaktionsabrechnung zu überprüfen, von Netzwerkknoten wie CKB oder Cardano im Konsens ohne Bobs Eingreifen erledigt. Derzeit dienen CKB und Cardano als Verifizierungsschicht und DA-Schicht unter der Bitcoin-Kette.

Die RGB-Vermögensdaten aller Personen werden in der CKB- oder Cardano-Kette gespeichert, die über weltweit überprüfbare Merkmale verfügt und die Implementierung von Defi-Szenarien wie Liquiditätspools und Vermögensverpfändungsprotokollen begünstigt. Natürlich geht der obige Ansatz auch auf Kosten der Privatsphäre. Das Wesentliche besteht darin, einen Kompromiss zwischen Privatsphäre und Benutzerfreundlichkeit des Produkts einzugehen. Wenn Sie dies nicht tun, können Sie auf den herkömmlichen RGB-Modus zurückgreifen Wenn Sie sich darum kümmern, können Sie RGB++ bedenkenlos verwenden. Das Modell hängt ganz von Ihren persönlichen Bedürfnissen ab. (Tatsächlich kann ZK mit der leistungsstarken funktionalen Vollständigkeit öffentlicher Ketten wie CKB und Cardano zur Implementierung privater Transaktionen verwendet werden.)

Es sollte hier betont werden, dass RGB++ eine wichtige Vertrauensannahme einführt: Benutzer müssen optimistisch sein, dass die CKB/Cardano-Kette oder die Netzwerkplattform, die aus einer großen Anzahl von Knoten besteht, die auf Konsensprotokollen basieren, zuverlässig und fehlerfrei ist. Wenn Sie CKB nicht vertrauen, können Sie auch dem interaktiven Kommunikations- und Überprüfungsprozess im ursprünglichen RGB-Protokoll folgen und den Client selbst ausführen.

Unter dem RGB++-Protokoll können Benutzer Bitcoin-Konten direkt verwenden, um ihre RGB-Asset-Container auf UTXO-Ketten wie CKB/Cardano ohne Cross-Chain zu betreiben. Sie müssen lediglich die Eigenschaften von UTXO in den oben genannten öffentlichen Ketten verwenden, um die Entsperrung festzulegen Bedingungen des Zellcontainers einfach so festlegen, dass er einer bestimmten Bitcoin-Adresse/Bitcoin UTXO zugeordnet wird. Wenn beide an der RGB-Asset-Transaktion beteiligten Parteien auf die Sicherheit von CKB vertrauen, müssen sie nicht einmal häufig Verpflichtungen in der Bitcoin-Kette eingehen. Stattdessen können sie nach Abschluss vieler RGB-Übertragungen eine Verpflichtung an die Bitcoin-Kette senden Die Funktion „Transaktionsfaltung“ kann die Nutzungskosten senken.

Es ist jedoch zu beachten, dass der für die isomorphe Bindung verwendete „Container“ eine öffentliche Kette benötigt, die das UTXO-Modell unterstützt, oder eine Infrastruktur mit ähnlichen Eigenschaften bei der Zustandsspeicherung. Die EVM-Kette ist nicht geeignet und wird auf viele Fallstricke stoßen. (Dieses Thema kann separat geschrieben werden und beinhaltet viel Inhalt. Interessierte Leser können sich auf den vorherigen Artikel von Geek web3 „RGB++ and Isomorphic Binding: How CKB, Cardano and Fuel Empower the Bitcoin Ecosystem“ beziehen;

Zusammenfassend sollte eine öffentliche Ketten-/Funktionserweiterungsschicht, die zur Realisierung isomorpher Bindung geeignet ist, die folgenden Eigenschaften aufweisen:

1. Verwenden Sie das UTXO-Modell oder ein ähnliches Zustandsspeicherschema.

2. Verfügt über eine beträchtliche UTXO-Programmierbarkeit, die es Entwicklern ermöglicht, Entsperrskripte zu schreiben;

3. Es gibt einen UTXO-bezogenen Zustandsraum, der den Asset-Status speichern kann;

4. Es gibt Bitcoin-bezogene Brücken oder Light Nodes;