Autor: Faust & Wuyue, von GeekWeb3 & BTCEden

Die Ankündigung der Einführung der RGB++-Schicht in diesem Monat, Juli 2024, markiert den vollständigen Übergang des zuvor veröffentlichten RGB++-Protokolls von der Theorie zu einem technischen Produkt. Mit seiner großen Vision, ein BTCFi-Ökosystem auf BTC, CKB, Cardano und anderen öffentlichen Pan-UTXO-Ketten (unspent transaction output) aufzubauen, trägt die Einführung der RGB++-Schicht auch dazu bei, spezifischere und praktischere Szenarien für die Plattform einzuführen, wodurch sie zum Mittelpunkt der Aufmerksamkeit unzähliger Menschen wird.

Basierend auf dem RGB++-Protokoll verwendet die RGB++-Schicht isomorphe Bindung und Leap, um eine „brückenfreie“ kettenübergreifende Interaktionserfahrung für RGB++-native Assets oder Inschriften/Runen zwischen BTC, CKB, Cardano und anderen öffentlichen Ketten vom Typ UTXO bereitzustellen. Sie nutzt die Turing-vollständige Smart-Contract-Umgebung von CKB, um die notwendigen Voraussetzungen für die Ausgabe von Assets durch Bitcoin und die Implementierung komplexer DeFi-Funktionen zu schaffen. Da sie durch das umfassende Kontoabstraktions-Ökosystem von CKB unterstützt wird und mit Bitcoin-Konten und -Wallets kompatibel ist, ebnet sie auch den Weg für die großflächige Einführung von BTCFi.

Dieser Artikel soll dabei helfen, die allgemeinen Arbeitsprinzipien und Funktionsmerkmale der RGB++-Schicht zu verstehen. Außerdem werden die Änderungen hervorgehoben, die die Schicht aufgrund ihrer vier besonderen Merkmale für das BTCFi-Ökosystem mit sich bringen wird.

1. RGB++-Protokoll als theoretische Grundlage der RGB++-Schicht

Das RGB++-Protokoll wurde im Januar veröffentlicht, um die „clientseitige Verifizierung“ des RGB-Protokolls durch die CKB-On-Chain-Verifizierung zu ersetzen. Es verwendet CKB als dezentralen Indexer und delegiert Aufgaben wie Datenspeicherung und Asset-Quellenverifizierung an CKB, wobei letzteres als Verifizierungsschicht und Datenverfügbarkeitsschicht (DA) für das RGB-Protokoll dient. Dies soll dazu beitragen, Probleme mit nicht ausgegebenen Transaktionen (UX) und ungünstige Defekte in DeFi-Szenarien im RGB-Protokoll zu lösen.

Im Einklang mit dem Konzept der „einmaligen Kapselung“ verwendet die isomorphe Bindung von RGB++ Cell – ein erweitertes UTXO in der CKB-Kette – als Datenträger für Inschriften-/Runen-artige Vermögenswerte, um eine Bindungsbeziehung mit UTXOs in der Bitcoin-Kette herzustellen und die Sicherheit von Bitcoin zu erben.

Wenn Alice beispielsweise einige TEST-Token an Bob übertragen möchte, kann sie eine Deklaration generieren, die die Zelle, die TEST-Asset-Informationen speichert, an einen von Bobs Bitcoin-UTXOs bindet. Wenn Bob die TEST-Token an jemand anderen übertragen möchte, muss auch der gebundene Bitcoin-UTXO übertragen werden. Auf diese Weise besteht eine 1:1-Bindungsbeziehung zwischen der Zelle, die RGB++-Asset-Daten enthält, und dem Bitcoin-UTXO. Solange der Bitcoin-UTXO nicht doppelt ausgegeben wird, kann der gebundene RGB++-Asset nicht doppelt ausgegeben werden. Mit diesem Mechanismus haben die RGB++-Assets die Sicherheit von Bitcoin geerbt.

Die RGB++-Schicht ist ein Produkt der technischen Implementierung des RGB++-Protokolls. Ihre beiden Hauptfunktionen sind isomorphe Bindung und Leap-Bridge-freie Cross-Chain.

2. Isomorphe Bindung und Sprung - Ausgabe von Vermögenswerten und brückenfreie Cross-Chain-Schicht für BTCFi

