Hlavní navigace

Taproot: co přesně nejnovější upgrade bitcoinového protokolu přinese?

16. 6. 2021
Doba čtení: 11 minut

Sdílet

 Autor: Depositphotos
Když jsme se na začátku loňského roku zmiňovali o dvou chystaných upgradech bitcoinového protokolu, věnoval jim pozornost málokdo, dnes se alespoň o tom prvním píše v celoplošných médiích a slovo Taproot skloňuje kdejaký kryptoinfluencer. Co ale doopravdy znamená a přináší opravdu takovou revoluci?

Taproot (formálně BIP 341) je první větší upgrade bitcoinového protokolu od aktivace Segregated Witness v roce 2017. Do bitcoinového protokolu přináší zlepšení ochrany transakčního soukromí a otevírá dveře větší flexibilitě práce se smart kontrakty.

Za duchovního otce Taprootu lze považovat bývalého CTO Blockstreamu, Gregoryho Maxwella, který s jeho prvotní ideou přišel v lednu 2018. Zhmotněnou (a upravenou) podobu ve formě hotového BIP (Bitcoin Improvement Proposals) společně s dalším velkým pozměňovacím návrhem (viz článek Jak odlehčit Bitcoinu a jako bonus získat víc soukromí) ale dodal až loni v lednu spoluzakladatel společnosti Blockstream, Pieter Wuille. K dolaďování návrhu, které probíhalo podstatnou část celého minulého roku, se připojila nejaktivnější skupina přispěvatelů do Bitcoin Core kódu, tedy jména jako Anthony Towns, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Ruffing, Rusty Russell a sám Maxwell.

Současný důvod popularity Taprootu je jednoduchý, vedle očekávaných benefitů zejména ohledně většího uživatelského soukromí je jím až překvapivě hladce dosažený konsensus mezi minery ohledně upgradu protokolu. Jinými slovy to znamená, že se v čase vymezeném od jednoho přepočtu obtížnosti do dalšího podařilo dosáhnout shody více než 90 % aktivních minerů. Respektive, což je o něco přesnější, více než 90 % vytěžených bloků signalizovalo upgradu podporu. Ještě loni na podzim situace tak jasná nebyla a navzdory všeobecné shodě ohledně pozitivních dopadů upgradu na uživatele představoval postoj zhruba poloviny minerů velkou neznámou. Vedle menších poolů váhal ve vyjádření podpory upgradu například Binance Pool.

Referenční klientský software, Bitcoin Core, obsahuje kód Taprootu již od verze Bitcoin Core 0.21.0, kde byl ovšem bez aktivační logiky, takříkajíc k veřejnému náhledu. Nyní tak může nastat další krok, a to ten, že BC klienti od verze 0.21.1 začnou od podzimu nová pravidla prosazovat, což vyústí právě v aktivaci Taprootu. Vezměme to ale popořadě.

Proč se kolem celkem nekontroverzního upgradu dělaly takové tanečky?  

Taproot představuje poměrně výraznou změnu oproti současné podobě bitcoinového protokolu, a přestože se jedná o tzv. soft fork (změnu zpětně kompatibilní – pouze přidává či zpřísňuje dosavadní pravidla, ale nemění ta stará), jeho implementace vyžadovala souhlas majority sítě, protože Taproot přináší zásah do konsensus protokolu. 

Naposledy byl podobný zásah (SegWit – BIP141) implementován podle pravidel BIP 9, která vznikla právě pro potřeby soft forků (umožňuje totiž implementaci více forků ve stejný čas). Tato implementace ovšem právě z důvodu nedostatečné shody neprobíhala úplně hladce (jedním z vedlejších důsledků byl i vznik Bitcoin Cash), a tak panovala částečně oprávněná obava, že by se podobná situace mohla opakovat. 

BIP 9 se totiž plánovaný upgrade zadrhl na tom, že domluvená aliance minerů využila svého práva signalizace připravenosti na změnu k dlouhodobému blokování upgradu a politickému vydírání zbytku sítě. Vše vyústilo ve vytvoření protialiance, která vyhrožovala aktivací vlastního (taktéž kontroverzního) soft forku sítě – USAF (user activated soft fork), definovaného v BIP148. Situace hrozila rozdělením sítě a obrovským chaosem. 

