Wojna o rozmiar bloków

Wyobraźmy sobie dwie zwykłe potrzeby. Anna chce wysłać bitcoiny bez długiego oczekiwania i wysokiej opłaty. Pavel prowadzi pełny węzeł: komputer samodzielnie sprawdzający bloki i transakcje. Chce weryfikować swoje pieniądze bez drogiego sprzętu. Obie potrzeby są zrozumiałe, ale więcej danych w bloku oznacza też więcej przesyłania i sprawdzania. Właśnie tej równowagi dotyczyła Block Size War. Blok to grupa transakcji dodawana do wspólnej historii płatności w sieci. Anna i Pavel to postacie przykładowe. W rzeczywistej debacie z lat 2015–2017 uczestniczyli programiści, operatorzy wydobycia, giełdy, dostawcy portfeli i użytkownicy. Spierali się zarówno o pojemność, jak i bezpieczny sposób wdrożenia zmian. Bitcoin nie miał dyrektora, który wybrałby jedną opcję i nakazał wszystkim przejście. [1] [11] [13]

Przed SegWit zasady ograniczały blok do 1 MB, czyli 1 000 000 bajtów. Nie oznaczało to stałej liczby płatności: transakcje zajmują różną ilość miejsca. Nowy blok powstaje średnio mniej więcej co dziesięć minut. Gdy zapotrzebowanie przekracza pojemność, górnicy zwykle wybierają transakcje z wyższymi stawkami opłat, a pozostałe czekają. Zwolennicy większych bloków chcieli dodać miejsce bezpośrednio w sieci bazowej i utrzymać przystępne płatności. Przeciwnicy obawiali się wymagań dotyczących łączy, komputerów i szybkiego rozsyłania bloków. Gdyby mniej osób mogło samodzielnie weryfikować, więcej użytkowników musiałoby ufać cudzym usługom. Sam wyższy limit nie przyspiesza powstawania bloków ani nie gwarantuje trwale niskich opłat. Liczą się również popyt i faktyczne wykorzystanie miejsca. [1] [2] [13]

Programista może napisać nowy program, a górnik zbudować według niego blok. Operator Full Node wybiera jednak zasady sprawdzane przez swój węzeł. Nawet większość mocy obliczeniowej nie może zmusić niezmienionego węzła do przyjęcia bloku łamiącego jego reguły. Moc pomaga wybierać między prawidłowymi łańcuchami; nie zamienia nieprawidłowego bloku w prawidłowy. Nie oznacza to jednego głosu na węzeł w światowym głosowaniu ani prawa jednej osoby do zabronienia innym odejścia. Firmy wybierają, co przyjmują, górnicy, co wydobywają, a użytkownicy, czemu przypisują wartość. Niezgodne zasady mogą utworzyć dwie sieci. Porozumienie biznesowe mogło więc wspierać zmianę, ale nie przepisywało automatycznie programów i decyzji wszystkich uczestników. [11] [12]

Propozycje opisywano w dokumentach BIP, czyli Bitcoin Improvement Proposal. BIP przedstawia pomysł, aby inni mogli go przeanalizować i omówić. Nadanie numeru nie oznacza jeszcze, że sieć go przyjęła. Gavin Andresen zaproponował w BIP 101 podniesienie limitu do 8 MB i dalszy wzrost według ustalonego harmonogramu. Plan zakładał mniej więcej podwajanie co dwa lata oraz warunki aktywacji. Mike Hearn wraz z Andresenem promował Bitcoin XT, alternatywne oprogramowanie oferujące tę drogę. Wydanie programu nie było jednak zmianą zasad całej sieci. Stare węzły odrzuciłyby blok przekraczający dotychczasowy limit. Był to Hard Fork: rozszerzenie zbioru dozwolonych bloków, do których przyjęcia potrzebne byłyby inne reguły. Debata wyszła więc poza pytanie o dodatkowe miejsce. Kto przejdzie na nowe zasady, jak skoordynować zmianę i co się stanie, jeśli istotna część uczestników odmówi? [1] [18] [13]

Eric Lombrozo, Johnson Lau i Pieter Wuille opisali inną drogę w BIP 141. SegWit zmienił układ danych transakcji i wprowadził wagę bloku z limitem 4 000 000 weight units. Część nazywana witness zawiera między innymi dane pozwalające sprawdzić prawo do wydania środków. Nie zniknęły i nie przestano ich weryfikować; zmienił się ich udział w obliczaniu wagi. Pojemność zależy od struktury transakcji, a nie od prostego dopuszczenia zwykłych bloków o wielkości czterech megabajtów. Waga określa, jak dane wlicza się do limitu bloku: bajt danych podstawowych liczy się jako 4 jednostki, a bajt dodatkowych danych związanych z witness jako 1. Transakcje o tej samej liczbie bajtów mogą więc zużywać różną część dozwolonej wagi. Przepustowość zależy również od używanych typów transakcji. W odpowiednich transakcjach SegWit usunął też możliwość zmiany identyfikatora przez modyfikację danych podpisu. Ułatwiło to budowę kanałów płatniczych Lightning Network. Zaprojektowano go jako Soft Fork: nowe prawidłowe bloki mieszczą się w starych zasadach, choć starsze węzły nie sprawdzają wszystkich nowych ograniczeń. Bitcoin Core 0.13.1 zawierał mechanizm aktywacji; samo wydanie programu nie uruchomiło SegWit. [2] [3]

