Eine kurze Analyse von RGB: Ein skalierbares, vertrauliches Smart-Contract-Protokoll auf Bitcoin-Basis
Hintergrund
Die Leistung von Bitcoin wird seit der Einführung der Kryptowährung im Jahr 2009 genau beobachtet. Da es nur sieben Transaktionen pro Sekunde verarbeiten kann, ermöglicht das Netzwerk keine skalierbaren Smart Contracts. Das SegWit-Upgrade erhöhte Bitcoins Blockgrößenlimit auf 4MB (1MB für Transaktionsdaten und 3MB für Witness-Daten); dennoch besteht die Einschränkung weiterhin. Währenddessen ist die Skalierbarkeitsherausforderung mit wachsendem Einfluss von Bitcoin akuter geworden. Skalierbarkeit bleibt eine grundlegende Herausforderung für das Bitcoin-Ökosystem. Heute erforschen Praktiker Lösungen mit verschiedenen Ansätzen, die hauptsächlich Folgendes umfassen:
- Sidechains einschließlich Liquid, Stacks, Rootstock, etc.;
- State Channels wie das Lightning Network, die bestimmte hochfrequente Transaktionen off-chain verarbeiten;
- Nicht-upgradierbare Skalierungslösungen wie RGB und Bitcoin Script, die den Bitcoin-Code nicht modifizieren;
- Upgrade-basierte Skalierungslösungen einschließlich Drivechain (BIP300/301), die starke Unterstützung der Miner erfordern und Skalierbarkeit durch Hard Forks erreichen.
Von den verschiedenen Ansätzen gewinnen einige frühe Skalierungslösungen erneut an Aufmerksamkeit. Insbesondere Nostr, ein Protokoll, das Ende 2022 viral ging, trug zur weit verbreiteten Einführung des Lightning Networks bei. Gleichzeitig boomten Ordinals Anfang 2023. Als Smart-Contract-Lösung basierend auf Bitcoin und dem Lightning Network, die Turing-Vollständigkeit, Skalierbarkeit und starken Datenschutz bietet, veröffentlichte RGB diesen April eine neue Version (v0.10).
RGBs Entwicklung
Die Entstehung von RGB lässt sich bis ins Jahr 2016 zurückverfolgen, als Peter Todd das Konzept des Single-Use Seal und der Client-Side-Validierung einführte. Auf diesen kritischen Konzepten aufbauend wurde RGB 2018 vorgeschlagen.
Im Jahr 2019 leitete Orlovsky, ein RGB-Kernentwickler, die Entwicklung von RGB und schuf viele Komponenten, die letztendlich das RGB-Protokoll ausmachen. Zusätzlich half die Gründung der LNP/BP Association in der Schweiz, die relevanten Standards bereitzustellen.
Nach umfangreichen Entwicklungsbemühungen präsentierte RGB im April 2023 seine Version 0.10.
Über RGBs Design
So erreicht RGB Skalierbarkeit und Vertraulichkeit:
Client-seitige Validierung
Die meisten existierenden öffentlichen Blockchains operieren unter einem globalen Konsensmodell, bei dem alle Knoten alle Transaktionen validieren, Transaktionsinformationen miteinander teilen und einen einheitlichen globalen Zustand aufrechterhalten.
Dieses Modell bringt jedoch mehrere Herausforderungen mit sich, darunter:
- Skalierungsbeschränkungen, die die Validierung aller Vertragsinteraktionen kostspielig machen;
- Hohe Kosten, die zu zentralisiertem Knotenbetrieb führen;
- Mangel an Privatsphäre aufgrund offener Transaktionsinformationen.
Die Client-seitige Validierung (CSV) schlägt einen alternativen Ansatz vor: Sie erfordert nur, dass die Konsensschicht kryptografische Zusicherungen erfüllt, die mit Ledger-Ereignissen verbunden sind, während die eigentlichen Ereignisinformationen (das Ledger) außerhalb der Blockchain gespeichert werden. Dieser Ansatz, der auf die Arbeit von Peter Todd zurückgeht, wird als "Client-seitige Validierung" bezeichnet. CSV verlagert Transaktionsdaten off-chain, wo detaillierte Informationen gespeichert und verifiziert werden, und nur minimale Informationen werden auf der Blockchain eingereicht. Darüber hinaus werden Transaktionsdaten off-chain nur zwischen Sender und Empfänger übertragen. Bei einer realen Transaktion ist beispielsweise eine Validierung nur erforderlich, wenn die Wallet und die Parteien Zugriff auf Vertragsdaten anfordern.
Hauptmerkmale von CSV:
- Detaillierte Transaktionsinformationen werden off-chain gespeichert und nur auf dem Client validiert;
- Nur Zusicherungen zu den Transaktionsdaten werden auf der Blockchain gespeichert;
- Die Validierung gilt nur für Transaktionen, von denen Benutzer Kenntnis haben müssen.
In RGB unterscheidet sich der Validierungsmechanismus für Asset-Transfers erheblich von dem von Bitcoin. Im Bitcoin-Netzwerk laden Knoten ständig Blöcke und Mempool-Transaktionen herunter und validieren diese, was ihnen ermöglicht, den aktuellsten Zustand des UTXO-Sets zu erfassen. Beim Auftreten einer neuen Transaktion überprüfen Bitcoin-Validatoren die Gültigkeit ihrer Historie, indem sie verifizieren, ob alle Inputs im aktuellsten UTXO-Set existieren.
RGB hingegen verlässt sich nicht auf einen globalen Netzwerk-Broadcast aller Transaktionen, um ein Äquivalent zum Bitcoin-UTXO-Set zu erstellen. Das bedeutet, dass ein RGB-Client beim Empfang einer eingehenden Zahlung nicht nur überprüfen muss, ob der letzte Zustandsübergang gültig ist, sondern auch die gleiche Validierung für alle vorherigen Zustandsübergänge bis zum Ursprungszustand im Ausgabevertrag durchführen muss. Diese Bottom-up-Validierung der Transaktionshistorie in RGB schützt auch vor Double-Spending-Attacken.
RGB verbessert die Skalierbarkeit, indem nur relevante Transaktionen validiert werden. Dieser Ansatz könnte jedoch zu Problemen im Zusammenhang mit schlechter Datenverfügbarkeit führen, was möglicherweise einen Datenaustausch zur Optimierung der Zahlungsvalidierung erfordert.
Bitcoin-basierte Einmalsiegel
Physische Einmalsiegel sind eindeutig nummerierte Kunststoffbänder, die üblicherweise verwendet werden, um Manipulationen während der Lagerung und des Versands zu erkennen. Sie lassen uns beispielsweise wissen, ob die Tür eines Versandcontainers während des Transports geöffnet wurde. Digitale Einmalsiegel schließen ein digitales Siegel über eine Nachricht, um sicherzustellen, dass es nur einmal verwendet werden kann, was es für Verkäufer unmöglich macht, dasselbe Eigentum zweimal zu verkaufen.
Anstatt eine vertrauenswürdige Instanz zu verwenden, um das Öffnen und Schließen digitaler Siegel zu zertifizieren, ist es möglich, Bitcoins Unspent Transaction Outputs (UTXOs) als Siegel zu verwenden. Ein UTXO kann als ein Siegel betrachtet werden, das bei seiner Erstellung geschlossen und bei seiner Ausgabe geöffnet wird. Angesichts der Konsensregeln von Bitcoin kann ein Output nur einmal ausgegeben werden; daher kann das Siegel nur einmal geöffnet werden. Auf diese Weise werden Einmalsiegel verwendet, um Bitcoins UTXOs mit Off-Chain-Vertragszuständen zu verknüpfen, wodurch die Ausführung des nächsten Zustandsübergangs durch Off-Chain-RGB-Transaktionen (Schließen des Siegels) ermöglicht wird. Ähnlich wie die physischen Einmalsiegel, die zur Sicherung von Versandcontainern verwendet werden, ist ein digitales Einmalsiegel ein einzigartiges Objekt, das ein Stück Information präzise versiegelt, um Double-Spending zu verhindern.
Hier ist eine einfache Analogie: Wir können uns UTXOs als eine Reihe von Schecks vorstellen, von denen jeder mit einem anderen Betrag ausgestellt ist. Bei einer Zahlung bezahlen Sie im Wesentlichen jemanden mit einem nicht eingelösten Scheck. Darüber hinaus geht jeder verbleibende Saldo des Schecks in Form eines neuen Schecks an Sie zurück. In diesem Szenario fügen Single-Use-Seals bestimmte Übertragungsaufzeichnungen in das Zusatzinformationsfeld des Schecks ein. Da ein Scheck nur einmal eingelöst werden kann, verhindert dieser Ansatz Doppelausgaben.
Lassen Sie uns sehen, wie dieser Prozess zwischen Alice, Bob und Dave funktioniert:
- Zu Beginn hat Alice einen RGB-Asset (z.B. USDT Tether oder USDT) mit einer Gesamtmenge von 100 Millionen ausgegeben und die Verpflichtungsinformationen in das Zusatzinformationsfeld eines gültigen Schecks (Scheck A) eingetragen. Der Scheckdrucker muss diese zusätzlichen Informationen nicht berücksichtigen, und Scheck A kann jeden beliebigen Nennwert haben, solange er Alice gehört und nicht eingelöst wurde.
- Wenn Alice 10 Millionen USDT an Bob überweisen möchte, muss sie Scheck A einlösen und im Zusatzinformationsfeld angeben, dass 10 Millionen USDT auf einen neuen Scheck (Scheck B) übergehen, der Bob gehört, und 90 Millionen USDT auf einen anderen neuen Scheck (Scheck C) übergehen, der Alice gehört und die verbleibenden 90 Millionen USDT enthält.
- Wenn Bob 10 Millionen USDT an Dave überweisen möchte, muss er Scheck B einlösen und im Zusatzinformationsfeld vermerken, dass 10 Millionen USDT auf einen neuen Scheck (Scheck D) übergehen, der Dave gehört.
- Der gleiche Prozess wiederholt sich bei jeder nachfolgenden Übertragung. Genauer gesagt, indossiert der vorherige Inhaber einen Teil des Betrags an den neuen Empfänger, und der Empfänger überprüft dann die gesamte Historie der Asset-Übertragungen. Ähnlich wie bei umlaufenden Schecks erzeugt jede Übertragung einen neuen Scheck, und jeder Scheck kann nur einmal eingelöst werden (UTXO). Gleichzeitig werden alte Schecks (UTXOs) ungültig, was sicherstellt, dass sich der Zustand nur vorwärts und nicht rückwärts bewegen kann, was auch Doppelausgaben verhindert. Auf diese Weise spiegeln die On-Chain-Aufzeichnungen zuverlässig die Zustandsänderungen eines Krypto-Assets wider.
RGB verwendet das oben beschriebene Bitcoin-basierte Einmal-Siegel-Modell, was bedeutet, dass der Absender bei einer RGB-Transaktion einen Zustandsübergang des Vertrags erstellt, der die zu übertragenden Rechte definiert. Betrachten wir den Fall von Token. Zunächst legt der Herausgeber eines Vertrags den Anfangszustand fest, der die Vertragsdetails definiert, wie den Namen des Vermögenswerts, die Gesamtversorgung und die UTXO mit dem Recht, die Versorgung zu bewegen. Wenn die Vermögenswerte dann erstmals übertragen werden, kann der Besitzer der ersten UTXO einen Zustandsübergang erstellen, der definiert, welche neue UTXO nun den Vermögenswert besitzt. RGB erreicht Zustandsübergänge, indem es den Mechanismus nutzt, dass UTXOs nur einmal ausgegeben werden können, was es ermöglicht, die Übertragung von Krypto-Assets und die Änderungen der Eigentumsrechte zuverlässig zu definieren und zu verfolgen.
RGB hält alle Transaktionsinformationen außerhalb des Bitcoin-Netzwerks und überträgt sie ausschließlich zwischen Sendern und Empfängern. Währenddessen werden die Verpflichtungsdaten in Bitcoin-UTXOs verankert. Sobald eine UTXO ausgegeben wird, kann sie nicht mehr auf die gleiche Weise ausgegeben werden, was eine Änderung im Vertrag signalisiert.
RGB nutzt die Bitcoin-Blockchain zum Schutz vor Doppelausgaben, und dies wird erreicht, indem jeder RGB-Zustandsübergang innerhalb der Bitcoin-Transaktion verankert wird, die die UTXO ausgibt, die die zu bewegenden Rechte besitzt. Mehrere Zustandsübergänge können in einer einzigen Bitcoin-Transaktion enthalten sein, aber jeder Zustandsübergang kann nur einmal eingereicht werden (andernfalls wäre eine Doppelausgabe möglich). Um mehrere Zustandsübergänge in einer Verpflichtung zu ermöglichen, werden die Zustandsübergänge mehrfach aggregiert und dann über Taproot oder OP_RETURN zur Bitcoin-Transaktion übermittelt. Wenn mehrere Verpflichtungen in einer Bitcoin-Transaktion existieren, wird nur die erste für die RGB-Validierungsregeln relevant sein, und die anderen werden ignoriert, wodurch jeder Versuch einer Doppelausgabe sinnlos wird. Hauptmerkmale von RGB
Skalierbarkeit
- Im Vergleich zu alternativen Protokollen, die die gesamte Logik on-chain halten, bewahrt CSV Daten off-chain auf, was Kosten und Rechenaufwand reduziert;
- RGB ist auf Bitcoin ohne Notwendigkeit von Codeänderungen oder komplexen On-Chain-Transaktionen sofort verfügbar;
- RGB unterstützt das Lightning Network.
Privatsphäre
- Dritte können RGB-Transaktionen oder deren Einmalsiegel nicht einsehen;
- RGB verfügt über geblindete UTXOs. Ein geblindeter UTXO besteht aus dem Hash der Verkettung zwischen dem UTXO und einem zufälligen Blindgeheimnis. Auf diese Weise weiß der Absender nicht, wohin die Assets gingen, und der neue Empfänger kann den geblindeten UTXO nur validieren, wenn er das Asset ausgibt;
- RGB verwendet auch einen Zero-Knowledge-Mechanismus namens Bulletproof. Mit diesem Mechanismus können Asset-Besitzer alle UTXOs sehen, die zuvor ein Asset besaßen, aber sie können nicht die Menge des Assets sehen, die bei jedem Zustandsübergang übertragen wurde.
RGB's vielseitige Funktionen und Anwendungsfälle
Schemata
Emittenten können RGB-Schemata verwenden, die als Vorlagen für Verträge dienen und für spezifische Anwendungsfälle eingesetzt werden können.
Hier sind einige Beispiele:
- RGB20 Ausgabe fungibler Assets
- RGB21 Ausgabe nicht-fungibler Assets
- RGB22 dezentralisierte digitale Identitäten
- RGB23 verifizierbar-einzigartiges Verlaufsprotokoll für prüfbare Daten
- RGB24 dezentralisiertes globales Domain-Namen-System
- RGB25 Ausgabe von Sammlerstücken
Jeder kann frei sein eigenes Schema für verschiedene Anwendungen entwickeln, ohne die Erlaubnis der RGB-Entwickler einholen zu müssen. Es wird jedoch erwartet, dass die meisten Anwendungsfälle durch einige wenige Hauptschemata abgedeckt werden können.
AluVM
RGB verwendet AluVM, eine speziell entwickelte registerbasierte RISC-Virtuelle Maschine. AluVM ist Turing-vollständig und kann den globalen Zustand mit den gleichen Verfügbarkeitsgarantien wie bestehende Blockchain-basierte Systeme betreiben. Ähnlich wie EVM verfügt AluVM über eine Architektur, die einen RGB-Knoten auf dem Lightning-Netzwerk verschachtelt und einen RGB-Client auf RGB-Knoten beherbergt.
Vollständig kompatibel mit dem Lightning-Netzwerk
Durch die Verknüpfung von Zahlungskanälen spezifischer Token mit dem Lightning-Netzwerk können RGB-Assets die gleiche Benutzererfahrung und Sicherheitsannahmen wie reguläre Lightning-Netzwerk-Zahlungen bieten. Dies gewährleistet kostengünstige, schnelle und stabile Zahlungen und kann dem gesamten Ökosystem zugutekommen, einschließlich Benutzern, Entwicklern und Lightning-Knotenbetreibern.
Vergleich mit anderen Lösungen
RGB vs. TARO
TARO (jetzt Taproot Assets), ein von Taproot unterstütztes Taro-Protokoll, wurde im April 2022 von Lightning Labs eingeführt, nachdem es 70 Millionen Dollar in einer Serie-B-Finanzierung aufgebracht hatte.
Sowohl RGB als auch TARO basieren auf CSV. Da die beiden ähnliche Designs haben, argumentieren einige sogar, dass TARO von RGB inspiriert wurde. Allerdings scheint es jetzt, dass sie sich auf unterschiedliche Aspekte konzentrieren: TARO konzentriert sich auf Token, während RGB darauf abzielt, Smart-Contract-Funktionen zu implementieren.
Vergleich mit anderen Bitcoin-Lösungen
Im Gegensatz zu Drivechain, das auf BIP300 und BIP301 basiert und Hard Forks erfordert, ist RGB mit bestehender Bitcoin-Technologie und potenziellen zukünftigen Soft Forks kompatibel, ohne dass Änderungen an der Basisebene von Bitcoin erforderlich sind.
Ordinals speichert alle Daten in der Blockchain, während RGB nur die Datenzusicherungen in der Kette behält. Angesichts der Sicherheit, die UTXOs bieten, verbraucht RGB minimalen On-Chain-Speicherplatz und ermöglicht eine nahtlose Integration mit dem Lightning-Netzwerk.
RGB vs. Rollup
Rollup ist eine Ethereum-Skalierungslösung, die es Benutzern ermöglicht, Gelder in Ethereums Smart Contracts einzuzahlen und dann mit anderen Benutzern im selben Rollup zu interagieren. Diese Transaktionen werden periodisch aggregiert und an die Blockchain übermittelt.
- Darüber hinaus ist RGB keine unabhängige Blockchain. Herausforderungen: Das RGB-Ökosystem befindet sich noch in einem frühen Stadium. Obwohl die Infrastruktur bereits vorhanden ist, bietet das Ökosystem nur eine Handvoll grundlegender Anwendungen, und es könnte eine Weile dauern, bis RGB seine Entwicklertools und Nutzerbasis erweitert.
- RGB-Clients speichern massive Datenmengen, und Ausgaben wären unmöglich, wenn die Off-Chain-Daten zur Validierung verloren gingen. Daher muss nicht nur der Schlüssel gespeichert werden. Im Gegensatz zu Bitcoin und anderen globalen Konsenssystemen müssen RGB-Clients nicht alle Transaktionen global sehen oder validieren. Stattdessen müssen sie nur Transaktionen validieren, die mit ihren Wallets in Verbindung stehen. Dies reduziert die Datenmenge, die jeder Client validieren muss, erheblich und macht das gesamte System skalierbarer. Obwohl die Validierung massiver Daten beim Empfang von Zahlungen problematisch erscheinen mag, da langsame Validierung langsame Transaktionen bedeutet, wird dies nur dann zu einem Problem, wenn der Transaktionsverlauf lang ist. In diesem Fall werden neue Datenverfügbarkeitsschichten benötigt, die es Clients ermöglichen, freiwillig die Zustandsübergangsdaten spezifischer Futures zu teilen. Auf diese Weise können zukünftige Empfänger einen Teil des Transaktionsverlaufs im Voraus validieren.
- Bei beliebten CSV-Token kann eine umfangreiche Nutzung die Validierungskosten erhöhen.
- RGB ist eine community-getriebene Entwicklung und basiert auf sorgfältiger Teamforschung, was langsamen Fortschritt und begrenzte Marktpromotionen bedeutet.
Lernkurve für Entwickler: Zusätzlich zu Bitcoin-Kenntnissen müssen Entwickler auch über RGB's Zustandsübergänge und Futures informiert bleiben.
Ökosystem-Projekte
DIBA
Website: https://diba.io/
DIBA ist ein Bitcoin NFT-Marktplatz, der das RGB Smart Contract Protokoll verwendet.
Cosminmart
Website: https://www.cosminmart.com/
Cosminmart ist ein Ökosystem, das auf dem RGB-Protokoll basiert und Funktionen wie Wallet, Marktplatz, Launchpad und Browser anbietet.
Mycitadel
Website: https://mycitadel.io/
Mycitadel zeichnet sich durch eine breite Palette von Funktionen aus, darunter Multi-Signatur, zeitlich begrenzte Ausgabebedingungen, Taproot und mehr.
Bitmask
Website: https://bitmask.app/
Bitmask ist eine Wallet-Erweiterung.
Über CoinEx
CoinEx , gegründet im Jahr 2017, ist eine globale Kryptowährungsbörse, die sich der Vereinfachung des Kryptohandels verschrieben hat. Die Plattform bietet eine Reihe von Dienstleistungen, darunter Spot- und Margin-Trading, Futures, Swaps, automatisierter Market Maker (AMM-Konto) und Finanzmanagementdienste für über 5 Millionen Nutzer in mehr als 200 Ländern und Regionen. Mit der ursprünglichen Absicht gegründet, ein gleichberechtigtes und respektvolles Kryptowährungsumfeld zu schaffen, widmet sich CoinEx dem Abbau traditioneller Finanzbarrieren, indem es benutzerfreundliche Produkte und Dienstleistungen anbietet, um den Kryptohandel für jeden zugänglich zu machen.
Referenzen
https://hackernoon.com/top-4-directions-of-bitcoin-ecosystem-scalability
https://docs.rgb.info/
https://github.com/RGB-WG/blackpaper/blob/master/README.md
https://docs.lightning.engineering/the-lightning-network/taproot-assets
https://docsend.com/view/he8x9erkjmphphvn