Soft fork i hard fork, czyli aktualizujemy blockchain

Przemek/ 5 grudnia, 2022

“Nic nie trwa wiecznie, niebezpiecznie jest wierzyć w to, że coś trwa wiecznie…” śpiewał Sidney Polak i ma on w tym dużo racji, nawet jeśli mowa o zdecentralizowanym świecie. Historii takich blockchainów jak Bitcoin czy Ethereum nie się praktycznie zmienić, ale można sprawić, aby nowo powstałe bloki rządziły się innymi prawami od tych poprzednich. Jak to się dzieje i na czym polegają aktualizacje blockchaina, o tym w kilku słowach opowiem w dzisiejszym wpisie.

Zdecentralizowany świat a nowa wersja oprogramowania

“Mówisz mi, że bitcoinów jest tylko 21 mln i nigdy nie będzie ich więcej, bo tak zapisane jest w kodzie. Tylko co jeśli ten kod zostanie zmieniony?”. Z tego rodzaju pytaniem spotkałem się już nie raz, a odpowiedź na nie wymaga zrozumienia mechanizmów związanych z aktualizacją zdecentralizowanego kodu.

Możesz się teraz zastanawiać, o jakich zmianach mówię. Przecież kiedyś pisałem, że w przypadku smart kontraktów kod pozostaje zawsze taki sam i nie ma możliwości jego zmiany. Pocieszę Cię, bo w tej kwestii nic się nie zmieniło, tyle że tym razem nie mówię o aktualizacji kodu kontraktów, a o uaktualnieniu zasad, którymi rządzi się sam blockchain.

Po co dokonywać zmian? Pierwszy i chyba najbardziej oczywisty powód to wykrycie błędu (tak, to też się zdarza, a programiści blockchaina nie są nieomylni:)), który warto byłoby naprawić. Druga sprawa to chęć usprawnienia obecnie działających mechanizmów, co przełożyć się może na lepsze działanie danej sieci. 

Tutaj od razu można ukrócić jeden z “argumentów”, dlaczego blockchain musi upaść. Osoby nierozumiejące tej technologii twierdzą, że w momencie powstania komputerów kwantowych cała technologia straci sens, a przynajmniej Bitcoin, ponieważ wszystkie jej zabezpieczenia zostaną złamane. Może i tak by się stało, gdyby nie dało się zmienić tych zabezpieczeń, jednak dzięki możliwości aktualizowania sieci, obecne algorytmy mogą zostać w przyszłości zmienione na takie, które oprą się mechanizmom kwantowym. Przy czym dodam, że osobiście uważam, że w takiej sytuacji potencjalny upadek Bitcoina byłby najmniejszym zmartwieniem ludzkości, ponieważ wszystkie inne zabezpieczenia będą również zagrożone.

Powodów, za którymi stoi chęć zmiany może być cała masa i nie różnią się zbytnio od tego, co możemy spotkać w przypadku standardowego oprogramowania. Może oprócz chęci stworzenia większej liczby monet niż obecnie obiecuje to nam algorytm. Jednak sposób ich wprowadzania to już zupełnie inna bajka.

Albo się dogadamy, albo się rozchodzimy

Aktualizacja scentralizowanego oprogramowania jest stosunkowo prosta. Oczywiście w zależności od rodzaju aplikacji i liczby jej użytkowników, proces może wymagać dostosowania pewnych działań, ale całość de facto polega w skrócie na przygotowaniu kodu przez zespół odpowiedzialny za aplikację, ustaleniu daty uaktualnienia i wgraniu nowej wersji. Wszystko zarządzane jest odgórnie i jeżeli dany podmiot zdecyduje się, że od jutra wszystkie nagłówki na stronie będą wyświetlane w kolorze różowym, to żaden użytkownik oprogramowania nie może tego zatrzymać.

W przypadku zdecentralizowanego podejścia jakim jest blockchain, takie podejście do sprawy nie ma racji bytu. Ponieważ nie istnieje jedna osoba lub podmiot, który decyduje o rozwoju takiego oprogramowania (mowa oczywiście o blockchainach takich jak np. Bitcoin czy Ethereum), nie ma też możliwości, aby ktoś odgórnie zarządził aktualizację. Co więcej, praktycznie każda osoba może zgłosić swoją propozycję zmian. Będzie to wymagać prawdopodobnie znajomości kodowania, niemniej jednak taka możliwość istnieje.