Um die isomorphe Bindung und den Leap-Ansatz zu verstehen, ist es wichtig, das Cell-Modell von CKB zu erklären. Eine Cell ist ein erweiterter UTXO mit mehreren Feldern wie LockScript, TypeScript und Data. Das LockScript funktioniert ähnlich wie das Sperrskript von Bitcoin und wird zur Berechtigungsüberprüfung verwendet. TypeScript ähnelt dem Smart-Contract-Code, während Data zum Speichern von Asset-Daten verwendet wird.

Wenn Sie RGB++-Assets in der CKB-Kette ausgeben möchten, erstellen Sie zuerst eine Zelle und schreiben Sie das Token-Symbol und den Vertragscode in die entsprechenden Felder. Anschließend können Sie die Zelle aufteilen und an viele Personen verteilen, genau wie beim Aufteilen und Übertragen von Bitcoin-UTXOs.

Aufgrund der strukturellen Ähnlichkeit der Zelle mit Bitcoin UTXOs und der Ähnlichkeit von CKB mit dem Signaturalgorithmus von Bitcoin können Benutzer mithilfe von Bitcoin-Wallets Vermögenswerte in der CKB-Kette manipulieren. Als Eigentümer einer Zelle können Sie ihr Sperrskript so einstellen, dass ihr Entsperrzustand mit dem eines Bitcoin UTXO übereinstimmt. So können Sie Zellen in der CKB-Kette direkt mithilfe des privaten Schlüssels eines Bitcoin-Kontos manipulieren.

Die oben hervorgehobenen Funktionen können auch zwischen CKB, BTC und anderen öffentlichen UTXO-Ketten implementiert werden. Sie können beispielsweise ein Cardano-Konto verwenden, um Asset-Daten in der CKB-Kette neu zu schreiben, und die Kontrollrechte von RGB++-Assets werden ohne Cross-Chain-Brücke von einem BTC-Konto auf ein Cardano-Konto übertragen. Denken Sie daran, dass die Bindung von RGB++-Assets an UTXOs in öffentlichen Ketten wie Bitcoin, Cardano, Liquid usw. – ähnlich wie Bankkonten in realen Fällen an die Telefonnummern und IDs der Kunden gebunden sind – dazu dient, Doppelausgaben zu verhindern.

Es sollte auch beachtet werden, dass RGB++-Assets eine Menge Daten sind, die Medienspeicher wie in einer Datenbank benötigen. Zellen in der CKB-Kette können als ihre Datenbank dienen. Dann könnte die Berechtigungsüberprüfung so eingestellt werden, dass Konten aus verschiedenen öffentlichen Ketten wie BTC und Cardano Zugriff haben, um RGB++-Asset-Daten in der CKB-Kette neu zu schreiben.

Die von RGB++ Layer vorgeschlagenen „Leap“- und brückenfreien Cross-Chains basieren auf der isomorphen Bindungstechnologie. Sie dienen dem Zweck der „Neubindung“ der an RGB++-Assets gebundenen UTXOs. Wenn Ihre Assets beispielsweise zuvor an Bitcoin-UTXOs gebunden waren, können sie jetzt an UTXOs auf Cardano, Liquid, Fuel und anderen Chains neu gebunden werden. Infolgedessen werden Asset-Kontrollberechtigungen von BTC-Konten auf Cardano oder andere Konten übertragen.

Aus Sicht des Benutzers entspricht dies dem Asset-Cross-Chaining, wobei CKB eine ähnliche Rolle wie ein Indexer und eine Datenbank spielt. Im Gegensatz zu herkömmlichen Cross-Chain-Methoden ändert „Leap“ jedoch nur die Berechtigung zum Ändern von Asset-Daten, während die Daten selbst weiterhin in der CKB-Kette gespeichert sind. Diese Methode ist prägnanter als das Lock-Mint-Modell und eliminiert die Abhängigkeit von zugeordneten Asset-Verträgen.

Technischer Implementierungsansatz der isomorphen Bindung

Angenommen, Alice hat 100 TEST-Token, deren Daten in Zelle Nr. 0 gespeichert sind und eine Bindungsbeziehung mit UTXO Nr. 0 in der Bitcoin-Kette haben. Um 40 TEST-Token an Bob zu übertragen, muss sie Zelle Nr. 0 in zwei neue Zellen aufteilen, wobei Zelle Nr. 1 40 TEST-Token enthält, die an Bob übertragen werden sollen, und Zelle Nr. 2 60 TEST-Token enthält, die noch von Alice kontrolliert werden.

In diesem Prozess muss der an Zelle Nr. 0 gebundene BTC UTXO#0 in UTXO#1 und UTXO#2 aufgeteilt und dann jeweils an Zelle Nr. 1 und Zelle Nr. 2 gebunden werden. Wenn Alice also Zelle Nr. 1 an Bob überträgt, kann sie mit einem Klick auch BTC UTXO#1 an Bob übertragen, um synchrone Transaktionen auf CKB- und BTC-Ketten zu erreichen.

