45 / 691REORG

Reorg

Reorganizacja łańcucha

Reorganizacja łańcucha zastępuje aktywny koniec blockchaina węzła inną poprawną gałęzią o większym skumulowanym Proof of Work; dotychczasowe bloki na końcu łańcucha są odłączane, a zwycięska gałąź jest dołączana.

Reorganizacja to lokalna zmiana chainstate, a nie zmiana reguł konsensusu Bitcoina. Full Node stosuje własne reguły walidacji i aktywuje gałąź o największym skumulowanym chainwork spośród tych, które je spełniają. Jeśli gałąź ta różni się już poniżej bieżącego końca łańcucha, węzeł cofa zmiany UTXO wprowadzone przez odłączone bloki, stosuje alternatywną gałąź i ponownie ocenia związane z tym transakcje pod kątem mempoola.

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. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

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. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

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. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

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. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

Transakcje z odłączonych bloków nie muszą zniknąć. Bitcoin Core próbuje przywrócić do mempoola kwalifikujące się transakcje inne niż coinbase. Jedna transakcja może już znajdować się w nowej gałęzi; inna może być w konflikcie, utracić wejścia, przestać być finalna lub nie spełniać zasad polityki mempoola. Portfel musi zatem uwzględniać możliwość anulowania potwierdzenia przez reorganizację. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

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. [Bitcoin Core v29.0 — chain activation and mempool reconciliation] [Bitcoin Core v29.0 — coinbase maturity validation] [Bitcoin Core v29.0 — confirmation depth]

Liczba potwierdzeń obejmuje blok zawierający transakcję oraz wszystkie kolejne bloki w obecnie aktywnym łańcuchu konkretnego węzła. Transakcja w ostatnim bloku bieżącego łańcucha ma jedno potwierdzenie. Każdy kolejny blok zazwyczaj zwiększa pracę potrzebną do zastąpienia historii, ale żadna skończona liczba potwierdzeń nie zapewnia matematycznie absolutnej ostateczności. Giełdy i sprzedawcy wybierają więc próg w zależności od wartości płatności i modelu ryzyka. [Bitcoin Core v29.0 — confirmation depth] [Bitcoin whitepaper — Sections 5 and 11]

Krótka reorganizacja może wystąpić naturalnie, gdy dwóch górników niemal jednocześnie znajdzie konkurencyjne bloki, a różne części sieci przez pewien czas podążają za różnymi końcami łańcucha; gałąź o mniejszym chainwork staje się wówczas nieaktualna, czyli stale. Atak polegający na podwójnym wydaniu celowo wykorzystuje ten sam mechanizm. Techniczna procedura wyboru łańcucha jest taka sama; różnią się przyczyna i cel ekonomiczny. [Bitcoin Developer Guide — Block Chain] [Bitcoin whitepaper — Sections 5 and 11]

Reorganizacja odbywa się w ramach jednego zestawu reguł: węzeł wybiera między gałęziami, które uważa za poprawne. Hard Fork natomiast zmienia reguły poprawności w taki sposób, że stare i nowe oprogramowanie mogą nie zgadzać się już co do tego, czy blok jest poprawny. Reorganizacja sama w sobie nie jest więc zmianą konsensusu. [Bitcoin Developer Guide — Block Chain]

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. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Potwierdzenie, Proof of Work, Stale Block, Podwójne wydanie, Full Node, UTXO. Do tego hasła prowadzą również odsyłacze z Potwierdzenie, Podwójne wydanie, Transakcja coinbase, Soft Fork.

DOC · 001Bitcoin Core v29.0 — chain activation and mempool reconciliationŹródło pierwotne ↗DOC · 002Bitcoin Core v29.0 — coinbase maturity validationŹródło pierwotne ↗DOC · 003Bitcoin Core v29.0 — confirmation depthŹródło pierwotne ↗DOC · 004Bitcoin Developer Guide — Block ChainDokumentacja ↗DOC · 005Bitcoin whitepaper — Sections 5 and 11Źródło pierwotne ↗
Najpierw źródła · To nie jest porada inwestycyjna