Mineři nakonec v této hře na kuře povolili a své původní záměry realizovali na vlastním altcoinu forknutém z hlavního BTC chainu. Vyostřená diskuze z této doby se nicméně přenesla i do loňských úvah o aktivaci Taprootu a navzdory dosaženému kompromisu se někteří radikálnější vývojáři stále nevzdali ideje vlastního klienta s násilnou aktivací v USAF stylu.

Proč je to problém?

Vraťme se na chvilku k aktivaci SegWitu, která po peripetiích nakonec proběhla standardně podle BIP 9. Ten vychází z konceptu, který sahá až k Satoshimu Nakamotovi – tzv. „flag days“. Vývojáři, kteří vytvářejí referenční klientskou implementaci, vloží do kódu datum, od kdy začnou platit nově připravené změny v kódu, a mineři i uživatelé jsou motivováni před tímto datem provést upgrade svých klientů, aby se zabránilo případnému rozdělení sítě. Tento model mohl skvěle fungovat v době, kdy ležela rozhodovací síla převážně na straně vývojářů, to ale dlouhodobě nebyl ani ideální, ani udržitelný stav, jak dokládají příběhy některých altcoinů, které se z podobného stavu governance nikdy nevymanily. 

Od roku 2012 se proto začal nasazovat nový koordinační mechanismus, který využívá hashovací sílu pro hlasování o tom, kdy se na nová pravidla přejde. Mineři každou větší změnu v konsensuálních pravidlech protokolu musí odsouhlasit většinou (95 %) současné hashing power. Děje se tak prostřednictvím vložení malého kusu signalizačního kódu do jimi vytěžených bloků. Nová pravidla tak nezačnou být vynucována dříve, než většina minerů upgraduje software a nezačne signalizovat jejich podporu. Tento koncept se postupně vyvinul právě až do podoby BIP 9, který byl použit právě během velmi problematické aktivace SegWitu, kdy to vypadalo, že mineři mohou držet zbytek participantů sítě libovolně dlouho v šachu.

V případě SegWitu mineři dostali rok, aby aktivovali upgrade, vyžadující signalizaci z 95 % bloků při libovolné obtížnosti, připravenost pak měli dát najevo signalizačním bitem. Pokud by se tak po roce nestalo (předpokládalo se z technických důvodů), aktivační doba vypršela a upgrade selhal, což měla být zpětná vazba pro vývojáře, aby se nad kódem ještě zamysleli.

Tehdy významná klika minerů, která spolu předtím jednala za zavřenými dveřmi, ovšem využila signalizace jako nástroj zablokování upgradu, aby se část sítě mohla pokusit prosadit konkurenční návrh Segwit2× (kontroverzní hard fork podle dohody společností Bitmain, BitFury, Purse a těžebních poolů F2Pool a ViaBTC na blockchainové konferenci Consensus 2017), ze kterého by tyto dvě skupiny profitovaly na úkor části sítě (velké bloky, podpora ASIC boost) a, což je závažnější, získaly by fakticky rozhodující vliv na další vývoj bitcoinového softwaru. Ve hře se objevilo i zneužívání některých dalších vlastností signalizace, to ale teď není zase tak podstatné.

SegWit v původní podobě se nakonec u Bitcoinu aktivovat podařilo, ale až po sérii dramatických akcí a zvratů. Nejprve naštvaní vývojáři a uživatelé alternativních bitcoinových klientů přišli s novým aktivačním schématem (BIP 148), který dělal to, že klient akceptoval jako validní pouze bloky, které signalizovaly podporu pro SegWit, počínaje tzv. „flag day“, a pokusili se tak vynutit soft fork oklikou sami. 

Paralelně mineři odpověděli nasazováním klienta btc1 s implementací BIP 91, což byl návrh Bitmain inženýra Jamese Hilliarda, který podobnou oklikou vedl k aktivaci SegWitu, ale zároveň byl kompatibilní s dohodou za zavřenými dveřmi z konference Consensus 2017 a snižoval požadavek z 95% konsenzu na 75%. Celá situace měla všechny rysy klasické hry na kuře, jednoho ze základních konfliktů v teorii her. Zde ovšem s tím rozdílem, že obě skupiny si coby rukojmí navíc k sobě vzali i všechny jinak v těchto politických hrách nezainteresované uživatele Bitcoinu.

