Drivechainy, stejně jako softchainy, jsou další implementací sidechainu s funkcí obousměrného kolíku.
Toto je názorový editorial Shinobiho, samouka v oblasti Bitcoinu a moderátora technicky zaměřeného Bitcoin podcastu.
Tentokrát budu rozebírat a diskutovat o tom, jak drivechainy fungují; původně byly navrženy v roce 2015. Ze všech dosud probíraných návrhů jsou drivechainy nejstarší a nejpropracovanější z hlediska konkrétních implementačních detailů a designu, zdokumentované v BIP 300 a 301. Paul Sztorc, tvůrce konceptu, měl na mysli několik hlavních cílů návrhu, a i když to není vůbec vyčerpávající, zde je několik z nich:
- Izolovat každý sidechain tak, aby případné selhání nebo problém ovlivnil pouze ty, kteří jej používají.
- Umožnit roztočení sidechainu, aniž by bylo nutné pro každý z nich vytvářet nový fork.
- Umožnit převod bitcoinů do sidechainu a z něj pomocí obousměrného peg.
- Umožnit volné experimentování v designu, o kterém doufá, že by zastaral potřebu altcoinů.
Existují dva základní aspekty celého designu, což je důvod, proč existují dva samostatné BIPy. Prvním je mechanismus peg (BIP300), který umožňuje fungování obousměrného pegu. Sztorc navrhl něco, čemu se říká hash rate escrow, což v nejzákladnějším pojetí umožňuje těžařům jako amorfní skupině kolektivně opatrovat mince ve všech sidechainech. Druhým je „slepé“ schéma sloučené těžby, kde je cílem umožnit těžařům bitcoinů být producenty bloků na úrovni konsensu, aniž by k tomu museli validovat sidechain. Obě tyto části dohromady představují obousměrný peg mechanismus a způsob, jak se těžaři bitcoinů mohou podílet na těžbě v sidechainech a zároveň se snaží zmírnit riziko centralizace, které představuje.
BIP300 specifikuje logiku pro návrh nového sidechainu, aktivaci nového sidechainu, návrh svazkové sady výběrů, schválení takové sady výběrů, logiku validace pro skutečné transakce výběru a validace pro transakce vkladu.
Aktivace nového sidechainu v rámci návrhu drivechainu je velmi podobná procesu soft forku aktivovaného prostřednictvím signalizace těžařů. Hlavní rozdíl je ovšem v tom, že ve skutečnosti nejde o soft fork – jediný fork pro aktivaci pravidel konsensu drivechainu umožňuje těžařům kdykoli signalizovat aktivaci nového sidechainu v rámci pravidel konsensu drivechainu. Aby mohl těžař navrhnout aktivaci nového sidechainu, musí do svého výstupu na coinbase umístit data OP_RETURN, která obsahují jedinečný identifikátor tohoto sidechainu, veřejný klíč, který se použije při operacích s vklady, údaje o verzi, lidsky čitelný popis a hashe softwarového klienta a jeho historie na GitHubu (nedochází zde k vynucování konsensu, pouze k údajům pro lidi).
Když těžař navrhne aktivaci nového sidechainu a zahrne všechna potřebná data do své coinbase, stává se z hlediska konsensu mainchainu jakýmsi obdobím „signalizace těžařů“ ohledně toho, zda tento nový sidechain vytvořit, či nikoli. Těžař může použít speciální formát pro zahrnutí návrhu do svých výstupů z coinbase a ostatní těžaři mohou vytvořit další výstup podle druhého formátu pro signalizaci aktivace. Nový návrh sidechainu vyžaduje, aby 90 % bloků v období obtížnosti signalizovalo aktivaci, aby bylo vytvoření nového sidechainu potvrzeno. Tím se vytváří mechanismus kolíku pro aktivaci sidechainu, ale interakce mezi sidechainem a mainchainem je mnohem nuancovanější.
V tuto chvíli může kdokoli pegovat mince do sidechainu. Pro peg do sidechainu uživatel jednoduše vytvoří transakci se dvěma vstupy s vlastním vstupem a UTXO odpovídajícím zůstatku sidechainu s jediným výstupem, který vše přiřadí sidechainu. Tím je zaručeno, že sidechain bude mít vždy pouze jedno UTXO obsahující všechny prostředky, které jsou v něm uzamčeny. Výběry jsou řešeny hlasováním horníků. Hlavní řetězec nemá žádnou představu o tom, kdo co vlastní na sidechainu, a hlavní řetězec bude považovat za platný každý výběr schválený těžaři v rámci hlasovacího mechanismu. Z tohoto důvodu dochází k dlouhému zpoždění procesu výběru. Proces stažení ze sidechainu má dvě fáze: návrh na stažení (balíček) a poté fáze hlasování o stažení. Aby mohli těžaři navrhnout stažení, musí ve své transakci na coinbase vytvořit výstup OP_RETURN s hashem transakce navrhovaného stažení. Tento hash však, podobně jako u sighash, označuje pouze odevzdání části transakce namísto celé. Nezavazuje se ke vstupnímu UTXO, které představuje prostředky uzamčené v drivechainu, ani k výstupu, který vrací vše, co se nevybírá, do speciálního sidechainu UTXO. Je to proto, že jakékoliv vklady do drivechainu by vytvořily nové UTXO, a tím by zneplatnily závazek k transakci výběru, když by ji lidé šli potvrdit.
Odtud začíná období hlasování těžařů o návrhu na stažení. Poté, co byl balíček navržen, mohou těžaři hlasovat o tom, zda je schválí, nebo ne. Každý vytěžený blok umožňuje danému těžaři zvýšit počítadlo schválení, a to o jednu nahoru nebo dolů, nebo o dvě nahoru, aby se zdržel hlasování. Kromě toho existují určitá specifická omezení, protože je možné mít více než jeden balík pro jeden sidechain – pokud se těžař rozhodne hlasovat „ano“ (zvýšit počítadlo o jedna) pro balík na stažení pro sidechain, musí hlasovat „ne“ (snížit počítadlo o jedna) pro každý další balík spojený s tímto konkrétním sidechainem.
To má zaručit, že nedojde k „dvojímu výběru“, kdy má někdo výstup ve více svazcích, které by mu na hlavním řetězci vyplatily více bitcoinů, než mu náleží.
Na druhé straně mohou těžaři také hlasovat proti každému jednotlivému navrhovanému balíčku. To má fungovat jako jakýsi alarm pro všechny, že těžař ověřující tyto výběry (ujišťující se, že jde o legitimně vlastněné mince na vedlejším řetězci, které jsou vybírány) si všiml, že se děje něco neplatného. Nezapomeňte, že klíčovým bodem tohoto návrhu je, že těžaři nemusí nic na sidechainu ověřovat, takže pokud se tak stejně nerozhodnou, může se stát, že mnoho těžařů bude upvotovat balíčky, které neověřují. Tato funkce alarmu je navržena tak, aby byli upozorněni, že by měli svazky ověřit, aby se zajistilo, že nedojde k podvodnému výběru.
Jakmile svazek dosáhne požadované prahové hodnoty (13 150 bloků nebo zhruba 90 dní), transakce, která skutečně zpracovává výběr, se stává platnou a může být potvrzena. Co ale lidé dělají, když těžaři schválí podvodný výběr, který ukradne peníze ze sidechainu? Sztorcův návrh spočívá v zapojení uživatelsky aktivovaného soft forku (UASF), který neplatnou transakci peg-out zneplatní. To představuje obrovské riziko z hlediska konsensu pro mainchain. UASF v roce 2017 byl vysoce riskantní krok, který jen stěží uspěl a Bitcoin byl mnohem menší než dnes. Čím větší Bitcoin poroste, tím obtížnější bude takové akce koordinovat.
Pokud si vzpomínáte na článek o spacechainech, tento návrh byl založen na slepé sloučené těžbě (BMM). Návrh BMM Rubena Somsena je vlastně jeho druhou variantou, přičemž první je návrh Sztorc, jak je uveden v BIP301. Specifikace BMM v drivechainech se skládá ze dvou zpráv: zprávy request a zprávy accept. Obě jsou koordinovány v tomto pořadí prostřednictvím speciálního typu transakce na mainchainu a speciálního výstupu v transakci těžaře na coinbase.
Transakci request sestavuje ten, kdo vytváří bloky sidechainu. Celý smysl BMM spočívá v tom, že touto osobou může být někdo, kdo netěží, takže request transakce je tu proto, aby mu umožnila zaplatit těžařům za potvrzení jím navrženého sidechainového bloku. Návrh bloku sidechainu konstruuje transakci, která obsahuje hash bloku sidechainu, ID přidělené sidechainu při jeho vytvoření a poslední čtyři bajty hlavičky předchozího bloku mainchainu. Na tyto typy transakcí se vztahují tři další pravidla konsensu. Za prvé, transakce s žádostí je neplatná, pokud v transakci coinbase daného bloku není také odpovídající výstup accept. To má zaručit, že těžaři nemohou inkasovat poplatek z požadavku, aniž by zároveň akceptovali a vytěžili blok sidechainu. Za druhé, pro každý sidechain je povoleno zahrnout do mainchain bloku pouze jednu transakci requestu. To má zajistit, aby v jednom bloku hlavního řetězce mohl být skutečně vytěžen pouze jeden blok z libovolného sidechainu. A konečně, poslední čtyři bajty předchozího bloku mainchainu se musí shodovat. Tím je zajištěno, že požadavek je platný pouze pro vytěžení v následujícím bloku a takové transakce nemohou být vytěženy později a ukrást peníze navrhovateli bloku sidechainu poté, co byl vytěžen blok někoho jiného.
Výstup akceptace je velmi jednoduchý: údaje v hlavičce zprávy a hash bloku sidechainu. Pokud těžař sám provozuje uzel drivechain, může jednoduše ignorovat transakce requestu a vždy zahrnout svůj vlastní výstup accept do své báze coinbase pro těžbu vlastních bloků sidechainu. Tyto dva aspekty dohromady umožňují těžařům, aby buď sami provozovali sidechain uzel, nebo aby to dělal jiný netěžař a platil těžaři za těžbu jeho bloků. Myšlenka je taková, že pokud těžaři sami neprovozují sidechainy a nesou dodatečné náklady na validaci, může to za ně dělat někdo jiný. Pokud existuje konkurence v netěžařích, kteří se snaží vydělat na poplatcích za sidechain, budou pravděpodobně neustále zvyšovat poplatek, který jsou ochotni zaplatit těžařům v transakci s žádostí, dokud nebude představovat většinu vydělaných poplatků, přičemž netěžař si ponechá pouze malé procento zisku a zbytek zaplatí těžařům.
Taková je mechanika fungování drivechains. Dále následuje federativní sidechains a po něm rozbor všech negativ a nevýhod, které může mít každá konstrukce.
Tento příspěvek napsal Shinobi. Vyjádřené názory jsou výhradně jeho vlastní a nemusí nutně odrážet názory společnosti BTC Inc. nebo časopisu Bitcoin Magazine.
