RGB++-Protokoll und die Zukunft von Bitcoin: Ciphers Erkenntnisse von Bitcoin Singapore 2024

Am 9. März hielt Cipher, Gründer von CELL Studio und Autor des RGB++-Protokolls, während der von der Nervos Foundation und ABCDE gemeinsam organisierten Bitcoin Singapore 2024-Konferenz eine Grundsatzrede mit dem Titel „Überblick und Perspektiven des RGB++-Protokolls“.

Hier ist eine Zusammenfassung der wichtigsten Punkte aus Ciphers Präsentation:

Herausforderungen für das RGB-Protokoll

Das RGB-Protokoll existiert bereits seit vielen Jahren, dennoch hat es aus verschiedenen Gründen keine weite Verbreitung gefunden:

Herausforderungen bei interaktiven Operationen

Bei Transaktionen mit BTC , ETH usw. muss der Empfänger nur eine Adresse angeben und der Absender kann heute oder morgen Geld überweisen, was sehr praktisch ist. Im Gegensatz dazu muss der Empfänger bei jeder RGB-Transaktion zunächst eine Rechnung ausstellen. Anschließend muss der Absender eine RGB-Transaktion erstellen und einen Nachweis der Vermögenshistorie erstellen, um ihn an den Empfänger zu senden. Nach Erhalt dieses Nachweises muss der Empfänger eine clientseitige Validierung (CSV) durchführen. Nach erfolgreicher Validierung muss er diesen Nachweis für zukünftige Transaktionen speichern.

Daher hängen RGB-Transaktionen nicht nur davon ab, dass beide Parteien online sind, sondern auch davon, dass beide Parteien relevante historische Daten speichern. Dies stellt eine erhebliche Hürde für verbraucherorientierte Produkte dar.

Probleme mit der Datenverfügbarkeit (DA)

Bei RGB-Transaktionen ist es wichtig, den historischen Nachweis des Vermögenswerts beizufügen. Wenn dieser Nachweis verloren geht, ist das genauso kritisch wie der Verlust eines privaten Schlüssels. Die Frage, wer den Benutzern beim Speichern ihrer Vermögenswerte hilft, ist ein Problem der Datenverfügbarkeit. Im ursprünglichen RGB-Protokoll, das auf den Schutz der Privatsphäre abzielt, speichert niemand sonst Vermögenswerte für Benutzer, was bedeutet, dass die Benutzer die Verantwortung für ihre eigene Datenspeicherung übernehmen müssen.

Selbst bei richtiger Datenspeicherung stellen wir uns ein Szenario vor, in dem Alice RGB-Assets an Bob übertragen möchte. Wie sendet sie ihm den historischen Nachweis dieser Assets? Per E-Mail oder WhatsApp? Die Übertragung über einen zentralen Kanal ist eindeutig ungeeignet und erfordert die Verwendung eines speziellen P2P-Kanals. P2P-Kanäle werfen jedoch Vertraulichkeitsprobleme auf: Warum sollte jemand bei der Übertragung dieser sensiblen Daten behilflich sein? Dies führt zu einer Reihe komplexer Probleme.

Interoperabilitätsprobleme

Die historischen Nachweisdaten von RGB-Assets werden von den Benutzern selbst aufbewahrt und bei Transaktionen an den Empfänger weitergegeben, aber nicht öffentlich zugänglich gemacht. Dies führt dazu, dass die Daten über alle Personen im Netzwerk verstreut sind. Für jemanden, der eine Handelsplattform aufbaut, egal ob zentralisiert oder dezentralisiert, sind Daten aus mehreren Quellen erforderlich, um den globalen Status von RGB aufrechtzuerhalten. Es gibt einige RGB-Dienstanbieter, die diese Daten für Anwendungsentwickler zentralisieren und speichern, doch dieser Ansatz beeinträchtigt die Privatsphäre von RGB. Trotz dieser Lösung bleiben Herausforderungen bestehen, beispielsweise die Erleichterung der Datenübertragung zwischen verschiedenen Dienstanbietern, die die RGB-Daten verschiedener Benutzer speichern.

Probleme mit der Smart Contract/Script Execution Environment

