Soft Fork

Wyobraźmy sobie Annę i Pawła, którzy weryfikują Bitcoin na własnych komputerach. Anna zaktualizowała program, Paweł jeszcze nie. Pojawia się zmiana podobna do BIP66: podpisy cyfrowe, potwierdzające uprawnienie do wydania określonych bitcoinów, muszą mieć ściślej zdefiniowany format. Niektóre wcześniej dopuszczalne sposoby zapisu przestają być dozwolone. Płatność z poprawnym podpisem w nowo wymaganym formacie przejdzie tę kontrolę u obojga. Jeśli jednak podpis użyje zapisu wcześniej dozwolonego, a teraz zabronionego, Anna go odrzuci, podczas gdy Paweł może go jeszcze zaakceptować. Zakładamy, że płatność spełnia wszystkie pozostałe zasady. Na tym polega Soft Fork: nowe zasady zabraniają dodatkowych przypadków, nie pozwalając na nic, czego zabraniały stare. Dopóki górnicy tworzą bloki zgodne z zaostrzonymi zasadami, oboje mogą śledzić ich łańcuch. Paweł nie sprawdza jednak sam dodatkowego warunku. Soft Fork pozwala więc zmieniać Bitcoin bez jednoczesnej aktualizacji wszystkich węzłów. Nie sprawia, że stary program kontroluje to samo co nowy, ani sam z siebie nie tworzy drugiej waluty. [1] [6]

Full Node to komputer, który samodzielnie sprawdza zasady Bitcoina. Wybierając między poprawnymi gałęziami, porównuje łączną pracę wykazaną przez wydobycie, a nie głosy ich zwolenników. Stary pełny węzeł może śledzić łańcuch, bo zaktualizowani górnicy zwykle tworzą uznawane przez niego bloki. Nie kontroluje jednak nowego warunku: może przyjąć gałąź o większej pracy, która go łamie, gdy nowe węzły ją odrzucą. Użytkownik potrzebujący nowej gwarancji musi zaktualizować własny program weryfikujący. Odbiór płatności, rozumienie formatu i pełna walidacja to różne możliwości. [1] [12]

BIP to ponumerowana propozycja techniczna. Samo jej opublikowanie nie zmienia sieci: trzeba opracować i sprawdzić oprogramowanie, a użytkownicy decydują, czy je uruchomią. Mainnet to główna sieć Bitcoina, w której przesyła się prawdziwe bitcoiny. Aktywacja określa, od kiedy zaktualizowane węzły zaczną wymagać przestrzegania nowej reguły. Obecność kodu w programie nie oznacza więc jeszcze, że służy on do sprawdzania bloków. W opisanych tu procedurach lock-in oznacza spełnienie warunku późniejszej aktywacji; sama reguła może jeszcze nie obowiązywać. Węzeł sprawdza ją dopiero w stanie ACTIVE. Stan oblicza na podstawie wcześniejszych bloków własnej gałęzi. Jeśli reorganizacja zmieni tę historię w pobliżu granicy aktywacji, wynik też może się zmienić. Dwa programy z różnymi parametrami aktywacji mogą zatem w tej samej chwili akceptować inne bloki. [2] [15]

Górnik buduje blok na poprzednim bloku, nazywanym rodzicem. Jeśli go nie sprawdzi, może zmarnować pracę na gałąź, którą inne węzły odrzucą. W lipcu 2015 część górników sygnalizowała BIP66, lecz nie walidowała poprawnie bloku nadrzędnego. Kontynuowali wydobycie po nieprawidłowym bloku, tworząc 4 lipca sześcioblokową nieprawidłową gałąź, a następnego dnia kolejną krótszą. Zaktualizowane węzły je odrzuciły. Wersja jest deklaracją górnika, nie dowodem sprawdzenia przygotowanego bloku, jego poprzednika i zawartych transakcji. [6] [14]

