Tajemné označení Taproot (formálně BIP 341) pod sebou skrývá velmi zajímavou technologii, která by měla přinést do bitcoinového protokolu zlepšení ochrany transakčního soukromí a otevírá dveře mnohem větší flexibilitě práce se smart kontrakty, než bylo dosud myslitelné.
S návrhem již rovnou v podobě BIP přišel 19. ledna letošního roku jeden z nejaktivnějších Bitcoin Core vývojářů (a spoluzakladatel společnosti Blockstream) Pieter Wuille a rychle si naklonil většinu zbývajících Bitcoin Core přispěvatelů. Na dolaďování návrhu se poslední půlrok velmi intenzivně pracovalo, a je tak již víceméně jasné, že by si měl najít cestu do některé z blížících se nových verzí Bitcoin Core a následně pravděpodobně i dalších v síti stále živých implementací klientského softwaru. Nebo ne?
Ne tak rychle. Taproot představuje poměrně signifikantní změnu bitcoinového protokolu, a přestože se jedná o tzv. softfork (změnu zpětně kompatibilní – pouze přidává či zpřísňuje dosavadní pravidla, ale nemění ta stará), jeho implementace bude vyžadovat souhlas majority sítě. Taproot totiž představuje zásah do konsensus protokolu. Naposledy byl takovýto zásah (SegWit – BIP141) implementován podle pravidel BIP 9, která vznikla právě pro potřeby softforků (umožňuje implementaci více forků ve stejný čas).
Jenže to se právě málem ukázalo jako osudné, protože domluvená aliance minerů využila svého práva signalizace připravenosti na změnu k dlouhodobému blokování upgradu, politickému vydírání zbytku sítě a prosazování vlastních zájmů, které byly v očividném rozporu se zájmem většiny dalších účastníků.
To přimělo bitcoinové vývojáře k bouřlivé diskuzi o tom, podle jakých pravidel by se měl odehrát následující podobný upgrade. Otázka není zrovna jednoduchá, vyplývá jednak z potřeby zachovat co nejdemokratičtější povahu governance protokolu a také z čistě 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.
V dávných dobách ještě za Satoshiho…
BIP 9, podle kterého nakonec po velkých bojích úspěšně proběhla aktivace SegWitu, vychází z prastarého konceptu, který sahá až k legendárnímu Satoshimu Nakamotovi – tzv. „flag days“. Vývojáři, kteří vytvářejí referenční klientskou implementaci, vložili do současného kódu datum, od kdy začnou platit nově připravené změny v kódu, a mineři i uživatelé byli motivováni před tímto datem provést upgrade svých klientů, aby se zabránilo případnému rozdělení sítě.
V této době ležela rozhodovací síla převážně na straně vývojářů (podobně, jako je tomu dnes u většiny altcoinů, ale také například u alternativních konceptů, jako třeba u Etherea), což v počátku úplně nevadilo, ale dlouhodobě to nebyl ani ideální, ani udržitelný stav.
Od roku 2012 se proto začíná 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 musí každou větší změnu v konsensuálních pravidlech protokolu 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.
Celý koncept se postupně vyvíjel 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ůvodní vizi vypadalo vše optimálně. Mineři dostali rok, aby aktivovali upgrade, vyžadující signalizaci z 95 % bloků při libovolné obtížnosti, připravenost 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.
V případě SegWitu, o jehož prospěšnosti panovala v komunitě víceméně shoda, ale klika minerů, která spolu předtím jednala za zavřenými dveřmi, využila signalizace vyloženě 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 tehdy profitovaly prakticky jen tyto dvě skupiny (velké bloky, podpora ASIC boost), a získat bezprecedentní rozhodující vliv na další vývoj bitcoinového softwaru. Ve hře se objevilo i zneužívaní 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 softfork 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í.
Alternativy
Jedním z možných řešení je návrat k BIP 8 od Bitcoin Core vývojáře Luke-jr, dnes již trochu archaické alternativě BIP 9. Princip je podobný jako u BIP 9, ale namísto toho, aby nedostatečná podpora hashpower vedla po roce k selhání upgradu, stane se přesný opak (aktivace softforku v daný čas). Nody po stanoveném datu začnou vynucovat nová pravidla a mineři, kteří podle nich netěží, riskují odmítnutí svých bloků. To je ale ve finále podobná nerovnováha moci jako v případě minerů a BIP 9, tentokrát ale přenesená na vývojáře, kteří v daném případě zneužívají uživatele k vynucení změny. Pozdější varianty návrhu BIP 8 proto přicházejí s možností, kdy si uživatel může zvolit, zdali se po vypršení data pro aktivaci začnou nová pravidla vynucovat, nebo ne.
Novější návrh obsahuje ještě další technickou úpravu, která zajišťuje plynulejší upgrade sítě, nechceme zde ale zacházet příliš do detailu. Hlavní slabina BIP 8 zůstává totiž pořád stejná: zvyšuje riziko (obzvlášť pokud je na signalizaci jen krátký čas), že většina hashpower neprovede včas upgrade (na rozdíl od uživatelů je motivace minerů k upgradům jiná), a dojde tak k rozdělení sítě se všemi vyplývajícími konsekvencemi. Další problematický aspekt novějšího návrhu je ten, že defaultně vypnutá vynucená signalizace vyžaduje iniciativu od samotných uživatelů a zanechává jejich aktivitu nekoordinovanou, což opět může přinést zmatky a v důsledku rozdělení sítě. Opačný scénář vychyluje mocenské závaží výrazně ve prospěch Bitcoin Core vývojářů.
Nicméně existují i jiné alternativní návrhy. Velmi slibně vypadá zejména Modern Soft Fork Activation, se kterým přišel bitcoinový vývojář a ideový autor mining protokolu BetterHash Matt Corallo.
Mechanismus Modern Soft Fork Activation je vlastně kombinací tří kroků. V prvním mají mineři možnost aktivovat softfork skrze signalizaci připravenosti, pokud ji bude signalizovat potřebné množství hashpower, tedy stejně jako v případě BIP 9. Pokud se tak nestane za stanovený čas, vyprší první okno pro aktivaci a nic se nestane. V druhém kroku dojde k revizi návrhu ze strany vývojářů, kteří pečlivě zanalyzují, proč aktivace selhala, a případně začnou řešit objevené technické problémy. Pokud nenajdou žádný technický problém, nastupuje krok tři.
Ten spočívá v aktivaci podle BIP 8 s „flag day“ aktivací. Tedy těžaři mají druhou šanci provést upgrade svých klientů a signalizovat připravenost a po dosažení potřebné hashrate aktivovat softfork. Pokud tak ale neučiní (naschvál, nebo z pohodlnosti), aktivuje se fork po skončení signalizační periody sám.
Hlavní výhodou celého procesu je velmi dlouhý čas, po který je nový kód všem participujícím stranám k dispozici, takže je možné se na upgrade pohodlně připravit a případně v něm objevit chyby. Mineři také případným blokování upgradu mohou získat pouze „trochu času“ (v praxi to může být klidně i několik let) navíc. Hlavní protiargument je paradoxně prakticky tatáž vlastnost. Pokud totiž mineři budou upgrade v první fázi blokovat, může se upgrade sítě protáhnout klidně i o několik let.
Celá diskuze je v současné době velmi živá a objevují se další a další nové návrhy, ať již jde o modifikace BIP 9 a BIP 8, nebo o relativně originální přístup, jako v případě konceptu Probabilistic Bitcoin softforků (zkráceně Sporks) Jeremyho Rubina, kde v aktivaci softforku hraje zásadní roli náhoda, statistická pravděpodobnost a ekonomická motivace.
Miner v případě odmítnutí aktivace, která v daném případě představuje určitou výsadu (stejně jako samotné uhádnutí nonce a vytěžení bloku), stojí před volbou aktivovat softfork, nebo přijít o odměnu za vytěžený specifický blok, na který lze statisticky narazit jen za určitou jednotku času.
To je ale přes veškerou zajímavost již opravdu zatím jen hudba budoucnosti a vzhledem k tomu, jak „rychlý“ je vývoj bitcoinového protokolu, zřejmě ještě poměrně vzdálené. Jakým způsobem bude aktivován Taproot? Debata na toto téma běží právě teď a nové návrhy se objevují prakticky každý týden. Nechme se tedy překvapit.