Die zentrale Bedeutung der isomorphen Bindung liegt in ihrer Anpassungsfähigkeit. Dies ist besonders wichtig, da CKBs Cell, Cardanos eUTXO und Bitcoins UTXO allesamt UTXO-Modelle sind und CKB mit Bitcoin/Cardano-Signaturalgorithmen kompatibel ist. Die Betriebsmethoden von UTXOs sowohl in der Bitcoin- als auch in der Cardano-Kette funktionieren auch für Cells in der CKB-Kette. Auf diese Weise können Bitcoin/Cardano-Konten direkt verwendet werden, um sowohl RGB++-Assets in der CKB-Kette als auch ihre gebundenen Bitcoin/Cardano-UTXOs gleichzeitig zu steuern, wodurch 1:1-synchrone Transaktionen erreicht werden.

Ausgehend vom oben beschriebenen Szenario, in dem Alice an Bob übergibt, sieht der allgemeine Arbeitsablauf wie folgt aus:

1. Alice erstellt lokal (noch nicht in der Kette) CKB-Transaktionsdaten und gibt an, dass Zelle Nr. 0 vernichtet wird, Zelle Nr. 1 zum Senden an Bob generiert wird und Zelle Nr. 2 für sich selbst behalten wird.

   
   

2. Alice generiert lokal eine Deklaration, bindet Zelle Nr. 1 an UTXO Nr. 1 und Zelle Nr. 2 an UTXO Nr. 2 und sendet sowohl Zelle Nr. 1 als auch UTXO Nr. 1 an Bob.

   
   

3. Anschließend generiert Alice lokal ein Commitment (ähnlich einem Hash), das dem ursprünglichen Inhalt entspricht, einschließlich der Deklaration aus Schritt 2 + den in Schritt 1 generierten CKB-Transaktionsdaten;

   
   

4. Alice initiiert eine Transaktion in der Bitcoin-Kette, zerstört UTXO#0, generiert UTXO#1 zum Senden an Bob, behält UTXO#2 für sich und schreibt das Commitment in Form eines OP_Return-Opcodes in die Bitcoin-Kette;

   
   

5. Nachdem Schritt 4 abgeschlossen ist, wird die in Schritt 1 generierte CKB-Transaktion an die CKB-Kette gesendet.

Beachten Sie, dass die Zelle und das entsprechende Bitcoin UTXO isomorph gebunden sind und direkt von Bitcoin-Konten gesteuert werden können. Das heißt, während des Interaktionsprozesses können Benutzer Ein-Klick-Operationen über Bitcoin-Konten in der RGB++-Brieftasche durchführen. Daher helfen an Bitcoin UTXOs gebundene RGB++-Assets, das Problem der Doppelausgabe zu lösen, da Assets auf der RGB++-Ebene die Sicherheit von Bitcoin erben.

Das obige Szenario ist nicht auf die isomorphe Bindung zwischen Bitcoin und CKB beschränkt, sondern gilt auch für ein breites Spektrum von Ketten, darunter Cardano, Liquid, Litecoin usw.

Implementierungsprinzip und unterstützte Szenarien von Leap

Die Leap-Funktion dient im Wesentlichen dazu, die an RGB++-Assets gebundene UTXO umzuschalten, z. B. die Bindung von Bitcoin auf Cardano zu ändern. Danach können Sie RGB++-Assets über Cardano-Konten steuern. In einem solchen Fall könnte anschließend immer noch eine Übertragung auf der Cardano-Kette erfolgen, wobei die UTXO-steuernden RGB++-Assets aufgeteilt und an mehrere Personen übertragen werden. Während RGB++-Assets auf mehrere öffentliche UTXO-Ketten übertragen und verteilt werden können, können sie das traditionelle Cross-Chain-Bridge-Lock-Mint-Modell umgehen.

In diesem Prozess spielt die öffentliche CKB-Kette eine ähnliche Rolle wie ein Indexer, der Leap-Anfragen überwacht und verarbeitet. Angenommen, Sie möchten an BTC gebundene RGB++-Assets auf ein Cardano-Konto übertragen. Die wichtigsten Schritte sind:

1. Veröffentlichen Sie eine Verpflichtung in der Bitcoin-Kette, in der Sie die Aufhebung der an den BTC UTXO gebundenen Zelle erklären.

   
   

