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

TL;DR

• RGB fungiert als Layer 2/3-Lösung im Bitcoin- und Lightning-Netzwerk. Das clientseitige Validierungsparadigma beherbergt alle Smart-Contract-Daten außerhalb von Bitcoin-Transaktionen. Dieses Design stellt den Betrieb des Systems auf dem Lightning-Netzwerk sicher und macht Änderungen an LN-Protokollen überflüssig.

• RGB-Smart Contracts sind auf Skalierbarkeit und Vertraulichkeit ausgelegt. Das System unterstützt privates und gemeinsames Eigentum, abstrahiert und trennt Belange und stellt eine post-Blockchain, Turing-vollständige Form des vertrauenslosen verteilten Rechnens dar, ohne dass neue Token eingeführt werden müssen.

• RGB-Verträge sind in separaten Segmenten, sogenannten „Shards“, organisiert, die jeweils über eine eigene Historie und eigene Daten verfügen. Dies verbessert die Skalierbarkeit und verhindert die Vermischung von Historien aus verschiedenen Verträgen. Sie interagieren über das Bifrost-Protokoll im Lightning Network und ermöglichen koordinierte Änderungen zwischen mehreren Parteien, ähnlich wie DEXes, die im Lightning Network betrieben werden.

• RGB verwendet zur Sicherheit Einmalsiegel, die über Bitcoin UTXOs definiert werden. Jede Partei, die über einen Smart Contract-Statusverlauf verfügt, kann dessen Einzigartigkeit überprüfen und das Bitcoin-Skript nutzen, um Eigentums- und Zugriffsrechte zu definieren.

• In RGB sind Eigentum und Validierung getrennte Einheiten. Das Eigentum wird vom Bitcoin-Skript verwaltet, einem nicht Turing-vollständigen System. Die Validierungsregeln werden hingegen vom RGB-Schema unter Verwendung des Turing-vollständigen Simplicity/Contractum/Rust-Skripts vorgegeben.

• Jeder RGB-Smart-Vertrag ist mit einem eindeutigen Status verknüpft, der durch Einmalsiegel bestimmt wird. Die Siegel und der Status folgen bestimmten Regeln und Validierungen, die vom Ersteller des Vertrags festgelegt und von einem „Schema“ gesteuert werden. Dieses Schema fungiert als Regelsatz zur Überprüfung der Vertragsdaten auf der Clientseite und ermöglicht ein hohes Maß an Protokollskalierbarkeit und Datenschutz.

• Das Design von RGB weist eine hohe Interoperabilität mit vorhandenen Bitcoin- und Lightning Network-Technologien auf und ermöglicht eine 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 zur Erreichung dieses Ergebnisses.

• RGB nutzt verschiedene fortschrittliche Technologien, darunter AluVM für deterministische portable Rechenaufgaben, PRISM für teilweise replizierte Infinite-State-Machine-Rechnungen und Storm für Treuhand-basierte, vertrauenslose 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 der Integrationsprozesse ein, rationalisiert Abläufe und minimiert Abhängigkeiten. Die aktualisierte Version verfügt über eine einheitlichere Bibliotheks-API und ein einheitlicheres Befehlszeilentool, was sie zugänglicher und benutzerfreundlicher macht.

Kurzbeschreibung

RGB ist ein Protokoll, das für die Ausgabe von Token im Bitcoin-Netzwerk mit verbesserter Privatsphäre und Kompatibilität mit dem Lightning Network entwickelt wurde. Es basiert auf dem Konzept der „Colored Coins“, wie sie im OmniLayer-Protokoll verwendet werden, wo Metadaten in Bitcoin-Transaktionen eine Token-Übertragung anzeigen. Beispielsweise funktionieren USDT-Transaktionen auf OmniLayer wie Bitcoin-Transaktionen, die mit zusätzlichen Daten ergänzt werden, die die USDT-Token-Bewegungen detailliert beschreiben. Diese Methoden unterliegen jedoch Einschränkungen wie Datengrößenbeschränkungen in OP_RETURN-Ausgaben, intensives Blockchain-Scanning und eingeschränkte Privatsphäre aufgrund der On-Chain-Sichtbarkeit.

