RGB stärkt die Skalierbarkeit und Datenschutzfunktionen von Bitcoin und Lightning Network

TL; DR

• RGB fungiert als Layer-2/3-Lösung auf dem clientseitigen Validierungsparadigma von Bitcoin und Lightning Network und speichert alle Smart-Contract-Daten außerhalb von Bitcoin-Transaktionen. Dieses Design stellt den Betrieb des Systems über dem Lightning Network sicher und macht Änderungen an den LN-Protokollen überflüssig.
  
• RGB-Smart-Verträge sind auf Skalierbarkeit und Vertraulichkeit ausgelegt. Das System unterstützt privates und gegenseitiges Eigentum, abstrahiert und trennt Anliegen und stellt eine Post-Blockchain-Turing-vollständige Form des vertrauenswürdigen verteilten Rechnens dar, ohne dass die Einführung neuer Token erforderlich ist.
  
• RGB-Verträge sind in separaten Segmenten, sogenannten „Shards“, organisiert, von denen jedes über einen eigenen Verlauf und eigene Daten verfügt, was die Skalierbarkeit verbessert und die Vermischung von Verläufen aus verschiedenen Verträgen verhindert. Sie interagieren über das Bifrost-Protokoll im Lightning Network und ermöglichen so koordinierte Änderungen zwischen mehreren Parteien, ähnlich wie DEXes, die im Lightning Network betrieben werden.
  
• RGB verwendet Einwegsiegel defiAus Sicherheitsgründen über Bitcoin UTXOs ned. Jede Partei, die über einen Smart-Contract-Statusverlauf verfügt, kann dessen Einzigartigkeit überprüfen, indem sie das Skript von Bitcoin nutzt define Eigentums- und Zugriffsrechte.
  
• In RGB sind Staatseigentum und Validierung getrennte Einheiten. Der Besitz wird durch das Bitcoin-Skript verwaltet, ein Nicht-Turing-Complete-System. Validierungsregeln hingegen werden durch das RGB-Schema unter Verwendung des Turing Complete Simplicity/Contractum/Rust-Skripts vorgegeben.
  
• Jeder RGB-Smart-Vertrag ist mithilfe von Einwegsiegeln einem eindeutigen Status zugeordnet. Die Siegel und der Status folgen spezifischen Regeln und Validierungen, die vom Ersteller des Vertrags festgelegt und durch ein „Schema“ geregelt werden. Dieses Schema fungiert wie ein Regelsatz zur Prüfung von Vertragsdaten auf der Clientseite und ermöglicht ein hohes Maß an Protokollskalierbarkeit und Datenschutz.
  
• Das Design von RGB ist hochgradig interoperabel mit bestehenden Bitcoin- und Lightning-Network-Technologien und erleichtert die nahtlose Integration mit diesen Plattformen und allen zukünftigen Upgrades.
  
• Im Gegensatz zum imperativen Programmierstil vieler Blockchain-Plattformen verwendet RGB einen deklarativen Stil. Dieser Ansatz konzentriert sich auf die Darstellung des gewünschten Ergebnisses und nicht auf die detaillierte Beschreibung der spezifischen Schritte, um dieses zu erreichen.
  
• RGB nutzt verschiedene fortschrittliche Technologien, darunter AluVM für deterministische tragbare Computeraufgaben, PRISM für teilweise replizierte unendliche Zustandsmaschinen-Computing und Storm für treuhändebasierte, vertrauenswürdige Speicherung mit ZK-Proofs. Diese Technologien tragen zur Robustheit, Vertraulichkeit und Erweiterbarkeit von RGB bei.
  
• RGB (v0.10) führt bemerkenswerte Verbesserungen der Benutzererfahrung und Integrationsprozesse ein, rationalisiert Abläufe und minimiert Abhängigkeiten. Die aktualisierte Version verfügt über eine einheitlichere Bibliotheks-API und ein Befehlszeilentool, wodurch sie zugänglicher und benutzerfreundlicher wird.

Kurze Beschreibung

RGB ist ein Protokoll zur Ausgabe von Token im Bitcoin-Netzwerk mit verbesserter Privatsphäre und Kompatibilität mit dem Lightning Network. Es baut auf dem Konzept der „farbigen Münzen“ auf, wie sie im OmniLayer-Protokoll verwendet werden, wo Metadaten in Bitcoin-Transaktionen auf eine Token-Übertragung hinweisen. Beispielsweise funktionieren USDT-Transaktionen auf OmniLayer als Bitcoin-Transaktionen, ergänzt durch zusätzliche Daten, die die USDT-Token-Bewegungen detailliert beschreiben. Diese Methoden unterliegen jedoch Einschränkungen wie Datengrößenbeschränkungen in OP_RETURN-Ausgaben, intensivem Blockchain-Scannen und eingeschränkter Privatsphäre aufgrund der Sichtbarkeit in der Kette.

RGB geht diese Probleme an, indem es einen Großteil der Validierungsprozesse aus der Bitcoin-Blockchain verlagert. Es übernimmt die clientseitige Validierung und verwendet Einwegsiegel, um Token mit den UTXOs von Bitcoin zu verbinden und gleichzeitig die Privatsphäre der Benutzer zu wahren.

Token werden übertragen, indem innerhalb einer Bitcoin-Transaktion eine Nachricht mit RGB-Zahlungsinformationen gesendet wird, sodass die Token von einem UTXO zu einem anderen verschoben werden können, ohne eine Spur im Bitcoin-Transaktionsdiagramm zu hinterlassen. Dies verbessert die Privatsphäre erheblich, da RGB-Transaktionen Token diskret „teleportieren“ und RGB-spezifische Daten über private Off-Chain-Kanäle weitergeleitet werden.

