Reorg

Anna přijme 20 000 satoshi, drobných jednotek bitcoinu. Peněženka ukáže jednu konfirmaci: platba je v bloku, který uzel právě přijal. Mezitím ale uzel zjistí, že existuje konkurenční platná větev, v níž tato platba zatím není. Jakmile tato větev představuje více nahromaděné těžební práce, uzel na ni přejde. Této výměně části historie se říká Reorg. Annina platba může znovu čekat na potvrzení, aniž by jí někdo ukradl klíče nebo změnil podpis. Rozhodující není hlasování ani prostý počet bloků, ale chainwork: součet práce, kterou jednotlivé bloky dokládají podle své obtížnosti. Neplatnou větev uzel odmítne i tehdy, když má této práce více. [1] [4]

Co Anna uvidí dál, záleží na nové větvi. Pokud je její platba také v ní, zůstane potvrzená, i když se může změnit počet potvrzení. Pokud v ní není, Bitcoin Core se ji může pokusit vrátit do Mempoolu, svého dočasného seznamu nepotvrzených transakcí čekajících na zařazení do bloku. Návrat však není zaručený. Výstup předchozí transakce je záznam částky a podmínek, za kterých ji lze utratit. Nová větev už mohla tytéž prostředky utratit jinou transakcí; jindy chybí předchozí výstup, z něhož se platí, nebo nejsou splněny časové či další podmínky přijetí. Proto je rozdíl mezi platbou, která jen znovu čeká, a platbou, kterou nová historie už nepřipouští. [1]

Jedna konfirmace znamená blok s platbou. Každý další blok za ním přidává další potvrzení a také práci, kterou by konkurenční větev musela překonat. Platba v posledním bloku tedy má jednu konfirmaci; čím hlouběji v přijaté historii leží, tím obtížnější bývá tuto část historie nahradit. Žádný konečný počet potvrzení ale neznamená matematickou záruku, že se to nikdy nestane. Obchodník či burza proto nastavují čekání podle hodnoty platby a rizika, které jsou ochotni přijmout. [3] [5]

Reorg sám o sobě není důkaz útoku. Dva těžaři mohou téměř současně najít blok navazující na stejného předchůdce. Zprávy se sítí nešíří okamžitě, takže různé uzly chvíli sledují různé konce řetězce. Když jedna platná větev získá více práce, uzly přejdou na ni; opuštěný blok je Stale Block. Stejný mechanismus se ovšem dá zneužít při Double Spend útoku: útočník se snaží prosadit historii, v níž stejné prostředky zaplatil jinam. Pro posouzení události je proto důležité, proč k přepnutí došlo a které platby změnilo. [4] [5]

Při Reorgu uzel dál používá stejná pravidla a vybírá mezi historiemi, které jim vyhovují. Hard Fork je jiná věc: mění pravidla platnosti tak, že starý a nový software mohou tentýž blok posoudit odlišně. Samotná reorganizace tedy nevytváří novou měnu ani neznamená, že někdo přepsal pravidla Bitcoinu. Následující kapitoly rozebírají, jak uzel tuto změnu historie technicky provede. [4]

Tip znamená poslední blok právě přijímané větve. Bod rozvětvení je poslední blok společný současnému aktivnímu řetězci a alternativní větvi. Hloubka reorgu se obvykle popisuje počtem bloků, které uzel odpojí od konce aktivního řetězce, než se vrátí k tomuto společnému předkovi. Jednoblokový reorg vymění tip, hlubší reorg odpojí několik potvrzených bloků. Hloubka je relativní k pohledu konkrétního uzlu. [1]

Full Node je uzel, který sám kontroluje pravidla. Názvy funkcí níže popisují jejich konkrétní provedení v Bitcoin Core. Bitcoin Core nevybírá jen nejvyšší nebo nejpopulárnější větev. Kandidátní řetězec musí při aktivaci splnit konsenzuální pravidla uzlu; více chainworku neudělá z neplatného bloku platný. FindMostWorkChain vybírá kandidáta s největší prací, o němž není známo, že je neplatný. To ještě neznamená úplnou validaci: další kontroly probíhají při připojování bloků v ActivateBestChain. Známé neplatné větve se vyřazují. [1]

UTXO je dosud neutracený výstup transakce; UTXO set je soubor těchto dostupných výstupů. Undo data jsou uložené údaje potřebné k vrácení účinků bloku. DisconnectTip a navazující validační logika vracejí účinky odpojených bloků v opačném pořadí. Utracená UTXO se obnoví a výstupy vytvořené odstraněným blokem přestanou být potvrzené. Proto Bitcoin Core uchovává undo data: musí umět rekonstruovat UTXO set přesně v bodě rozvětvení. [1]

Rollback zde znamená návrat před odpojené bloky; chainstate je pracovní stav uzlu odpovídající přijaté historii. Po rollbacku ConnectTip připojuje bloky větve s vyšším chainworkem v dopředném pořadí. Každá transakce se znovu validuje vůči rekonstruovanému UTXO setu a pravidlům platným v dané výšce. Výsledkem je chainstate odpovídající jedné konkrétní historii, nikoli směs transakcí z obou větví. [1]

Coinbase Transaction je první transakce bloku, která těžaři přiděluje odměnu. Výška h označuje pozici bloku v řetězci. Coinbase transakce je výjimka: do mempoolu se po odpojení nevrací. Výstup coinbase vytvořený ve výšce h lze podle konsenzu utratit nejdříve v bloku h + 100. Při tipu h + 99 má zdrojový blok 100 konfirmací a podmínka zralosti dovoluje zahrnutí útraty do následujícího bloku. Když reorg odstraní blok s coinbase, odměna tohoto bloku z aktivního chainstate zmizí. Neplatné mohou být i navazující transakce, které spoléhaly na odstraněnou historii. [1] [2] [3]

Následují názvy funkcí konkrétní verze programu, nikoli další kroky, které by měl provádět uživatel peněženky. V Bitcoin Core v29.0 jsou kroky explicitní: FindMostWorkChain najde kandidáta s největším chainworkem bez známé neplatnosti, ActivateBestChainStep může odpojit současný tip, ConnectTip ověří a připojí alternativní bloky a MaybeUpdateMempoolForReorg znovu prověří transakce z odpojených bloků. Aktivace může odhalit neplatnost kandidáta a pokračovat hledáním jiné větve. Rozsáhlý reorg vyžaduje zpracovat více odpojených a připojených bloků, takže může zpracování ActivateBestChain prodloužit. [1]