RGB behebt diese Probleme, indem es die meisten Validierungsprozesse aus der Bitcoin-Blockchain heraus verlagert. Es übernimmt die clientseitige Validierung und verwendet Einmalsiegel, um Token mit Bitcoin-UTXOs zu verbinden, wobei die Privatsphäre der Benutzer gewahrt bleibt. Token werden übertragen, indem man sich innerhalb einer Bitcoin-Transaktion auf eine Nachricht mit RGB-Zahlungsinformationen festlegt, sodass die Token von einer UTXO zur anderen verschoben werden können, ohne eine Spur im Bitcoin-Transaktionsdiagramm zu hinterlassen. Dies erhöht die Privatsphäre erheblich, da RGB-Transaktionen Token diskret „teleportieren“, wobei RGB-spezifische Daten über private Off-Chain-Kanäle übertragen werden.

Um den Besitz sicherzustellen und Inflation zu verhindern, müssen Empfänger außerdem den gesamten Transaktionsverlauf der erhaltenen Token validieren. RGB ermöglicht zukünftige Upgrades ohne die Notwendigkeit von Hard Forks und stellt sicher, dass Miner den Vermögensfluss nicht verfolgen können, was eine höhere Widerstandsfähigkeit gegen Zensur bietet. Im Gegensatz zu herkömmlichen Blockchain-Strukturen funktioniert RGB ohne Blöcke oder Ketten und positioniert sich als dezentrales Protokoll ohne Blöcke, das hohe Vertraulichkeit, Sicherheit und Skalierbarkeit verspricht.

Einführung und Vision

Einzeiler: Ein vom Client validiertes Status- und Smart-Contract-System, das auf Ebene 2/3 im Bitcoin- und Lightning-Netzwerk betrieben wird.

Weitere Details:

RGB ist ein skalierbares und vertrauliches Smart-Contract-System für Bitcoin und Lightning Network. RGB-Smart-Contracts arbeiten mit einem clientseitigen Validierungsparadigma und speichern alle Smart-Contract-Daten außerhalb von Bitcoin-Transaktionen, d. h. den Bitcoin-Blockchain- oder Lightning-Kanalstatus. Dadurch kann das System auf dem Lightning Network ohne Änderungen an den LN-Protokollen ausgeführt werden und bietet außerdem eine Grundlage für ein hohes Maß an Protokollskalierbarkeit und Datenschutz.

Smart Contracts verkörpern die Prinzipien des privaten und gemeinsamen Eigentums, der Abstraktion und der Trennung von Belangen. Sie stellen eine „post-Blockchain“, Turing-vollständige Form des vertrauenslosen verteilten Rechnens dar, die keine Einführung von Tokens erfordert.

RGB-Verträge arbeiten in separaten Segmenten, die „Shards“ genannt werden. Jeder Shard hat seine eigene Historie und Daten, was bedeutet, dass verschiedene Verträge ihre Historien nicht vermischen. Diese Methode verbessert die Skalierbarkeit. Der Begriff „Shard“ wird verwendet, um zu zeigen, dass RGB ähnliche Ziele erreicht wie das Shard-Konzept von Ethereum.

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 Network zu funktionieren.

Technologie & Architektur

Allgemeiner Überblick über RGB-Betrieb und Einwegdichtungen

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

Als Sicherheitsmechanismus verwendet RGB Einmalsiegel, die über Bitcoin-UTXOs definiert werden und es jeder Partei mit Smart-Contract-Statusverlauf ermöglichen, dessen Einzigartigkeit zu überprüfen. Im Wesentlichen nutzt RGB Bitcoin-Skripte für sein Sicherheitsmodell und definiert Eigentums- und Zugriffsrechte.

Abbildung 2. RGB-Arbeitsprinzip auf hoher Ebene. Quelle: „Driving Mass Adoption of Crypto: Wie das RGB-Protokoll die Zukunft von Bitcoin erhellt“ von Waterdrip Capital.

Jeder RGB-Smart-Contract wird durch einen Genesis-Status definiert, der vom Smart-Contract-Herausgeber (oder einfach ausgedrückt: Emittent) erstellt wird, sowie durch einen gerichteten azyklischen Graphen (DAG) von Statusübergängen, die als vom Client validierte Daten verwaltet werden.

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