Darüber hinaus müssen Empfänger den gesamten Transaktionsverlauf der erhaltenen Token validieren, um das Eigentum sicherzustellen und Inflation zu verhindern. RGB ermöglicht zukünftige Upgrades ohne die Notwendigkeit von Hard Forks, wodurch sichergestellt wird, dass Miner den Vermögensfluss nicht nachverfolgen können, was zu einem höheren Widerstand gegen Zensur führt. Im Gegensatz zu herkömmlichen Blockchain-Strukturen benötigt RGB keine Blöcke oder Ketten und positioniert sich als blockfreies dezentrales Protokoll, das hohe Vertraulichkeit, Sicherheit und Skalierbarkeit verspricht.

Einführung und Vision

Einzeiler: Ein vom Kunden validiertes Zustands- und Smart-Contract-System, das auf Schicht 2/3 im Bitcoin- und Lightning-Netzwerk betrieben wird.

Weitere Details:

RGB ist ein skalierbares und vertrauliches Smart-Contract-System für Bitcoin & Lightning Network. RGB-Smart-Verträge funktionieren mit Clientseitige Validierung Paradigma, Wohnen alle intelligenten Vertragsdaten außerhalb Bitcoin-Transaktionen, d. h. Bitcoin-Blockchain oder Lightning-Kanalstatus. Dadurch kann das System ohne Änderungen an den LN-Protokollen auf dem Lightning Network betrieben werden und bietet außerdem eine Grundlage für ein hohes Maß an Protokollskalierbarkeit und Datenschutz.

Intelligente Verträge verkörpern Prinzipien des privaten und gegenseitigen Eigentums, der Abstraktion und der Trennung von Belangen. Sie stellen eine „Post-Blockchain“ dar, eine Turing-vollständige Form des vertrauenswürdigen verteilten Rechnens, das keine Einführung von Token erfordert.

RGB-Verträge werden in separaten Segmenten ausgeführt, die als „Shards“ bezeichnet werden. Jeder Shard hat seinen eigenen Verlauf und seine eigenen Daten, was bedeutet, dass unterschiedliche Verträge ihren Verlauf nicht vermischen. Diese Methode verbessert die Skalierbarkeit. Der Begriff „Shard“ wird verwendet, um zu zeigen, dass RGB ähnliche Ziele erreicht wie mit dem Shards-Konzept von Ethereum beabsichtigt.

Obwohl sie unabhängig voneinander funktionieren, können RGB-Verträge über das Bifrost-Protokoll im Lightning Network interagieren. Dies ermöglicht koordinierte Änderungen zwischen mehreren Parteien. Beispielsweise ermöglicht es DEXes, über das Lightning-Netzwerk zu funktionieren.

Technologie & Architektur

Allgemeiner Überblick über den RGB-Betrieb und Einwegdichtungen

Abbildung 1. Allgemeiner Überblick über die Funktionsweise von RGB.
Quelle: LNP/BP Association Github.

Als Sicherheitsmechanismus nutzt RGB Einwegdichtungen defined über Bitcoin UTXOs, die jeder Partei, die über einen Smart-Contract-Statusverlauf verfügt, die Möglichkeit bieten, seine Einzigartigkeit zu überprüfen. Im Wesentlichen nutzt RGB das Bitcoin-Skript für sein Sicherheitsmodell und defines Eigentum und Zugangsrechte.

Abbildung 2. RGB-High-Level-Funktionsprinzip.
Quelle: „Driving Mass Adoption of Crypto: How the RGB Protocol is Illuminating the Future of Bitcoin“ von Waterdrip Capital.

Jeder RGB-Smart-Vertrag ist defined von a Genesis-Zustand, hergestellt von der Smart-Contract-Emittent (oder, einfach ausgedrückt, Emittent) und ein gerichteter azyklischer Graph (DAG) von Zustandsübergänge als vom Kunden validierte Daten verwaltet.

Abbildung 3. Transaktionen, geschlossenes Siegel und Zeuge.
Quelle: LNP/BP Association Github.

Wir können es wie folgt zusammenfassen: Jede Transaktion hat ein UTXO, und der Besitz dieses UTXO gewährt dem Eigentümer das Recht, den Staat zu besitzen. Das Eigentum bestimmt, wer den Blockchain-Status ändern und das UTXO „ausgeben“ kann. Die Person, die den Staat innehat, wird als Partei bezeichnet besitzender Staat.

Die Partei ist befugt, den relevanten Abschnitt des Smart-Contract-Status zu ändern, indem sie einen neuen Statusübergang generiert und ihn in einer Transaktion bestätigt, wobei sie die Ausgabe verwendet, die den vorherigen Status enthält.

Der Prozess bedeutet Schließung eines Siegels über den Staatsübergang, und ein Paar, das die Ausgabentransaktion und entsprechende Extra-Transaktionsdaten zum Zustandsübergang umfasst, wird als a bezeichnet Zeuge (dargestellt in einem Bild oben).

Eigentum und Zugang: Kernimmobilien

Abbildung 4. Eigentum und Zugriff.
Quelle: LNP/BP Association Github.

Staatseigentum und Validierung sind unterschiedliche Konzepte. Validierungsregeln legen fest, wie sich der Status ändern kann, geben jedoch nicht an, wer die Änderung bewirken darf. 

Andererseits wird der Besitz durch ein Bitcoin-Skript auf der Ebene der Bitcoin-Blockchain kontrolliert, was nicht Turing Complete ist. Im Gegensatz dazu unterliegen Validierungsregeln dem RGB-Schema unter Verwendung von Simplicity/Contractum Script, d. h. Turing Complete. 

RGB-Schema

Bei RGB-Smart-Verträgen wird jedem Vertrag durch Einwegsiegel ein eindeutiger Status zugewiesen. Für diese Siegel gelten neben dem Staat spezifische Regeln und Validierungen, die zu Beginn vom Vertragsersteller festgelegt werden. Dieses Setup wird durch ein „Schema“ gesteuert, das als Regelwerk zur Validierung von Vertragsdaten auf Kundenseite fungiert. Das Schema kann komplexe Skripte enthalten, die integraler Bestandteil der Vertragslogik sind.

