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 CAT20. Jaki spryt techniczny ma CAT20? Czego możemy się nauczyć?
Fraktalny Bitcoin
Zanim zrozumiemy CAT20, musimy krótko zrozumieć Fractal Bitcoin. Ich związek jest podobny do ERC20 i ETH. Protokół CAT20 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 powodu 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 ERC20 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 CAT20.
Protokół CAT
Poniższą treść można znaleźć w białej księdze: Wprowadzenie | Protokół CAT (https://catprotocol.org/)
I repozytorium github:
GitHub - CATProtocol/cat-token-box: monorepozytorium 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ół CAT20, a na Unisacie dodano odpowiedni panel: https://explorer.unisat.io/fractal-mainnet/cat20.
Każdy powinien móc zareagować, gdy zobaczy nazwę CAT20. Powinna być bardziej podobna do ERC20. W porównaniu z dojrzałym protokołem ERC20 wdrożenie tokenu jest bardzo wygodne dla każdego. W jaki sposób CAT20 realizuje cykl życia podobny do ERC20.
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 ERC20:
Będą pewne różnice. CAT20 może ustawić limity wstępnego wydobycia i ilości na mennicę. Oczywiście ERC20 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 „bc1pucq...ashx” odpowiada zatwierdzeniu. Następnie pozostają dwie transakcje wskazujące na " bc1pszp...rehc4 ". 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 CAT20. 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 musisz za każdym razem ustawić liczbę wyjść mennic na większą niż 1, aby po mennicy można było używać coraz większej liczby mennic.
Jednak każde dodatkowe wyjście mintera oznacza, że trzeba zapłacić więcej utxo ze względów ekonomicznych, więcej osób chętnie ustawi mintera na 0, co nieuchronnie spowoduje deflację mintera, co wymaga od niektórych osób przyjścia, aby przekazać darowiznę i zapłacić. dodatkowy minter 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 kluczowi prywatnemu odpowiada klucz publiczny, 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ż charakterystyczny dla adresów P2TR.
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ł jeszcze upubliczniony i nie znamy jeszcze konkretnej implementacji.
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 CAT20. CAT20 posiada dwa podstawowe stany: ilość oraz adres właściciela Tokena. Widać, że w przeciwieństwie do poprzedniego BRC20 lub napisu, Twój CAT20 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śli chcesz sprawdzić aktualną sytuację mennicy możesz wyszukać transakcje z kotem w OP_RETURN.
ZAN jest tutaj, aby uzyskać wodę bez progu!
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 @GaoYeezo75065) z zespołu ZAN (konto X @zan_team)