Wir können es wie folgt zusammenfassen: Jede Transaktion hat eine UTXO, und der Besitz dieser UTXO gewährt dem Besitzer das Recht, den Status zu besitzen. Der Besitz bestimmt, wer den Blockchain-Status ändern und die UTXO „ausgeben“ kann. Die Person, die den Status besitzt, wird als Partei bezeichnet, deren Status der Eigentümer ist. Die Partei hat die Befugnis, den relevanten Abschnitt des Smart Contract-Status zu ändern, indem sie einen neuen Statusübergang generiert und ihn in einer Transaktion bestätigt, wobei die Ausgabe verwendet wird, die den vorherigen Status enthält. Der Prozess bedeutet das Schließen eines Siegels über dem Statusübergang, und ein Paar, das aus der Ausgabetransaktion und den entsprechenden Extra-Transaktionsdaten zum Statusübergang besteht, wird als Zeuge bezeichnet (siehe Abbildung oben).

Eigentum & Zugang: Kerneigenschaften

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

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

Andererseits wird der Besitz durch ein Bitcoin-Skript auf der Ebene der Bitcoin-Blockchain kontrolliert, das nicht Turing-vollständig ist. Die Validierungsregeln werden dagegen durch das RGB-Schema geregelt, das Simplicity/Contractum-Skript verwendet, also Turing-vollständig ist.

RGB Schema

In RGB-Smart Contracts wird jedem Vertrag durch Einmalsiegel ein eindeutiger Status zugewiesen. Diese Siegel unterliegen zusammen mit dem Status bestimmten Regeln und Validierungen, die vom Ersteller des Vertrags zu Beginn festgelegt werden. Diese Konfiguration wird durch ein „Schema“ gesteuert, das als Regelsatz zur Validierung der Vertragsdaten auf der Clientseite fungiert. Das Schema kann komplexe Skripte enthalten, die integraler Bestandteil der Vertragslogik sind.

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

Clientseitige Validierung und Designprinzipien

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

1. Starke Eigentümerschaft: In RGB haben Smart Contracts einen oder mehrere klar definierte Eigentümer. Nur benannte Eigentümer haben die Befugnis, den Status des Vertrags zu ändern. Diese Verträge umreißen eindeutige Rechte oder Vorgänge, die entweder als öffentlich (für alle zugänglich) oder als Eigentum (auf den Eigentümer beschränkt) kategorisiert sind.

2. Vertraulichkeit: Informationen innerhalb des Vertrags werden vertraulich behandelt und sind nur den Teilnehmern, insbesondere den Eigentümern des Staates, 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 sicher, dass keine vertraulichen Informationen in öffentlichen Hauptbüchern gespeichert werden.

3. Trennung der Belange: RGB verfügt über ein modulares Design mit unterschiedlichen Schichten, denen jeweils eine bestimmte Aufgabe zugewiesen ist. Diese Schichten arbeiten unabhängig voneinander, sodass die unteren Schichten nicht mehr die Struktur der höheren Schichten kennen 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 erweiterter 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 bei gleichen Eingaben und dem vorherrschenden Zustand der zugrunde liegenden Blockchain oder des Lightning Network-Kanals durchgängig identische Ergebnisse. 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 wird auf AluVM ausgeführt, 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 vorhandenen Bitcoin- und Lightning Network-Technologien funktioniert. Es ist auch 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, erklärt das RGB-Team.

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

RGB-Ansatz: Deklarative vs. imperative Programmierung:

• Die meisten Blockchain-Plattformen, darunter auch Ethereum, verwenden Smart Contracts, die in einem imperativen Stil geschrieben sind. Bei diesem Ansatz fungiert der Vertrag als Programm, das die schrittweise Ausführung von Aufgaben explizit anweist und einem präzisen und detaillierten Rezept ähnelt.

• Diese imperativen Programme sind oft recht restriktiv und durch die Fähigkeiten der zugrunde liegenden Blockchain-Plattform begrenzt. Obwohl sie manchmal als Turing-vollständig bezeichnet werden, sind sie mit erheblichen Einschränkungen verbunden.

Deklarativer Charakter von RGB Smart Contracts:

• RGB hingegen verwendet keine imperative Programmierung. Stattdessen wird eine spezielle Form der funktionalen Programmierung verwendet, bei der Smart Contracts deklarativ definiert werden.

• Bei der deklarativen Programmierung beschreiben Sie nicht im Detail, wie etwas zu tun ist, sondern wie das Ergebnis aussehen soll. Das ist etwa so, als würden Sie skizzieren, wie eine Mahlzeit aussehen soll, statt eine Schritt-für-Schritt-Anleitung zum Kochen zu geben.