Abbildung 5. RGB-Schema.
Quelle: LNP/BP Association Github.

Clientseitige Validierungs- und Designprinzipien

Abbildung 6. Clientseitige RGB-Validierung.
Quelle: LNP/BP Association Github.

1. Starkes Eigentum: In RGB haben intelligente Verträge eine klare Bedeutung defined Besitzer oder Besitzer. Nur bestimmte Eigentümer sind befugt, den Vertragsstatus zu ändern. In diesen Verträgen werden unterschiedliche Rechte oder Vorgänge dargelegt, die entweder als öffentlich (für alle zugänglich) oder als Eigentum (auf den Eigentümer beschränkt) kategorisiert sind.
2. Vertraulichkeit: Informationen im Rahmen des Vertrags werden vertraulich behandelt und sind nur den Teilnehmern, insbesondere den Staatseigentümern, bekannt. Teilnehmer haben die Möglichkeit, bestimmte Daten öffentlich zu machen, aber standardmäßig sind alle Informationen privat. Diese Vertraulichkeit verhindert, dass externe Analysetools auf die Daten zugreifen, und stellt so sicher, dass keine sensiblen Informationen in öffentlichen Hauptbüchern gespeichert werden.
3. Trennung von Bedenken: RGB verfügt über einen modularen Aufbau mit unterschiedlichen Ebenen, denen jeweils eine bestimmte Aufgabe zugewiesen ist. Diese Schichten arbeiten unabhängig voneinander, sodass niedrigere Schichten nicht über die Struktur der höheren Schichten Bescheid wissen müssen. Dieses Design verbessert die Organisation und Effizienz des Systems.
4. Erweiterbarkeit: Das System ist leicht erweiterbar und ermöglicht die Erstellung und Integration fortschrittlicher Smart Contracts, ohne dass das Kernprotokoll geändert oder die gesamte RGB-Bibliothek neu kompiliert werden muss.
5. Determinismus: Die Validierungslogik von RGB ist deterministisch und liefert stets identische Ergebnisse mit denselben Eingaben und dem vorherrschenden Zustand der zugrunde liegenden Blockchain oder des Lightning Network-Kanals. Diese Konsistenz wird durch zwei Hauptkomponenten erreicht: a. Die in Rust geschriebene Kernvalidierungslogik ist auf allen Systemen, auf denen RGB ausgeführt wird, gleich. B. Die vertragsspezifische Validierungslogik läuft auf AluVM, einer virtuellen Maschine, die unabhängig von der Plattform einen konsistenten Satz von Anweisungen bereitstellt.
6. LNP/BP-Interoperabilität: RGB ist so konzipiert, dass es nahtlos mit bestehenden Bitcoin- und Lightning Network-Technologien zusammenarbeitet. Es ist außerdem so konzipiert, dass es mit allen zukünftigen Upgrades dieser Technologien kompatibel ist.
   

Ansatz von RGB und Pure Blockchain/L1-Ansatz

Der reine Blockchain/L1-Ansatz ist falsch, sagt das RGB-Team.

Abbildung 7. RGB-Kommentare zum Blockchain/L1-Ansatz.
Quelle: LNP/BP Association Github.

RGBs Ansatz: Deklarative vs. imperative Programmierung:

• Die meisten Blockchain-Plattformen, einschließlich Ethereum, nutzen intelligente Verträge, die in einem zwingenden Stil geschrieben sind. Bei diesem Ansatz fungiert der Vertrag als Programm, das die schrittweise Ausführung von Aufgaben explizit steuert und einem präzisen und detaillierten Rezept ähnelt.
• Diese zwingenden Programme sind oft recht restriktiv und durch die Fähigkeiten der zugrunde liegenden Blockchain-Plattform eingeschränkt. Auch wenn sie manchmal als Turing-vollständig bezeichnet werden, weisen sie erhebliche Einschränkungen auf.

Deklarativer Charakter von RGB-Smart-Verträgen:

• RGB hingegen verwendet keine zwingende Programmierung. Stattdessen wird eine spezielle Form der funktionalen Programmierung verwendet, bei der es sich um intelligente Verträge handelt defideklarativ ned.
• Bei der deklarativen Programmierung beschreiben Sie nicht im Detail, wie etwas zu tun ist, sondern wie das Ergebnis aussehen soll. Es ist, als würde man skizzieren, wie eine Mahlzeit aussehen sollte, anstatt Schritt-für-Schritt-Anleitungen zum Kochen bereitzustellen.
• Das „Schema“ in RGB ist deklarativ definition eines Smart Contracts. Es legt die Regeln und Bedingungen des Vertrags fest, nicht jedoch die genaue Reihenfolge der Maßnahmen, um diese zu erfüllen.

Paradigmenwechsel in der Programmierung:

• Der Übergang vom imperativen Stil von Ethereum zum deklarativen Stil von RGB in der Smart-Contract-Programmierung ähnelt dem Übergang von der traditionellen imperativen Programmierung zur funktionalen oder deklarativen Programmierung in der allgemeinen Softwareentwicklung.
• Dieser Wandel erfordert eine andere Denkweise: Konzentration auf das „Was“ (die gewünschten Ergebnisse) statt auf das „Wie“ (die spezifischen Schritte, um diese Ergebnisse zu erzielen).

Einfache Bedienung

Der ursprüngliche Plan sah vor, Simplicity in RGB zu integrieren, und man bemühte sich darum, die Kompatibilität vom ersten Tag an sicherzustellen. Angesichts des schleppenden Fortschritts der Simplicity-Entwicklung und der Ungewissheit hinsichtlich des Veröffentlichungszeitplans wurde jedoch klar, dass es unpraktisch war, sich darauf zu verlassen. Die laufende RGB-Veröffentlichung, die derzeit vorbereitet wird, warf Fragen zur Aufnahme von Simplicity auf.

