BIP-110 wyjasnione: co kontrowersyjny soft fork mowi o konsensusie Bitcoina

Pytanie ukryte pod forkiem

BIP-110 latwo wrzucic do dlugiego sporu o Ordinals i dowolne dane w Bitcoinie. Takie ujecie pomija to, co naprawde jest stawka. Propozycja nie dodaje lokalnego filtra, ktory kazdy operator wezla moze wybrac. Zmienia reguly konsensusu decydujace o tym, ktore bloki w ogole naleza do Bitcoina.

To inny rodzaj zmiany. Filtr antyspamowy to preferencja. Regula konsensusu to definicja. BIP-110 stawia pytanie, ktore stoi ponad debata o danych: czy Bitcoin ma jedynie sprawdzac, czy transakcja jest wazna wedlug neutralnych regul, czy tez reguly maja dodatkowo zakazywac pewnych zastosowan miejsca w blokach? A z pierwszego pytania wynika drugie: jak daleko moze posunac sie mniejszosc, by narzucic swoja preferowana odpowiedz?

To analiza tych pytan oraz mechaniki, ktora czyni je pilnymi w tym miesiacu. CanoeBit nie zajmuje stanowiska w sprawie ceny Bitcoina i nie formuluje zadnej rekomendacji co do tego, co ktokolwiek powinien zrobic. Aktualny stan, harmonogram aktywacji i zgloszony blad klienta opisuje wiadomosc BIP-110 zbliza sie do obowiazkowej sygnalizacji.

Co BIP-110 naprawde ogranicza

Przez okolo rok, czyli 52 416 blokow, BIP-110 dodalby siedem regul konsensusu. Nowe skrypty wyjscia bylyby ograniczone do 34 bajtow, przy czym wyjscia OP_RETURN dopuszczano by do 83. Wypchniecia danych oraz elementy witness sluzace jako argumenty skryptu bylyby ograniczone do 256 bajtow. Niezdefiniowanych wersji witness i Tapleaf nie daloby sie wydac, annex Taproot bylby zabroniony, control blocks bylyby ograniczone do 257 bajtow, a OP_SUCCESS oraz wykonane instrukcje OP_IF i OP_NOTIF bylyby niewazne w Tapscript.

Wazny niuans jest taki, ze te reguly sa ogolne. Uderzaja w techniki, na ktorych opieraja sie dzis inskrypcje, ale szeroko siegaja w Script, dane witness i kilka sciezek aktualizacji Taproota. Sama specyfikacja przyznaje, ze istnieja waskie, eksperymentalne przypadki dotyczace wczesniej podpisanych transakcji Taproot, w ktorych srodki moglyby teoretycznie zostac zamrozone lub utracone, mimo ze dbaja z duza starannoscia o objecie grandfatheringiem kazdej monety potwierdzonej przed aktywacja.

Propozycja nie jest wiec czystym "zakazem Ordinals". To szerokie zaostrzenie tego, jak moze wygladac wazna transakcja Bitcoin, z niewielkim resztkowym ryzykiem dla zastosowan legalnych, lecz nieudokumentowanych. To rzecz warta rozwazenia, nie dlatego, ze ryzyko jest duze, ale dlatego, ze nikt nie jest w stanie wyliczyc kazdej konstrukcji kontraktowej juz obecnej w obiegu.

Steelman: dlaczego obawa jest uzasadniona

Frustracja stojaca za BIP-110 nie jest nierozsadna i warto przedstawic ja w najmocniejszej postaci, zanim sie ja rozlozy na czynniki.

Pelne wezly musza pobrac i zweryfikowac kazdy blok. Niewydane skrypty wyjscia zyja w zbiorze UTXO, ktory wezly trzymaja na szybkiej pamieci i nie moga go przycinac. Duze inskrypcje konkuruja z transakcjami monetarnymi o rzadkie miejsce w blokach, moga podnosic oplaty za zwykle platnosci, a czesc osadzonych tresci to material, ktorego operatorzy wezlow woleliby w ogole nie hostowac. Jesli ktos wierzy, ze pierwszym celem Bitcoina jest bycie pieniadzem, patrzenie, jak jego miejsce w blokach zapelnia sie danymi obciazajacymi na zawsze kazdy wezel, jest autentyczna skarga.