• Das „Schema“ in RGB ist eine deklarative Definition eines Smart Contracts. Es gibt die Regeln und Bedingungen des Vertrags an, jedoch nicht die genaue Abfolge der Vorgänge, um diese zu erreichen.

Paradigmenwechsel in der Programmierung:

• Der Übergang vom imperativen Stil von Ethereum zum deklarativen Stil von RGB in der Smart-Contract-Programmierung ähnelt dem Wechsel von der traditionellen imperativen Programmierung zur funktionalen oder deklarativen Programmierung in der allgemeinen Softwareentwicklung.

• Dieser Wandel erfordert eine andere Denkweise: Die Konzentration auf das „Was“ (die gewünschten Ergebnisse) und nicht auf das „Wie“ (die konkreten Schritte zum Erreichen dieser Ergebnisse).

Einfachheit

Der ursprüngliche Plan sah vor, Simplicity in RGB zu integrieren, und es wurde vom ersten Tag an versucht, die Kompatibilität sicherzustellen. Angesichts des schleppenden Fortschritts der Simplicity-Entwicklung und der Unsicherheit bezüglich des Veröffentlichungszeitplans wurde jedoch klar, dass es unpraktisch war, sich darauf zu verlassen. Die laufende RGB-Version, die derzeit vorbereitet wird, wirft Fragen bezüglich der Integration von Simplicity auf.

Da wir erkannten, dass es für Simplicity keinen verlässlichen Zeitplan gab, begannen wir mit der Prüfung von Alternativen (WASM, EVM (als Scherz), IELE usw.). Schließlich wurde klar, dass die Entwicklung einer proprietären virtuellen Maschine für RGB die einzige praktikable Option war, die die anfängliche Abhängigkeit von Simplicity ersetzte.

Aus diesem Grund haben wir uns entschieden, AluVM zu erstellen – eine rein funktionale, hochportable, auf Rust basierende virtuelle Maschine für clientseitig validierte Smart Contracts (RGB), Lightning Network, deterministisches verteiltes und Edge-Computing.

Prisma

PRISM steht für „partiell replizierte Infinite-State-Machine“-Computing.

Die RGB-Technologie definiert Regeln für die Entwicklung von Smart Contracts auf einer grundlegenden Ebene, dem sogenannten Schema. Sie beschränkt jedoch nicht alle zukünftigen Aktionen des Vertrags auf einen einzigen, übergreifenden Algorithmus. Stattdessen führt jeder Knoten im Netzwerk einzelne Vorgänge aus, und sowohl der Status des Vertrags als auch der Vertrag selbst bleiben gültig, solange diese Vorgänge den Regeln des Schemas entsprechen.

Darüber hinaus schränkt dieser Ansatz die historische Entwicklung des Vertrags nicht mit einem vorgegebenen Algorithmus ein. Ein Vertrag kann also 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 Vertragszustands und wenden Regeln lokal an. Dies bietet ein breiteres Spektrum an Möglichkeiten für die Vertragsentwicklung.

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

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

Genauere Unterschiede bestehen wie folgt:

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

AluVM

AluVM – (Algorithmic Logic Unit VM) ist eine rein funktionale RISC-virtuelle Maschine, die für deterministische portable Computeraufgaben entwickelt wurde.

AluVM zeichnet sich durch die Verwendung eines registerbasierten Systems aus, das den wahlfreien Speicherzugriff verhindert. Dieses Design verbessert die Eignung von AluVM für Anwendungen wie Smart Contracts, Remote Code Execution sowie Distributed und Edge Computing. Die Hauptstärken von AluVM liegen in seinem Determinismus, seiner Robustheit und seiner Fähigkeit zur formalen Codeanalyse.

Hauptmerkmale: Ausnahmelosigkeit, Portabilität, Sandboxing, Sicherheit, Erweiterbarkeit.

Die Instruction Set Architecture (ISA) von AluVM ist anpassbar 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 wahlfreie Speicherzugriff beschränkt ist, eignet sich die AluVM ISA hervorragend für Rechenaufgaben, darunter auch solche, die mit elliptischen Kurven zusammenhängen. Einzigartig ist, dass die Umgebung der VM die AluVM ISA erweitern kann, wodurch zusätzliche Funktionen wie das Laden von Daten in die Register der VM und die Unterstützung spezieller Anweisungen (z. B. SIMD) ermöglicht werden, die auf bestimmte Anwendungen zugeschnitten sind.