Da wir erkannten, dass es keinen verlässlichen Zeitplan für Simplicity gibt, haben wir eine Prüfung von Alternativen eingeleitet (WASM, EVM (als Scherz), IELE usw.). Schließlich stellte sich heraus, dass die Entwicklung einer proprietären virtuellen Maschine für RGB die einzig praktikable Option war und die anfängliche Abhängigkeit von Simplicity ersetzte.

Deshalb haben wir uns entschieden, etwas zu schaffen AluVM – rein funktionale, hochportable Rust-basierte virtuelle Maschine für clientseitig validierte Smart Contracts (RGB), Lightning Network, deterministisches verteiltes und Edge-Computing.

Prisma

PRISM steht für „Partially Replicated Infinity State Machines“-Computing.

RGB-Technologie defiNES-Regeln für die Entwicklung intelligenter Verträge auf einer grundlegenden Ebene, genannt Schema, beschränken jedoch nicht alle zukünftigen Aktionen des Vertrags auf einen einzigen, übergreifenden Algorithmus. Stattdessen führt jeder Knoten im Netzwerk individuelle Operationen aus und sowohl der Vertragsstatus als auch der Vertrag selbst bleiben gültig, solange diese Operationen den Regeln des Schemas entsprechen. 

Darüber hinaus beschränkt dieser Ansatz die historische Entwicklung des Vertrags nicht durch einen vorgegebenen Algorithmus. Daher kann ein Vertrag unterschiedliche Verhaltensweisen aufweisen, solange jede Änderung bestimmte Validierungsregeln erfüllt. Diese Methode konzentriert sich eher auf lokale Regeln als auf einen globalen Algorithmus.

Im Gegensatz dazu verwendet Ethereum einen globalen Algorithmus, bei dem jede Operation den gesamten Zustand des Smart Contracts beeinflusst. Mit RGB arbeiten Sie nur mit einem Teil des Vertragsstatus und wenden die Regeln lokal an. Dies bietet ein breiteres Spektrum an Möglichkeiten für die Vertragsentwicklung.

Unten sehen Sie eine allgemeine Übersicht über die Unterschiede zwischen Statuskanälen und clientseitiger Validierung: 

Abbildung 8. Trennung verteilter Systeme.
Quelle: LNP/BP Association Github.

Spezifischere Unterschiede sind wie folgt: 

Abbildung 9. Vergleich von Statuskanälen und clientseitiger Validierung.
Quelle: LNP/BP Association Github.

AluVM

AluVM – (algorithmische Logikeinheit VM) ist eine rein funktionale virtuelle RISC-Maschine, die für deterministische tragbare Computeraufgaben entwickelt wurde

AluVM zeichnet sich durch den Einsatz eines registerbasierten Systems aus, das einen zufälligen Speicherzugriff verhindert. Dieses Design verbessert die Eignung von AluVM für Anwendungen wie Smart Contracts, Remote-Codeausführung sowie verteiltes und Edge-Computing. Die Kernstärken von AluVM liegen in seinem Determinismus, seiner Robustheit und seiner Fähigkeit zur formalen Codeanalyse.

Schlüsseleigenschaften: Ausnahmelos, Portabilität, Sandboxing, Sicherheit, Erweiterbarkeit.

Die Instruction Set Architecture (ISA) von AluVM ist anpassungsfähig und ermöglicht die Erstellung unterschiedlicher Laufzeitumgebungen für verschiedene Anwendungen. AluVM selbst ist eine hoch vorhersehbare, funktionale, registerbasierte virtuelle Maschine und ISA. 

Während der zufällige Speicherzugriff eingeschränkt wird, zeichnet sich der AluVM ISA bei der Ausführung arithmetischer Aufgaben aus, einschließlich solcher im Zusammenhang mit elliptischen Kurven. Einzigartig ist, dass die VM-Umgebung die AluVM ISA erweitern kann und das Hinzufügen von Funktionalitäten wie dem Laden von Daten in die Register der VM und der Unterstützung spezieller Anweisungen (z. B. SIMD) ermöglicht, die auf bestimmte Anwendungen zugeschnitten sind.

AluVM ist hauptsächlich für den Einsatz in verteilten Systemen gedacht, bei denen Konsistenz und Zuverlässigkeit über verschiedene Plattformen hinweg wichtiger sind als die Verarbeitungsgeschwindigkeit. Zu den Hauptanwendungen für AluVM mit den richtigen ISA-Erweiterungen gehören Blockchain-Technologie, für den Konsens in Netzwerken entscheidende Berechnungen, Edge-Computing, Multiparty-Computing (das deterministisches maschinelles Lernen umfasst), clientseitige Validierung, eingeschränktes Internet2-Computing und genetische Algorithmen. Diese Anwendungen profitieren von der Fähigkeit von AluVM, in verschiedenen Umgebungen konsistent und sicher zu funktionieren.

Abbildung 10. AluVM-Vergleich.
Quelle: LNP/BP Association Github.

Contractum

Contractum unterscheidet sich von anderen Programmiersprachen für intelligente Verträge, indem es die funktionalen Fähigkeiten von Haskell mit der Nähe zum Bare Metal von Rust verbindet. Es besetzt eine Nische, die Smart Contracts bisher nicht zugänglich waren:

Abbildung 11. Contractum, Simplicity und andere Sprachen im Vergleich.
Quelle: Contractum.org

Contractum ist eine Programmiersprache zur Erstellung von RGB-Verträgen. Mit Contractum geschlossene Verträge werden mithilfe einer Methode namens „Client-Side-Validation“ überprüft. Dieser Ansatz fügt der Bitcoin-Blockchain keine Daten hinzu, was mit einer Form der Sharding-Technologie verglichen werden kann, die durch die Verwendung von Zero-Knowledge-Proofs weiter verbessert wird. 

Die clientseitige Validierung trennt außerdem die Vertragsentwicklung von Blockchain-Transaktionen, sodass es unmöglich ist, diese Transaktionen mit herkömmlichen Blockchain-Analysemethoden zu verfolgen oder zu analysieren.

