Popularno-naukowe od @BobBodily, jak zawsze cytowane w całości, bez modyfikacji. Po pierwsze, krótkie podsumowanie BRC-20: BRC-20 jest zdecydowanie najskuteczniejszym protokołem tokena zamiennego na Bitcoinie. Wolumen transakcji w zeszłym roku szedł w setki milionów, jeśli nie miliardów. Nie jest idealny (używa nieefektywnego kodowania, rozdyma zestaw UTXO i obecnie ma ograniczoną funkcjonalność), ale jest niezwykle łatwy we wdrożeniu i tworzeniu tokenów, a także zainspirował napisy w całym świecie kryptowalut w prawie każdym łańcuchu. Następny w kolejce jest krótki wstęp techniczny: BRC-20 to metaprotokół zbudowany na metaprotokole Ordinals, który z kolei jest zbudowany na Bitcoinie. Oznacza to, że Ordinals wykorzystuje Bitcoin jako warstwę pełnej dostępności danych i indeksator poza łańcuchem w celu określenia stanu metaprotokołu. BRC-20 wykorzystuje protokół Ordinals jako kompletną warstwę dostępności danych z indeksatorem poza łańcuchem w celu określenia statusu metaprotokołu. Oznacza to, że BRC-20 jest w rzeczywistości protokołem meta-meta, ponieważ jest zbudowany na bazie porządkowych. Złożoność budowy BRC-20 na Ord: Specyfikacje techniczne protokołu porządkowego zmieniały się w ciągu ostatniego roku. Ord to zupełnie nowy protokół, więc sporo się w nim zmieniło. Kiedy budujesz standard tokena na bazie Ord, Twój protokół zwiększa ryzyko, ponieważ masz protokół przesyłania jako zależność. Tak właśnie stało się z Ord 0.8.0 i Ord 0.9.0. Różne wersje napisów Ord różnią się nieco, co oznacza, że ​​indeksator BRC-20 będzie zgłaszał nieprawidłowe salda w zależności od tego, czy są zbudowane na wersji 0.8.0 i 0.9.0. Oczywiście nie jest to pożądane. Rozwiązanie L1F Podstawa warstwy 1 Rozwiązanie @L1Fxyz polega na zamrożeniu wersji protokołu Ord do wersji 0.9.0, aby zapobiec występowaniu podobnych problemów w przyszłości. Zatem mimo że mamy inne klasy Przeklętych Glifów, można uniknąć wszelkich niezgodności między wersjami, budując wszystkie indeksatory w wersji 0.9.0. Nie jest to rozwiązanie trwałe, ale na razie sprawdza się bardzo dobrze, utrzymując stabilność BRC-20. Unisat chce popchnąć protokół do przodu Unisat jako pierwszy wprowadził na rynek system modułów czarno-białych. Dzięki temu osoby budujące na BRC-20 (jak Unisat) mogą wprowadzać nową funkcjonalność w czarnych modułach (tymczasowe lokalizacje, które nie są indeksowane w głównym protokole).Możesz wkładać monety do czarnego modułu, ale nie możesz ich wyjąć, dopóki nie zostaną zatwierdzone, zasadniczo jak Bitcoin Space Chain (most jednokierunkowy). Wczoraj jednak Unisat ogłosił, że chce zaktualizować wersję Ord w ramach indeksatora BRC-20 do najnowszej wersji po rocznicy. Jubileusz jest oficjalną wersją Ordu i nie będziemy już przeklinać porządkowych (wszystkie napisy będą zawsze miały liczby dodatnie). Punkt debaty: Jak uaktualnić BRC-20 Aktualizacja wersji Ord pod indeksatorem BRC-20 jest właściwie bardzo dobrym pomysłem. Protokół Ord będzie stabilniejszy, nie będziemy już przeklinać liczb porządkowych, nie będziemy musieli się martwić o niedopasowanie balansu itp. Unisat chce jak najszybciej uruchomić tę usługę, co ma sens, ponieważ Unisat jest startupem. Startupy nie mają czasu siedzieć i czekać. Musisz ciężko pracować, aby znaleźć produkt odpowiedni na rynek i zbudować go dla swoich użytkowników. L1F chce opóźnić aktualizację, ponieważ jeśli się pospieszymy z aktualizacją, możemy otrzymać więcej błędów. Best in Slot i inni odkryli niektóre z tych błędów protokołu. Ma to sens, ponieważ L1F ma na celu ochronę podstaw protokołu, dzięki czemu może akceptować aktualizacje z wolniej poruszających się, bardziej celowych ścieżek protokołu. Niektórzy uważają, że jest to próba przejęcia kontroli przez zespół Unisatu nad protokołem. Inni uważają, że L1F po prostu próbuje kontrolować protokół, co powinno być bardziej zorientowane na rynek. Rozwiązanie Boba Ze względu na niesamowity sukces porozumienia BRC-20 nie możemy działać szybciej. Dni startu BRC-20 dobiegły końca. BRC-20 to protokół absolutnie masowy (TVL, użytkownicy, infrastruktura, portfele, rynek) i nic nie należy już robić szybko. Podoba mi się podejście L1F. Domo zawsze zdawał sobie sprawę ze znaczenia stabilności protokołu (BRC-20 tak naprawdę nie zmienił się od czasu jego powstania), co jest jego mocną stroną. Łatwiej się zintegrować. Łatwiej budować na.itp. Potrzebujemy decentralizacji, rozwagi oraz powolnego procesu osiągania konsensusu i kompromisu, aby przyspieszyć zmiany w protokole BRC-20.