AluVM ist hauptsächlich für den Einsatz in verteilten Systemen vorgesehen, bei denen Konsistenz und Zuverlässigkeit über verschiedene Plattformen hinweg wichtiger sind als die Verarbeitungsgeschwindigkeit. Die Hauptanwendungen für AluVM mit den richtigen ISA-Erweiterungen umfassen Blockchain-Technologie, Berechnungen, die für den Konsens in Netzwerken entscheidend sind, Edge Computing, Multiparty Computing (das deterministisches maschinelles Lernen umfasst), Client-seitige 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.

Vertrag

Contractum unterscheidet sich von anderen Smart-Contract-Programmiersprachen, indem es die funktionalen Fähigkeiten von Haskell mit der Nähe zum Bare Metal von Rust verbindet. Es besetzt eine Nische, die für Smart Contracts bisher unzugänglich war:

Abbildung 11. Vergleich von Contractum, Simplicity und anderen Sprachen.Quelle: contractum.org

Contractum ist eine Programmiersprache zum Erstellen von RGB-Verträgen. Mit Contractum erstellte Verträge werden mithilfe einer Methode namens Client-Side-Validation überprüft. Dieser Ansatz fügt der Bitcoin-Blockchain keine Daten hinzu und kann mit einer Form der Sharding-Technologie verglichen werden, die durch die Verwendung von Zero-Knowledge-Beweisen noch weiter verbessert wird.

Darüber hinaus trennt die clientseitige Validierung die Entwicklung des Vertrags von den Blockchain-Transaktionen, sodass es unmöglich ist, diese Transaktionen mit herkömmlichen Blockchain-Analysemethoden zu verfolgen oder zu analysieren.

Abbildung 12. Vertragsmerkmale. Quelle: Contract.org

Um sich mit der Gestaltung von Contractums zu befassen, ist es wichtig, sich mit den Technologien vertraut zu machen, die in RGB-Smart Contracts zum Einsatz kommen:

Abbildung 13. Technologien, die von RGB-Smart-Contracts 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 erweiterte technische Verbesserungen implementiert, die die Fähigkeiten des Frameworks für die Entwicklung komplexer Anwendungen verbessern. Diese Updates 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 „Globaler Status“ ist eine wichtige Neuerung in RGB v0.10, die es jedem Vertrag ermöglicht, einen allgemein zugänglichen Status beizubehalten. Dieser Status ist nicht nur für die virtuelle RGB-Maschine zugänglich, sondern auch für externe Clients wie Wallets und andere Anwendungen.

Der Nutzen dieses globalen Status ist entscheidend für die Erstellung anspruchsvoller Anwendungen auf der RGB-Plattform, insbesondere solcher, die eine komplexe Statusverwaltung erfordern, wie synthetische Assets und algorithmische Stablecoins. Er ermöglicht eine dynamischere Interaktion mit dem Status des Vertrags 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 wesentlicher Unterschied des RGB-Ansatzes ist die nicht obligatorische Standardisierung dieser Schnittstellen und ihre inhärente Verpackung mit Verträgen, wodurch die Notwendigkeit einer separaten Verteilung entfällt. Dies erleichtert semantisch bewusste 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.

Striktes Typsystem

Das neue Kodierungsformat in RGB v0.10 verwendet ein System „strenger Typen“. Dieses System ist ein neuartiger funktionaler Datentypansatz, der für die effiziente Darstellung und Introspektion von Vertragszuständen innerhalb des RGB-Frameworks entwickelt wurde.

Das strikte Typsystem gewährleistet die Einhaltung der Datengrößen zur Kompilierungszeit, was insbesondere für den Betrieb auf Geräten mit beschränkten Ressourcen, wie etwa einfachen Hardware-Wallets mit begrenztem Speicher, von Vorteil ist.

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

Smart Contracts auf Rust-Basis

RGB-Smart Contracts können jetzt in Rust erstellt werden, wobei die Funktionen der Sprache hinsichtlich 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 Zustandsüberwachung

Smart Contracts in RGB v0.10 können ihren eigenen Status innerhalb des von der virtuellen RGB-Maschine ausgeführten Validierungscodes prüfen.

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

URL-basiertes Rechnungsformat

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

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

WASM (WebAssembly)-Unterstützung

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

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

Taproot-Deskriptoren und benutzerdefinierte Ableitung