Aby ustalić, jakie reguły rzeczywiście stosuje Twój węzeł, zacznij od wersji programu i informacji, które zwraca on sam. Zależnie od wersji polecenia getdeploymentinfo i getblockchaininfo podają dane o wdrożonych zmianach oraz łańcuchu. Wraz z dokumentacją wydania, wysokością aktywacji i dziennikami pomagają odróżnić przygotowaną regułę od już aktywnej. Internetowy eksplorator bloków pokazuje perspektywę innej usługi, a nie dowód tego, co sprawdza Twój komputer. Hashrate mierzy moc obliczeniową wydobycia. Nie daje górnikom prawa do obchodzenia reguł Twojego węzła: w stanie ACTIVE zaktualizowany węzeł odrzuci blok naruszający nowy warunek, nawet gdy stoi za nim większość mocy. Trwałość podziału zależy również od pracy zgromadzonej przez gałęzie i ich wykorzystania gospodarczego. Proste usunięcie aktywnego ograniczenia ponownie dopuściłoby obecnie nieprawidłowe bloki, byłoby więc zmianą typu Hard Fork. Przed aktywacją parametry można zmienić skoordynowanym wydaniem programu, lecz taka zmiana również nie instaluje się sama na cudzych węzłach. [1] [15] [16]

V(stary) obejmuje wszystkie bloki akceptowane przed aktualizacją. Soft Fork zachodzi tylko, gdy V(nowy) mieści się wewnątrz: nowy węzeł odrzuca dodatkowe przypadki, a każdy blok zgodny z nową regułą przechodzi stare kontrole. Termin opisuje zgodność reguł, nie mały rozmiar, bezpieczeństwo ani społeczną zgodę. Zwiększenie limitu widocznego dla starego węzła lub dopuszczenie wcześniej nieprawidłowego wydania środków poszerza zbiór i zwykle wymaga zmiany typu Hard Fork. [1] [17]

Zaostrzenie zasad może też wprowadzić nową funkcję. BIP66 doprecyzował DER, czyli format kodowania danych podpisu. BIP65 i BIP112 dodały warunki czasowe wydawania do wybranych poleceń NOP, które wcześniej niczego nie wymuszały. SegWit wprowadził programy witness oraz dane weryfikacyjne witness, między innymi podpisy. Taproot później wykorzystał zarezerwowaną wersję 1. Starsze węzły nie sprawdzają odpowiednich nowych warunków. Anyone-can-spend opisuje ich ograniczony obraz sytuacji, a nie sposób na ominięcie zaktualizowanych węzłów i wydanie cudzych monet. SegWit wiąże też kryptograficznie dane witness z blokiem za pomocą witness commitment. Wiązanie to zapisuje się w transakcji coinbase, pierwszej transakcji z nagrodą dla górnika, zachowując zgodność ze starymi zasadami bloku bazowego. [6] [5] [7] [8] [12]

Bit ma wartość 0 albo 1. Poszczególne bity w nVersion, polu wersji nagłówka bloku, mogą sygnalizować gotowość górnika. BIP9 przypisuje każdemu wdrożeniu nazwę, konkretny bit, czas rozpoczęcia i termin końcowy. Pierwotna procedura mainnetu ocenia okresy po 2016 bloków. Co najmniej 1916 sygnalizujących bloków w stanie STARTED, czyli 95 %, oznacza przejście następnego okresu do LOCKED_IN. Po jeszcze jednym okresie oczekiwania następuje ACTIVE. Jeśli warunek nie zostanie spełniony przed terminem, procedura może zakończyć się stanem FAILED. Stan początkowy, przed rozpoczęciem, nazywa się DEFINED. Każdy węzeł oblicza tę sekwencję z wcześniejszych bloków. Własne nVersion bloku nie rozstrzyga zatem, czy obowiązuje go nowa reguła. Sygnały pomagają skoordynować przejście, nie są głosowaniem nad ważnością poszczególnych bloków. Po osiągnięciu lock-in późniejsze sygnały nie zmieniają już wyniku tej procedury. [2]

Versionbits pozwala górnikom sygnalizować gotowość, ale nie zmieniać reguł cudzych węzłów. BIP8 używa wysokości bloków zamiast granic czasowych. Jeśli lockinontimeout ma wartość true, a wdrożenie nie osiągnęło jeszcze lock-in, ostatni okres może przejść w MUST_SIGNAL z obowiązkową sygnalizacją. BIP148 wymagał od uczestniczących węzłów odrzucania bloków, które nie sygnalizowały SegWit; BIP91 wykorzystał niższy próg sygnalizacji górników do koordynacji tego przejścia. Jeśli egzekwowanie reguł, hashrate i akceptacja ekonomiczna się rozejdą, łańcuch może się podzielić. Wybór aktywacji wiąże się więc z kompromisami dotyczącymi bezpieczeństwa. [11] [9] [10] [17]

