Odbiorca otrzymuje consignment z właściwą historią, sprawdza go względem genesis i schema oraz weryfikuje, czy odpowiednie state transitions są powiązane z ważnymi transakcjami Bitcoin.
RGB Protocol opiera się na Client-Side Validation i single-use seals. Bitcoin nie replikuje szczegółowych danych kontraktu; uczestnicy przechowują i sprawdzają je sami, a Bitcoin UTXO i transakcje dają publiczny dowód zamknięcia pieczęci oraz ochronę przed double-spend. [6]
Kontrakt rozpoczyna operacja Genesis, a następnie zmieniają go state transitions w skierowanym grafie acyklicznym. Przejścia zużywają poprzedni owned state, tworzą nowy stan i przez anchor wiążą commitments z Bitcoin witness transaction. [3]
Schema jest deklaratywnym szablonem logiki biznesowej: określa typy danych, stan własny i globalny, dozwolone operacje oraz reguły walidacji. Genesis tworzy konkretną instancję schema, na przykład emisję i początkowe alokacje zamiennego albo unikatowego aktywa. [2]
Przy transferze nadawca przekazuje odbiorcy consignment z genesis, schema, właściwą historią i dowodami. Przed przyjęciem odbiorca lokalnie weryfikuje cały łańcuch, anchors i powiązania z Bitcoin; sam ticker lub wskazanie w wallet nie dowodzi ważności. [4]
Publiczny wykaz wydań oznacza v0.10 jako stabilne, a serię v0.11 jako wstępną; wersje beta ostrzegają też o zmianach konsensusu RGB, a nie Bitcoin. Użycie produkcyjne wymaga więc dokładnej i zgodnej wersji całego stosu klienckiego, nie ogólnej deklaracji obsługi RGB. [5]
Nazwa RGB bez kontekstu jest niejednoznaczna. Obecna dokumentacja wyraźnie oddziela opisany RGB Protocol on Bitcoin od niedokończonej, odmiennej propozycji v0.12 oraz RGB++ na Nervos/CKB; ten sam skrót nie oznacza wspólnej architektury ani interoperacyjności. [1]
Prywatność i skalowanie mają koszt dostępności danych. Bitcoin nie odtworzy utraconego consignment z commitment; odbiorca musi zdobyć pełną właściwą historię, a właściciel bezpiecznie archiwizować stash i pozostałe dane klienta. [4]
Oceniając twierdzenie o RGB, trzeba sprawdzić dokładne wersje protokołu i bibliotek, schema i genesis, contract ID, typ commitment, obsługiwaną warstwę, kompletność consignment oraz stan audytów. Sam zwrot on Bitcoin nie dowodzi interoperacyjności, bezpieczeństwa ani odzyskiwalności. [5]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. Do tego hasła prowadzą również odsyłacze z Taproot Assets, Runes.
01Czy kontrakty RGB są zapisane bezpośrednio w blockchainie Bitcoin?+
Nie. Bitcoin zawiera transakcje i kryptograficzne commitments potrzebne do porządku i zamknięcia pieczęci; szczegółowy stan i historię walidacji przesyła się i przechowuje po stronie klienta.
02Czy każdy token określany jako RGB jest wzajemnie kompatybilny?+
Nie automatycznie. Wallet musi obsługiwać konkretną wersję protokołu, schema, interface i procedurę commitment. Przed przyjęciem należy sprawdzić contract ID i pełny consignment, a nie tylko nazwę lub ticker.