Autor: Faust, maniak web3 i BTCEden.org Lianchuang
Wraz z popularnością wydawania RGB++ i powiązanych aktywów, dyskusja na temat zasad protokołów RGB i RGB++ stopniowo stała się tematem niepokojącym coraz więcej osób. Ale wszyscy zdają sobie sprawę, że aby zrozumieć RGB++, trzeba najpierw zrozumieć protokół RGB.
Oryginalny protokół RGB jest nieco niejasny pod względem struktury technicznej, a materiały referencyjne są rozproszone. Jak dotąd nie ma wielu systematycznych i łatwych do zrozumienia materiałów referencyjnych, chociaż geek web3 opublikował wcześniej dwa systematyczne artykuły dotyczące interpretacji RGB i RGB++ (Możesz sprawdzić historię naszego oficjalnego konta), ale według opinii członków społeczności powyższy artykuł jest za długi i zbyt obciążający mózg.
Aby umożliwić większej liczbie osób szybsze zrozumienie protokołów RGB i RGB++, autor tego artykułu pospieszył z dokończeniem krótkiej interpretacji RGB i RGB++ w języku narodowym podczas wydarzenia w Hongkongu. Można go przeczytać w kilka minut i ma nadzieję, że pomoże więcej zainteresowań społeczności Czytelnicy mogą lepiej i bardziej intuicyjnie zrozumieć RGB i RGB++.
Protokół RGB: użytkownicy muszą samodzielnie przeprowadzić weryfikację danych
Protokół RGB to specjalny protokół zasobów P2P i system obliczeniowy poza łańcuchem Bitcoin. Pod pewnymi względami jest podobny do kanału płatności: użytkownicy muszą sami uruchomić klienta i zweryfikować własne zachowanie związane z transferem (Zweryfikuj samodzielnie). Nawet jeśli jesteś tylko odbiorcą aktywów, musisz najpierw upewnić się, że w zestawieniu przeniesienia nadawcy aktywów nie ma błędów, zanim oświadczenie przeniesienia zacznie obowiązywać. Oczywiście różni się to całkowicie od tradycyjnej formy wysyłania i odbierania aktywów. Nazywamy to „transferem interaktywnym”.
Dlaczego tak jest? Powodem jest to, że w celu zapewnienia prywatności protokół RGB nie przyjmuje „protokołu konsensusu” w tradycyjnych blockchainach, takich jak Bitcoin i Ethereum (gdy dane przejdą przez protokół konsensusu, będą obserwowane przez prawie wszystkie węzły w sieci i prywatność nie jest gwarantowana). Jak zapewnić bezpieczeństwo zmian zasobów bez procesu konsensusu obejmującego dużą liczbę węzłów? Wykorzystywany jest tutaj pomysł zwany „Weryfikacją klienta” (weryfikuj samodzielnie). Musisz samodzielnie uruchomić klienta i osobiście zweryfikować zmiany aktywów, które Cię dotyczą.
Załóżmy, że istnieje użytkownik RGB o imieniu Bob, który zna Alicję i Alicja chce przekazać Bobowi 100 tokenów TESTOWYCH. Po tym, jak Alicja wygeneruje informacje o transferze „Alicja do Boba”, musi najpierw wysłać Bobowi informacje o transferze i dane dotyczące zasobu oraz pozwolić mu sprawdzić je osobiście, aby upewnić się, że są prawidłowe przed przystąpieniem do kolejnego procesu, a na koniec staje się prawidłowy transfer RGB. Dlatego protokół RGB umożliwia użytkownikom osobistą weryfikację ważności danych, zastępując tradycyjny algorytm konsensusu.
Nie ma jednak konsensusu, a dane otrzymywane i przechowywane przez różnych klientów RGB są niespójne. Każdy przechowuje wyłącznie dane dotyczące swoich zasobów lokalnie i nie zna statusu zasobów innych osób. Chroni to prywatność, tworząc jednocześnie „wyspę danych”. Jeśli ktoś twierdzi, że ma 1 milion tokenów TEST i chce przekazać Ci 100 000, jak możesz mu wierzyć?
W sieci RGB, jeśli ktoś chce przesłać Ci pieniądze, musi najpierw przedstawić dowód posiadania majątku, prześledzić historyczne źródło aktywów od pierwszego wydania do wielokrotnej zmiany właściciela i upewnić się, że Token, który ma zostać Ci przekazany jest w porządku. To tak, jakbyś odebrał. Gdy otrzymasz niezidentyfikowane banknoty, poprosisz drugą stronę o wyjaśnienie historycznego pochodzenia tych banknotów i tego, czy zostały wyprodukowane przez wyznaczonego emitenta, aby uniknąć fałszywej waluty.
Powyższe procesy zachodzą poza łańcuchem Bitcoin i same te procesy nie pozwalają na bezpośrednie powiązanie RGB z siecią Bitcoin. W związku z tym protokół RGB przyjmuje ideę zwaną „pieczęcią jednorazowego użytku”, aby powiązać zasoby RGB z UTXO w łańcuchu Bitcoin, dopóki Bitcoin UTXO nie zostanie podwojony, powiązane aktywa RGB nie zostaną podwojone, więc że sieć Bitcoin może zostać wykorzystana do zapobiegania „reorganizacji” zasobów RGB. Oczywiście wymaga to wystawienia zobowiązania w łańcuchu Bitcoin i użycia kodu operacji OP_Return.
Uporządkujmy przepływ pracy protokołu RGB:
1. Aktywa RGB są powiązane z Bitcoin UTXO, a Bob jest właścicielem niektórych Bitcoin UTXO. Alicja chce przekazać Bobowi 100 tokenów. Przed otrzymaniem zasobów Bob z wyprzedzeniem informuje Alicję, który Bitcoin UTXO Boba powinien zostać użyty do powiązania tych zasobów RGB.
Alice tworzy dane dotyczące transferu zasobów RGB „Alice to Bob” wraz z historycznymi źródłami tych zasobów i przekazuje je Bobowi do weryfikacji.
Gdy Bob lokalnie potwierdzi, że dane są prawidłowe, wysyła do Alice potwierdzenie, informując ją, że transakcja może zostać zrealizowana.
Alice buduje dane transferu RGB „Alice to Bob” w drzewie Merkle i publikuje korzeń Merkle w łańcuchu Bitcoin jako zobowiązanie. Zaangażowanie możemy po prostu zrozumieć jako skrót danych transferu.
Jeśli ktoś będzie chciał w przyszłości potwierdzić, że wspomniany powyżej przelew „Alice do Boba” faktycznie miał miejsce, musi zrobić dwie rzeczy: uzyskać pełną informację o przelewie „Alice do Boba” w ramach łańcucha Bitcoin, a następnie sprawdzić, czy tam jest jest odpowiednią transakcją w łańcuchu Bitcoin Commitment (hash danych transferu), to wszystko.
Bitcoin pełni tutaj rolę historycznego dziennika sieci RGB, ale w dzienniku zapisywany jest tylko skrót/korzeń Merkle danych transakcji, a nie same dane transakcji. Dzięki zastosowaniu weryfikacji klienta i jednorazowego plombowania, protokół RGB charakteryzuje się niezwykle wysokim poziomem bezpieczeństwa, ponieważ sieć RGB składa się z dynamicznych użytkowników-klientów w formie P2P, bez konsensusu, w każdej chwili możesz zmienić kontrahenta bez przeprowadzania Transakcji; żądania są wysyłane do ograniczonej liczby węzłów, więc sieć RGB jest wyjątkowo odporna na cenzurę. Ta forma organizacyjna jest bardziej odporna na cenzurę niż duże sieci publiczne, takie jak Ethereum.
Oczywiście koszt niezwykle wysokiego bezpieczeństwa, odporności na cenzurę i ochrony prywatności jest również oczywisty: użytkownicy muszą sami uruchomić klienta, aby zweryfikować dane, jeśli druga strona wysyła jakieś zasoby, które zmieniały właścicieli dziesiątki tysięcy razy i tak się stało długa historia, Ty też musisz wszystko weryfikować pod presją;
Ponadto każda transakcja wymaga wielokrotnej komunikacji między obiema stronami. Strona odbierająca musi najpierw zweryfikować źródło aktywów nadawcy, a następnie wysłać potwierdzenie w celu zatwierdzenia żądania przelewu nadawcy. Podczas tego procesu obie strony muszą przekazać co najmniej trzy wiadomości. Ten rodzaj „przelewu interaktywnego” jest poważnie niezgodny z „przelewem nieinteraktywnym”, do którego przywykła większość ludzi. Czy możesz sobie wyobrazić, że jeśli ktoś chce przesłać Ci pieniądze, musi przesłać Ci dane transakcji do sprawdzenia i pobrania Czy proces przelewu może zostać zrealizowany dopiero po otrzymaniu wiadomości?
Ponadto wspomnieliśmy, że w sieci RGB nie ma konsensusu, a każdy klient jest wyspą, co nie sprzyja migracji złożonych scenariuszy inteligentnych kontraktów w tradycyjnych łańcuchach publicznych do sieci RGB, ponieważ wszystkie protokoły Defi w Ethereum lub Solanie opierają się na A globalnie widoczna i przejrzysta dla danych księga rachunkowa. Jak zoptymalizować protokół RGB, poprawić doświadczenia użytkownika i rozwiązać powyższe problemy? Stało się to nieuniknionym problemem dla protokołu RGB.
RGB++: weryfikacja klienta staje się optymistycznym hostingiem
Protokół o nazwie RGB++ przedstawia nowy pomysł. Łączy protokół RGB z publicznymi łańcuchami obsługującymi UTXO, takimi jak CKB, Cardano i Fuel. Ten ostatni służy jako warstwa weryfikacyjna i warstwa przechowywania danych dla zasobów RGB oraz konwertuje pierwotnie wykonane dane przez użytkowników Praca weryfikacyjna jest przekazywana zewnętrznym platformom/sieciom publicznym, takim jak CKB. Jest to równoznaczne z zastąpieniem weryfikacji klienta „zewnętrzną zdecentralizowaną platformą do weryfikacji”, o ile ufasz sieciom publicznym, takim jak CKB, Cardano , Paliwo itp. Jeśli im nie ufasz, możesz także wrócić do tradycyjnego trybu RGB.
RGB++ i oryginalny protokół RGB są ze sobą teoretycznie kompatybilne.
Aby osiągnąć powyższe efekty należy zastosować ideę zwaną „wiązaniem izomorficznym”. Sieci publiczne, takie jak CKB i Cardano, mają własne rozszerzone UTXO, które jest bardziej programowalne niż UTXO w łańcuchu BTC. „Wiązanie izomorficzne” polega na użyciu rozszerzonego UTXO w łańcuchach CKB, Cardano i Fuel jako „kontenerach” dla danych zasobów RGB, zapisywaniu parametrów zasobów RGB w tych kontenerach i wyświetlaniu ich bezpośrednio w łańcuchu bloków. Ilekroć ma miejsce transakcja zasobów RGB, odpowiedni kontener zasobów może również wykazywać podobne cechy, podobnie jak związek między elementami i cieniami. Na tym polega istota „wiązania izomorficznego”.
Na przykład, jeśli Alicja posiada 100 tokenów RGB i UTXO A w łańcuchu Bitcoin, a także ma UTXO w łańcuchu CKB, to UTXO jest oznaczone jako „RGB Token Balance: 100”, a warunki odblokowania są powiązane z UTXO A. .
Jeśli Alicja chce dać Bobowi 30 tokenów, może najpierw wygenerować Zaangażowanie. Odpowiednia instrukcja brzmi: przenieś 30 tokenów RGB powiązanych z UTXO A do Boba i prześlij 70 do innych UTXO kontrolowanych przez nią.
Następnie Alicja wydaje UTXO A na łańcuch Bitcoin, publikuje powyższą instrukcję, a następnie inicjuje transakcję w łańcuchu CKB w celu wykorzystania kontenera UTXO zawierającego 100 tokenów RGB i wygenerowania dwóch nowych kontenerów, jeden zawierający 30 tokenów (do Boba), drugi przechowuje 70 żetonów (kontrolowanych przez Alicję). W tym procesie zadanie sprawdzenia ważności aktywów Alicji i ważności zestawienia transakcji jest realizowane przez węzły sieci, takie jak CKB lub Cardano, w drodze konsensusu, bez interwencji Boba. W tej chwili CKB i Cardano służą jako warstwa weryfikacyjna i warstwa DA w łańcuchu Bitcoin.
Dane RGB wszystkich osób o aktywach są przechowywane w łańcuchu CKB lub Cardano, który ma globalnie weryfikowalną charakterystykę i sprzyja wdrażaniu scenariuszy Defi, takich jak pule płynności i protokoły zastawu aktywów. Oczywiście powyższe podejście poświęca również prywatność. Istotą jest kompromis między prywatnością a łatwością obsługi produktu. Jeśli zależy Ci na najwyższym bezpieczeństwie i prywatności, możesz wrócić do tradycyjnego trybu RGB; dbasz o to, możesz bezpiecznie używać RGB++. Tryb zależy całkowicie od Twoich osobistych potrzeb. (W rzeczywistości, dzięki potężnej kompletności funkcjonalnej łańcuchów publicznych, takich jak CKB i Cardano, ZK można wykorzystać do realizacji transakcji prywatnych)
Należy w tym miejscu podkreślić, że RGB++ wprowadza ważne założenie zaufania: użytkownicy muszą być optymistami, że łańcuch CKB/Cardano, czyli platforma sieciowa złożona z dużej liczby węzłów opierająca się na protokołach konsensusu, będzie niezawodna i wolna od błędów. Jeśli nie ufasz CKB, możesz także prześledzić interaktywny proces komunikacji i weryfikacji w oryginalnym protokole RGB i samodzielnie uruchomić klienta.
W ramach protokołu RGB++ użytkownicy mogą bezpośrednio używać kont Bitcoin do obsługi własnych kontenerów zasobów RGB w łańcuchach UTXO, takich jak CKB/Cardano, bez łańcucha krzyżowego. Muszą jedynie użyć charakterystyki UTXO w powyższych łańcuchach publicznych, aby ustawić warunki odblokowania kontenera Cell. Po prostu ustaw go tak, aby był powiązany z określonym adresem Bitcoin/Bitcoinem UTXO. Jeśli obie strony transakcji dotyczącej aktywów RGB ufają bezpieczeństwu CKB, nie muszą nawet często publikować Zobowiązań w łańcuchu Bitcoin. Po zakończeniu wielu transferów RGB mogą następnie wysłać Zobowiązanie do łańcucha Bitcoin. funkcja składania transakcji.” może obniżyć koszty użytkowania.
Należy jednak zauważyć, że „kontener” używany w wiązaniu izomorficznym wymaga łańcucha publicznego obsługującego model UTXO lub infrastruktury o podobnej charakterystyce w pamięci stanu. Łańcuch EVM nie jest odpowiedni i napotka wiele pułapek. (Ten temat można napisać osobno i obejmuje wiele treści. Zainteresowani czytelnicy mogą zapoznać się z poprzednim artykułem Geek web3 „RGB++ i wiązanie izomorficzne: jak CKB, Cardano i Fuel Empower the Bitcoin Ecosystem”;
Podsumowując, publiczna warstwa rozszerzeń łańcucha/funkcji odpowiednia do realizacji wiązania izomorficznego powinna mieć następujące cechy:
Użyj modelu UTXO lub podobnego schematu przechowywania stanu;
Posiada znaczną programowalność UTXO, umożliwiając programistom pisanie skryptów odblokowujących;
Istnieje przestrzeń stanów związana z UTXO, która może przechowywać status zasobu;
Istnieją mosty lub węzły świetlne związane z Bitcoinem;