RGB v0.10 verwendet taproot-basierte OP_RETURN-Verpflichtungen (als Tapret bezeichnet), was eine Unterstützung auf Deskriptorebene für Wallets erforderlich macht, 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 aus Grin-Projekten stammte.

Diese Verringerung 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 den Bedarf an mehreren API-Aufrufen und komplexer sprachübergreifender Datenstrukturkodierung reduziert.

RGB-Vertragszustände werden jetzt als JSON-Objekte dargestellt, was eine einfache Serialisierung zwischen verschiedenen Programmiersprachen ermöglicht.

Verbesserungen der Benutzererfahrung

Die neue Version von RGB vereinfacht das Benutzererlebnis, indem zuvor getrennte Komponenten in einer einheitlichen Bibliotheks-API und einem Befehlszeilentool konsolidiert werden.

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 Einstiegshürde für Benutzer und Wallet-Anwendungen gesenkt wird.

In diesem Abschnitt wird insbesondere Waterdrip Capital dafür gedankt, dass sie in ihrem Beitrag mit dem Titel „Die Massenakzeptanz von Kryptowährungen vorantreiben: Wie das RGB-Protokoll die Zukunft von Bitcoin beleuchtet“ die neuesten Funktionen ins Rampenlicht gerückt haben.

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 zum Starten 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 das Angebot und den Bestand eines Vermögenswerts in Bitcoin-Transaktionsdaten zu speichern.

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

Taproot Assets verwendet eine Methode analog zum Ordinals-Konzept, bei der BRC-20-Token Versorgungsinformationen in den Metadaten aufgezählter Satoshis speichern. Umgekehrt bettet Taproot Assets diese Informationen in die Taproot-Ausgabe einer Bitcoin-Transaktion ein und verwendet dabei einen sogenannten „dünn besetzten Merkle-Baum“. Im Wesentlichen integriert Taproot Assets einen Merkle-Baum in die Bitcoin-Transaktion, der als Nachweis für den Kontostand eines bestimmten Benutzers und die gesamte Tokenversorgung dient. Dieser Baum wiederum spiegelt Daten aus dem „Universum“ wider – einem Repository, das den vollständigen Vermögensverlauf 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 zum Nachweis der Bilanz: Off-Chain-Daten aus dem Universum oder den im UTXO eingebetteten spärlichen Merkle-Baum.

Betriebsmechanismus

1. Der Token-Ersteller führt eine P2TR-Transaktion (Pay to Taproot) mithilfe des Taproot Assets-Protokolls aus.

2. Informationen über den Vermögenswert werden in Form eines Merkle-Baums im UTXO dieser Transaktion (effektiv im Genesis-Block) gespeichert.

3. Um das Token zu übertragen, ändert der Besitzer des Taproot-Schlüssels die Kontostandsinformationen im Merkle-Baum und stellt so sicher, dass das Gesamtvermögensangebot 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 Übertragungen zu verarbeiten und anschließend den aktualisierten Saldenstand zu veröffentlichen.

Vorteile von Taproot Assets

• Ein wesentlicher Vorteil von Taproot Assets ist die vollständige Kompatibilität mit dem Lightning Network, was die Skalierbarkeitsmöglichkeiten verbessert und die Transaktionskosten senkt.

• Taproot Assets erstellt eine eigene Ebene für die Aufzeichnung von Vorgängen mit benutzerdefinierten Token. Obwohl es in erster Linie auf Off-Chain-Daten basiert, macht es den Stand der Guthaben im Hauptnetzwerk öffentlich.

• Dieser Ansatz ist im Vergleich zu BRC-20 flexibler, skalierbarer und umfassender, stellt für unerfahrene Benutzer jedoch auch eine größere Komplexität dar.

BitVM

BitVM ist ein hochmodernes Projekt, das darauf abzielt, Bitcoin in eine vollständig dezentralisierte Computerplattform zu verwandeln. Das am 9. Oktober 2023 vorgestellte BitVM-Whitepaper stellt eine Technologie vor, die sich derzeit in der Testphase befindet und weiterentwickelt werden muss, um ihr volles Potenzial auszuschöpfen.

Kernfunktionalität und Konzept von BitVM