Ten wywod jest spojny. Spor nie dotyczy tego, czy osadzanie danych ma koszty. Dotyczy tego, czy tymczasowa zmiana konsensusu o niskim progu jest wlasciwym narzedziem, by sie z nimi zmierzyc.

Gdzie rozumowanie sie rozrzedza

Dwa problemy oslabiaja propozycje na jej wlasnych warunkach.

Pierwszy jest ekonomiczny. Pierwotny projekt Satoshiego zawiera juz mechanizm antyspamowy: oplaty i sztywny limit rozmiaru bloku. Gdy miejsce w blokach sie zapelnia, staje sie drogie, a zastosowania nieprzynoszace zadnego zwrotu monetarnego zwykle wypadaja z rynku przez cene. To nie teoria. Fale inskrypcji wielokrotnie stygly, w miare jak oplaty rosly, a aktywnosc przestawala sie oplacac. Regula konsensusu, ktora jedynie utrudnia jedna metode, zapasza dane do przemieszczenia sie, a nie do znikniecia.

Drugi problem jest gorszy i to wlasnie tu lekarstwo moze zywic chorobe. Jesli zakaze sie ciaglego przechowywania danych w oczywistych polach, zdeterminowani aktorzy moga rozbic ladunki na wiele malych wypchniec albo przebrac je za zwykle dane finansowe. Rozproszone na wielu wyjsciach dane te moga trafic do zbioru UTXO, jedynej czesci lancucha, ktorej wezly nie moga przyciac. W probie utrzymania niechcianych danych na zewnatrz zmiana ryzykuje przeniesienie ich w najdrozsze miejsce do przechowywania. Propozycja temu nie zaprzecza. Twierdzi, ze fragmentacja i wyzszy koszt i tak wysylaja sygnal. To realny argument, ale to sygnal, a nie rozwiazanie.

Jak powstaloby rozszczepienie lancucha

Mechanika rozszczepienia jest prosta i po czesci dlatego ryzyko jest wiarygodne. Od bloku 961 632 wezly BIP-110 i zwykle wezly Bitcoina stosuja rozne reguly. Jesli blok ustawia bit 4, obie strony moga go zaakceptowac. Jesli blok tego nie robi, zwykle wezly nadal uznaja go za wazny, a wezly BIP-110 go odrzucaja.

W tym momencie obie grupy przestaja podazac za tym samym lancuchem. Przy przewazajacej wiekszosci mocy obliczeniowej, ktora nie sygnalizuje, zwykly lancuch Bitcoina toczylby sie niemal niezaklocenie, a wezly BIP-110 czekalyby, az ktorys z nielicznych sygnalizujacych gornikow wyprodukuje blok na ich galezi. Drugi lancuch moze istniec technicznie. Czy liczy sie ekonomicznie, to osobne pytanie, a obecne dane nie sugeruja, by sie liczyl.

Dwa wybory projektowe zaostrzaja niebezpieczenstwo. Nie ma zadnej ogolnej ochrony przed replay, wiec transakcja moze byc wazna na obu lancuchach naraz, co wczesniejsze forki pokazaly, gdy uzytkownicy przenosza monety w pierwszych godzinach. A sam klient aktywacyjny niesie odtwarzalny blad aktualizacji udokumentowany w raporcie BlockSlop, w ktorym dwa wezly stosujace te same reguly moga trafic na rozne lancuchy w zaleznosci od historii swojego katalogu danych. Zmiana konsensusu, ktorej wlasny klient nie potrafi zagwarantowac, ze identyczne wezly sie zgodza, nie jest dojrzala.

Liczba, ktora rozstrzyga wszystko

Prog sygnalizacji to cichy srodek tego sporu. Taproot, bezsporna i czysto dodajaca aktualizacja, zostal wdrozony z progiem gornikow na poziomie 90 procent. BIP-110, ktory usuwa istniejace mozliwosci i moze wywolac rozszczepienie, ustawia swoja poprzeczke na 55 procent.

