Im Juli 2024 kündigte CKB offiziell die Einführung des RGB++-Layers an, der die Transformation des zuvor theoretischen RGB++-Protokolls in ein vollständig entwickeltes Produkt markiert, das bereit ist, konkretere und praktischere Anwendungsszenarien einzuführen. Mit der Vision, ein BTCFi-Ökosystem über BTC und andere UTXO-basierte öffentliche Chains wie CKB und Cardano aufzubauen, erregte RGB++ Layer schnell erhebliche Aufmerksamkeit. Zusammenfassend lässt sich sagen, dass die RGB++-Schicht auf dem RGB++-Protokoll basiert und homomorphe Bindung und Leap-Technologie verwendet, um ein nahtloses Cross-Chain-Interaktionserlebnis für native RGB++-Assets oder Inschriften/Runen über UTXO-basierte Blockchains wie BTC, CKB und Cardano hinweg zu bieten, ohne dass Cross-Chain-Bridges erforderlich sind. Durch die Nutzung der Turing-vollständigen Smart-Contract-Umgebung von CKB werden die notwendigen Bedingungen für Bitcoin geschaffen, um komplexe DeFi-Funktionen zu erreichen. Darüber hinaus ist es, unterstützt durch das umfassende Kontoabstraktions-Ökosystem von CKB, mit Bitcoin-Konten und -Wallets kompatibel, bietet eine hervorragende Benutzererfahrung für Bitcoin-Benutzer und ebnet den Weg für die weit verbreitete Einführung von BTCFi. Im folgenden Text wollen wir uns mit den Funktionsprinzipien und Funktionen des RGB++-Layers befassen und die Änderungen untersuchen, die er für das BTCFi-Ökosystem mit sich bringen wird. Da die theoretische Grundlage auf dem RGB++-Protokoll basiert, beginnen wir mit der Erörterung des Protokolls selbst.

RGB++ Protokoll: Die theoretische Grundlage der RGB++ Schicht

Das RGB++-Protokoll, das im Januar dieses Jahres veröffentlicht wurde, transformiert grundlegend die Validierungsmethode vom „Client-seitigen Validierung“ des RGB-Protokolls in die On-Chain-Verifizierung auf der CKB-Chain. Im Wesentlichen nutzt dieser Ansatz CKB als dezentralen Indexer und weist Aufgaben wie Datenspeicherung und Asset-Quellenverifizierung CKB zu. Damit positioniert er CKB als Validierungsschicht und DA-Schicht für das RGB-Protokoll und adressiert die UX-Probleme und DeFi-Unterstützungseinschränkungen, die im ursprünglichen RGB-Protokoll vorhanden sind.

In Anlehnung an das Konzept der "einmaligen Kapselung" führt RGB++ das Konzept der homomorphen Bindung ein, wobei die erweiterten UTXO (Cells) der CKB-Kette als Datenträger für Inschriften-/Runen-ähnliche Assets verwendet werden. Diese Zellen werden dann an UTXOs auf den Bitcoin-, Cardano- oder Liquid-Chains gebunden, so dass RGB++-Assets die Sicherheit dieser UTXO-basierten Blockchains erben und Doppelausgaben verhindern können. Dieser Ansatz der "Bindung an die Vererbung der Sicherheit" entspricht realen Szenarien, in denen ein Bankkonto mit einer Telefonnummer und einer ID verknüpft werden muss, um die Sicherheit zu erhöhen.

Angenommen, Alice möchte einige TEST-Token an Bob übertragen. Sie kann eine Aussage generieren, die die Zelle, die die TEST-Asset-Informationen speichert, an Bob's Bitcoin UTXO bindet. Wenn Bob beabsichtigt, die TEST-Token an jemand anderen zu übertragen, muss auch der gebundene Bitcoin UTXO übertragen werden. Dadurch entsteht eine Eins-zu-Eins-Bindungsbeziehung zwischen der Zelle, die RGB++ Asset-Daten trägt, und dem Bitcoin UTXO. Solange der Bitcoin UTXO nicht doppelt ausgegeben wird, wird auch das gebundene RGB++ Asset nicht doppelt ausgegeben.