Abbildung 12. Contractum-Merkmale.
Quelle: Contractum.org

Um sich am Contractum-Design zu beteiligen, ist es wichtig, sich mit den Technologien vertraut zu machen, die von RGB-Smart Contracts verwendet werden:

Abbildung 13. Technologien, die von RGB-Smart-Verträgen verwendet werden.
Quelle: Contractum.org

Aktuelle Updates in der neuen Version RGB v0.10

In der neuesten Version von RGB (Version 0.10) wurden mehrere fortschrittliche technische Verbesserungen implementiert, die die Fähigkeiten des Frameworks für die Entwicklung komplexer Anwendungen verbessern. Diese Aktualisierungen konzentrieren sich hauptsächlich auf die Einführung eines globalen Status für jeden RGB-Vertrag, die Integration von Vertragsschnittstellen und die Einführung eines strengen Typsystems.

Globaler Status in RGB-Verträgen

Die Funktion „Global State“ ist eine entscheidende Neuerung in RGB v0.10 und ermöglicht es jedem Vertrag, einen allgemein zugänglichen Status beizubehalten. Auf diesen Zustand kann nicht nur die virtuelle RGB-Maschine zugreifen, sondern auch externe Clients wie Wallets und andere Anwendungen.

Der Nutzen dieses globalen Zustands ist von entscheidender Bedeutung für die Erstellung anspruchsvoller Anwendungen auf der RGB-Plattform, insbesondere solcher, die eine komplizierte Zustandsverwaltung erfordern, wie synthetische Vermögenswerte und algorithmische Stablecoins. Es ermöglicht eine dynamischere Interaktion mit dem Vertragsstatus und geht über die Einschränkungen traditioneller Smart-Contract-Architekturen hinaus.

Vertragsschnittstellen

RGB v0.10 führt „Vertragsschnittstellen“ als standardisiertes Kommunikationsprotokoll für verschiedene Smart Contracts ein. Diese Schnittstellen funktionieren ähnlich wie die Vertrags-ABIs (Application Binary Interfaces) und ERCs (Ethereum Request for Comments) von Ethereum.

Ein wesentliches Unterscheidungsmerkmal des RGB-Ansatzes ist die nicht zwingende Standardisierung dieser Schnittstellen und ihre inhärente Verpackung mit Verträgen, wodurch die Notwendigkeit einer separaten Verteilung entfällt. Dies erleichtert semantische Interaktionen zwischen Benutzern und Verträgen über Benutzeroberflächen in Wallets und anderer Software.

Diese Schnittstellen sind nicht statisch; Entwickler können bestehende Verträge im Laufe der Zeit um zusätzliche Schnittstellen erweitern und so die Funktionalität verbessern, ohne den unveränderlichen Vertragskern zu ändern.

Strenges Typensystem

Das neue Kodierungsformat in RGB v0.10 verwendet ein „strenges Typen“-System. Bei diesem System handelt es sich um einen neuartigen Ansatz für funktionale Datentypen, der für die effiziente Darstellung und Introspektion von Vertragszuständen innerhalb des RGB-Frameworks entwickelt wurde.

Das strikte Typsystem gewährleistet die Sicherstellung der Datengrößen zur Kompilierungszeit, was besonders für den Betrieb auf ressourcenbeschränkten Geräten, wie etwa Low-End-Hardware-Wallets mit begrenzter Speicherkapazität, von Vorteil ist.

Darüber hinaus wird die gesamte RGB-Konsensschicht in Version 0.10 in strikte Typen kompiliert und bietet so eine Grundlage für formale Beweise der Binärkompatibilität zwischen verschiedenen Softwareversionen. Diese Funktion vereinfacht und sichert nicht nur die Verwendung von RGB, sondern ermöglicht es auch Asset-Emittenten und Vertragsentwicklern, zusätzliche Metadaten an ihre Assets oder Verträge anzuhängen. Solche Metadaten können eine entscheidende Rolle bei der Überprüfung der Identität und Authentizität von Vermögenswerten oder Verträgen im RGB-Ökosystem spielen.

Rustbasierte Smart Contracts

RGB-Smart-Verträge können jetzt in Rust erstellt werden, wobei die Fähigkeiten der Sprache für Typsicherheit und Leistung genutzt werden.

Die strikte Systemtypintegration erleichtert die direkte Kompilierung von Rust-Datentypen in RGB-Vertragsstrukturen und verbessert so die Effizienz und Zuverlässigkeit des Vertragscodes.

Erweiterte Funktionen zur Zustandsintrospektion

Intelligente Verträge in RGB v0.10 können ihren eigenen Status innerhalb des von der virtuellen RGB-Maschine ausgeführten Validierungscodes überprüfen.

Diese Funktion ist besonders nützlich für die Erstellung komplexer Verträge, die mit Bitcoin-Transaktionen, diskreten Protokollverträgen und anderen komplexen Datenstrukturen interagieren und den Umfang und die Funktionalität von RGB-Smart-Verträgen erweitern.

URL-basiertes Rechnungsformat

Das Update führt ein neues Rechnungsformat ein, das das bisherige Bech32m-codierte System ersetzt.

Diese neuen URL-basierten Rechnungen sind deutlich kürzer und benutzerfreundlicher und ermöglichen eine einfachere Überprüfung und automatische Öffnung mit vorkonfigurierter Software.

WASM (WebAssembly)-Unterstützung

Die RGB-Standardbibliothek ist jetzt mit Umgebungen kompatibel, in denen es keinen E/A- und Dateisystemzugriff gibt, wie etwa Webseiten oder Browser-Plugins.

Dies erweitert die potenziellen Anwendungsfälle von RGB und ermöglicht den nahtlosen Einsatz in einer Vielzahl webbasierter Anwendungen und Erweiterungen.

Taproot-Deskriptoren und benutzerdefinierte Ableitung

RGB v0.10 nutzt Taproot-basierte OP_RETURN-Commitments (als Tapret bezeichnet), was eine Unterstützung auf Deskriptorebene für Wallets erfordert, um Transaktionen mit optimierten Ausgaben zu erkennen.