To odwrocenie jest wymowne. Zmiana o wyzszym ryzyku prosi o mniejsza zgode niz ta o nizszym ryzyku. Obrona propozycji glosi, ze tymczasowa, roczna regula nie potrzebuje niemal powszechnej gotowosci. Odczytana strukturalnie niska poprzeczka wyglada jednak mniej na margines bezpieczenstwa, a bardziej na probe pokonania poprzeczki, ktorej szerokie poparcie nie jest w stanie osiagnac samo. A nawet 55 procent nie jest blisko: sygnalizacja utrzymywala sie na kilku procentach przez cale wdrozenie.

Tutaj wyrazenie "obowiazkowa sygnalizacja" zaprasza do bledu. Nie zmusza gornikow do aktywacji czegokolwiek. Oznacza tylko, ze wezly BIP-110 beda odrzucac niesygnalizujace bloki od tej wysokosci. Jesli wiekszosc gornikow nadal produkuje zwykle bloki, bloki te pozostaja wazne dla reszty sieci, a to wezly BIP-110 zostaja w tyle. Soft fork aktywowany przez uzytkownikow moze wywierac presje na gornikow, ale tylko wtedy, gdy wiarygodna wiekszosc ekonomiczna gield, powiernikow, portfeli i uzytkownikow odrzuca wszystko poza surowszym lancuchem. Zadna taka wiekszosc nie jest widoczna dla BIP-110.

Lancuch, ktory wloklby sie w zolwim tempie

Zalozmy, ze osobny lancuch BIP-110 powstaje i zachowuje niewielka moc obliczeniowa, ktora dzis sygnalizuje, okolo poltora procent sieci. Odziedziczylby obecna trudnosc Bitcoina przy ulamku mocy potrzebnej, by jej sprostac.

Arytmetyka jest bezlitosna. Bloki przychodzilyby srednio mniej wiecej co jedenascie godzin zamiast co dziesiec minut, prawie 68 razy wolniej. Bitcoin przelicza trudnosc tylko co 2 016 blokow, a w tym tempie dojscie do pierwszej korekty zajeloby rzedu 950 dni, okolo dwoch i pol roku. Do tego czasu lancuch produkowalby sporadyczne bloki, a nie dzialajaca siec platnicza. Lancuch mniejszosciowy jest technicznie mozliwy. Uzyteczny, przy tych liczbach, nie jest.

Odczyt CanoeBit i gdzie sie zalamuje

Nasz strukturalny odczyt jest taki: BIP-110 ma znacznie wieksze szanse wytworzyc maly, powolny i w duzej mierze ignorowany lancuch mniejszosciowy niz zmienic Bitcoina, a jego projekt aktywacji zastepuje konsensus twierdzeniem. Powtarzanie, ze propozycja ma konsensus, nie tworzy go. Konsensus powstaje, gdy niezalezni uzytkownicy, gornicy, deweloperzy i przedsiebiorstwa dobrowolnie zbiegaja sie przy wspolnych regulach, a tej zbieznosci tutaj nie widac.

Poniewaz uczciwa analiza nazywa wlasne warunki porazki, oto nasze. Ten odczyt zalamalby sie, gdyby znaczaca czesc mocy obliczeniowej przeniosla sie na galaz BIP-110 albo gdyby duze gieldy, powiernicy i dostawcy portfeli zobowiazali sie traktowac jako Bitcoin wylacznie surowszy lancuch. W takim przypadku istnialaby prawdziwa wiekszosc ekonomiczna i rachunek by sie zmienil. Zalamalby sie takze, gdyby niskie liczby sygnalizacji byly zle zmierzone, a rzeczywista gotowosc byla znacznie wyzsza, niz pokazuja panele. Zaden z tych warunkow nie jest dzis oczywisty, ale oba sa obserwowalne i oba sa tym, co obserwowalibysmy, by rozpoznac, ze sie mylilismy.

Wezszy punkt pozostaje w mocy niezaleznie od tego, jak rozstrzygnie sie fork. Debata o miejscu w blokach i przechowywaniu danych jest warta przeprowadzenia. Rozstrzyganie jej pospiesznie skonstruowana zmiana konsensusu o niskim progu, egzekwowana przez klienta ze znanym bledem rozbieznosci, to zly sposob jej prowadzenia.