Bei der Diskussion der RGB++-Schicht handelt es sich im Wesentlichen um eine technische Umsetzung des RGB++-Protokolls mit zwei Hauptmerkmalen: isomorphe Bindung und Leap-Brücke-freies Cross-Chain. Lassen Sie uns in die technischen Prinzipien hinter isomorpher Bindung und Leap eintauchen.

Isomorphes Binding und Leap: Die Vermögensausgabe von BTCFi und die brückenlose Cross-Chain-Schicht

Um das Konzept der isomorphen Bindung und von Leap wirklich zu verstehen, müssen wir zuerst das Zellmodell von CKB kurz erklären. Ein Zell ist im Wesentlichen ein erweiterter UTXO (Unspent Transaction Output) mit mehreren Feldern, einschließlich LockScript, TypeScript und Data. LockScript funktioniert ähnlich wie das Sperrskript von Bitcoin und dient der Berechtigungsüberprüfung. TypeScript ist dem Smart-Vertragscode ähnlich, während Data zur Speicherung von Vermögensdaten verwendet wird.

Um RGB++-Assets auf der CKB-Blockchain auszugeben, müssen Sie zunächst eine Zelle erstellen und die relevanten Felder mit dem Token-Symbol und dem Vertragscode ausfüllen. Sie könnten zum Beispiel das Token-Symbol auf "TEST" setzen. Diese Zellen können dann zerlegt und an viele Benutzer verteilt werden, ähnlich wie Bitcoin UTXOs (Unspent Transaction Outputs) aufgeteilt und übertragen werden.

Da die Struktur von Zellen der von Bitcoin UTXO ähnelt und CKB Bitcoin-Signaturalgorithmen unterstützen kann, können Benutzer Vermögenswerte auf der CKB-Kette mit Bitcoin-Wallets manipulieren. Wenn Sie eine Zelle besitzen, können Sie das Sperrskript so konfigurieren, dass es den Freischaltbedingungen von Bitcoin UTXOs entspricht. Dies ermöglicht es Ihnen, Bitcoin-Private Keys zu verwenden, um Zellen auf der CKB-Kette zu kontrollieren. Diese Fähigkeit erstreckt sich auf CKB-, BTC- und andere UTXO-basierte öffentliche Ketten. Zum Beispiel könnten Sie ein Cardano-Konto verwenden, um Asset-Daten auf der CKB-Kette zu ändern, die Kontrolle über RGB++-Assets von einem BTC-Konto auf ein Cardano-Konto zu übertragen, ohne die Notwendigkeit einer Cross-Chain-Brücke.

Dieser Prozess erfordert das Binden von RGB++-Vermögenswerten an UTXOs auf öffentlichen Ketten wie Bitcoin, Cardano und Liquid, ähnlich wie das Verknüpfen eines Bankkontos mit einer Telefonnummer und einer Identifikationsnummer in der realen Welt. RGB++-Vermögenswerte sind im Wesentlichen Daten, die eine Speichermedien wie eine Datenbank benötigen; in diesem Fall fungieren CKB-Zellen als Datenbank. Sie können eine Berechtigungsüberprüfung einrichten, um verschiedenen öffentlichen Kettenkonten (BTC, Cardano usw.) zu ermöglichen, RGB++-Vermögensdaten auf der CKB-Kette zu ändern. Dies ist das Kernprinzip des isomorphen Bindens.

Sprung und Brückenfreie Cross-Chain

Die „Leap“- und brückenfreien Cross-Chain-Funktionen der RGB++-Schicht basieren auf isomorpher Bindung. Sie ermöglichen das „Neubinden“ von UTXOs, die mit RGB++-Assets verbunden sind. Wenn beispielsweise Ihr Asset ursprünglich an ein Bitcoin-UTXO gebunden war, können Sie es an ein UTXO auf Cardano, Liquid, Fuel oder anderen Chains neu binden. Dies bedeutet, dass Sie die Asset-Kontrolle von einem BTC-Konto zu einem Cardano-Konto übertragen können, ohne die Notwendigkeit einer Cross-Chain-Brücke.