Ve hře na kuře každý hráč (zde zjednodušeně uživatelé vs. mineři) sleduje svůj zájem a jde o to, kdo v konfliktní situaci podlehne nátlaku a stane se tak „kuřetem“. Účastníci hry volí tahy paralelně a nemohou se domlouvat. Klasickým příkladem takové hry jsou dvě auta jedoucí proti sobě po úzké silnici. Každý řidič může buď strhnout řízení a druhému se vyhnout, nebo pokračovat v jízdě. Pokud řidič neuhne, ale soupeř ano, vyhrává. Pokud řidič uhne, zajistí sobě i soupeři přežití, ale projevil se jako slabší. Když uhnou oba, nikdo z nich nezíská kýženou prestiž, a konečně, když neuhne žádný z řidičů, dojde ke srážce a rozhodnutí bude fatální pro obě strany. Přesně tak vypadaly vyhlídky bitcoinové sítě v červenci 2017. Jako pomyslné kuře se nakonec zachovala k velké úlevě všech zúčastněných (nikdo tehdy nepočítal s nástupem Bitcoin Cash) aliance minerů, která si spočítala, že by je reálně hrozící rozdělení sítě a s ním ruku v ruce jdoucí rapidní pokles zisků zabolely v první fázi asi výrazně více. Jedna věc ale byla zřejmá, BIP 9 není do budoucna optimální řešení.

Situace nicméně po zažehnání krize přiměla bitcoinové vývojáře k bouřlivé diskuzi o tom, podle jakých pravidel by se měly vlastně odehrávat podobné změny v budoucnu. Tato diskuze se znovu rozvířila právě loni v souvislosti s aktivací Taprootu. Proti sobě totiž stály tři dominující tendence – snaha zachovat co nejdemokratičtější povahu governance protokolu a praktické potřeby maximálně eliminovat riziko rozdělení sítě na dva nekompatibilní chainy pracující podle odlišných pravidel a zároveň zbytečně nebrzdit vývoj.  

Bouřlivá diskuze, v níž vedle USAF aktivace padly i návrhy jako návrat k prapůvodnímu BIP 8, nakonec skončila docela rozumným kompromisem v podobě tzv. Speedy Trial aktivačního mechanismu. Během něho mají mineři tři měsíce na vyjádření podpory pro upgrade. Pokud se během této doby podaří alespoň v jednom okně střídaní obtížnosti (trvá přibližně dva týdny) dosáhnout toho, že 90% vytěžených bloků (alespoň 1815 bloků) signalizuje podporu, dojde k uzamčení upgradu a ten se aktivuje s blokem 709 632, který vychází někdy na letošní listopad. Taková situace nastala koncem minulého týdne, takže nyní mají všichni mineři, uživatelé využívající plnohodnotné klienty, ale také burzy a další projekty pět měsíců na to, aby se na upgrade připravili.

To znamená především upgradovat na kompatibilní software, byť se jedná o soft fork a změny jsou zpětně kompatibilní. Také by bylo fajn učinit některá preventivní bezpečnostní opatření.  

Co Taproot doopravdy přinese a proč tvoří spojené nádoby se Schnorrovými podpisy

Aktivace Taprootu proběhne společně se změnou podpisového algoritmu na tzv. Schnorr Signatures. Ten konečně nahradí eliptické křivky (ECDSA), které měly své mouchy již v době vzniku Bitcoinu, ale na které, na rozdíl od Schnorr Signatures, neexistovala v době vzniku návrhu bitcoinového protokolu žádná patentová práva.

Proč obě změny přijdou na řadu současně?

Začněme od Adama, respektive od Schnorra. Schnorr Signatures jsou elegantním řešením lineárního nakládání s podpisy, které řeší úsporu kapacity v bloku a lepší ochranu soukromí. Za jejich ideou stojí německý kryptograf Claus-Peter Schnorr, který je představil již v 80. letech (oficiální akademický dokument pochází z roku 1991) a vychází z prací Davida Chauma, Tahera Eigamala, Amose Fiata a Adi Shamira. Schnorr Signatures i Taproot mají společný prekurzor v podobě SegWitu. S jeho příchodem totiž došlo k zavedení verzování platebních skriptů (scriptPubKey). Tato zdánlivě jen dokumentační funkce v praxi umožňuje bezpečným způsobem vytvářet zpětně nekompatibilní změny v platebních skriptech.

S příchodem verzování skriptů také přibyly nové možnosti, jako je schopnost změnit podpisový algoritmus nebo přijít s úplně novým OPcodem. A tím se obloukem dostáváme zpátky ke Schnorrovým podpisům a Taprootu. Obě technologie totiž v důsledku vedou k optimalizaci a obfuskaci transakčního kódu.