Jeżeli od dłuższego czasu obracasz się w blockchainowym świecie, to w tej chwili możesz mieć wątpliwości, co do tego, co przed chwilą przeczytałeś. Czyż nieprawdą jest, że Vitalik Buterin decyduje o rozwoju i zmianach w sieci Ethereum? Cóż…i tak i nie. Dzięki temu, że ma on ogromną siłę przebicia i jest jednym z twórców tego rozwiązania, jego siła tkwi w dużej społeczności, która za nim stoi. Jeżeli pominąć ten aspekt, to wdrażanie jego propozycji zmian nie różni się od tego, jak Twoje sugestie mogłyby być włączone w system.

Aby jakakolwiek zmiana została wdrożona, to sieć musi się na to zgodzić. Mówiąc sieć, mam na myśli osoby utrzymujące dany blockchain, czyli w przypadku Bitcoina będą to zarówno górnicy, jak i węzły walidujące dołączane bloki. W zależności od tego, jak bardzo te strony się ze sobą dogadają, możemy oczekiwać różnych rezultatów.

W najprostszym przypadku, kiedy to zarówno górnicy jak i węzły sieci zgodzą się przyjąć zmianę, czyli zainstalować u siebie aktualizację, to cała sieć przechodzi na nowe zasady działania. W odwrotnym przypadku, czyli w momencie, gdy nikt nie zdecyduje się wdrożyć nowego podejścia, proponowana poprawka przepada, a blockchain działa dalej według starych reguł. W takim przypadku nawet bycie Vitalikiem nic nie pomoże:).

Sytuacja robi się jednak ciekawsza, jeżeli tylko część sieci postanowi wdrożyć aktualizację. Gdy odsetek osób, które nie chcą zmiany będzie stosunkowo niewielki, to prawdopodobnie i one z czasem zaakceptują nowości, ponieważ większość sieci i tak będzie działało po nowemu. Jeżeli natomiast siły “rebeliantów” są dosyć spore, to mogą oni stwierdzić, że sieci dalej będą działać po staremu, a to de facto prowadzi do powstania dwóch oddzielnych łańcuchów. Sytuacja taka miała chociażby miejsce po kradzieży środków z protokołu “The DAO”, kiedy Ethereum podzieliło się na dwa łańcuchu, ponieważ część osób chciała “unieważnić” kradzież, poprzez działanie  wstecz i kontynuowanie dodawania nowych bloków bez uwzględnienia tego zawierającego hack, natomiast pozostali uważali, że takie coś jest niedopuszczalne. Również niedawno miała miejsce podobna sytuacja, kiedy powstał blockchain EthereumPoW, a nastąpiło to po przejściu Ethereum na algorytm Proof of Stake, z czym ponownie część osób się nie zgodziła.

Jeszcze jedno istotne pytanie, to kto jest ważniejszy w tej całej układance? Czy są to górnicy, który tworzą nowe bloki, węzły, które weryfikują nowo utworzone bloki, a może sami użytkownicy, którzy dokonują transakcji? Całe piękno polega na tym, że wszyscy tutaj mają takie samo znaczenie. Jeżeli wszyscy górnicy stwierdzą, że nie podoba im się zmiana i nie będą jej wdrażać, ale węzły walidujące zaaplikują nowe reguły, to żaden nowy blok może nie zostać dołączony. Co prawda spowoduje to brak możliwości dokonywania transakcji, ale taka sytuacja nie leży w niczyim interesie. W analogicznej sytuacji, gdyby węzły nie chciały zaakceptować nowych reguł tworzenia bloków, to ponownie żaden blok może nie zostać dołączony do blockchaina, co również nie leży w niczyim interesie. Ale co ważniejsze, jeśli nawet wszyscy górnicy i wszystkie węzły wprowadzą zmianę, która nie spodoba się użytkownikom, przez co przestaną dokonywać transakcji, to cała sieć stanie się bezwartościowa. Na tym właśnie polega całe piękno decentralizacji.