Die Smart Contract- oder Skriptausführungsumgebungen in RGB sind mit erheblichen Herausforderungen verbunden. Es wird eine virtuelle Maschine (VM) namens AluVM verwendet, aber die Einzelheiten ihrer Programmiersprache müssen noch festgelegt werden. Darüber hinaus sind wichtige Entwicklungstools wie Compiler und Debugger noch nicht vollständig entwickelt. Es fehlt auch die Unterstützung für gemeinsame Zustände und dezentrale (besitzerlose) Verträge. Derzeit ist es offensichtlich, dass sich AluVM noch in einem sehr frühen Stadium befindet.

RGB ist daher mit zahlreichen komplexen Problemen konfrontiert, die jeweils viel Zeit und Mühe erfordern. Diese Herausforderungen tragen erheblich zu den Verzögerungen bei der effektiven Umsetzung von RGB bei.

Ein Überblick über das RGB++-Protokoll

RGB-Transaktionen sind durch einen Mapping-Prozess eng mit Bitcoin-Transaktionen verknüpft. Darüber hinaus erfordern RGB-Transaktionen eine Off-Chain-Infrastruktur, die Datenverfügbarkeit (DA), clientseitige Validierung, P2P-Netzwerke, virtuelle Maschinen, gemeinsame Zustände und dezentrale Verträge umfasst. Bei der Betrachtung einer solchen Infrastruktur kommt einem natürlich die Blockchain in den Sinn, da sie über Fähigkeiten in den Bereichen Datenmanagement, Validierung, Integration virtueller Maschinen, P2P-Netzwerke, Anreize und Smart Contracts verfügt. Das RGB++-Protokollkonzept basiert auf dieser grundlegenden Intuition und schlägt die Verwendung der UTXO-modellbasierten und Turing-vollständigen CKB-Blockchain als Ersatz für die von RGB benötigte Off-Chain-Infrastruktur vor.

RGB++ führt ein Konzept namens isomorphe Bindungstechnologie ein. Jede Bitcoin-Transaktion enthält eine Ausgabe. Im Fall einer RGB-Transaktion ist die Einbeziehung eines OP_RETURN-Segments in die Bitcoin-Ausgabe erforderlich. Dieses Segment enthält bestimmte Hash-Daten, die als Commitment bezeichnet werden. Wenn dieses Commitment mit dem Hash einer Transaktion auf einer anderen öffentlichen Blockchain übereinstimmt und die Eingaben und Ausgaben beider Transaktionen isomorph sind – was bedeutet, dass sie sich in der Struktur entsprechen – und vorausgesetzt, dass der UTXO (Unspent Transaction Output) dieser alternativen Blockchain über Turing-vollständige Rechen- und Zustandsspeicherfunktionen verfügt, wird die Transaktion auf der Bitcoin-Blockchain vollständig in die Transaktion auf dieser anderen Blockchain integriert oder an sie gebunden. Die CKB-Blockchain (Common Knowledge Base) erfüllt diese Voraussetzungen. Daher ist die Durchführung einer Transaktion auf Bitcoin effektiv gleichbedeutend mit der Durchführung einer entsprechenden Transaktion auf der CKB-Kette. Jede Änderung des Status der Bitcoin-Transaktion spiegelt eine Änderung des Status der Transaktion auf der CKB-Kette wider und hält sich an die auf CKB vorhandenen Vertragsbeschränkungen. Dies fasst die Essenz der isomorphen Bindungstechnologie zusammen. Dieses Konzept umfasst jedoch zahlreiche komplizierte technische Aspekte, darunter die Aufrechterhaltung der Transaktionskonsistenz und die Vermeidung von Doppelausgaben, auf die an dieser Stelle nicht näher eingegangen wird.

Die isomorphe Bindungstechnologie ermöglicht die Erweiterung der Zustandsfunktionen von Bitcoin. Betrachten wir beispielsweise das im folgenden Diagramm dargestellte btc_utxo#1. Dieses Bitcoin UTXO (Unspent Transaction Output) weist normalerweise nur zwei Zustände auf: ein Sperrskript und einen Betrag, wobei letzterer den Kontostand darstellt. In der entsprechenden blauen Zelle in der CKB-Blockchain (Common Knowledge Base) sind die Funktionen jedoch, wie im Diagramm dargestellt, umfassender. Im Gegensatz zur eingeschränkten Funktionalität des Bitcoin UTXO, die nur den Kontostand anzeigt, kann diese isomorphe Zelle in der CKB-Kette nicht nur Kontostanddaten, sondern auch verschiedene andere Datentypen speichern.

