# Hard forky, soft forky a chain splity v Bitcoinu

Pojmy *fork* a *chain split* se v souvislosti s Bitcoinem často zaměňují, přestože označují dvě různé věci. Fork znamená změnu pravidel, podle kterých uzly rozhodují, zda jsou bloky a transakce platné. Chain split naproti tomu znamená skutečné rozdělení historie blockchainu na dvě větve.

Tyto dva jevy spolu mohou souviset, ale jeden automaticky neznamená druhý. Fork může proběhnout bez trvalého rozdělení blockchainu a naopak ke krátkodobému chain splitu dochází běžně i bez jakékoliv změny pravidel.

## Chain split

Představme si, že blockchain dospěl k bloku číslo 4 a dva těžaři přibližně současně vytěží dva různé bloky ve stejné výšce, označme je 5A a 5B.

Kvůli době potřebné k šíření bloků sítí mohou některé uzly nejprve obdržet blok 5A a jiné blok 5B. Každá skupina uzlů proto dočasně považuje za špičku blockchainu jiný blok. Těžaři také pokračují v práci nad blokem, který považují za aktuální.

Jakmile někdo vytěží další blok, například 6A navazující na 5A, větev A získá více kumulované práce. Uzly se na ni přepnou a blok 5B se stane vedlejší větví. Transakce z něj, které nebyly zároveň obsaženy ve vítězné větvi, se mohou vrátit do mempoolu.

Teoreticky může rozdělení pokračovat déle: může vzniknout 6A i 6B, potom 7A a 7B atd. Za běžných okolností však síť rychle konverguje k jedné historii, protože je stále méně pravděpodobné, že obě větve budou získávat přesně stejné množství práce.

Právě proto se u bitcoinových plateb čeká na několik potvrzení. Čím hlouběji je transakce v blockchainu, tím menší je pravděpodobnost, že se ocitne ve větvi, která bude později opuštěna.

Extrémním případem by bylo fyzické rozdělení sítě. Kdyby například dvě velké části internetu mezi sebou dlouhodobě nemohly komunikovat, každá by mohla pokračovat ve vlastní historii blockchainu. Po obnovení spojení by bylo nutné rozhodnout, která větev má více kumulované práce, případně by za určitých podmínek mohlo rozdělení přetrvat.

Chain split tedy znamená **rozdělení historie blockchainu**.

Fork znamená něco jiného.

## Co je fork

Bitcoinové uzly mají sadu konsenzuálních pravidel, podle kterých kontrolují bloky a transakce. Pravidla například určují, jak smějí vypadat transakce, jaké podmínky musí splňovat skripty nebo jaké vlastnosti musí mít blok.

Pokud tato pravidla změníme, vzniká fork.

Nejdůležitější je přitom nesledovat pouze samotný počet nebo „velikost“ pravidel, ale množinu bloků a transakcí, které daná pravidla považují za platné.

Označme množinu bloků platných podle starých pravidel jako **Vₛ** a množinu platnou podle nových pravidel jako **Vₙ**.

Právě vztah těchto dvou množin určuje rozdíl mezi soft forkem a hard forkem.

## Soft fork

Při soft forku nová pravidla **zpřísňují podmínky platnosti**. Množina bloků platných podle nových pravidel je proto podmnožinou bloků platných podle pravidel starých:

**Vₙ ⊂ Vₛ**

To je nejdůležitější vlastnost soft forku.

Každý blok, který je platný podle nových pravidel, je tedy zároveň platný i podle pravidel starých. Opačně to však neplatí: starý uzel může považovat za platný blok, který nový uzel odmítne.

Právě odtud pochází zpětná kompatibilita soft forku. Starý uzel o novém pravidle vůbec nemusí vědět. Pokud těžaři dodržují nová pravidla, produkují bloky, které budou přijímat jak nové, tak staré uzly.

Typickým soft forkem je například zavedení dodatečné podmínky, kterou blok nebo transakce musí splnit. Něco, co bylo podle starých pravidel povoleno, je od určitého okamžiku zakázáno.