Die Einführung benutzerdefinierter Ableitungsindizes in dieser Version verhindert, dass Nicht-RGB-Wallets versehentlich Ausgaben ausgeben, die RGB-Assets enthalten, und schützt so die Integrität dieser Assets.

Vereinfachte Abhängigkeiten

Die RGB-Konsensschicht in Version 0.10 hat ihre Abhängigkeiten reduziert und sich insbesondere von einer benutzerdefinierten, kugelsicheren Implementierung entfernt, die ursprünglich von Grin-Projekten abgeleitet wurde.

Diese Reduzierung der Abhängigkeiten verbessert die Stabilität der API und die allgemeine Robustheit des Systems.

Optimierter Integrationsprozess

Das Update vereinfacht betriebliche Arbeitsabläufe, indem es die Notwendigkeit mehrerer API-Aufrufe und komplexer sprachübergreifender Datenstrukturkodierung reduziert.

RGB-Vertragszustände werden jetzt als JSON-Objekte dargestellt, was eine einfache Serialisierung über verschiedene Programmiersprachen hinweg ermöglicht.

Verbesserungen der Benutzerfreundlichkeit

Die neue Version von RGB vereinfacht die Benutzererfahrung, indem sie zuvor unterschiedliche Komponenten in einer einheitlichen Bibliotheks-API und einem Befehlszeilentool konsolidiert.

Während der RGB-Knoten weiterhin auf Heimservern betrieben werden kann, ist seine Verwendung für die Interaktion mit dem RGB-System nicht mehr zwingend erforderlich, wodurch die Eintrittsbarriere für Benutzer und Wallet-Anwendungen verringert wird.

Dieser Abschnitt enthält einen besonderen Dank an Waterdrip Capital für die Hervorhebung der neuesten Features in ihrem Artikel mit dem Titel „Driving Mass Adoption of Crypto: How the RGB Protocol Illuminates the Future of Bitcoin.“

RGB-Konkurrenten

Abbildung 14. FRGB vs. Ethereum in einfachen Worten.
Quelle: LNP/BP Association Github

Pfahlwurzel

Taproot Assets, früher bekannt als Taro, ist ein Protokoll zur Einführung von Token im Bitcoin-Netzwerk. Dieses Protokoll nutzt das UTXO-Modell von Taproot zusammen mit zugehörigen Lösungen wie Tapscript und Taptweak. Diese Tools werden verwendet, um Informationen über den Bestand und den Saldo eines Vermögenswerts in Bitcoin-Transaktionsdaten zu speichern.

Abbildung 15. Schema zum Speichern von Informationen über Taproot Assets-Token.
Quelle: „Taproot Assets: Ausgabe von Vermögenswerten auf Bitcoin“ von Voltage

Taproot Assets verwendet eine dem Ordinals-Konzept analoge Methode, bei der BRC-20-Token Versorgungsinformationen in den Metadaten der aufgezählten Satoshis speichern. Umgekehrt bettet Taproot Assets diese Informationen in die Taproot-Ausgabe einer Bitcoin-Transaktion ein und nutzt dabei einen sogenannten „sparse Merkle Tree“. Im Wesentlichen integriert Taproot Assets einen Merkle-Baum in die Bitcoin-Transaktion, der als Beweis für das Guthaben eines bestimmten Benutzers und den gesamten Token-Vorrat dient. Dieser Baum wiederum spiegelt Daten aus dem „Universum“ wider – einem Repository, das die gesamte Asset-Historie verwaltet und vom Token-Emittenten verwaltet wird.

Abbildung 16. Digitaler Zustandsbaum.
Quelle: „Taproot Assets: Ausgabe von Vermögenswerten auf Bitcoin“ von Voltage

State Digital Tree – Die Architektur von Taproot Assets bietet zwei Optionen für den Gleichgewichtsnachweis: Off-Chain-Daten aus dem Universum oder den spärlichen Merkle-Baum, der in UTXO eingebettet ist.

Betriebsmechanismus

1. Der Token-Ersteller führt eine P2TR-Transaktion (Pay to Taproot) unter Verwendung des Taproot Assets-Protokolls aus. 
2. Informationen über den Vermögenswert in Form eines Merkle-Baums werden im UTXO dieser Transaktion (effektiv im Genesis-Block) gespeichert. 
3. Um den Token zu übertragen, ändert der Besitzer des Taproot-Schlüssels die Kontostandinformationen im Merkle-Baum und stellt so sicher, dass der Gesamtbestand an Vermögenswerten konstant bleibt. 
4. Solche Änderungen werden über eine neue Taproot-Transaktion eingeführt. Für jede Token-Übertragung ist jedoch keine separate On-Chain-Transaktion erforderlich. Ähnlich wie bei Rollups oder dem Lightning Network ermöglicht das Protokoll dem Eigentümer, einen „Stapel“ von Überweisungen zu verarbeiten und anschließend den aktualisierten Stand der Salden zu veröffentlichen.

Vorteile von Taproot Assets

• Ein wesentlicher Vorteil von Taproot Assets ist die vollständige Kompatibilität mit dem Lightning Network, wodurch die Skalierbarkeit verbessert und die Transaktionskosten gesenkt werden.
• Taproot Assets erstellt eine eigene Ebene für die Aufzeichnung von Vorgängen mit benutzerdefinierten Token. Während es sich hauptsächlich auf Off-Chain-Daten stützt, veröffentlicht es den Stand der Guthaben im Hauptnetzwerk. 
• Dieser Ansatz ist im Vergleich zu BRC-20 flexibler, skalierbarer und umfassender, stellt jedoch auch eine höhere Komplexität für unerfahrene Benutzer dar.

BitVM