23 maja 2017 roku Digital Currency Group opublikowała New York Agreement, porozumienie firm i górników. Łączyło poparcie dla SegWit z obietnicą Hard Forku do 2 MB w ciągu sześciu miesięcy. Ten drugi krok stał się znany jako SegWit2x, a implementację zapewniał projekt btc1. Dla części uczestników był to akceptowalny kompromis: każda strona miała dostać część tego, czego chciała. Inni sprzeciwiali się drugiej zmianie i sposobowi jej forsowania. Zgoda firmy nie oznaczała automatycznej zgody wszystkich klientów. Bitcoin Core później wyraźnie zaznaczył, że btc1 nie jest obowiązkową aktualizacją jego programu, a poparcie dla SegWit nie oznacza poparcia dla SegWit2x. Czytając ówczesne wiadomości, trzeba pamiętać, że dwie zmiany w jednej umowie nadal były odrębnymi zmianami zasad. [6] [7] [11]

Autor występujący jako Shaolin Fry zaproponował BIP 148, wariant UASF, czyli Soft Forku aktywowanego przez użytkowników. Od 1 sierpnia 2017 roku, według Median Time Past, węzły stosujące tę regułę miały odrzucać bloki bez sygnalizacji SegWit, o ile aktywacja nie była już przesądzona lub dokonana. Rozbieżność między wydobyciem a przyjmowaniem bloków groziła podziałem sieci. Nie był to pozbawiony ryzyka przełącznik obsługiwany jednocześnie przez wszystkich. Median Time Past to środkowa wartość po uporządkowaniu znaczników czasu ostatnich 11 bloków, a nie godzina na zegarze każdego użytkownika. Sygnalizacja oznaczała znacznik w nagłówku bloku wyrażający poparcie górnika dla tego wdrożenia; sam znacznik nie uruchamiał jeszcze nowych zasad. James Hilliard opisał w BIP 91 koordynację górników z niższym progiem: 269 z 336 bloków, około 80 %. Po uruchomieniu uczestnicy mieli odrzucać bloki bez sygnału dla pierwotnego wdrożenia SegWit. Lipcowa koordynacja zmniejszyła ryzyko konfliktu wokół sierpniowego terminu. Nie oznaczało to jednak, że sam SegWit przeszedł w lipcu do stanu przesądzonej aktywacji lub już działał. Nadal obowiązywał jego mechanizm BIP 9. [4] [5] [9] [19]

Bitcoin Cash oddzielił się 1 sierpnia 2017 roku. Oprogramowanie Bitcoin ABC obsługiwało na tej gałęzi większe bloki, wówczas z domyślnym limitem 8 MB. Od rozdzielenia sieci miały odmienne zasady i własne monety. Wspólna wcześniejsza historia nie pozwalała swobodnie przenosić późniejszych płatności między BTC i BCH. Bitcoin Cash nie był SegWit2x, a Bitcoin ABC nie był btc1. Pomieszanie nazw łączy sierpniowy podział z innym, później zawieszonym planem. Różniła się też replay protection, czyli ochrona przed powtórzeniem transakcji na drugiej gałęzi. Dla użytkownika miało to praktyczny skutek: operacja w jednej sieci nie powinna przypadkowo wydać środków także w drugiej. Nie należało też wpisywać wspólnych kluczy do dowolnego narzędzia obiecującego nowe monety. [8] [15] [11]

SegWit wszedł w stan LOCKED_IN od bloku 479 808, 9 sierpnia 2017 roku. Okres decyzyjny był zakończony; pozostał jeszcze okres oczekiwania przed egzekwowaniem nowych zasad. Aktywacja nastąpiła w bloku 481 824, 24 sierpnia. Wysokości dzieli 2 016 bloków. Lipcowe BIP 91, sierpniowe przesądzenie aktywacji i samo uruchomienie nie są więc jednym wydarzeniem. Pozostawał drugi etap SegWit2x, zaplanowany na wysokość 494 784. 8 listopada organizatorzy z Mikiem Belshem na czele ogłosili zawieszenie: według ich komunikatu nie osiągnięto wystarczającego porozumienia dla płynnego przejścia. Bitcoin nie stracił działającego SegWit, a osobny Bitcoin Cash nie zniknął. Zakończyła się ta konkretna próba przełożenia poparcia firm i górników na podniesienie limitu Bitcoina. [9] [10] [12] [14] [16] [17]

Spór pokazał, że Bitcoin może się zmieniać, ale napisanie kodu, zebranie podpisów firm i uzyskanie akceptacji zasad to różne zadania. Nie udowodnił, że programiści nie mają wpływu, górnicy są nieistotni lub każda przyszła decyzja zakończy się tak samo. Przepustowości, dostępnej weryfikacji i porozumienia nie da się załatwić samą zmianą nazwy aktualizacji. Czytając nowy projekt, najpierw zapytaj, co zmienia, które węzły przestałyby się zgadzać i jak przebiegałaby aktywacja. Następnie odróżnij propozycję, wydany program i rzeczywiście obowiązujące reguły. Ówczesne BIP i kod dokumentują mechanizmy; wypowiedzi stron — ich stanowiska. Żadna pojedyncza deklaracja uczestnika nie jest sama w sobie bezstronną historią całego konfliktu. [1] [6] [11] [12]