Je tedy zavádějící říkat, že soft fork je „malá změna“ a hard fork „velká změna“. Rozdíl není ve velikosti změny, ale ve vztahu množin platných bloků.

Stejně tak není pravda, že soft fork nemůže způsobit chain split. Pokud část těžařů začne nová pravidla vynucovat a jiná část vytvoří blok, který je podle starých pravidel platný, ale podle nových nikoliv, mohou se obě skupiny dočasně rozejít.

Proto i soft forky potřebují vhodný aktivační mechanismus.

## Hard fork

U hard forku už množina bloků platných podle nových pravidel **není podmnožinou** množiny bloků platných podle pravidel starých:

**Vₙ ⊄ Vₛ**

Typickým případem je rozvolnění pravidel. Nová pravidla například dovolí něco, co staré uzly odmítají. Pak může platit:

**Vₛ ⊂ Vₙ**

Hard fork ale nemusí být pouze jednoduchým rozšířením. Nová množina platných bloků se může se starou pouze částečně překrývat nebo může být definována úplně jinak. Podstatné je, že existuje alespoň jeden blok, který nová pravidla přijmou, ale stará odmítnou.

Pokud takový blok vznikne, staré uzly na něj nemohou navázat. Mohou proto pokračovat po jiné větvi blockchainu.

Hard fork tedy vytváří **možnost** trvalého chain splitu, ale neznamená, že k němu nutně dojde. Jestliže na nová pravidla koordinovaně přejdou prakticky všichni relevantní účastníci, může hard fork proběhnout bez trvalého rozdělení sítě.

## První limit velikosti bloků

Historickým příkladem zpřísnění pravidel je zavedení limitu velikosti bitcoinového bloku.

V úplně raných verzích Bitcoinu nebyl konsenzuální limit velikosti bloku nastaven tak, jak jej známe později. Nejprve bylo možné upravit software těžařů tak, aby větší bloky jednoduše nevytvářel. To však ještě samo o sobě není konsenzuální pravidlo.

Je totiž rozdíl mezi tím, co software **produkuje**, a tím, co je ochoten **přijmout**.

Pokud těžební software nevytváří bloky větší než určitý limit, ale uzel by větší blok od jiného těžaře přijal, nejde ještě o konsenzuální omezení.

Teprve pokud validační část klienta řekne: „blok větší než stanovený limit je neplatný“, stává se z omezení součást konsenzu.

Taková změna je soft forkem. Některé bloky, které by podle starých pravidel ještě byly platné, nové uzly odmítnou.

## P2SH jako příklad soft forku

Zajímavějším příkladem soft forku je Pay-to-Script-Hash, tedy P2SH.

U běžného bitcoinového výstupu potřebujeme určit podmínku, za které lze příslušné coiny utratit. U jednoduchých plateb může jít například o požadavek na podpis odpovídající určitému veřejnému klíči.

Komplikovanější skripty, například multisig, však mohou být poměrně velké a nepraktické. P2SH proto umožnilo místo celého skriptu vložit do výstupu pouze jeho hash.

Při utrácení se potom dodá samotný skript. Uzel zkontroluje, že jeho hash odpovídá hodnotě uložené ve výstupu.

Z pohledu starého uzlu tím může být podmínka v zásadě splněna: byl dodán správný předobraz hashe.

Nový uzel však provede ještě další kontrolu. Dodaný skript skutečně interpretuje a ověří všechny podmínky, které obsahuje — například požadované podpisy.

Nová pravidla tedy připouštějí méně transakcí než stará. Nestačí pouze dodat správný skript, ale tento skript musí být také úspěšně vykonán.

Opět tedy platí:

**nově platné transakce ⊂ dříve platné transakce.**

P2SH je proto soft fork, přestože uživatelům přinesl něco, co z jejich pohledu vypadalo jako nová funkce a nový typ adresy.

To je důležitý princip: soft fork může funkcionalitu Bitcoinu výrazně rozšířit, přestože z hlediska konsenzu funguje jako zpřísnění pravidel.

## Neplánované rozdělení sítě v roce 2013