Co prawda, nieco uprościłem zasady, kiedy to sieć przestaje działać, a kiedy nie i jeśli interesuje Cię bardziej ten temat, to polecam Ci zapoznać się z tym wykładem(. Niemniej jednak ostatecznie o funkcjonowaniu sieci decydują wszystkie zainteresowane strony.

Twarde i miękkie widelce

Myślę, że sprawę samego wdrażania zmian mamy wyjaśnioną, teraz możesz poczytać  chwilę na temat samego typu aktualizacji blockchaina. Możemy wyróżnić dwa rodzaj wprowadzanych zmian i jest to tzw. Soft Fork oraz Hard Fork. W uproszczeniu “fork” w programowaniu jest to sytuacja, kiedy bierzemy jakiś kod i wprowadzamy do niego zmiany, przez co powstaje nowa jego wersja.

Podział na “soft” i “hard” jest uzależniony od tego, czy dana zmiana wymaga aktualizacji oprogramowania przez wszystkich czy nie. Może się tak okazać, że np. pomimo wprowadzonej poprawki przez górników, węzły nie muszą nic robić, a sieć dalej będzie poprawnie funkcjonować. Posłużę się w tym miejscu analogią, która mam nadzieję, dobrze wytłumaczy to zagadnienie.

Wraz ze znajomymi wybieracie się do klubu. Ubiór pozostaje dowolny, ale wiecie, że bramkarz przepuszcza jedynie osoby w czarnym obuwiu. Nie ma znaczenia czy są to trampki, szpilki czy baletki, ważne aby było całkowicie czarne. Docieracie do klubu, ochroniarz patrzy Wam na buty, a że wszyscy trzymaliście się znanej zasady, to zostajecie wszyscy razem wpuszczeni.

Po jakimś czasie ponownie wybieracie się na imprezę, tylko tym razem zawężacie zasady swojego ubioru. Wszyscy od dzisiaj mają się ubierać elegancko, a jedyne buty jakie akceptujecie w swoim towarzystwie, to czarne szpilki i lakierki. Tak wystrojeni udajecie się do klubu, bramkarz weryfikuje obuwie, a ponieważ wciąż jest ono całkowicie czarne, bezproblemowo wchodzicie do środka.

Kolejnym razem postanowiliście zmienić całkowicie swoje reguły i zdecydowaliście, że każdy z Was ubiera białe buty licząc, że ochrona nie zauważy. Jednak po dotarciu na miejsce usłyszeliście “uprzejmą” odmowę wejścia i udaliście się do domu.

Tydzień później usłyszeliście, że zaszła zmiana na bramce i nowy człowiek przepuszcza również osoby w białym obuwiu. Z tą informacją udaliście się na imprezę, po czym bez problemu znaleźliście się w klubie. 

Powyższy przykład może się wydawać nieco infantylny i nie mający nic wspólnego z blockchainem, ale obrazuje to, czym są wspomniane rodzaje forków. Pierwsza sytuacja, w której ekipa zmienia rodzaj butów, a nie ich kolor odpowiada soft forkowi, druga zaś, gdy nowy kolor wszedł do gry reprezentuje hard fork.

Przechodząc już na bardziej techniczny język, soft fork to taka sytuacja, w której aktualizacja reguł tworzenia nowych bloków nie wymaga podjęcia kroków przez węzły. Oczywiście mogą one również uaktualnić swoje oprogramowanie, ale i bez tego cała sieć będzie dobrze działać. Dzieje się tak, ponieważ zasady dla nowo powstałych bloków są bardziej szczegółowe niż poprzednio. Przykładowo gdyby wielkość pojedynczego bloku Bitcoina została zmniejszona do maksymalnie 0.5MB (dzisiaj jest to 1MB), to nowo produkowane bloki wciąż będą akceptowane przez węzły, ponieważ 0.5 jest ciągle mniejsze niż 1.

Hard fork natomiast jest sytuacją, gdy zestaw reguł zostaje rozszerzony. I tak analogicznie, gdyby wielkość produkowanych bloków wzrosła do 2MB, to węzły przestałyby je uznawać za poprawne, chyba że również zaktualizowałyby reguły walidacji.

Jeszcze inaczej można powiedzieć, że soft fork to mechanizm, który dodaje reguły, natomiast hard fork te reguły usuwa. Jest to spore uproszczenie, ale to stwierdzenie nie nagina rzeczywistości:)

Można się spotkać jeszcze z terminem “full fork”. Używany jest on przez niektóre osoby w sytuacji, gdy zmiana jest jednocześnie hard jak i soft forkiem. Czyli część reguł jest dodawana, a część usuwana. Jednak są też osoby, które taką aktualizację wrzucają do worka hard forków.

Istnieje jeszcze jedna sytuacja, kiedy dochodzi do aktualizacji, o której nie musi wiedzieć nikt w sieci, oprócz nas. Przykładem może być optymalizacja sposobu przechowywania danych na dysku górnika/węzła lub jakiś sposób zarządzania plikami. Taka zmiana nie ma wpływu na funkcjonowanie całej sieci, a jest ona jedynie lokalnym usprawnieniem. Niektórzy nazywają taką sytuacją jako “non-fork”.

Mam nadzieję, że po przeczytaniu tego wpisu rozumiesz już, czym są i jak wprowadzane są zmiany w sieciach typu blockchain. Pomimo, że cały proces wymagać może wiele czasu i wysiłku, to można go sprowadzić do prostych słów: tylko aktualizacja, która zostanie zaakceptowana przez społeczność danego blockchaina, może zostać wgrana w oprogramowanie. Pamiętaj jednak, że nie wszystkie blockchainy są zdecentralizowane, przez co wszelkie zmiany wprowadzane są dosyć podobnie do tego, co dzieje się w standardowych rozwiązaniach.