Aus Sicht eines Benutzers entspricht dies einem Cross-Chain-Asset-Transfer, wobei CKB sowohl als Indexer als auch als Datenbank fungiert. Im Gegensatz zu traditionellen Cross-Chain-Methoden ändert „Leap“ jedoch nur die Verwendungsrechte der Asset-Daten, während die Daten selbst auf der CKB-Chain gespeichert bleiben. Dieser Ansatz ist einfacher als das Lock-Mint-Modell und beseitigt die Abhängigkeit von der Zuordnung von Asset-Verträgen. Die obige Erklärung ist ein Produktüberblick über isomorphe Bindung und Leap. Lassen Sie uns ihre technische Implementierung anhand eines konkreten Beispiels verstehen.

Implementierung der isomorphen Bindung

Lassen Sie uns die technische Umsetzung des isomorphen Bindens verstehen. Angenommen, Alice hat 100 TEST-Token mit Daten, die in Zelle#0 gespeichert sind und an UTXO#0 in der Bitcoin-Blockchain gebunden sind. Nun möchte Alice 40 TEST-Token an Bob übertragen. Zuerst teilt sie Zelle#0 in zwei neue Zellen auf: Zelle#1 enthält 40 TEST-Token, die an Bob übertragen werden, und Zelle#2 enthält 60 TEST-Token, die unter der Kontrolle von Alice bleiben. In diesem Prozess wird auch der BTC-UTXO#0, der an Zelle#0 gebunden ist, in UTXO#1 und UTXO#2 aufgeteilt, die jeweils an Zelle#1 und Zelle#2 gebunden sind. Wenn Alice Zelle#1 an Bob überträgt, kann sie auch BTC-UTXO#1 mit einer einzigen Operation an Bob übertragen und so synchronisierte Transaktionen auf beiden CKB- und BTC-Blockchains durchführen.

Wir können hier die isomorphe Bindung in der Tiefe verstehen. Tatsächlich besteht die Kernbedeutung dieses Konzepts darin, dass CKP's Cell, Cardanos eUTXO und BTC UTXO alle UTXO-Modelle sind und CKB mit dem Bitcoin/Cardano-Signaturalgorithmus kompatibel ist. Die Dekomposition und Übertragung von UTXO, die auf den letzten beiden Chains stattfindet, kann auch 1:1 mit der Cell auf der CKB-Chain synchronisiert werden. Auf diese Weise können die Betriebsergebnisse, wenn wir das an das RGB++-Vermögen gebundene BTC UTXO betreiben, auf die Cell auf der CKB-Chain synchronisiert werden, ähnlich wie die Beziehung zwischen dem Objekt und dem Schatten. Darüber hinaus müssen wir auch beachten, dass das RGB++-Vermögen mit den beiden Objekten BTC UTXO und CKB Cell verbunden ist, die beide Bestandteile des RGB++-Vermögens sind. Beide sind unverzichtbar.

Wenn wir den obengenannten Fall von Alice, der Geld an Bob überweist, untersuchen, ist der allgemeine Prozess: 1. Alice erstellt lokal eine CKB-Transaktionsdaten (noch nicht auf die Kette hochgeladen). Diese Transaktion zeigt an, dass Zelle#0, die die Vermögensdaten aufzeichnet, zerstört wird, Zelle#1 generiert und an Bob gegeben wird, und Zelle#2 für sich behalten wird; 2. Alice generiert lokal eine Aussage, bindet Zelle#1 an BTC UTXO#1, bindet Zelle#2 an BTC UTXO#2 und sendet sowohl Zelle#1 als auch BTC UTXO#1 an Bob; 3. Anschließend generiert Alice lokal eine Verpflichtung (ähnlich wie ein Hash), und der entsprechende ursprüngliche Inhalt enthält die Aussage in Schritt 2 + die in Schritt 1 generierten CKB-Transaktionsdaten. Die Verpflichtungsdaten werden dann auf der Bitcoin-Kette aufgezeichnet; 4. Alice initiiert eine Transaktion auf der Bitcoin-Kette, zerstört UTXO#0, generiert UTXO#1 und sendet es an Bob, behält UTXO#2 für sich und schreibt Verpflichtung in der Form des OP_Return-Opcodes auf die Bitcoin-Kette; 5. Nach Abschluss von Schritt 4 wird die in Schritt 1 generierte CKB-Transaktion an die CKB-Kette gesendet.