Im Kern verwendet BitVM das Konzept der Optimistic Rollups, um die Berechnungen für Smart Contracts aus dem Netzwerk auszulagern und anschließend eine On-Chain-Verifizierung auf der Grundlage von „Betrugsnachweisen“ durchzuführen. Theoretisch sollen Datenaustausch und Berechnungen direkt zwischen den Parteien erfolgen, sobald Smart-Contract-Informationen in einer Taproot-Transaktion (als Binärcode) aufgezeichnet sind. Dieser Ansatz soll die Überlastung der Blockchain reduzieren. Wenn der Beweiser (die Partei, die den Beweis erbringt, d. h. der Vertragsinhaber) jedoch fehlerhafte Daten überträgt, kann ein Prüfer eine On-Chain-Prüfung einleiten. Dieser Prozess bildet die Grundlage des Betrugsnachweiskonzepts.

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 von Natur aus nicht unterstützt. Um dieses Problem zu lösen, verwendet BitVM einen Merkle-Baum, um ein logisches NAND-Gatterschema zu erstellen, das dann in einer Taproot-Transaktion aufgezeichnet wird. Im Wesentlichen fungiert der Merkle-Baum in den Transaktionsdaten als NAND-Schema, wobei 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 „Zweiges“ zur Eingabe für den nächsten wird. Zwischen den Smart-Contract-Parteien finden ständige Transaktionsaustausche zur Wertüberprüfung statt. Wenn sich die Berechnungsversion des Prüfers als falsch herausstellt, erhält der Prüfer seine in der Taproot-Transaktion gesperrten Vermögenswerte.

Abbildung 17. Schematische Darstellung von NAND. Quelle: „The Big Deal with BitVM: Beliebige Berechnungen jetzt auf Bitcoin ohne Fork möglich“ von Bitcoin Magazine

Erstellen 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 und welche Auswirkungen dies auf Berechnungen hat, finden Sie in der technischen Dokumentation.

Dieser Ansatz ermöglicht eine präzise, ​​schrittweise Überprüfung der Smart-Contract-Berechnungen und entspricht den Grundsätzen der Blockchain-Integrität und -Sicherheit.

Herausforderungen beim Smart Contract Bilateralismus

Bei BitVM besteht weiterhin ein erhebliches Problem aufgrund der bilateralen Struktur von Smart Contracts, die den direkten Datenaustausch ausschließlich zwischen dem Prüfer und dem Beweiser ermöglichen und die Beteiligung Dritter ausschließen. Diese Einschränkung behindert die Entwicklung von dApps und erfordert zusätzliche Lösungen für Vertragskonstruktionen mit mehreren Parteien.

Darüber hinaus bedeuten die komplexen und einfachen Eigenschaften von BitVM, dass die Entwicklung funktionaler Produkte auf dieser Grundlage mehrere Jahre dauern kann. Um diese grundlegende Technologie in praktische Anwendungen umzusetzen, sind erhebliche Entwicklungs- und Innovationsarbeit unabdingbar.

Für einen detaillierteren Einblick lesen Sie bitte das BitVM-Whitepaper – https://bitvm.org/bitvm.pdf 

Abschluss

Das RGB-Protokoll ist eine technische Entwicklung im Bitcoin-Ökosystem und führt Funktionen für die Implementierung von Smart Contracts und die Ausgabe von Token ein, die direkt an das Bitcoin-Netzwerk gebunden sind. Dies wird durch eine Kombination aus clientseitiger Validierung und Verwendung von Einwegsiegeln erreicht, die Token mit den UTXOs von Bitcoin verknüpfen und gleichzeitig die Transaktionsvertraulichkeit wahren.

Einer der wichtigsten technischen Vorteile von RGB ist sein Ansatz hinsichtlich Skalierbarkeit und Datenschutz. Indem der Großteil der Validierungsarbeit von der Bitcoin-Blockchain abgezogen und kryptografische Methoden zur Transaktionsüberprüfung eingesetzt werden, reduziert RGB effektiv die Datenlast der Blockchain. Dieser Ansatz trägt dazu bei, die Effizienz des Netzwerks aufrechtzuerhalten, insbesondere bei steigenden Transaktionsvolumina.

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

Die Komplexität der RGB-Technologie stellt jedoch eine Herausforderung hinsichtlich der Zugänglichkeit und des Verständnisses für den Benutzer dar. Die Architektur des Protokolls und die eingesetzten fortgeschrittenen kryptografischen Methoden können schwierig zu verstehen und umzusetzen sein, insbesondere für Neulinge in der Blockchain-Technologie. Diese Komplexität könnte eine breitere Akzeptanz und Benutzereinbindung behindern.