BitVM ist ein hochmodernes Projekt, das darauf abzielt, Bitcoin in eine vollständig dezentrale Computerplattform umzuwandeln. Das am 9. Oktober 2023 vorgestellte BitVM-Whitepaper stellt eine Technologie vor, die sich derzeit in der Testphase befindet und einer Weiterentwicklung bedarf, um ihr volles Potenzial auszuschöpfen.

Kernfunktionalität und Konzept von BitVM

Im Kern nutzt BitVM das Konzept von Optimistic Rollups, um die Berechnungen für Smart Contracts aus dem Netzwerk zu externalisieren und anschließend eine On-Chain-Verifizierung auf der Grundlage von „Betrugsnachweisen“ durchzuführen. Sobald Smart-Contract-Informationen in einer Taproot-Transaktion (als Binärcode) aufgezeichnet sind, sollen theoretisch der Datenaustausch und die Berechnungen direkt zwischen den Parteien stattfinden. Dieser Ansatz soll die Überlastung der Blockchain verringern. Wenn jedoch der Prüfer (die Partei, die den Nachweis erbringt, d. h. der Vertragsinhaber) fehlerhafte Daten übermittelt, kann ein Verifizierer eine On-Chain-Prüfung einleiten. Dieser Prozess bildet die Grundlage des Fraud-Proof-Konzepts.

Handhabung der On-Chain-Verifizierung in einem rechnerisch begrenzten Netzwerk

Die Herausforderung besteht darin, eine Betriebsprüfung in einem Netzwerk durchzuführen, das solche Berechnungen grundsätzlich nicht unterstützt. Um dieses Problem zu lösen, verwendet BitVM einen Merkle-Baum, um ein logisches NAND-Gate-Schema zu erstellen, das dann in einer Taproot-Transaktion aufgezeichnet wird. Im Wesentlichen fungiert der Merkle-Baum in den Transaktionsdaten als NAND-Schema, bei dem jeder „Zweig“ einen von zwei möglichen Werten trägt: 1 oder 0. Die On-Chain-Berechnung erfolgt Stück für Stück, wobei die Ausgabe eines „Zweigs“ wird die Eingabe für den nächsten. Zwischen den Smart-Contract-Parteien findet ein ständiger Transaktionsaustausch zur Wertüberprüfung statt. Wenn sich herausstellt, dass die Berechnungsversion des Prüfers falsch ist, erhält der Prüfer seine Vermögenswerte in der Taproot-Transaktion gesperrt.

Abbildung 17. Schematische Darstellung von NAND.
Quelle: „Der große Deal mit BitVM: Willkürliche Berechnung jetzt auf Bitcoin ohne Fork möglich“ von Bitcoin Magazine

Aufbau von NAND mit Taproot und Merkle Tree

Detaillierte Informationen darüber, wie BitVM den Aufbau von NAND mithilfe von Taproot- und Merkle-Bäumen erleichtert, sowie seine Auswirkungen auf Berechnungen finden Sie in der technischen Dokumentation.

Dieser Ansatz ermöglicht eine präzise, ​​schrittweise Überprüfung von Smart-Contract-Berechnungen im Einklang mit den Prinzipien der Blockchain-Integrität und -Sicherheit.

Herausforderungen beim Smart-Contract-Bilateralismus

Bei BitVM besteht nach wie vor ein erhebliches Problem aufgrund der bilateralen Struktur von Smart Contracts, die den direkten Datenaustausch ausschließlich zwischen Prüfer und Prüfer ermöglicht und die Beteiligung Dritter ausschließt. Diese Einschränkung behindert die Entwicklung von dApps und erfordert zusätzliche Lösungen für den Aufbau von Mehrparteienverträgen. 

Darüber hinaus bedeuten die komplexen und einfachen Eigenschaften von BitVM, dass sich die Entwicklung funktionaler Produkte, die diese Grundlage nutzen, über mehrere Jahre erstrecken kann. Um diese grundlegende Technologie in praktische Anwendungen umzusetzen, sind umfangreiche Entwicklungen und Innovationen unerlässlich.

Für einen detaillierten Einblick zögern Sie nicht, eine BitVM zu lesen Whitepaper - https://bitvm.org/bitvm.pdf 

Zusammenfassung

Das RGB-Protokoll ist eine technische Entwicklung im Bitcoin-Ökosystem, die Funktionen für die Implementierung intelligenter Verträge und die Ausgabe von Token einführt, die direkt mit dem Bitcoin-Netzwerk verbunden sind. Dies wird durch eine Kombination aus clientseitiger Validierung und der Verwendung von Einwegsiegeln erreicht, die Token mit den UTXOs von Bitcoin verknüpfen und gleichzeitig den Transaktionsschutz wahren.

Einer der wichtigsten technischen Vorteile von RGB ist sein Ansatz für Skalierbarkeit und Datenschutz. Durch die Verlagerung des Großteils der Validierungsarbeit von der Bitcoin-Blockchain und den Einsatz kryptografischer Methoden zur Transaktionsüberprüfung reduziert RGB effektiv die Datenlast auf der Blockchain. Dieser Ansatz trägt dazu bei, die Effizienz des Netzwerks aufrechtzuerhalten, insbesondere bei steigenden Transaktionsvolumina.

Die Kompatibilität von RGB mit dem Lightning Network ist ein weiterer wichtiger Aspekt, der eine skalierbarere und effizientere Transaktionsverarbeitung ermöglicht. Diese Funktion ist besonders relevant angesichts der wachsenden Nachfrage nach schnelleren und kostengünstigeren Transaktionsmethoden im Kryptowährungsbereich.

Allerdings stellt die komplexe Natur der RGB-Technologie Herausforderungen hinsichtlich der Zugänglichkeit und dem Verständnis für den Benutzer dar. Die Architektur des Protokolls und die verwendeten fortschrittlichen kryptografischen Methoden können schwierig zu verstehen und zu implementieren sein, insbesondere für diejenigen, die neu in der Blockchain-Technologie sind. Diese Komplexität könnte eine breitere Akzeptanz und Benutzereinbindung behindern.