Zajímavým historickým případem je incident z roku 2013 při přechodu na Bitcoin Core 0.8.

Po nasazení nové verze vznikl blok, se kterým se novější a starší implementace kvůli rozdílům v databázovém backendu a jeho limitech vypořádaly odlišně. Část uzlů jej přijala, zatímco jiné jej odmítly.

Blockchain se v důsledku toho rozdělil.

Nešlo o plánovaný fork. Rozdílné chování implementací však fakticky vytvořilo dvě různé množiny platných bloků.

Řešením bylo nejprve koordinovaně obnovit těžbu na větvi kompatibilní se starší verzí 0.7. Následně byla validační pravidla sjednocena tak, aby bylo chování uzlů deterministické. Pozdější odstranění původního omezení pak bylo možné provést koordinovaně.

Tento případ dobře ukazuje, proč není vhodné ztotožňovat hard fork s chain splitem. Hard fork může chain split způsobit, ale nemusí. A chain split může vzniknout i neplánovaně v důsledku implementační chyby.

## SegWit: soft fork, který zvětšil bloky

Segregated Witness je jeden z nejlepších příkladů toho, proč intuitivní vysvětlení soft forku jako „zmenšení možností“ může být zavádějící.

SegWit byl soft fork, ale jeho praktickým důsledkem bylo mimo jiné zvýšení množství dat, které lze do jednoho bitcoinového bloku zahrnout. Před SegWitem jsme byli zvyklí na přibližně megabajtové bloky, zatímco segwitové bloky mohou mít fyzicky výrazně větší velikost.

Jak může soft fork něco zvětšit?

Trik spočívá v tom, jak jsou nová data interpretována starými uzly.

SegWit oddělil podpisová data — *witness* — od části transakce, kterou zpracovávají staré uzly. Staré uzly witness neznají a nevalidují jej. Z jejich pohledu mají nové typy výstupů velmi jednoduché podmínky a transakce zůstávají platné podle starých pravidel.

Nové uzly však vědí, že k takové transakci patří witness data, a ověří v nich podpisy a další podmínky.

Z pohledu starého uzlu by tedy některé segwitové výstupy bylo možné považovat téměř za *anyone-can-spend*. Nové uzly nad ně ovšem přidávají nové validační podmínky: výstup lze ve skutečnosti utratit jen tehdy, pokud witness splňuje požadovaná pravidla.

Opět se tedy množina platných transakcí **zmenšuje**.

SegWit zároveň zavedl pojem *block weight*. Staré uzly nadále uplatňují svůj limit na část bloku, kterou znají, zatímco nové uzly počítají maximální váhu bloku v jednotkách *weight units*. Witness data přitom mají při tomto výpočtu nižší váhu.

Výsledkem je soft fork, který z hlediska uživatele zvýšil efektivní kapacitu blockchainu.

SegWit navíc odstranil významnou část problému s transaction malleability, protože podpisová data již nejsou součástí výpočtu tradičního transaction ID.

## Proč je potřeba aktivace

Ani soft fork nelze bezpečně aktivovat tím, že v určitém bloku prostě část uzlů začne používat nová pravidla.

Představme si, že od bloku 100 nové uzly začnou odmítat určitý typ bloku, který staré uzly stále považují za platný.

Pokud některý těžař takový blok vytvoří, staré uzly jej přijmou a nové odmítnou. Část těžařů může pokračovat nad tímto blokem a část nad posledním společným blokem.

Vznikne chain split.

Smyslem aktivačního mechanismu proto není definovat, co je soft fork a co hard fork. Jeho cílem je zajistit, aby v okamžiku aktivace byla dostatečná část ekonomicky významné sítě připravena dodržovat nová pravidla.

Historicky se často používala signalizace těžařů v blocích. Během určitého počtu bloků se sledovalo, jak velká část těžebního výkonu signalizuje připravenost na nová pravidla. Po dosažení stanoveného prahu se pravidla aktivovala v předem definovaném okamžiku.

Takový mechanismus výrazně snižuje pravděpodobnost, že po aktivaci budou vznikat bloky porušující nová pravidla.

