BRC-20 to metaprotokół, czyli zbiór zasad interpretowania danych zapisanych w Bitcoinie. Podstawowe operacje deploy, mint i transfer tworzą token, emitują jego jednostki i je przenoszą. Nie są to dodatkowe BTC ani nowa część konsensusu Bitcoina.
Autor znany jako domo sprawdzał, czy na bazie Ordinals można stworzyć wymienne tokeny: jednostki tego samego tokena pełniące tę samą rolę w ewidencji. Pierwotny tekst opisuje eksperyment i przestrzega przed uznaniem go za ostateczne rozwiązanie. Reguły BRC-20 są umową jego uczestników, a nie zmianą zasad Bitcoina. [1]
Inscription to treść umieszczona w danych witness podczas wydawania wyniku Taproot. W BRC-20 zawiera JSON, czyli tekst z nazwanymi polami, takimi jak p, op i tick. Węzeł Bitcoina weryfikuje transakcję, ale nie wykonuje tego tekstu jako księgowości tokena. Znaczenie nadaje mu indeksator. [5]
Pierwszy prawidłowy deploy zajmuje ticker, czyli oznaczenie tokena, bez rozróżniania wielkich i małych liter. Ustala podaż max oraz opcjonalnie limit emisji lim i precyzję dec. Podstawowe reguły dopuszczają najwyżej 18 miejsc po przecinku. Obok pierwotnych tickerów o długości 4 bajtów IP1 wprowadził tickery o długości 5 bajtów związane z self_mint. Liczą się bajty UTF-8, nie litery; tych wariantów nie można dowolnie zamieniać. [2] [3] [6]
Właściciel najpierw tworzy transfer inscription z kwotą amt. Rezerwuje ją z dostępnego salda, nie zmieniając jeszcze salda całkowitego. Dopiero pierwsze przeniesienie tej inscription przekazuje jednostki odbiorcy. Wysłanie jej do siebie zwalnia rezerwację. Każda transfer inscription działa tylko raz; ponowna sprzedaż tego samego zapisu nie przesyła tokenów po raz kolejny. [1] [3]
Indeksatory muszą jednakowo interpretować kolejność zdarzeń, limity i pierwszy transfer. Właściciela salda śledzą według scriptPubKey, czyli skryptu blokującego wynik, a nie wyłącznie wyświetlanego adresu. Reorganizacja może zmienić kolejność i wynikową ewidencję. Samo potwierdzenie transakcji Bitcoina nie dowodzi więc, że zawarta w niej operacja BRC-20 była prawidłowa. [3]
Podstawowe zasady akceptują typ treści text/plain lub application/json oraz poprawny JSON. Wymagane pola i nazwy operacji zapisuje się małymi literami; wymagane wartości, także liczby, są ciągami znaków w cudzysłowach. dec ogranicza liczbę miejsc po przecinku, a uint64_max zakres liczbowy. Liczba bez cudzysłowu lub zbędny przecinek mogą unieważnić operację, choć człowiek bez trudu ją odczyta. [3]
Jeśli usługa najpierw tworzy mint na własny adres, to ona może otrzymać saldo tokena. Późniejsze przekazanie samej mint inscription nie przenosi tego salda. Przypadkowe wydanie odpowiedniego UTXO również może przynieść nieoczekiwany rezultat. Wysłanie inscription jako opłaty dla górnika i niszczenie tokenów mają osobne zasady; zwykły przelew BTC nie jest uniwersalną instrukcją obsługi BRC-20. [1] [6]
Sprawdź pierwszy prawidłowy deploy, max, lim, dec i ewentualne self_mint, a następnie prześledź zdarzenia w kolejności bloków i transakcji. OPI pozwala porównywać hashe zdarzeń poszczególnych bloków i hash skumulowany dla całej historii. Wersja reguł musi się jednak zgadzać: nowsze moduły programowalne rozszerzają pierwotny model. To hasło wyjaśnia jego podstawę, a nie wszystkie rozszerzenia. [4]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Ordinals Inscriptions, Runes, UTXO, Taproot, Bitcoin Script, Fee Rate.
01Czy Full Nodes Bitcoina weryfikują BRC-20?+
Weryfikują transakcje Bitcoina i ich skrypty, ale nie obliczają sald BRC-20. Odtwarza je indeksator zgodnie z regułami metaprotokołu. Sam węzeł Bitcoina nie wystarcza więc do sprawdzenia ewidencji tokenów.
02Czy BRC-20 to to samo co Runes?+
Nie. Podstawowy BRC-20 używa tekstowych Ordinals Inscriptions i transferu w dwóch etapach. Runes zapisuje binarne wiadomości runestone w wyniku z OP_RETURN i inaczej przypisuje tokeny do UTXO. Reguł tych systemów nie można stosować zamiennie.