Zusätzlich zur Datenkomponente besitzt die Zelle ein Typskript. Dieses Skript dient einem bestimmten Zweck: Es definiert die Bedingungen, unter denen Assets empfangen werden, und legt Beschränkungen für die Assettypen fest.

Darüber hinaus enthält die Zelle ein Sperrskript, das in diesem Fall explizit mit btc_utxo#1 verknüpft ist. Diese Verknüpfung impliziert, dass die Zelle in der CKB-Blockchain nur ausgegeben werden kann, wenn btc_utxo#1 ausgegeben wird.

Auf der CKB-Plattform haben wir einen Bitcoin-Light-Knoten implementiert. Sobald eine Bitcoin-Transaktion initiiert wird, wird sie von einem Relay-Mechanismus erfasst, der diese Transaktion dann als Beweis auf die CKB-Blockchain überträgt. Bei diesem Prozess wird das Vorhandensein der Transaktion auf dem Bitcoin-Light-Knoten überprüft und sichergestellt, dass die Verpflichtung isomorph zur Transaktion ist.

Durch diesen Ansatz erweitern wir die Funktionalitäten von Bitcoin erheblich. Er ebnet den Weg für die Ausgabe einer breiten Palette von Vermögenswerten direkt auf Bitcoin und erleichtert die Erweiterung Turing-vollständiger Verträge.

Der Vorteil dieses Ansatzes besteht darin, dass wir erfolgreich Turing-vollständiges Scripting in den Bitcoin-Bereich eingeführt haben und dabei einen Sicherheitsstatus beibehalten haben, der fast identisch mit dem von Bitcoin Layer 1 (L1) ist. Dies liegt daran, dass alle historischen Aufzeichnungen, Transaktionen und Verpflichtungen über die UTXO-Kette auf Bitcoin L1 verknüpft sind.

Der Kompromiss besteht jedoch in einer leichten Einschränkung der Privatsphäre. Im Fall von RGB werden die Daten unter einzelnen Benutzern verteilt, was es für andere schwierig macht, auf die RGB-Daten eines bestimmten Benutzers zuzugreifen. Bei RGB++ werden alle Off-Chain-Daten auf der CKB-Blockchain veröffentlicht, die diese Zustände aufrechterhält, was zu einer Einschränkung der Privatsphäre führt. Im schlimmsten Fall ist die Privatsphäre jedoch nur auf das Niveau von Bitcoin-Transaktionen reduziert; IP-Adressen oder persönliche Identitätsinformationen werden nicht preisgegeben.

Tatsächlich könnten wir eine erweiterte Datenschutzebene auf CKB implementieren. Vor vier Jahren haben wir gemeinsam mit der Grin-Community ein Papier geschrieben, in dem wir die Verwendung der Mimblewimble-Technologie auf CKB zur Erstellung dieser erweiterten Datenschutzebene diskutieren. In Zukunft könnten wir diese Ebene in RGB++ integrieren und so nicht nur die Verschleierung von Transaktionsbeträgen, sondern auch die Trennung der Verknüpfungen im Transaktionsverlauf ermöglichen. Der daraus resultierende Datenschutz wäre stärker als der von RGB.

Zusammenfassend haben wir die Vision von RGB auf einfachere Weise umgesetzt und seine Möglichkeiten noch weiter erweitert.

Das Potenzial von Bitcoin L1-Assets freisetzen

Hier ist eine vereinfachte Einführung in das Sprungkonzept.

Die homomorphe Bindungstechnologie , die auf Bitcoin angewendet werden kann, ist gleichermaßen auf Litecoin, Liquid und andere UTXO-basierte Ketten anwendbar. Wie bereits erwähnt, ist der Zahlungsempfänger sowohl in RGB- als auch in RGB++-Systemen ein Bitcoin-UTXO, der allein die Ausgabeberechtigung besitzt. Wenn ich eine RGB++-Transaktion auf Bitcoin erstelle, habe ich die Möglichkeit, den Zahlungsempfänger nicht als Bitcoin-UTXO, sondern als Litecoin-UTXO zu bezeichnen. Folglich „springt“ dieser Vermögenswert zu Litecoin, da seine nachfolgende Ausgabe die Freigabe durch einen Litecoin-UTXO erfordert. In ähnlicher Weise kann dieser Vermögenswert zu Liquid springen oder sogar zurück zu Bitcoin springen.