Signalizace těžařů ovšem není totéž jako hlasování o tom, jaká pravidla Bitcoin „má mít“. Těžaři vytvářejí bloky, ale validitu těchto bloků posuzují uzly. Provozovatel každého uzlu si sám vybírá software a tedy i pravidla, která jeho uzel vynucuje.

## Těžaři, uzly a uživatelé

Je užitečné rozlišovat role jednotlivých účastníků.

Těžař potřebuje vytvořit blok, který ostatní přijmou. Transakce pro tento blok typicky získává z mempoolu svého uzlu. Pokud jeho uzel používá jiná pravidla než uzly uživatelů, mohou se jejich představy o platnosti transakcí lišit.

Těžař samozřejmě může vytvořit i prázdný blok, takže samotný nesoulad ohledně mempoolu mu technicky nemusí zabránit v těžbě. Ekonomicky ale těžaři chtějí získávat také transakční poplatky a především potřebují, aby jejich bloky přijímala síť, na které má vytěžená odměna hodnotu.

Konsenzus Bitcoinu proto není jednoduché hlasování jediné skupiny. Těžební výkon je důležitý, ale stejně důležité je, jaká pravidla přijímají ekonomické uzly, burzy, peněženky, obchodníci a uživatelé.

## Kdy vzniknou „dva Bitcoiny“

Pokud hard fork skutečně vede k trvalému chain splitu, od společného bloku existují dvě historie. Uživatel, který před rozdělením vlastnil určitý UTXO, jej zpočátku zpravidla vlastní na obou větvích.

Která větev se bude nazývat „Bitcoin“, však samotný blockchain neurčuje.

Protokol neobsahuje proměnnou s názvem „Bitcoin“. Zná bloky, transakce, UTXO a satoshi, ale neví, jak jeho síť nazývají lidé nebo pod jakým tickerem se její měna obchoduje.

O tom, kterou větev bude společnost považovat za Bitcoin, se rozhoduje na sociální a ekonomické úrovni: podle toho, jakou větev podporují uživatelé, burzy, peněženky, obchodníci, poskytovatelé infrastruktury a další účastníci.

Proto může být technické rozdělení blockchainu přesně definované, zatímco otázka „který z nich je skutečný Bitcoin?“ už čistě technickou odpověď nemá.

## Replay protection

Při úmyslném rozdělení blockchainu vzniká ještě jeden praktický problém.

Pokud obě větve používají stejné formáty transakcí a stejné podpisové podmínky, může být transakce vytvořená pro jednu větev platná i na druhé. Někdo ji pak může vzít a přeposlat do druhé sítě.

Tomu se říká *replay*.

Hard forky, které chtějí vytvořit skutečně samostatnou měnu, proto často přidávají mechanismus *replay protection*: změní například způsob podpisu transakcí nebo jinou část protokolu tak, aby transakce vytvořená pro jednu větev nebyla platná na druhé.

Bez replay protection je manipulace s prostředky po rozdělení komplikovanější, protože je nejprve potřeba coiny na obou větvích bezpečně „oddělit“.

## Co si z toho odnést

Nejdůležitější rozdíl mezi soft forkem a hard forkem lze formulovat velmi jednoduše.

U **soft forku** platí:

**nově platné bloky ⊂ dříve platné bloky.**

Nové uzly tedy některé bloky, které by staré uzly přijaly, odmítají. Blok, který splňuje nová pravidla, však přijme i starý uzel.

U **hard forku** tato podmínka neplatí:

**nově platné bloky ⊄ dříve platné bloky.**

Existuje tedy alespoň nějaký blok, který přijme nový uzel, ale starý uzel jej odmítne.

A konečně **chain split** není druh forku, ale stav blockchainu: dvě části sítě pokračují v různých historiích.

Soft fork může chain split způsobit. Hard fork jej způsobit může, ale nemusí. Chain split může vzniknout i bez plánovaného forku.

Právě oddělení těchto tří pojmů — změna pravidel, vztah množin platných bloků a skutečné rozdělení historie — umožňuje o bitcoinových forcích uvažovat přesněji.