Einige der komplizierteren Details wurden oben weggelassen. Tatsächlich, wenn Alice ihre RGB++-Vermögenswerte an Bob überträgt, muss sie zuerst eine komplexe Identitätsüberprüfung durchführen, um zu beweisen, dass sie tatsächlich die Besitzerin von Cell#0 ist. Die hier involvierten Dinge umfassen: 1. Nachweis, dass Cell#0 und BTC UTXO#0 tatsächlich gebunden sind; 2. Alice beweist, dass sie die tatsächliche Kontrolleurin von Cell#0 und BTC UTXO#0 ist. Achten Sie darauf, dass Zellen und Bitcoin UTXOs, die mit RGB++-Vermögensdaten geschrieben sind, gleichzeitig von Bitcoin-Konten umgeschrieben werden können. Während des gesamten Interaktionsprozesses können Ein-Klick-Vorgänge über Bitcoin-Konten abgeschlossen werden. Die oben genannten Szenarien sind nicht auf die isomorphe Bindung zwischen Bitcoin und CKB beschränkt, sondern können auf Cardano, Liquid, Litecoin und andere breite Kategorien ausgedehnt werden. Es gibt noch viel Raum für Vorstellungskraft.

Leap's Umsetzungsprinzipien und Unterstützungsszenarien

Wir haben bereits erwähnt, dassDie Leap-Funktion besteht eigentlich darin, den UTXO zu wechseln, der an das RGB++-Asset gebunden ist, z. B. von Bitcoin auf Cardano, und dann können Sie das Cardano-Konto verwenden, um das RGB++-Asset zu steuern. Danach können Sie auch Gelder auf der Cardano-Chain überweisen, um die UTXO-Assets, die RGB++ kontrollieren, aufzuteilen und an mehr Personen zu übertragen. Auf diese Weise können RGB++-Assets auf mehrere UTXO-Public-Chains übertragen und verteilt werden, aber das traditionelle Cross-Chain-Bridge-Lock-Mint-Modell kann umgangen werden. In diesem Prozess muss die öffentliche CKB-Kette wie ein Indexer fungieren, um Leap-Anforderungen zu beobachten und zu verarbeiten. Angenommen, Sie möchten RGB++-Assets, die an BTC gebunden sind, auf ein Cardano-Konto übertragen. Die Kernschritte sind nichts weiter als:1. Veröffentlichen Sie eine Verpflichtung auf der Bitcoin-Chain, die die Aufhebung der Bindung der an BTC UTXO gebundenen Zelle ankündigt;2. Veröffentlichen Sie eine Verpflichtung auf der Cardano-Chain, in der Sie ankündigen, dass die Zelle an Cardano UTXO gebunden wird;3. Ändern Sie das Sperrskript von Cell, um den mit den Entsperrbedingungen verbundenen Bitcoin-UTXO auf Cardano in eUTXO zu ändern.

Wir können feststellen, dass während dieses gesamten Prozesses die RGB++-Vermögensdaten immer noch auf der CKB-Kette gespeichert sind, aber das Bitcoin UTXO, das mit den Entsperrungsbedingungen verbunden ist, auf der Cardano-Kette in eUTXO geändert wird. Natürlich ist der spezifische Ausführungsprozess viel komplizierter als das oben Genannte, daher gehe ich hier nicht ins Detail. Darüber hinaus gibt es eine implizite Voraussetzung im Leap-Plan, nämlich dass die CKB-Public Chain als Drittanbieter-Witness, Index und DA-Einrichtung fungiert. Als Public Chain übertrifft ihre Glaubwürdigkeit bei weitem herkömmliche Cross-Chain-Bridge-Methoden wie MPC und Multisignatur. Tatsächlich können sehr interessante Szenarien auf der Grundlage der Leap-Funktion realisiert werden. Zum Beispiel können wir „Full-Chain-Transaktionen“ realisieren. Angenommen, wir bauen einen Indexer über Bitcoin, Cardano und CKB und errichten eine Handelsplattform, auf der Käufer und Verkäufer RGB++-Vermögenswerte handeln können. Käufer können ihre Bitcoins an Verkäufer übertragen und dann ihre Cardano-Konten verwenden, um RGB++-Vermögenswerte zu erhalten. Während dieses Prozesses werden die Daten des RGB++-Vermögenswerts immer noch in der Zelle aufgezeichnet, aber die Zelle wird an den Käufer übertragen und dann wird die Entsperrungsberechtigung von der Bitcoin UTXO des Verkäufers auf die Cardano eUTXO des Käufers geändert.

