Ten artykuł służy wyłącznie do udostępniania informacji technicznych i nie stanowi porady inwestycyjnej.
Czy BTC również będzie miało swój własny inteligentny kontrakt?
W najnowszym ekosystemie Bitcoin Fractal BTC ostatecznie uruchomił sieć główną we wrześniu, po przejściu przez wiele sieci testowych. Główną cechą Fractal jest możliwość posiadania „inteligentnych kontraktów” i niemal w tym samym czasie, gdy uruchomiono sieć główną, został uruchomiony nowy protokół tokena CAT 20. Jaki spryt techniczny ma CAT 20? Czego możemy się nauczyć?
Fraktalny Bitcoin
Zanim zrozumiemy CAT 20, musimy krótko zrozumieć Fractal Bitcoin. Ich związek jest taki sam jak ERC 20 i ETH. Protokół CAT 20 jest wdrażany na Fractal Bitcoin.
Fractal Bitcoin, znany również jako Fractal Bitcoin, to sieć „drugiej warstwy”, w pełni kompatybilna z BTC. W porównaniu do BTC czas potwierdzenia bloku jest szybszy i zajmuje tylko 1 minutę. Jego podstawowa zasada jest po prostu taka, jak sama nazwa wskazuje, czyli utworzenie kilku kopii sieci BTC. Każda sieć będzie przetwarzać transakcje. Im więcej węzłów będzie w stanie przetwarzać transakcje, tym naturalnie będzie to przebiegać. Jednak szczegółowe szczegóły, takie jak sposób komunikowania się różnych łańcuchów, nie są jeszcze jasne i nie ma odpowiednich oficjalnych dokumentów technicznych, do których można by się odnieść.
Jeśli tylko transakcja łańcuchowa drugiej warstwy jest szybsza, wydaje się, że nie ma powodów do ekscytacji. Jednak aktywacja OP_CAT we Fractal, która została dawno porzucona przez BTC ze względów bezpieczeństwa, wyniosła możliwości Fractal Bitcoin na wyższy poziom. Niektórzy twierdzą, że OP_CAT może umożliwić BTC posiadanie w tym zakresie możliwości inteligentnych kontraktów sposób, jest miejsce na wyobraźnię.
Teraz ktoś wdrożył protokół podobny do ERC 20 na Fractal Bitcoin.
Jeśli chodzi o to, dlaczego OP_CAT został porzucony i dlaczego można go używać na Fractal Bitcoin, możemy porozmawiać o tym później. Tutaj skupiamy się na CAT 20.
Protokół CAT Poniższą treść można znaleźć w białej księdze: Wprowadzenie | Protokół CAT (https://catprotocol.org/)
Oraz repozytorium github: GitHub - CATProtocol/cat-token-box: Monorepo dla pakietów implementujących protokół CAT (https://github.com/CATProtocol/cat-token-box)
Dzięki podstawowej obsłudze OP_CAT wkrótce dostępny będzie odpowiedni protokół, protokół CAT. Obecnie faktycznie działającym protokołem jest protokół CAT 20, a na Unisacie dodano odpowiedni panel: https://explorer.unisat.io/fractal-mainnet/cat20.
Każdy powinien móc zareagować, gdy zobaczy nazwę CAT 20. Powinna być bardziej podobna do ERC 20. W porównaniu z dojrzałym protokołem ERC 20 wdrożenie tokenu jest bardzo wygodne dla każdego. W jaki sposób CAT 20 wdraża cykl życia podobny do ERC 20?
Wdrożyć
Przed wdrożeniem użytkownicy muszą podać adres swojego portfela i podstawowe informacje o tokenie. Podstawowe informacje o tokenie są podobne jak w przypadku ERC 20:
Będą pewne różnice. CAT 20 może ustawić limity wstępnego wydobycia i ilości dla każdej Mennicy. Oczywiście ERC 20 może również osiągnąć te możliwości dzięki możliwościom kontraktowym.
W fazie wdrażania zostaną zainicjowane dwie transakcje, które można uznać za dwie fazy: „zatwierdzenie” i „ujawnienie”. Cytując oficjalny diagram, etapy wdrażania są następujące:
Na etapie „commit” w skrypcie wyjściowym transakcji zostaną zapisane podstawowe informacje o tokenie, takie jak nazwa, symbol itp. tokena. HashId transakcji zainicjowanej w fazie „commit” zostanie użyty jako symbol tokena w celu odróżnienia innych tokenów.
Możesz zobaczyć, że utxo tej transakcji „bc 1 pucq...ashx” odpowiada zatwierdzeniu. Następnie pozostają dwie transakcje wskazujące na " bc 1 pszp...rehc 4 ". Pierwsza służy do uiszczenia opłaty za gaz za kolejny etap "odsłonięcia", a druga to zmiana.
Na etapie „ujawniania” widać, że istnieją dwa wejścia utxo, odpowiadające dwóm pierwszym wyjściom poprzedniego etapu zatwierdzania. Ta transakcja najpierw wygeneruje OP_RETURN, w którym zostanie zapisany Hash stanu początkowego CAT 20. Następnie zostanie wyprowadzony Minter, który będzie odgrywał ważną rolę w późniejszym procesie Mint i służy do utrzymywania zmian stanu procesu Mint.
Patrząc wstecz na cały proces wdrażania, „zatwierdź” i „ujawnij” podążają za dwoma etapami przesyłania i ujawniania, powszechnie używanymi w łańcuchu bloków. Jest to stosunkowo powszechny sposób wdrażania projektów. Niektóre dane projektu są dostępne tylko w trybie „ujawniania”. etapy zostaną ujawnione.
Jak
Kiedy po raz pierwszy spojrzymy na Mint Token, transakcja wygląda tak.
Jak widać na powyższym obrazku, proces Mint ma następujące cechy.
Dane wejściowe mennicy to minter, który jest początkowo generowany podczas wdrażania.
Za każdym razem mennica ma jednego i tylko jednego mintera na wejściu i dowolną liczbę minterów na wyjściu (trochę problematyczne)
Każda mennica ma tylko jeden żeton (trochę problematyczne)
Wymagana jest kolejność wyników, po minter musi nastąpić token
Znając proces Mint, możemy faktycznie odkryć pewne szczególne sytuacje, które sprawią, że cały proces Mint będzie interesujący.
Na przykład minter jako wynik transakcji menniczej może wynosić 1, wielokrotność lub nawet 0. Jeśli Mint będzie za każdym razem ustawiony na 1, liczba mennic, których można użyć w całej sieci, pozostanie niezmieniona (1), co spowoduje, że Mint będzie zatłoczony i każdy będzie musiał złapać tego mintera, aby tego uniknąć W takim przypadku należy za każdym razem ustawić liczbę wyjściową mennic na większą niż 1, tak aby po mennicy można było używać coraz większej liczby mennic.
Jednak każde dodatkowe wyjście mintera oznacza, że będziesz musiał zapłacić dodatkowe utxo ze względów ekonomicznych, więcej osób będzie skłonnych ustawić minter na 0, co nieuchronnie spowoduje deflację mintera, co wymaga od niektórych osób przyjścia, aby przekazać darowiznę i zapłacić. dodatkowy minster dobrowolnie.
W wersji V2 domyślnie generowane są dwie mennice, a status dwóch mennic będzie możliwie podobny.
Strukturyzacja transakcji
Niektórzy znajomi mogli odkryć problem, czyli dlaczego utxo Mintera można używać do konstruowania transakcji? Aby zrozumieć ten problem, należy przeanalizować kod źródłowy „umowy”.
1. ujawnij utxo
Najpierw analizujemy transakcję podczas procesu ujawniania i stwierdzamy, że jako dane wejściowe wykorzystuje ona zatwierdzenie wyniku poprzedniej transakcji. Dlaczego możemy wziąć utxo, które nie jest naszym adresem i skonstruować dane wejściowe transakcji?
Zgodnie ze zdrowym rozsądkiem klucz prywatny odpowiada kluczowi publicznemu, a klucz publiczny wyznacza adres. Sprawdzając, czy wejściowe utxo jest prawidłowe, zwykle ustala się to poprzez porównanie, czy podpis jest zgodny z pierwotną transakcją po odszyfrowaniu kluczem publicznym. Ta część logiki jest napisana w skrypcie Bitcoin. Możemy więc sprytnie przepisać logikę skryptu Pary kluczy publiczny i prywatny zapisane w skrypcie należą do naszego własnego adresu, dzięki czemu możemy kontrolować utxo dwóch różnych adresów.
Patrząc na kod źródłowy możemy zobaczyć, co się stało:
Jest tu inny problem, czyli klucz prywatny odpowiada kluczowi publicznemu, więc dlaczego wygenerowany adres zatwierdzenia różni się od naszego adresu? Tutaj możesz to zobaczyć z kodu źródłowego
Innymi słowy, nasz klucz prywatny dostosuje klucz publiczny zgodnie z ISSUE_PUBKEY, który jest również cechą charakterystyczną adresu P 2 TR.
2, miętowe uxo
Podczas procesu ujawniania używamy innego utxo jako danych wejściowych, ale w rzeczywistości klucz szyfrowania jest taki sam, czyli klucz prywatny wdrażającego. Ale na etapie mintera każdy może używać tych utxo jako danych wejściowych. Jak to się robi?
Myślę, że ta część to wspomniana wcześniej zdolność OP_CAT, to znaczy zdolność inteligentnych kontraktów. Każdy minter jest inteligentnym kontraktem. Jednak kod źródłowy tej części nie został obecnie upubliczniony, a konkretna implementacja nie jest jeszcze znana.
Status transakcji (V2)
W minterze stan jest również zachowany. Stan ten występuje w dwóch miejscach: jedno znajduje się w OP_RETURN wyniku transakcji, a drugie jest przechowywane w inteligentnym kontrakcie, którym jest wspomniany powyżej Minter i Token.
To, co jest przechowywane w OP_RETURN, to Hash bieżącego statusu wyjściowego transakcji, a pozostałe czasy Mint Tokena są przechowywane w kontrakcie. Po każdej Mennicy liczba mennic nowo wygenerowanego Mennicy będzie równa pozostałej liczbie mennic podzielonej przez dwa. Przedstawione za pomocą diagramu:
Na koniec gry pozostała liczba wszystkich Minterów wynosi 0.
Wracając do pierwotnego obrazu, oprócz tego, że Minter jest inteligentnym kontraktem, wygenerowany Token jest także inteligentnym kontraktem, czyli CAT 20. CAT 20 posiada dwa podstawowe stany: ilość oraz adres właściciela Tokena. Możesz zobaczyć, że w przeciwieństwie do poprzedniego BRC 20 lub napisu, Twój CAT 20 nie znajduje się w UTXO Twojego adresu.
Przenosić
Podczas przesyłania liczba tokenów wejściowych i wyjściowych w transakcji musi być spójna. Oczywiście w tej samej transakcji może znajdować się wiele różnych tokenów, o ile numery wejściowe i wyjściowe różnych tokenów są spójne.
Oparzenie
Jeżeli chcesz spalić Token wystarczy, że przeniesiesz Token na zwykły adres.
Streszczać
Można zauważyć, że wszystkie operacje są konstruowane przez samych użytkowników, co jest bardzo elastyczne, więc w części kontraktowej trzeba przeprowadzić wiele logiki weryfikacji. Niektóre z luk, które zostały dotychczas ujawnione, wynikają również z zaniedbań w logice weryfikacji.
Taki projekt może mieć pewne zalety:
Jeśli chcesz sprawdzić stan posiadania wszystkich Tokenów, wystarczy sprawdzić utxo tokena i nie ma potrzeby kontynuowania wyszukiwania.
Jeżeli chcesz sprawdzić aktualną sytuację mennicy możesz wyszukać transakcje z katem w danych w OP_RETURN.
ZAN jest tutaj, aby uzyskać wodę bez żadnych progów!
Wskazówka: Co 24 godziny możesz otrzymywać darmowy token testnetowy o wartości 0,01 ETH, który pomoże Ci w doświadczaniu i testowaniu projektów Web3 w ekosystemie Ethereum. Kliknij, aby otrzymać go teraz: https://zan.top/faucet?chInfo=ch_WZ
Wkrótce będzie obsługiwanych więcej sieci publicznych ~
Ten artykuł został napisany przez Yeezo (konto X @GaoYeezo 75065) z zespołu ZAN (konto X @zan_team)