2. Veröffentlichen Sie eine Verpflichtung in der Cardano-Kette, in der Sie die Bindung der Zelle an den Cardano UTXO erklären.

   
   

3. Ändern Sie das Sperrskript der Zelle und ändern Sie die Entsperrbedingung von einem privaten Schlüssel eines Bitcoin-Kontos in einen privaten Schlüssel eines Cardano-Kontos.

Beachten Sie, dass die RGB++-Asset-Daten während dieses Vorgangs weiterhin in der CKB-Kette gespeichert sind. Die Entsperrbedingung wird von einem privaten Bitcoin-Schlüssel in einen privaten Cardano-Schlüssel geändert. Natürlich ist der spezifische Ausführungsprozess viel komplexer als oben beschrieben, aber wir werden hier nicht näher darauf eingehen.

Beim Sprung zu nicht-CKB-öffentlichen Ketten ist die implizite Prämisse, dass die CKB-öffentliche Kette als Zeuge, Indexer und DA-Einrichtung Dritter fungiert. Dies liegt daran, dass ihre Glaubwürdigkeit als öffentliche Kette traditionelle Cross-Chain-Bridge-Methoden wie Multi-Party Computation (MPC) und Multi-Signatur bei weitem übertrifft.

Ein weiteres interessantes Szenario, das auf der Grundlage der Leap-Funktion implementiert werden kann, sind „Full-Chain-Transaktionen“. Ein Beispiel für dieses Szenario ist, wenn ein Indexer für Bitcoin, Cardano und CKB eingerichtet wird, um eine Handelsplattform aufzubauen, die es Käufern und Verkäufern ermöglicht, mit RGB++-Vermögenswerten zu handeln. In einem solchen Fall können Käufer ihre Bitcoins an Verkäufer übertragen und RGB++-Vermögenswerte mit ihren Cardano-Konten erhalten.

Während des gesamten Vorgangs werden die Daten der RGB++-Assets weiterhin in Zellen aufgezeichnet, die an den Käufer übertragen werden, und ihre Entsperrberechtigungen werden vom privaten Bitcoin-Schlüssel des Verkäufers in den privaten Cardano-Schlüssel des Käufers geändert.

Verpackung

Obwohl die Leap-Funktion perfekt für RGB++-Assets ist, gibt es immer noch einige Engpässe:

Für Bitcoin und Cardano sind RGB++-Assets im Wesentlichen Inschriften/Runen/farbige Münzen, die auf dem OP_RETURN-Opcode basieren. Die Knoten dieser öffentlichen Ketten können die Existenz von RGB++-Assets nicht wahrnehmen, da CKB als Indexer an der Koordination teilnimmt. Mit anderen Worten: Für Bitcoin und Cardano unterstützt die RGB++-Schicht hauptsächlich den Sprung von Inschriften/Runen/farbigen Münzen und nicht die kettenübergreifenden nativen Assets wie BTC und ADA.

Als Gegenmaßnahme führte die RGB++-Schicht Wrapper ein, eine Brücke, die auf Betrugsnachweisen und Überbesicherung basiert. Am Beispiel des rBTC-Wrappers wird eine Brücke zwischen BTC und der RGB++-Schicht hergestellt. Eine Reihe von Smart Contracts, die auf der RGB++-Schicht laufen, überwacht die Wächter der Brücke. Wenn die Wächter böswillig handeln, wird ihre Sicherheit gekürzt. Wenn sie sich verschwören, um gesperrte BTCs zu stehlen, werden die rBTC-Inhaber zur vollständigen Entschädigung verpflichtet.

Durch die Kombination aus Leap und Wrapper können verschiedene Assets im BTCFi-Ökosystem, z. B. native RGB++-Assets, BRC20, ARC20, Runen usw., mit anderen Ebenen oder öffentlichen Ketten verbunden werden.

Das folgende Diagramm zeigt einen Teil des Nutzungsprozesses von LeapX. Es unterstützt die Interoperabilität fast aller gängigen BTCFi-Assets mit verschiedenen Ökosystemen. Es gibt entsprechende Verarbeitungsabläufe für Assets, die auf unterschiedliche Weise ausgegeben werden, wobei einige entweder Wrapper oder Leap verwenden.

3. CKB-VM: Die Smart Contract Engine für BTCFi

Aufgrund der fehlenden Unterstützung für Smart Contracts im traditionellen BTCFi können im sich entwickelnden Bereich nur relativ einfache dezentrale Anwendungen (dApps) implementiert werden. Einige Implementierungsmethoden können gewisse Zentralisierungsrisiken bergen, während andere eher umständlich oder unflexibel sind.

