Reorg

Anna otrzymuje 20 000 satoshi, drobnych jednostek bitcoina. Portfel pokazuje jedno potwierdzenie: płatność znajduje się w bloku przyjętym przez jej węzeł. Węzeł dowiaduje się jednak o konkurencyjnej poprawnej gałęzi, która jeszcze nie zawiera tej płatności. Gdy wykazuje ona więcej skumulowanej pracy wydobywczej, węzeł na nią przechodzi. Taką wymianę części historii nazywamy Reorg. Płatność Anny może znów czekać na potwierdzenie, choć nikt nie ukradł jej kluczy ani nie zmienił podpisu. Nie decyduje głosowanie ani sama liczba bloków, lecz chainwork: suma pracy wykazanej przez każdy blok zgodnie z jego trudnością. Niepoprawną gałąź węzeł odrzuci nawet wtedy, gdy ma ona więcej pracy. [1] [4]

To, co Anna zobaczy dalej, zależy od nowej gałęzi. Jeśli również zawiera ona płatność, ta pozostaje potwierdzona, choć liczba potwierdzeń może się zmienić. W przeciwnym razie Bitcoin Core może spróbować przywrócić ją do Mempool, swojej tymczasowej listy niepotwierdzonych transakcji czekających na blok. Powrót nie jest gwarantowany. Wyjście wcześniejszej transakcji zapisuje kwotę oraz warunki jej wydania. Nowa gałąź mogła już wydać te same środki w innej transakcji; może też brakować wcześniejszego wyjścia, które ma zostać wydane, albo nie być spełnione warunki czasowe lub inne zasady przyjęcia. Płatność czekająca ponownie to więc co innego niż taka, na którą nowa historia już nie pozwala. [1]

Jedno potwierdzenie oznacza blok zawierający płatność. Każdy kolejny blok dodaje potwierdzenie i pracę, którą konkurencyjna gałąź musiałaby przewyższyć. Płatność w ostatnim bloku ma zatem jedno potwierdzenie; im głębiej leży w przyjętej historii, tym trudniej zwykle zastąpić tę jej część. Żadna skończona liczba potwierdzeń nie daje jednak matematycznej gwarancji, że zastąpienie jest niemożliwe. Sprzedawcy i giełdy dobierają więc czas oczekiwania do wartości płatności i akceptowanego ryzyka. [3] [5]

Sam Reorg nie dowodzi ataku. Dwaj górnicy mogą niemal równocześnie znaleźć bloki z tym samym poprzednikiem. Wiadomości nie rozchodzą się natychmiast, więc węzły przez chwilę śledzą różne końce łańcucha. Gdy jedna poprawna gałąź zgromadzi więcej pracy, przechodzą na nią; porzucony blok to Stale Block. Ten sam mechanizm można jednak wykorzystać w ataku Double Spend: atakujący próbuje narzucić historię, w której te same środki trafiły gdzie indziej. Dlatego trzeba ustalić przyczynę zmiany gałęzi oraz to, których płatności dotyczyła. [4] [5]

Podczas Reorg węzeł zachowuje te same reguły i wybiera między historiami, które je spełniają. Hard Fork zmienia zasady poprawności, przez co stare i nowe oprogramowanie mogą inaczej oceniać ten sam blok. Sama reorganizacja nie tworzy więc nowej waluty ani nie przepisuje reguł Bitcoina. Dalsze rozdziały opisują techniczne wykonanie takiej zmiany historii. [4]

Tip to ostatni blok aktualnie przyjętej gałęzi. Punkt rozgałęzienia to ostatni blok wspólny dla obecnie aktywnego łańcucha i alternatywnej gałęzi. Głębokość reorganizacji opisuje się zwykle liczbą bloków na aktywnym końcu łańcucha, które trzeba odłączyć, aby wrócić do tego wspólnego przodka. Reorganizacja o głębokości jednego bloku zastępuje ostatni blok łańcucha; głębsza reorganizacja cofa kilka potwierdzonych bloków. Głębokość zależy od perspektywy konkretnego węzła. [1]

Full Node sam sprawdza reguły. Poniższe nazwy funkcji opisują ich implementację w Bitcoin Core. Bitcoin Core nie wybiera po prostu najwyższej ani najpopularniejszej gałęzi. Podczas aktywacji łańcuch kandydujący musi spełnić reguły konsensusu węzła; większy chainwork nie sprawi, że niepoprawny blok stanie się poprawny. FindMostWorkChain wybiera kandydata o największej pracy, o którym nie wiadomo, by był niepoprawny. Nie oznacza to jeszcze pełnej walidacji: dalsze kontrole odbywają się podczas dołączania bloków w ActivateBestChain. Gałęzie o znanej niepoprawności są odrzucane. [1]

UTXO to niewydane wyjście transakcji; zbiór UTXO obejmuje takie dostępne wyjścia. Dane undo przechowują informacje potrzebne do cofnięcia skutków bloku. DisconnectTip i dalsza logika walidacji cofają skutki odłączonych bloków w odwrotnej kolejności. Wydane UTXO są przywracane, a wyjścia utworzone przez usunięty blok przestają być potwierdzone. Dlatego Bitcoin Core przechowuje dane pozwalające cofnąć zmiany: musi umieć odtworzyć UTXO set dokładnie w punkcie rozgałęzienia. [1]

Rollback oznacza tutaj powrót do stanu sprzed odłączonych bloków; chainstate to roboczy stan węzła odpowiadający przyjętej historii. Po cofnięciu zmian ConnectTip dołącza bloki gałęzi o większym chainwork w kolejności od wcześniejszych do późniejszych. Każda transakcja jest ponownie walidowana względem odtworzonego UTXO set i reguł obowiązujących na danej wysokości. Wynikiem jest chainstate odpowiadający jednej konkretnej historii, a nie mieszanka transakcji z obu gałęzi. [1]

Coinbase Transaction jest pierwszą transakcją bloku i przyznaje górnikowi nagrodę. Wysokość h oznacza pozycję bloku w łańcuchu. Transakcja coinbase jest wyjątkiem: po odłączeniu bloku nie wraca do mempoola. Zgodnie z regułami konsensusu wyjście coinbase utworzone na wysokości h można wydać najwcześniej w bloku h + 100. Gdy koniec łańcucha znajduje się na wysokości h + 99, blok źródłowy ma 100 potwierdzeń, a warunek dojrzałości pozwala uwzględnić wydanie w następnym bloku. Jeśli reorganizacja usuwa blok zawierający coinbase, nagroda za ten blok znika z aktywnego chainstate. Niepoprawne mogą stać się także późniejsze transakcje, które opierały się na usuniętej historii. [1] [2] [3]

To nazwy funkcji konkretnej wersji programu, a nie dodatkowe czynności użytkownika portfela. W Bitcoin Core v29.0 kroki są jawne: FindMostWorkChain znajduje kandydata o największym chainwork, o którym nie wiadomo, by był niepoprawny; ActivateBestChainStep może odłączyć bieżący koniec łańcucha; ConnectTip sprawdza i dołącza alternatywne bloki; a MaybeUpdateMempoolForReorg ponownie sprawdza transakcje z odłączonych bloków. Aktywacja może ujawnić niepoprawność kandydata i kontynuować poszukiwanie innej gałęzi. Rozległa reorganizacja wymaga przetworzenia większej liczby odłączanych i dołączanych bloków, może więc wydłużyć przetwarzanie w ActivateBestChain. [1]