Während RGB den Datenschutz verbessert, indem Vertragsdaten nicht in die Blockchain einfließen, wirft dieser Aspekt auch Fragen zur Verifizierbarkeit der Daten und der Möglichkeit zur Transaktionsüberprüfung 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 einen bemerkenswerten Konkurrenten in der sich entwickelnden Landschaft der Blockchain-Technologien, insbesondere gegenüber 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 Verarbeitung von Daten außerhalb der Kette aus und bietet einen einzigartigen Ansatz für Smart-Contract-Funktionalität und Token-Management.

Ebenso führt BitVM ein neuartiges Konzept für dezentrales Computing auf Bitcoin ein, während die Fortschritte von RGB in Version 0.10 bei clientseitiger Validierung, Vertragsschnittstellen und einem strikten Typsystem seinen einzigartigen Ansatz zur Verbesserung der Skalierbarkeit und Benutzerinteraktion innerhalb des Bitcoin-Ökosystems demonstrieren. Diese Verbesserungen unterstreichen RGBs Kompetenz bei der Bewältigung von Skalierbarkeits- und Effizienzproblemen, Bereiche, in denen traditionelle und neue Protokolle oft an ihre Grenzen stoßen.

Die Vereinfachung von Abhängigkeiten und Integrationsprozessen in der neuesten Version von RGB weist zudem auf einen Fokus auf Benutzerfreundlichkeit und Systemstabilität hin und hebt das Unternehmen von der Konkurrenz ab. Dies positioniert RGB nicht nur als robuste Plattform für datenschutzorientierte und skalierbare Smart Contracts und Token-Ausgaben, 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 Smart Contracts und Token-Ausgabe bietet. Es befasst sich mit wichtigen Fragen der Skalierbarkeit und des Datenschutzes, steht jedoch vor Herausforderungen in Bezug auf Komplexität und potenzielle Ü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.

Begriffsverweise: 

1. Turing-vollständig: 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 Herausgebern als „Vertragsvorlage“ verwendet werden kann, ohne dass benutzerdefinierter Code aus externen Quellen codiert oder geprüft werden muss. Das RGB-Schema ist kein Skript, sondern eine Datenstruktur.

3. Discrete Log Contracts (DLCs) im Kontext von State Channels 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 Vermögenspreisen. DLCs arbeiten außerhalb der Blockchain und wahren die Vertraulichkeit von Vertragsdetails und Teilnehmeridentitäten. Sie nutzen externe Datenquellen oder Orakel zur Vertragsabwicklung. In Verbindung mit State Channels verbessern DLCs die Skalierbarkeit, indem sie die Abwicklung mehrerer Transaktionen ermöglichen, ohne die Blockchain zu überlasten. Damit sind sie ideal für private, effiziente Finanztransaktionen, die von realen Ergebnissen abhängen.

4. Storm – Treuhandbasierter, vertrauensloser Speicher mit zk-Proofs. Storm kombiniert treuhandbasierter, vertrauensloser Speicher mit Zero-Knowledge-Proofs, um sichere und private Transaktionen zu ermöglichen. In diesem System werden Daten oder Vermögenswerte treuhänderisch verwaltet und nur freigegeben, wenn bestimmte Bedingungen erfüllt sind. Dadurch wird eine vertrauenslose Umgebung gewährleistet, in der keine zentrale Autorität erforderlich ist. Die Integration von zk-Proofs ermöglicht die Überprüfung dieser Transaktionen unter Wahrung höchster Vertraulichkeit, da sie die Validierung von Daten ermöglichen, ohne zugrunde liegende Details preiszugeben.

5. Prometheus – schiedsgerichtsbasiertes, vertrauensloses verteiltes Rechnen. Prometheus stellt einen Ansatz für dezentrales Rechnen dar, der Schiedsgerichtsmechanismen zur Streitbeilegung, vertrauenslose Interaktionen für sichere und dezentrale Vorgänge und die Effizienz von Statuskanälen für das Off-Chain-Berechnungsmanagement kombiniert.

6. Ein Computer mit reduziertem Befehlssatz ist eine Art Mikroprozessorarchitektur, die einen kleinen, hochoptimierten Befehlssatz anstelle der hochspezialisierten Befehlssätze verwendet, die normalerweise in anderen Architekturen zu finden sind.

Der Beitrag „RGB stärkt die Skalierbarkeit und Datenschutzfunktionen von Bitcoin und Lightning Network“ erschien zuerst auf Metaverse Post.