Bitcoinový slovníček pro mírně pokročilé

Anatomie bloku

K popisu anatomie bitcoinového bloku použijeme blok obsahující transakci z dílu anatomie transakce s pořadovým číslem 676274 a hashem 00000000000000000000706c7f21388b285414c4829ee3981398e0cac82e43e3. Následuje hexadecimální reprezentace serializace hlavičky bloku:

0000802094dbc3cc1db91c6a106f6fb55b6e99a0b80eccc84b6d0b0000000000000000006b63e7d1a32149535d3f429ff5f9e7d9b1b19326876faff54d19610d7923ae7d1ebc5c606fdf0c174bf00ded

barva hodnota význam formát
20800000 verze bloku 4 bajty LE
00…3db94 hash předchozího bloku 32 bajtů LE
d7ae2…6b merkle root; kořenový hash Merkleho stromu transakcí 32 bajtů LE
605cbc1e časové razítko (timestamp) 4 bajty LE
170cdf6f bits; stanovuje cíl těžby 4 bajty LE
ed0df04b nonce; změnou se dosahuje změny hashe, jinak nemá význam 4 bajty LE

Z verze, konkrétně prvních tří bitů zleva (001), můžeme vyčíst signalizaci podle BIP 9. Přítomnost hashe předchozího bloku je jasná, blok je tím – podobně jako oka řetězu – pevně spojen s předchozím blokem. Kořenový hash Merkleho stromu transakcí zaručuje, že se změna byť jediného bajtu v jediné do bloku zahrnuté tx projeví v konečném důsledku změnou hashe hlavičky tohoto bloku. Časové razítko říká, že k vytěžení bloku došlo 1616690206 sekund od 1/1/1970, tedy 25/3/2021 v 16:36:46 UTC. Tento údaj ovšem nemusí být zcela přesný. Aby byl blok přijat sítí, musí být časové razítko větší, než medián časových razítek posledních 11 bloků a menší než o dvě hodiny navýšený medián aktuálních časů uzlů, ke kterým je uzel připojen. Z pole bits si vypočteme target – první bajt (zleva) je exponent, zbytek koeficient. Zůstaneme‐li v hexa, bude target cdf6f × 10017−3. Porovnáme, je‐li hash našeho bloku menší než vypočtený target. Poslední pole obsahuje nonci, které se budeme věnovat později.

Za hlavičkou následuje LE varint s počtem transakcí v bloku a pak už serializace všech těchto transakcí. První z nich je ovšem speciální, tzv. mincetvorná (coinbase). Ta se oproti zbytku liší tím, že nemá žádný skutečný vstup, resp. technicky vzato má mincetvorná transakce právě jeden vstup – hash předchozí transakce je 32 bajtů nul, index výstupu je ffffffff, podpisový skript musí být v rozmezí 2 a 100 bajtů, a musí být sám o sobě pravdivý. Právě sem umístil Satoshi v genesis bloku legendární titulek Timesů, zatímco ve scriptSigu mincetvorné transakce našeho bloku si můžeme přečíst zprávu „Mined by AntPool713“. Od BIPu 34 se do podpisového skriptu mincetvorné transakce dává na první místo element s číslem bloku. Tím je zajištěno, aby bylo možno odlišit jinak stále stejné mincetvorné transakce jejich unikátním hashem txid. Navzdory tomu, že neutrácí žádné UTXO, může si těžař na výstupu uzamknout odměnu (v době psaní) až 6,25 BTC plus součet poplatků všech zahrnutých transakcí. Pokud blok obsahuje segwitovou transakci, musí také obsahovat OP_RETURN výstup s kořenem paralelního Merkleho stromu svědků (witness). Protože podpisové skripty segwit transakcí již nejsou součástí výpočtu hashe transakce, a jejich změna by se tedy neprojevila změnou kořenového hashe Markleho stromu v hlavičce bloku (a protože strukturu hlavičky nelze změnit soft-forkem), jsou hashe svědků (witness) transakcí zahrnuty do hlavního Merkleho stromu (a tím i do hashe hlavičky bloku) právě touto cestou. Díky tomu platí, že změna kteréhokoliv bajtu kterékoliv v bloku zahrnuté transakce se nakonec projeví změnou hashe bloku.

Velikost zahrnutých transakcí v bloku nesmí překročit 4 miliony WU. Na druhou stranu však nemusí blok obsahovat žádnou další transakci, kromě mincetvorné. To se dělo zejména v prvních měsících fungování sítě, nyní už jen zřídka.

Anatomie těžby

Tzv. těžba bitcoinu je způsob, kterým je vybírán takový příští náhodný zápisce do blockchainu, který bude mít ekonomickou incentivu nepokoušet se o podvodný zápis. Úkolem takového uchazeče o zápis příštího bloku do blockchainu je z dosud nepotvrzených transakcí sestavit tzv. kandidátský blok a ten upravit do takové podoby, aby byl hash hlavičky tohoto bloku menší, než tzv. cíl těžby, nebo‐li target. Ten byl v genesis bloku nastaven na ffff × 1001d-3. Od té doby je jednou za 2016 bloků (tzv. epocha obtížnosti) přepočítáván tak, že se spočte rozdíl časového razítka posledního a prvního* bloku končící epochy. Pokud je tento vypočtený rozdíl větší než osm týdnů, použije se dále hodnota osmi týdnů; pokud je vypočtený rozdíl menší než 84 hodin, použije se dále hodnota 84 hodin. Nový cíl = předcházející cíl × rozdíl ÷ 2 týdny. Tímto postupem se postupně došlo i k cíli výše popsaného bloku (cdf6f × 10017-3).

Jelikož výstup hashovací funkce nelze předvídat, je splnění této podmínky věcí náhody. Této náhodě lze jít naproti jedině tím, že je zahashováno a otestováno co možná nejvíce hlaviček bloku v co možná nejkratším čase. K tomu právě slouží pole nazvané nonce. S rozsahem 4 bajty dává bez změny zbytku hlavičky přes 4 miliardy možný hashů. Protože hlavička obsahuje také každou vteřinu měnící se timestamp, lze díky nonci testovat přes 4 miliardy hashů každou vteřinu. Těžaři (těžařské pooly) s výkonem přes 4 miliardy hashů za sekundu pak mohou paralelně testovat různé kandidátské bloky, lišící se v pořadí zahrnutých transakcí, čímž je zase dosaženo různých kořenů merkle stromu transakcí.

Jakkoliv je vytěžení (najití takové podoby hlavičky, která zahashováním dá relativně nízké číslo – cíl těžby) výpočetně velmi náročné – v době psaní toho pojednání vypočítají všichni těžaři v síti přes 170 miliard miliard hashů za vteřinu, aby jeden z nich objevil průměrně jednou za 10 minut vyhovující hash – ověření celého bloku je ve srovnání s tím až legračně jednoduché – za tímto účelem stačí provést pouhé tisíce výpočtů hashe. Tím je zajištěna krajní nevýhodnost pokusů o podvádění či porušení pravidel při těžbě, neboť to by bylo nesrovnatelně jednodušeji a rychleji odhaleno.

Těžba tedy není žádné „řešení komplexního matematického problému“, jako to tvrdí např. Dr. Sheldon Cooper v TBBT S11E09. Je to problém veskrze jednoduchý – tak dlouho hashovat hlavičku sestaveného bloku s různými noncemi, měnícím se časovým razítkem a eventuelně i různými ariantami stromu transakcí, až nám vyjde hash menší, než cíl těžby.

* toto je bug. Správně by se měl použít rozdíl razítka posledního bloku končíčí epochy a posledního bloku epochy předcházející té končící.