Článek Chystá se další významný upgrade bitcoinového protokolu. Zatím ale není shoda na tom, jak změnu vynutit využil chystanou implementaci Taprootu k lehkému uvedení do problematiky bitcoinové governance a přijímání změn v bitcoinovém protokolu. Jak ale vyplynulo ze čtenářské zpětné vazby, ne každému je jasné, jaká a jak zásadní změna se to vlastně chystá.
Taproot (BIP 341), jehož implementace do protokolu proběhne s ještě další změnou v podobě Schnorrových podpisů (těmi se podrobně zabýváme v článku Jak odlehčit Bitcoinu a jako bonus získat víc soukromí), protože obě technologie hodně těží ze vzájemné synergie, přináší určité zlepšení ochrany transakčního soukromí, zmenšení transakční velikosti a otevírá dveře větší flexibilitě práce se smart kontrakty, než bylo dosud u Bitcoinu myslitelné.
S návrhem přišel začátkem letošního roku jeden z nejaktivnějších Bitcoin Core vývojářů (a spoluzakladatel společnosti Blockstream) Pieter Wuille. Dnes na dolaďování návrhu pracují nejaktivnější přispěvatelé do Bitcoin Core kódu (Anthony Towns, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Ruffing, Rusty Russell či Gregory Maxwell).
Co přesně dělá a jak souvisí právě se Schnorrovými podpisy, což je sofistikovanější (a přitom paradoxně starší) alternativa k podepisování transakcí pomocí technologie eliptických křivek (ECDSA)?
Taproot a Schnorrovy podpisy jako (téměř) nerozlučná dvojice
Obě změny mají společný prekurzor, totiž SegWit. Protože s příchodem SegWitu došlo (mimo jiné) ke změně v podobě platebních skriptů (scriptPubKey), zavedl SegWit verzování skriptů. Tato zdánlivě jen dokumentační funkce v praxi umožňuje vytvářet zpětně nekompatibilní změny v platebních skriptech. Tedy, ne, že by k rozšiřování platebních skriptů nemohlo docházet a nedocházelo již před tím, ale nebylo to moc čisté, a už vůbec ne neproblematické (kvůli narůstající komplexitě). Každopádně s příchodem verzování skriptů přibyly nové možnosti, například 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 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 smart kontrakt (Bitcoin k tomu dnes musí využívat Pay-to-ScriptHash). Trik je v tom, že se ověření provádí na kryptografické vrstvě, a nikoli ve vrstvě skriptovací, což s sebou navíc přináší i vyšší bezpečnost (vyloučení skriptovacích chyb).
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 chceme odeslat velké množství transakcí z více našich adres na jinou, musíme 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ý 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, protože tím, jak transakce narůstá na objemu, uzurpuje místo ostatním, které by se do těženého bloku také rády dostaly. Schnorr oproti tomu dosahuje toho, že i takováto transakce obsahuje jen jediný podpis, a byla přesto stejně bezpečná a snadno ověřitelná. Vedlejším benefitem je také větší soukromí, protože všechny transakce v podání Schnorr Signatures vypadají stejně, nepoznáte totiž, zda se jedná o běžnou transakci, nebo o MultiSig transakci.
Jak do toho zapadá Taproot
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í kontraktu. Díky tomu je například možné celkem snadno rozlišit jednoduché transakce (podpis jedním klíčem) od složitějších chytrých kontraktů s časovými zámky, více podpisy (multisig), případně kombinací těchto a dalších podmínek.
Zatímco podmínky samotné nejsou před utracením transakce veřejně viditelné, v momentě, kdy se dostane transakce do blockchainu, je již situace jiná, majitel (nebo majitelé) transakce musí odhalit celý skript a jeho řešení, aby bylo možné ověřit, že skutečně došlo ke splnění podmínek pro utracení. Dochází přitom (typicky u multisig transakcí) k odhalení celého řešení, tedy i podmínek, které splněny nebyly (k utracení jsou například potřeba dva podpisy a nesmí k němu dojít před určitým datem, majitelů klíčů je ale více). To přináší hned několik nevýhod. První z nich je zbytečný nárůst posílaných dat, druhou pak, že je to velmi špatné řešení z hlediska ochrany soukromí. Útratou se totiž odhalí všechny možné způsoby, jak bylo možné transakci utratit, z čehož společnosti zabývající se blockchainovou analýzou dovedou odvodit spoustu zajímavých věcí (například jaká byla použita peněženka, kdo další mohl prostředky utratit atd.).
Již delší dobu existuje návrh, jak tento problém obejít, který dosud ale nebyl do bitcoinového protokolu implementován. Říká, že můžeme všechny podmínky útraty transakce individuálně zahashovat a vložit je do tzv. Merklova stromu, který z nich vytvoří jeden hash (Merkle root). Pokud následně dojde k útratě transakce, stačí k jejímu ověření jen samotný Merkle root (no dobře, také ještě několik přidružených dat – tzv. Merkle path). Ten totiž úplně postačuje k ověření toho, že v něm byla určitá specifická data obsažena, a neodhaluje přitom zbytek v něm zahashovaných dat. Dojde tak pouze k odhalení splněné podmínky a zákonitě také k tomu, že byla pro danou transakci tato datová struktura využita. Takovému řešení se říká MAST (Merkelized Abstract Syntax Tree).
Taproot a Schnorr ale vedou k tomu, že z utracené transakce nelze poznat, že 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 jde o další sadu instrukcí, jak definovat podmínky utracení, která dokáže dokonale skrýt, jak složitá struktura (skript) se za transakcí skrývá.
Můžeme například daný pár klíčů (pro názornost zjednodušujeme) vynásobit dvěma. Klíče budou stále platné a schopné podepsat transakci a při pohledu z venku 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 (včetně třeba uzavírání Lightning network kanálů – varianta 2-of-2 multisig, nebo atomic swapů) na blockchainu jako jednoduchá transakce.
Taproot obsahuje vlastní verzi Merklova stromu nazvanou „script tree“. Ten, kdo definuje podmínky utracení transakce, může volit mezi útratou s pubkey (běžná transakce) a útratou se skriptem. Důležité je, že Merkle root stromu je v Taprootu skrytý a umožňuje přímé utrácení. Na blockchain míří jediný klíč a nikdo nevidí zbylé podmínky 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ě. V praxi tak již (doufejme) vůbec nebude možné rozlišit Pay-to-Public-Key-Hash od Pay-to-Script-Hash transakcí. Výsledkem je větší ochrana soukromí i úspora místa v blockchainu. V teorii to zní hezky, v praxi bude ale samozřejmě hodně záležet na tom, jaká bude ochota řešení podporovat ze strany tvůrců populárních bitcoinových peněženek.
Když už je řeč o lepší ochraně soukromí, Taproot otevírá dveře také dalším vylepšením, například použití tzv. Adaptor Signatures u Atomic Swapů (metoda P2P výměny kryptoměn mezi dvěma stranami). Ty pak lze využít podobně, jako je dnes využíván mechanismus CoinJoin (způsob kombinování více plateb z různých zdrojů do jedné transakce), tedy coby mixovací nástroj. Také tyto transakce se budou na blockchainu jevit jako jakákoli jiná běžná transakce.
ČLÁNKY DO MAILU