Wrapper

Obwohl die Leap-Funktion perfekt für RGB++-Assets geeignet ist, gibt es dennoch einige Engpässe: Bei Bitcoin und Cardano handelt es sich bei RGB++-Assets im Wesentlichen um Inschriften/Runen/gefärbte Münzen, die auf dem OP_RETURN-Opcode basieren. Diese öffentlichen Kettenknoten können die Existenz von RGB++-Assets nicht wahrnehmen, und CKB beteiligt sich tatsächlich als Indexer an der Koordination. Das heißt, für Bitcoin und Cardano unterstützt die RGB++-Schicht hauptsächlich den Sprung von Inschriften/Runen/gefärbten Münzen und nicht die Cross-Chain von nativen Vermögenswerten wie BTC, und ADA.In dieser Hinsicht hat RGB++ Layer offiziell den Wrapper eingeführt, der einfach als Brücke verstanden werden kann, die auf Betrugssicherheit und Überbesicherung basiert. Am Beispiel des rBTC-Wrappers wird BTC mit der RGB++-Schicht überbrückt, und eine Reihe von Smart Contracts, die auf der RGB++-Schicht ausgeführt werden, überwachen die Wächter der Bridge. Wenn sich ein Vormund böswillig verhält, werden seine Sicherheiten gekürzt. Wenn sich Erziehungsberechtigte absprechen, um gesperrte BTC zu stehlen, können rBTC-Inhaber eine vollständige Entschädigung erhalten.

Nach der Kombination von Leap und Wrapper können verschiedene Vermögenswerte im BTCFi-Ökosystem, wie RGB++-Native-Vermögenswerte, BRC20, ARC20, Runen usw., auf andere Ebenen oder öffentliche Ketten übertragen werden.

Das unten stehende Bild ist Teil des Antragsprozesses von LeapX. Sie können sehen, dass es die Interoperabilität von nahezu allen BTCFi-Mainstream-Assets in verschiedene Ökosysteme unterstützt. Und es gibt entsprechende Verarbeitungsverfahren für Assets mit unterschiedlichen Ausgabemethoden. Einige verwenden Wrapper und andere verwenden Leap.

CKB-VM: BTCFi's Smart Contract Engine

Oben haben wir hauptsächlich die isomorphe Bindung und die Leap-Konzepte von RGB++ Layer erklärt. Lassen Sie uns nun die anderen Punkte unten betrachten. Im traditionellen BTCFi können aufgrund des Mangels an Unterstützung für Smart Contracts nur einige relativ einfache Dapps implementiert werden. Einige Implementierungsmethoden bergen bestimmte Risiken der Zentralisierung, während andere umständlich und unflexibel sind. Um eine auf der Blockchain verfügbare Smart Contract-Schicht zu implementieren, bietet CKB CKB-VM für RGB++ Layer. Jede Programmiersprache, die eine RISC-V-Virtual Machine unterstützen kann, kann für die Vertragsentwicklung auf RGB++ Layer verwendet werden. Entwickler können ihre bevorzugten Tools und Sprachen verwenden, um effiziente und sichere Smart Contract-Entwicklung und Bereitstellung unter einem einheitlichen Smart Contract-Framework und Ausführungsumgebung zu erreichen. Im Folgenden finden Sie eine Überweisungsmethode für benutzerdefinierte Token UDT in CKB, die in der C-Sprache implementiert ist. Es ist zu erkennen, dass abgesehen von der Unterschied in der Sprache die grundlegende Logik die gleiche ist wie bei allgemeinen Tokens. Da RISC-V umfangreiche Sprach- und Compilerunterstützung bietet, sind die Anforderungen an Entwickler für den Einstieg in die Smart Contract-Entwicklung relativ niedrig. Wir können diese Logik leicht mit JavaScript, Rust, Go, Java und Ruby neu schreiben, anstatt eine bestimmte DSL-Sprache zum Schreiben von Verträgen lernen zu müssen. Natürlich ist Sprache nur ein Aspekt der Programmierung, und das Erlernen spezifischer Smart Contract-Frameworks ist unvermeidlich.

