Ein Empfänger erhält ein Consignment mit der relevanten Historie, prüft es gegen Genesis und Schema und kontrolliert, ob die zugehörigen State Transitions an gültige Bitcoin-Transaktionen gebunden sind.
RGB Protocol baut auf Client-Side Validation und single-use seals auf. Bitcoin repliziert die detaillierten Vertragsdaten nicht; die Teilnehmer bewahren und prüfen sie selbst, während Bitcoin-UTXOs und Transaktionen den öffentlichen Nachweis für Seal-Schließung und Double-Spend-Schutz liefern. [6]
Ein Vertrag beginnt mit einer Genesis-Operation und verändert sich danach durch State Transitions in einem gerichteten azyklischen Graphen. Transitionen verbrauchen vorherigen owned state, erzeugen neuen Zustand und binden ihre Commitments über einen Anchor an eine Bitcoin witness transaction. [3]
Ein Schema ist eine deklarative Vorlage der Geschäftslogik: Es legt Datentypen, eigenen und globalen Zustand, zulässige Operationen und Validierungsregeln fest. Genesis erzeugt daraus eine konkrete Instanz, etwa Ausgabe und Anfangszuteilungen eines fungiblen oder einzigartigen Assets. [2]
Bei einer Übertragung gibt der Sender dem Empfänger ein Consignment mit Genesis, Schema, relevanter Historie und Beweisen. Vor der Annahme prüft der Empfänger lokal die ganze Kette, Anchors und Bitcoin-Verknüpfungen; ein Ticker oder eine Wallet-Anzeige allein beweist keine Gültigkeit. [4]
Die öffentliche Release-Übersicht kennzeichnet v0.10 als stabil und die Reihe v0.11 als Vorabversion; Betas warnen zudem vor Änderungen am RGB-Konsens, nicht am Bitcoin-Konsens. Produktiver Einsatz verlangt daher eine exakt kompatible Version des gesamten Client-Stacks statt einer allgemeinen RGB-Support-Angabe. [5]
Die Bezeichnung RGB ist ohne Kontext mehrdeutig. Die aktuelle Dokumentation trennt das hier beschriebene RGB Protocol on Bitcoin ausdrücklich vom unfertigen, abweichenden Entwurf v0.12 und von RGB++ auf Nervos/CKB; dieselbe Abkürzung bedeutet weder gleiche Architektur noch Interoperabilität. [1]
Privatsphäre und Skalierung haben Kosten bei der Datenverfügbarkeit. Bitcoin kann ein verlorenes Consignment nicht aus dem Commitment rekonstruieren; der Empfänger braucht die vollständige relevante Historie, und der Eigentümer muss Stash und weitere Client-Daten sicher sichern. [4]
Für eine RGB-Behauptung sind die genauen Protokoll- und Bibliotheksversionen, Schema und Genesis, Contract ID, Commitment-Typ, unterstützte Schicht, Vollständigkeit des Consignments und Auditstatus zu prüfen. On Bitcoin allein belegt weder Interoperabilität noch Sicherheit oder Wiederherstellbarkeit. [5]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. Auf diesen Eintrag verweisen außerdem Taproot Assets, Runes.
01Liegen RGB-Verträge direkt in der Bitcoin-Blockchain?+
Nein. Bitcoin trägt die Transaktionen und kryptografischen Commitments für Reihenfolge und Seal-Schließung; detaillierter Zustand und Validierungshistorie werden clientseitig übertragen und gespeichert.
02Sind alle als RGB bezeichneten Token untereinander kompatibel?+
Nicht automatisch. Eine Wallet muss die konkrete Protokollversion, das Schema, Interface und Commitment-Verfahren unterstützen. Vor der Annahme sind Contract ID und vollständiges Consignment zu prüfen, nicht nur Name oder Ticker.