Während RGB den Datenschutz verbessert, indem es Vertragsdaten von der Blockchain fernhält, wirft dieser Aspekt auch Fragen zur Datenüberprüfbarkeit und der Fähigkeit zur Prüfung von Transaktionen auf, die für bestimmte Anwendungen und die Einhaltung gesetzlicher Vorschriften von entscheidender Bedeutung sind.

Das neueste Update von RGB, Version 0.10, positioniert es als bemerkenswerten Konkurrenten in der sich entwickelnden Landschaft der Blockchain-Technologien, insbesondere im Vergleich zu neuen Protokollen wie Taproot Assets und BitVM. Im Gegensatz zu Taproot Assets, das sich auf die Nutzung des UTXO-Modells von Taproot für die Token-Ausgabe im Bitcoin-Netzwerk konzentriert, zeichnet sich RGB durch seine erweiterten Datenschutzfunktionen und die Datenverarbeitung außerhalb der Kette aus und bietet einen eindeutigen Ansatz für die Funktionalität intelligenter Verträge und die Token-Verwaltung.

Während BitVM ein neuartiges Konzept für dezentrales Computing auf Bitcoin einführt, zeigen die Fortschritte von RGB in Version 0.10 bei der clientseitigen Validierung, Vertragsschnittstellen und einem strengen Typsystem seinen einzigartigen Ansatz zur Verbesserung der Skalierbarkeit und Benutzerinteraktion innerhalb des Bitcoin-Ökosystems. Diese Verbesserungen unterstreichen die Fähigkeit von RGB, Skalierbarkeits- und Effizienzherausforderungen zu bewältigen, Bereiche, in denen traditionelle und neue Protokolle häufig auf Einschränkungen stoßen.

Die Vereinfachung von Abhängigkeiten und Integrationsprozessen in der neuesten Version von RGB deutet darüber hinaus auf einen Fokus auf Benutzererfahrung und Systemstabilität hin und unterscheidet es von der Konkurrenz. Dies positioniert RGB nicht nur als robuste Plattform für datenschutzorientierte und skalierbare Smart Contracts und Token-Ausgabe, sondern auch als zukunftsweisende Lösung im breiteren Blockchain-Bereich.

Zusammenfassend lässt sich sagen, dass das RGB-Protokoll eine bedeutende technologische Entwicklung innerhalb des Bitcoin-Netzwerks darstellt und erweiterte Funktionen für intelligente Verträge und die Ausgabe von Token bietet. Es befasst sich mit wichtigen Fragen der Skalierbarkeit und des Datenschutzes, steht jedoch vor Herausforderungen hinsichtlich der Komplexität und potenziellen Überprüfbarkeit. Die laufende Entwicklung und zukünftige Iterationen des Protokolls werden sich wahrscheinlich darauf konzentrieren, diese erweiterten Funktionen mit der Benutzerzugänglichkeit und regulatorischen Überlegungen in Einklang zu bringen.

Semesterreferenzen: 

1. Turing abgeschlossen: In der Praxis kann das System jedes Rechenproblem mit ausreichend Zeit und Speicher ausführen. Die meisten modernen Programmiersprachen sind Turing-vollständig, was bedeutet, dass sie theoretisch in der Lage sind, jedes Rechenproblem zu lösen.
   
2. Schema: Ein Vertragsschema dient als eigentlicher Code für einen Smart Contract, der von den Emittenten als „Vertragsvorlage“ verwendet werden kann, ohne dass von externen Quellen bereitgestellter benutzerdefinierter Code codiert oder geprüft werden muss. Das RGB-Schema ist kein Skript, sondern eine Datenstruktur.
   
3. Diskrete Protokollverträge (DLCs) im Kontext staatlicher Kanäle sind spezialisierte Smart Contracts, die hauptsächlich im Bitcoin-Netzwerk verwendet werden. Sie ermöglichen die private und effiziente Ausführung komplexer Finanzvereinbarungen auf der Grundlage externer Ereignisse, wie z. B. Vermögenspreisen. DLCs ​​arbeiten außerhalb der Kette und wahren die Vertraulichkeit von Vertragsdetails und Teilnehmeridentitäten. Sie nutzen externe Datenquellen oder Orakel zur Vertragslösung. Bei der Integration mit staatlichen Kanälen verbessern DLCs die Skalierbarkeit, indem sie mehrere Transaktionsabwicklungen ermöglichen, ohne die Blockchain zu überlasten, was sie ideal für private, effiziente Finanztransaktionen macht, die von realen Ergebnissen abhängen.
   
4. Sturm – Treuhandbasierte, vertrauenswürdige Speicherung mit ZK-Proofs. Storm kombiniert treuhänderisch vertrauenswürdige Speicherung mit wissensfreien Beweisen, um sichere und private Transaktionen zu ermöglichen. In diesem System werden Daten oder Vermögenswerte treuhänderisch gespeichert und nur dann freigegeben, wenn bestimmte Bedingungen erfüllt sind. Dadurch wird eine vertrauenswürdige Umgebung gewährleistet, in der keine zentrale Autorität erforderlich ist. Die Integration von zk-proofs ermöglicht die Verifizierung dieser Transaktionen unter Wahrung höchster Vertraulichkeit, da sie die Validierung von Daten ermöglichen, ohne zugrunde liegende Details preiszugeben.
   
5. Prometheus – Schlichtungsbasiertes, vertrauensloses verteiltes Rechnen. Prometheus stellt einen Ansatz für dezentrales Computing dar, der Schlichtungsmechanismen zur Streitbeilegung, vertrauenslose Interaktionen für sichere und dezentrale Abläufe und die Effizienz staatlicher Kanäle für das Off-Chain-Computing-Management kombiniert.
   
6. A Reduzierter Befehlssatz Computer ist eine Art Mikroprozessorarchitektur, die einen kleinen, hochoptimierten Befehlssatz anstelle des hochspezialisierten Befehlssatzes verwendet, der normalerweise in anderen Architekturen zu finden ist.