Nie był to spór o nową regułę, lecz ukryta zależność walidacji od implementacji bazy danych: nowsza LevelDB obsłużyła blok o nietypowo dużej liczbie wejść, a wcześniejsze wersje wyczerpały domyślną liczbę blokad Berkeley DB; górnicy skoordynowali powrót do zgodnej gałęzi, a późniejsze wydanie 0.8.1 przygotowało kontrolowane przejście.
11 marca 2013 roku węzeł z Bitcoinem 0.8 wydobył blok 225 430. Nowa wersja go zaakceptowała, natomiast część węzłów w wersji 0.7.2 i starszych odrzuciła; od wspólnego rodzica zaczęła więc rosnąć gałąź z tym blokiem oraz gałąź bez niego. Różnica nie dotyczyła samego hash ani proof of work, tylko tego, czy lokalne oprogramowanie w ogóle uznawało blok za ważny. [2]
Wyzwalaczem nie był po prostu rozmiar bloku w bajtach. Blok zawierał niespotykaną wcześniej liczbę wejść transakcji, a stare węzły podczas zapisu wyczerpały domyślną liczbę blokad Berkeley DB. Liczba potrzebnych blokad zależała również od układu stron bazy danych konkretnego węzła, dlatego mniejszy, poza tym ważny blok mógł zawieść tam, gdzie wcześniej przechodziły testowe bloki o maksymalnym rozmiarze. [1]
Bitcoin 0.8 przeniósł indeksy bloków i transakcji z Berkeley DB do LevelDB, która nie miała takiego limitu blokad. Początkowo około 60 % hashrate budowało gałąź 0.8, lecz starsze węzły nie liczyły jej pracy, bo odrzuciły blok początkowy. Reguła najcięższego łańcucha wybiera wyłącznie spośród historii wcześniej zweryfikowanych przez węzeł, więc sama nie mogła rozstrzygnąć tej niezgodności. [1]
Pieter Wuille opublikował alarm i zalecił sprzedawcom wstrzymanie obsługi płatności. Po rozmowach deweloperów i operatorów BTCGuild kierowany przez Michaela Marsee, znanego jako Eleuthria, oraz Slush Pool Marka Palatinusa wróciły do Bitcoin 0.7. Celem nie było trwałe uznanie technicznie nowszej gałęzi za błędną, lecz szybkie skupienie pracy na historii, którą potrafiły zweryfikować obie szeroko używane wersje. [3]
Gdy zgodna gałąź zdobyła przewagę skumulowanej pracy, węzły 0.8 zreorganizowały się na nią, a bloki wydobyte wyłącznie w pierwotnej gałęzi 0.8 stały się stale. BIP 50 odnotowuje co najmniej jeden duży double spend podczas rozłamu; według raportu był eksperymentem, nie zamierzoną kradzieżą. Zdarzenie pokazało jednak, dlaczego giełdy i sprzedawcy przy niepewnym czubku łańcucha wstrzymują depozyty i czekają na dalsze potwierdzenia. [1]
Bitcoin Core 0.8.1 wydano 18 marca 2013 roku. Wprowadził tymczasową regułę akceptacji bloków obowiązującą od 21 marca do 15 maja, która zapobiegała przyjmowaniu bloków niemożliwych do przetworzenia przez starsze peery, oraz wbudowany checkpoint na bloku 225 430. Raport wskazuje także szacowany limit 10 000 blokad, limit wydobywanego bloku 500 000 bajtów i backporty z limitem 537 000 blokad Berkeley DB. [4]
Tymczasowa zgodność nie była stanem docelowym. Operatorzy starszych węzłów mieli do 15 maja przejść na 0.8.1, zaktualizowany backport albo jawnie zwiększyć limit blokad; górnicy nie powinni podnosić go przed uzgodnionym terminem, aby ponownie nie stworzyć bloku odrzucanego przez resztę sieci. 16 sierpnia 2013 roku sieć zaakceptowała blok 252 451 i definitywnie pozostawiła niezałatane węzły za sobą. [5]
Incydent pokazał, że konsensus to więcej niż opis formatu bloku. Obejmuje dokładne zachowanie kodu walidacji, bibliotek, transakcji bazodanowych, ścieżek błędów i testów granicznych. Dalsze działania objęły więc obciążeniowe generowanie transakcji w testnet, lepsze alerty dla usług, monitorowanie długich bocznych gałęzi i ostrożniejszą koordynację zmian; szybkie opanowanie sytuacji ujawniło też ówczesną zależność od kilku dostępnych deweloperów i dużych pooli. [1]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Bitcoin Core, Reguły konsensusu, Hard Fork, Reorg, Full Node, Mining Pool. Do tego hasła prowadzą również odsyłacze z Schelling Point.
01Czy jedna grupa zdecydowała, który blockchain jest prawdziwy?+
Deweloperzy i duże poole koordynowali działania awaryjne, ale nie mogli zdalnie przepisać węzłów. BTCGuild i Slush zmieniły oprogramowanie używane przez górników, a użytkownicy uruchamiali wersje z własnymi regułami walidacji. Zgodna gałąź zwyciężyła dopiero po zaakceptowaniu przez wystarczającą liczbę węzłów i zgromadzeniu większej pracy z perspektywy węzłów Bitcoin 0.8.
02Czy obie gałęzie były jednocześnie ważne?+
Zależało to od wersji walidującej. Bitcoin 0.8 uznawał blok 225 430 i jego gałąź za ważne, natomiast część starszych węzłów odrzucała blok z powodu limitu Berkeley DB i znała tylko drugą gałąź. Różne odpowiedzi na te same dane wejściowe są właśnie awarią konsensusu; dzisiejsza aktywna historia kontynuuje skoordynowanie wybraną zgodną gałąź.