Schnorr Signatures optimalizují kapacitu bloků tím, že úsporněji pracují se vstupy a s podpisy transakcí – umožňují jejich agregaci do jednoho. Výsledkem pak je i to, že transakce Schnorr MultiSig jsou nerozeznatelné od běžných jednoduchých transakcí. Schnorr navíc MultiSig (transakce obsahující více podpisů z různých zdrojů) na rozdíl od ECDSA podporuje nativně a nepotřebuje k nim extra řešení (Bitcoin k tomu dnes využívá Pay-to-ScriptHash).

Abyste mohli provést bitcoinovou transakci, musíte každý neutracený výstup podepsat, všechny tyto podpisy pak ale následně zabírají místo v blocích bitcoinového blockchainu. Pokud chcete odeslat velké množství transakcí z více adres na jinou, musíte podepsat každou z nich zvlášť. Tím ale transakce může nabobtnat i do té míry, že je pak transakční poplatek neúměrně vysoký vůči posílané částce v BTC. Veškerá data v podpisu totiž zvětšují velikost transakce a právě z velikosti se vypočítává transakční poplatek. Schnorr oproti tomu dosahuje toho, že i takováto transakce obsahuje jen jediný podpis, a je přesto stejně bezpečná a ověřitelná. Dalším efektem je pak větší soukromí, protože všechny transakce v podání Schnorr Signatures vypadají stejně. V síťovém provozu tak můžete snadno zamaskovat MultiSig transakce.

Problém dnešních bitcoinových transakcí z hlediska ochrany soukromí je ten, že lze u již utracených transakcí vidět podmínky, které byly stanoveny pro utracení. Díky tomu je možné snadno odlišit jednoduché transakce (podpis jedním klíčem) od složitějších kontraktů s časovými zámky, více podpisy (multisig) a případně kombinací těchto a dalších podmínek. A zde se konečně opět dostáváme k samotnému Taprootu.

Ten totiž umožňuje, že lze všechny podmínky útraty individuálně zahashovat a vložit je do tzv. Merklova stromu, který z nich vytvoří jediný hash (Merkle root). Pokud následně dojde k útratě transakce, stačí k jejímu ověření samotný Merkle root (respektive tzv. Merkle path), který postačuje k ověření toho, že v něm byla určitá specifická data obsažena, a neodhaluje přitom zbytek zahashovaných dat. Dojde tak pouze k odhalení splněné podmínky a k odhalení toho, že byla pro danou transakci tato datová struktura využita. Hovoříme o tzv. MASTu (Merkelized Abstract Syntax Tree).

Taproot zkombinovaný se Schnorrovými podpisy pak vede k tomu, že z utracené transakce nelze poznat, zda byla MAST syntaxe vůbec užita. V případě Schnorru dochází k agregaci více podpisů do jednoho, stejného triku lze využít právě u multisig transakcí, které pak vypadají jako jednoduché. Taproot využívá vlastností Schnorru, aby toto řešení ještě vylepšil. Zatímco Schnorr do bitcoinového protokolu přidává nový typ podpisu, Taproot na tom staví zavedením nové verze transakčního výstupu a nového způsobu definování podmínek utracení transakce. 

Jinými slovy, máme zde novou sadu instrukcí, jak definovat podmínky utracení, která dokáže skrýt, jak složitá struktura (skript) se za transakcí skrývá. Představme si, že například vynásobíme pár klíčů dvěma. Klíče budou stále platné a schopné podepsat transakci a při pohledu zvenku nikoho ani nenapadne, že jsme klíče daným způsobem vylepšili. Navenek totiž budou vypadat jako jakékoli jiné páry klíčů. Díky Taprootu pak vypadá jakýkoli kooperativní výstup (uzavírání Lightning network kanálů – varianta 2-of-2 multisig nebo atomic swapů) na blockchainu jako jednoduchá transakce.

Zjednodušeně řečeno, zatímco Schnorr zajišťuje, aby transakce s více podpisy (multisig) vypadaly jako „obyčejné“ Pay-to-Public-Key-Hash transakce, přidání Taprootu rozšiřuje množinu transakcí, které mohou ve finále na blockchainu vypadat podobně.

Autor článku

Externí spolupracovník serveru Lupa.cz a expert na blockchain a kryptoměny. Jako šéfredaktor v minulosti vedl ADASTRA Business Intelligence Magazine a server ITbiz.cz. Dnes pracuje jako redaktor časopisu Forbes.