Natürlich gibt es einen Sonderfall, den es zu berücksichtigen gilt. Wenn ein Vermögenswert zur CKB-Blockchain springt, befinden sich seine Dateninterpretationsebene, seine Vertragsebene und sein Eigentum alle auf CKB. Das bedeutet, dass er nicht mehr von einer anderen Kette abhängig ist und direkt Transaktionen durchführen und mit Smart Contracts auf CKB interagieren kann. Dies kann als Sprung zu L2 beschrieben werden. Auf L2 können Benutzer Tausende oder sogar Zehntausende von Transaktionen durchführen, bis jemand beschließt, den Vermögenswert zurück zu Bitcoin zu springen. Das nennen wir Transaktionsfaltung. Ob RGB oder RGB++, Transaktionen finden auf der Bitcoin-Blockchain statt, wo die Mining-Gebühren teuer sind. Sobald ein Vermögenswert jedoch zu CKB springt und eine Transaktionsfaltung durchläuft, werden die Gebühren deutlich niedriger und er kann jederzeit problemlos zur Bitcoin-Blockchain zurückkehren. Dieser gesamte Prozess basiert nicht auf Brücken mit mehreren Signaturen oder Vertrauen in Einzelpersonen; die einzige Voraussetzung ist, auf ein paar weitere Blockbestätigungen zu warten. Um von der Bitcoin-Blockchain zur CKB-Blockchain zu springen, muss man auf 6 Bitcoin-Blockbestätigungen warten. Um von der CKB-Blockchain zurück zu Bitcoin zu springen, sind 24 CKB-Blockbestätigungen erforderlich, um Blockrücksetzungen zu verhindern.

Aus diesem Grund sagen wir, dass wir ein neues Paradigma eingeführt haben. Natürlich ist das nicht unsere Erfindung, sondern eine Idee, die in den frühen Materialien von RGB existierte, wo RGB-Assets zwischen verschiedenen UTXO-Ketten springen konnten. Nachdem wir die Turing-Vollständigkeit mit dem Sprung zu CKB kombiniert hatten, stellten wir fest, dass die potenziellen Anwendungen umfangreich und völlig anders sind als die traditionelle Darstellung der Multisignaturbrücken von Ethereum.

Zukunftsaussichten

Als nächstes wollen wir uns mit der Skalierbarkeit befassen. Die Transaktionsrate von Bitcoin beträgt ungefähr 7 Transaktionen pro Sekunde (TPS), während CKB bei etwa 200 TPS seinen Höhepunkt erreicht. Wenn Sie die Kosten für Vertragsausführung und Skriptvalidierung berücksichtigen, könnte die TPS auf etwa 50 reduziert werden, was weniger als einer Verzehnfachung im Vergleich zu Bitcoin entspricht. Das ist bei weitem nicht genug, also welche Möglichkeiten gibt es zur Skalierung? Wir sehen zwei Hauptrichtungen:

• State Channels : State Channels stellen eine ultimative Skalierungslösung dar und bieten eine sehr hohe Leistungsobergrenze. Die Herausforderung liegt jedoch in der Komplexität der Implementierung von Mehrparteienverträgen, wodurch State Channels besser für Zahlungstransaktionen und Interaktionen zwischen Einzelpersonen und Servern geeignet sind. Jan soll das Team bei der Weiterentwicklung der Forschung zu State Channels anführen.

  
  

• AppChain Stack : Durch die Konstruktion einer Layer 2 (L2)-Lösung auf Basis des UTXO-Modells wird die L2-AppChain ihre Verankerung auf CKB sicherstellen und sich isomorph daran ausrichten. Dieser Ansatz ermöglicht es uns, innovative Skalierungsstrategien innerhalb dieses neuen Paradigmas zu entwickeln. Dies ist auch ein Schwerpunkt für CELL Studio im kommenden Jahr.

  
  

Abschließend möchte ich die Mission und den Fahrplan für RGB++ skizzieren. RGB++ zielt darauf ab, grundlegende Protokollmodule zu entwickeln, um die einfache Verwendung und Integration durch Entwickler und Benutzer von Drittanbietern zu ermöglichen. Der Fahrplan des RGB++-Protokolls sieht wie folgt aus. Das Protokoll ist bereits im Bitoin-Mainnet live und das RGB++ SDK wurde am 3. April veröffentlicht.

Von Cipher, Gründer von CELL Studio und Autor des RGB++-Protokolls.