V červenci jste poprvé veřejně odhalili své dlouho připravované plány na to, jak překopat dosavadní strukturu bitcoin miningu. Rozruch vzbudil zejména návrh druhé generace protokolu Stratum, který poměrně zásadním způsobem mění komunikaci mezi minery a pooly. Od té doby uplynul nějaký čas, ale finální návrh nikde. Kdy jej plánujete zveřejnit?
Měli jsme interní termín nastavený na polovinu září a chtěli protokol prezentovat na blížících se vývojářských konferencích. Co-CEO Braiins Honza Čapek jede 9. září na Bitcoin Edge Dev++ do Tel Avivu, kde chceme Stratum V2 představit vývojářské komunitě. Máme ale trochu potíž popsat všechny věci, které jsme měli v úmyslu.
Nyní pracujeme prakticky už jen na simulacích protokolu, abychom měli zmapovány všechny situace, které mohou díky komplexitě use casů při jeho nasazení nastat. Chceme mít jistotu, že protokol bude fungovat při všech představitelných scénářích. Těch kombinací je poměrně dost, což je způsobeno hlavně zpětnou kompatibilitou s původním protokolem Stratum V1. Pravděpodobně tedy s finálním návrhem v polovině září ven ještě nepůjdeme, konec září by ale mohl být již definitivní limit, protože se uvnitř firmy potřebujeme zabývat i jinými věcmi.
Stratum 1 si získalo obrovskou popularitu zejména díky své jednoduchosti a snadné rozšiřitelnosti. Využití populárního JSON-RPC formátu zpráv umožňovalo jednoduchou implementaci i debugging. Toto všechno Stratum 2 opouští ve prospěch binárního kódu. Co k tomu vedlo?
Zrovna tento aspekt byl pro nás naprosto jasný od samého začátku. Výhoda přímé čitelnosti kódu plnila svůj účel v době, kdy byla těžba bitcoinu hobby záležitostí a lidé si museli doma ve sklepích nějak pomoci sami. Dnes je mining profesionální záležitost a to, co se na začátku jevilo jako výhoda, již pár let přináší jen problémy.
Jenom když si spočítáte obrovské množství dat, která se zbytečně přenášejí kvůli použití JSON-RPC formátu, tak je použití binárního kódu jasná volba. Osobně bych rád spočítal, kolik peněz celkově stálo například posílání „mining submit stringu“, který koluje v každé zprávě o vykonané práci a je to naprosto zbytečná záležitost. Když si člověk spočítá, kolik stojí repetitivní posílání podobných informací, dojde k neuvěřitelnému číslu.
Jaká tedy bude redukce přenášených dat u Stratum V2 oproti jedničce?
Redukce dat by měla dělat více než padesát procent. Když si spočítáte, kolik stojí data od providerů, můžete dojít k docela zajímavé úspoře. My například procesujeme na poolu okolo půl milionu spojení, každé spojení vede na nějaké servery, které mají určitý traffic. Jistý objem dat máme v rámci paušálu zadarmo, ale cokoli nadto se platí.
Nicméně chápeme, že pro člověka, který si chce dumpnout spojení a podívat se, co obsahuje, je určitě výhodnější číst JSON. Plánujeme proto udělat do Wiresharku plugin, který umožní číst Stratum V2 přímo z drátů a zobrazit obsah TCP komunikace v nějakém pro člověka čitelném formátu. Neexistuje nicméně důvod, proč by měla informace chodit po drátech nezakódovaná.
Můžete přiblížit, co všechno by mělo Stratum V2 umět, těch slibovaných změn bylo poměrně hodně a o řadě z nich se toho zatím příliš neví.
Hlavní výhoda Stratum 1 bylo, že umožňoval, aby si server řídil chování klienta. Do té doby nebylo prakticky možné efektivně koordinovat, co budou klienti, kteří se k serveru v obrovském množství připojují, dělat. Jediný dostupný nástroj komunikace minera a poolu byl nepříliš efektivní Long polling. Stratum umožnil, že najednou bylo možné posílat nezávisle na sobě klientům práci ve formě push informací.
Jedna z věcí, které řeší dvojka, je eliminace latencí v tomto procesu. Dnes, když zadáváte práci minerům, tak posíláte zhruba dvoukilobajtový packet do každého spojení, který obsahuje informace o coinbase, merkle path a podobně. Z optimalizačních důvodů často jako první posílají pooly prázdnou template (bez merkle path a transakcí), protože jsou pak data výrazně menší, protokol je hodně citlivý na latence a je v zájmu poolů, aby mineři začali těžit co nejdřív. To znamená, že pool nejprve posílá prázdný blok, protože je to pro něj v současnosti takto výhodnější.
Toto by se mělo s postupně se snižující block reward měnit, protože odměna z transakčních fee bude hrát v poměru k odměně za vytěžení bloku stále důležitější roli. I tak ale bude stále platit, že je pro pool důležité dostat informaci k minerům co nejdříve. Stratum V2 proto umožňuje asynchronní předposílání prací pro příští blok.
Například vím, že těžím na nějaké template, vybral jsem určité transakce a můžu tušit, jaké transakce se nejspíš dostanou do bloku z jiných poolů, protože typická motivace poolů je maximalizace zisku. Na základě tohoto odhadu mohu vybrat transakce, které se s velkou pravděpodobností nedostanou do následujícího bloku, a postavit si dopředu template pro budoucí blok a posílat jej minerům asynchronně ještě před tím, než se vytěží současný blok.
Hlavní pointa je, že v momentu, kdy dojde k nalezení bloku, jde o triviální operaci ověření na serveru, jestli některý z odhadů dopadl dobře, a pokud ano, tak lze rychleji poslat informaci mineru, že job xyz je platný a on jej může začít těžit. To vede k tomu, že miner začíná těžit bez jakékoli nadbytečné latence. Není to sice úplný blok, jde o to nejlepší, co se dalo odhadnout, ale je to okamžitá informace, která je stejně rychlá jako prázdný blok. Eliminuje se tím hlavně těžení na prázdném bloku, což je trochu kontroverzní praktika. Optimalizačních praktik v podobě těžby prázdných bloků se tím sice možná nezbavíme úplně, ale jejich procento by mělo významně poklesnout.
Další poměrně zásadní změnou je to, že protokol odlišuje různé druhy zařízení, tedy zařízení, která skutečně něco počítají, a ostatní zařízení. Velké farmy typicky nevyužívají přímého připojení k poolu na TCP úrovni, ale využívají lokální proxy, která si drží spojení na servery, od kterých bere práci, a směrem k poolu se tak chová jako jedno zařízení.
To má výhodu, že se zmenšuje množství dat, která tečou mezi farmou a poolem – stačí jen jedno otevřené spojení. Na druhé straně to ale způsobuje také větší varianci hashrate. Nedá se například na úrovni poolu sledovat, jak se chovají jednotlivá zařízení, a odhalit tak včas problémy, což je pro změnu velká nevýhoda.
V2 umožňuje propojení přes proxy s tím, že se neztrácí možnost sledovat jednotlivá zařízení, protože zahrnuje dva dialekty protokolu – jeden pro komunikaci s proxy (plnohodnotný protokol), druhý pro přímou komunikaci s těžebními zařízeními (odlehčený protokol očištěný o jakoukoli manipulaci s merkle path a coinbase informacemi). To může v praxi umožnit značnou optimalizaci datové zátěže poolu. Není samozřejmě všechno černobílé, protože se také zdvojnásobuje počet zpráv, které mezi poolem a těžaři putují, ale v praktických scénářích, které na trase mohou nastat, jde o zajímavou optimalizaci, která podporuje aplikaci některých složitějších use casů.
Třetí klíčovou vlastnost jste zmiňoval ve vašem předchozím článku – je to prevence krádeže hashrate.V praxi se sice mnohem spíše setkáte s krádeží samotných zařízení, nebo jejich překonfigurováním, což jsou poměrně rozšířené praktiky, ale pokud by k ní přeci jen došlo, bude to mít poměrně zásadní konsekvence.
Celý mechanismus stojí na předpokladu, že chce útočník obohatit sám sebe, pokud by cílem bylo jen to, že někomu zabráním těžit, tak lze stále provést celou řadu úspěšných útoků. Pooly, když rozdělují práci, každému mineru přidělí unikátní práci. Kdybych chtěl někomu ukrást hashrate, tak bude můj útok spočívat v tom, že někomu podstrčím svoji přidělenou práci, budu se při tom tvářit jako pool, který ji přiděluje, a následně ji po vykonání sám za sebe odevzdám.
Stratum V2 umožňuje, aby pool pomocí svého privátního klíče podepsal pro minera práci v momentě, kdy mu ji posílá. Ten si tak může snadno ověřit, že práce pochází přímo z poolu. Protokol nicméně již neřeší navazující problémy, jako je management klíčů (invalidce, distribuce), což je trochu složitější téma a chceme do budoucna v tomto směru trh více edukovat, protože jinak může samotné používání podpisů vyústit ve falešný pocit bezpečí.
Jakým způsobem chcete prosadit adopci protokolu? Přeci jen přináší i jednu radikální změnu, která značně limituje dosavadní moc pool operátorů.
Již na začátku, když jsme o tomto tématu přemýšleli, tak jsme chtěli, aby „work selection“ nebyla povinná vlastnost. Celý mining protokol lze využívat i bez zapnutí této funkce. To umožňuje dvě důležité věci, za prvé rychlejší a snazší adopci (jednodušší interoperabilitu s V1 pooly skrz nějaké přepínání přes proxy) a také možnost se na straně poolu rozhodnout, zdali tuto funkci bude podporovat. My můžeme za sebe říci, že ji chceme naimplementovat a následně to bude otázka komunitního tlaku, jestli pro ně bude důležitější svoboda, nebo třeba vyšší odměny. Zkrátka klasický konkurenční boj. Pokud ji mineři budou vyžadovat a bude existovat alespoň jedna implementace, tak to otevírá stavidla pro masivnější adopci.
Work selection také není za všech okolností výhoda a přináší s sebou i řadu problémů (domluva na tom, jak vypadá blok, asynchronní validace, promítání do odměn, pokud miner pracuje na špatném bloku). Když si miner navíc sám vybere blok, tak jeho hodnota bude jiná než hodnota bloku, na kterém těží ostatní mineři na poolu, což je nutné nějak zahrnout do výše odměn minera.
Když se například někdo rozhodne těžit 300kB bloky, tak nemůže očekávat stejnou odměnu jako ostatní, kteří těží 2MB bloky. Na veřejných poolech tak přibývá vedle počtu hashů za vteřinu ještě další dimenze odměňování. Není to neřešitelný problém, ale je to určitá komplikace, která bude zpomalovat implementaci work selection na veřejných poolech.
Ještě k té otázce sebrání určité moci. Řekl bych, že dnes pooly berou celou záležitost jako profesionálně vedený byznys a ve finále implementují to, co je pro ně ekonomicky výhodnější. V určitý moment se sice dostaly do situace, kdy mohly věci aktivně ovlivňovat, tak si to také vyzkoušely, ale ve finále budou mnohem radši, když tuto zodpovědnost budou moci přesunout na minery a budou poskytovat svoji část služby jednoduše jako servis.
Publikací návrhu ve formě BIP vaše práce okolo něj nekončí, co vás čeká pak?
Po publikaci návrhu budeme chtít napsat plnohodnotnou proxy, která umožní zařízením s V1 protokolem se připojovat k V2 poolu, a naopak. Máme také poměrně daleko rozepsanou podporu V2 pro Braiins OS, nový release, který chystáme, má již v sobě plnohodnotně „header only“ V2 protokol. Následně bude záležet na zpětné vazbě. Můj předpoklad je, že během tří, čtyř měsíců od publikace návrhu by se měl „usadit prach“ a my budeme implementovat navrhované změny nebo vysvětlovat, proč je v protokolu nechceme. Následně chceme vydat V2 end-point na pool, aby si mineři s Braiins OS mohli vyzkoušet těžbu přímo proti poolovému uzlu. Budeme také chtít vypublikovat všechny zdrojové kódy.
Jaký je vlastně vztah Stratum V2 a BetterHash?
O přechodu na novou binární podobu Stratum jsme přemýšleli poprvé asi před dvěma lety, po příchodu návrhu BetterHash jsme si nejprve přečetli dokumentaci, což bylo poměrně náročné čtení, kde člověk, když dojde na konec, tak neví, co bylo na začátku. Následně jsme si s Mattem Corallem několikrát volali a dávali mu feedback z naší praxe a vysvětlili, proč nemůžeme BetterHash naimplementovat. Následně za námi na jedné konferenci přišel někdo, kdo prohlašoval, že má přístup k obrovskému množství hashrate, který může převést k nám na pool, pokud implementujeme BetterHash. Znovu jsme museli vysvětlit všechna bezpečnostní a technická rizika, pro která nemůžeme BetterHash naimplementovat, ale zároveň nás to nakoplo dotáhnout Stratum V2 do konce.
Matt nám také dal pro Stratum V2 řadu cenných připomínek, připojil se ale až v poměrně pozdní fázi vývoje protokolu. Na druhé straně, Mattův problém trochu je, že nikdy neprovozoval miningovou infrastrukturu, a proto mu řada praktických věcí unikla a některé pro nás důležité funkce Stratum V2 mu přišly jednoduše zbytečné. Nicméně proto, aby Stratum V2 mohlo plně rozvinout svůj potenciál, jsou potřeba i úpravy v Bitcoind (první bitcoinový klient), které umožní, aby bylo vůbec možné work selection úspěšně naimplementovat. A tím, že Matt je vedle autorství BetterHash také Bitcoin Core vývojář, je pro nás extrémně hodnotné s ním spolupracovat, ani ne tak kvůli protokolu samotnému, ale právě kvůli těmto změnám.
Jaká je vlastně celá historie Braiins OS, co bylo hlavní motivací k jeho vývoji?
My jsme svého času pracovali na vlastním těžebním hardwaru, máme dokonce v šuplíku vlastní design bitcoinového miningového čipu, a to včetně simulací jeho chování, ale nikdy jsme se kvůli potřebnému kapitálu nedostali do fáze vytvoření fyzického layoutu. Další fáze bylo vytvoření vlastního otevřeného softwaru, těch důvodů pro to byla celá řada. Jedním z těch hlavních byl fakt, že my jako pool vidíme, jak moc rozbitý je firmware zařízení, která se k nám připojují. Dalším obrovským kopancem v tomto ohledu byly kauzy Bitmainu s Asic boostem a Antbleed, které poukázaly na to, jak obrovský problém je uzavřený firmware na ASIC minerech.
Kdy přesně se dočkáme Braiins OS plné Stratum V2 podpory?
S již zmiňovanou Dev++ konferencí bychom chtěli mít venku verzi bOS, která implementuje absolutní minimum protokolu, bez API a dalších vlastností, které finální miner musí mít, aby si s protokolem mohli lidé začít hrát. Také by tam měla být podpora pro block eruptery, což sice asi nikdy nebyl profitabilní miner, ale je to dodnes zajímavý nástroj pro testování a vývoj, neboť v sobě obsahuje ASIC čipy, a je přitom malý a levný na provoz. Následně by měl přijít release vlastního BIP a v momentu, kdy si budeme vším dostatečně jistí, chceme přijít s implementací plnohodnotné podpory. Na to ale zatím nemáme stanovený žádný deadline.
ČLÁNKY DO MAILU