P2SH (BIP16) pozwala przesłać środki na hash skryptu, czyli programu określającego warunki ich późniejszego wydania. Przy wprowadzaniu tej zmiany w 2012 roku sygnały w transakcjach coinbase pomagały ocenić gotowość górników. Same nowe kontrole zaczynały jednak obowiązywać od ustalonej granicy znaczników czasu bloków; sygnalizacja nie zastępowała weryfikacji. Coinbase to pierwsza transakcja bloku, zawierająca wynagrodzenie górnika. Późniejsze zmiany wykorzystywały wersję bloku i progi sygnalizacji. BIP34 nakazał zapisywanie w coinbase wysokości bloku, jego pozycji w łańcuchu. BIP66 zaostrzył format podpisów DER, a BIP65 wprowadził CHECKLOCKTIMEVERIFY, czyli kontrolę najwcześniejszego czasu lub wysokości dopuszczającej wydanie środków. Kolejne zwiększanie numeru wersji utrudniało równoległe wdrażanie niezależnych zmian. Dlatego BIP9 wprowadził osobne bity. W 2016 roku na wysokości 419328 wspólnie aktywowano BIP68, BIP112 i BIP113, lecz każdy dotyczy innej części warunków czasowych. BIP68 wprowadza względne oczekiwanie od potwierdzenia wydawanego wyjścia. BIP112 pozwala wymagać go w skrypcie przez CHECKSEQUENCEVERIFY, w skrócie CSV. BIP113 zmienia natomiast podstawę czasu dla bezwzględnej blokady transakcji: zamiast znacznika czasu ocenianego bloku używa Median Time Past, mediany znaczników czasu poprzednich 11 bloków. Wspólna aktywacja nie oznacza więc, że wszystkie trzy propozycje wprowadzają tę samą względną blokadę. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit aktywowano na wysokości 481824 w sierpniu 2017 roku. Oddzielił dane weryfikacyjne witness, na przykład podpisy, od części transakcji używanej do obliczenia jej identyfikatora txid. Dlaczego to ważne? W starszym zapisie można było zmienić reprezentację podpisu, a przez to identyfikator transakcji, nie zmieniając odbiorcy ani kwoty płatności. Ta możliwość to malleability, czyli podatność na taką modyfikację. Zmiana samych danych witness nie zmienia txid; nie rozwiązuje to jednak w ten sposób problemu wejść nadal używających starszego formatu. Stary węzeł widzi transakcję bez danych witness i traktuje program witness v0 jako anyone-can-spend. Zaktualizowany sprawdza dodatkowo witness oraz digest podpisu, czyli skrót podpisywanych danych. Witness commitment zapisany w wyjściu coinbase kryptograficznie wiąże dane witness z blokiem, dzięki czemu pełna weryfikacja wykrywa ich zmianę lub pominięcie. Weight, waga danych przy rozliczaniu pojemności bloku, zwiększył efektywną pojemność. Blok bazowy widoczny dla starego węzła pozostał w pierwotnym limicie jednego megabajta. [8]

Key-path pozwala wydać środki podpisem dla klucza wyjściowego, a script-path przez spełnienie warunków ujawnionego skryptu. Schnorr to schemat podpisu, Tapscript — język tych skryptów. BIP341 i BIP342 definiują wydawanie przez key-path i script-path, z podpisami Schnorr i Tapscript, dla natywnych wyjść SegWit z 32-bajtowym programem witness w wersji 1. Stary węzeł widzi anyone-can-spend: zgodność pozostaje, pełna walidacja nie. Speedy Trial użył zmienionego BIP9, progu 1815/2016 (90 %) i minimalnej wysokości 709632. Taproot aktywował się tam 14 listopada 2021. Reguły i drogę aktywacji należy oceniać osobno. [12] [13] [16]