Native AA-Ökologie: nahtlose Verbindung von BTC und RGB++

Lassen Sie uns schließlich kurz die native AA und die Kontoabstraktion hinter der RGB++ Layer verstehen. Da die Essenz von BTCFi darin besteht, eine vielfältige Defi-Erfahrung für native Bitcoin-Vermögenswerte bereitzustellen, wird die Kompatibilität mit gängigen Bitcoin-Wallets ein wichtiger Faktor sein, den BTCFi-Peripherieeinrichtungen zu berücksichtigen. Die RGB++ Layer verwendet direkt die native AA-Lösung von CKB und ist sowohl auf der Entwicklerseite als auch auf der Benutzerseite mit wichtigen UTXO-Public Chains wie BTC und Cardano kompatibel. In der RGB++ Layer können Benutzer verschiedene Signaturalgorithmen zur Authentifizierung verwenden. Benutzer können beispielsweise Assets in der RGB++ Layer direkt mit Konten, Wallets oder Authentifizierungsmethoden wie BTC, Cardano oder sogar WebAuthn manipulieren. Nehmen wir als Beispiel das folgende Wallet-Middleware CCC, das Wallets und dApps die Bedienbarkeit verschiedener Public Chains auf CKB bieten kann. Das untenstehende Bild zeigt das Verbindungsfenster von CCC. Wir können sehen, dass es gängige Wallet-Eingänge wie Uniswap und Metamask unterstützt.

Ein weiteres Beispiel ist die Implementierung von WebAuthn, von der die CKB-ökologische Brieftasche JoyID ein typischer Vertreter ist. Mit JoyID können Benutzer sich direkt über biometrische Merkmale wie Fingerabdruck oder Gesichtserkennung authentifizieren, was nahtloses und hochsicheres Anmelden und Identitätsmanagement ermöglicht. Man kann sagen, dass die Grundlage für die isomorphe Bindung und Leap darin besteht, dass die RGB++-Ebene eine vollständige native AA-Lösung hat, die gut mit den Kontostandards anderer öffentlicher Ketten kompatibel ist. Diese Funktion erleichtert nicht nur die Unterstützung einiger wichtiger Szenarien, sondern auch die UX ebnet den Weg.

Zusammenfassen

Oben haben wir das Gesamtbild der RGB++-Schicht untersucht. Sie kann als wichtige Infrastruktur für verschiedene Memecoins wie Inschriften/Runen/Gefärbte Münzen genutzt werden, um vollständige Ketteninteraktionsszenarien zu realisieren. Die von RGB++ Layer auf RiscV basierende Smart-Contract-Ausführungsumgebung kann den Boden für die komplexen Geschäftslogiken bereitstellen, die von BTCFi benötigt werden. Aufgrund von Platzbeschränkungen ist dieser Artikel nur eine einfache Popularisierung der Kerntechnologie von RGB++ Layer und führt keine systematische Popularisierung vieler komplexer Details durch. In Zukunft werden wir weiterhin die Fortschritte von RGB++ Layer verfolgen und eine gründlichere und tiefere Analyse einer Reihe von technischen Lösungen im Zusammenhang mit diesem Projekt durchführen. Bleiben Sie dran!

Aussage:

1. Dieser Artikel wird von [ reproduziertgeek web3], das Urheberrecht gehört dem ursprünglichen Autor [Faust & Misty Moon], wenn Sie Einwände gegen den Nachdruck haben, wenden Sie sich bitte an den Gate LearnTeam, und das Team wird es so schnell wie möglich gemäß den entsprechenden Verfahren bearbeiten.

2. Haftungsausschluss: Die in diesem Artikel zum Ausdruck gebrachten Ansichten und Meinungen stellen nur die persönlichen Ansichten des Autors dar und stellen keine Anlageberatung dar.

3. Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt und werden nicht erwähntGate.io, der übersetzte Artikel darf nicht reproduziert, verteilt oder plagiiert werden.