Um eine Blockchain-verfügbare Smart-Contract-Schicht zu haben, führte CKB die CKB-VM über die RGB++-Schicht ein. Ziel ist es, jede Programmiersprache, die die virtuelle RISC-V-Maschine unterstützt, für die Vertragsentwicklung auf der RGB++-Schicht zu verwenden. Entwickler können ihre bevorzugten Tools und Sprachen verwenden, um effiziente und sichere Smart Contracts in einem einheitlichen Smart-Contract-Framework und einer einheitlichen Ausführungsumgebung zu entwickeln und bereitzustellen.

Im Allgemeinen sind die Einstiegsvoraussetzungen für die Entwicklung von Smart Contracts mit RISC-V relativ gering, da es eine umfassende Sprach- und Compilerunterstützung bietet. Natürlich ist die Sprache nur ein Aspekt der Programmierung, und das Erlernen spezifischer Smart-Contract-Frameworks ist unumgänglich. Mit der RGB++-Schicht kann die Logik jedoch problemlos in JavaScript, Rust, Go, Java und Ruby neu geschrieben werden, anstatt eine spezifische DSL-Sprache zum Schreiben von Verträgen zu erlernen.

Das folgende Diagramm zeigt eine Methode zum Übertragen benutzerdefinierter Token (UDT) mit CKB in der Sprache C. Abgesehen von den unterschiedlichen Sprachen ist die grundlegende Logik für allgemeine Token dieselbe.

4. Natives AA-Ökosystem: Nahtlose Verbindung von BTC und RGB++

Da BTCFi im Wesentlichen vielfältige DeFi-Erlebnisse für native Bitcoin-Assets bereitstellen soll, ist das Verständnis des Kontoabstraktions-Ökosystems hinter RGB++ Layer zusammen mit seinen gängigen Bitcoin-Wallets ein wichtiger Faktor, den die BTCFi-Peripherieeinrichtungen berücksichtigen müssen.

RGB++ Layer verwendet direkt die native AA-Lösung von CKB, die sowohl auf Entwickler- als auch auf Benutzerseite mit den wichtigsten öffentlichen UTXO-Ketten wie BTC und Cardano kompatibel ist. Mit dem RGB++ Layer können verschiedene Signaturalgorithmen zur Authentifizierung verwendet werden. Das heißt, Benutzer können Assets auf dem RGB++ Layer direkt mit BTC-, Cardano- oder sogar WebAuthn-Konten, Wallets oder Authentifizierungsmethoden manipulieren.

Ein Beispiel ist die Wallet-Middleware CCC, die CKB die Funktionsfähigkeit verschiedener öffentlicher Ketten für Wallets und dApps bereitstellen kann. Das folgende Bild zeigt das Verbindungsfenster von CCC und wie es gängige Wallet-Einträge wie Unisat und Metamask unterstützt.

Ein weiteres Beispiel ist die Implementierung von WebAuthn mit JoyID, einer Wallet des CKB-Ökosystems, die ein typischer Vertreter ist. JoyID-Benutzer können ihre Konten direkt über biometrische Methoden (wie Fingerabdruck oder Gesichtserkennung) authentifizieren, um eine nahtlose und hochsichere Anmeldung und Identitätsverwaltung zu erreichen.

Man kann sagen, dass die RGB++-Schicht eine vollständige native AA-Lösung hat, die auch die Kontostandards anderer öffentlicher Ketten erfüllen kann. Diese Funktion erleichtert nicht nur die Unterstützung einiger wichtiger Szenarien, sondern beseitigt auch Hindernisse für UXs.

Zusammenfassung

Dieser Artikel stellte die Kerntechnologien der RGB++-Schicht vor, ohne auf einige komplexe Details einzugehen.

Es zeigt, dass die RGB++-Schicht eine wichtige Infrastruktur für die Realisierung von Szenarien zur Interaktion in der gesamten Kette sein kann, einschließlich verschiedener Meme-Münzen und Inschriften/Runen/farbiger Münzen. Die RISC-V-basierte Smart-Contract-Ausführungsumgebung der Schicht kann auch dazu beitragen, den Boden für die komplexe Geschäftslogik zu schaffen, die BTCFi zum Wachsen benötigt.

Mit dem Fortschreiten der RGB++-Ebene wird eine ausführlichere Analyse der Reihe technischer Lösungen im Zusammenhang mit dem Projekt bereitgestellt. Bitte bleiben Sie dran!