Vaše tým dokončil alpha verzi vašeho blockchainu a nyní je čas spustit testnet a poté mainnet. Máte skutečný blockchain s nezávislými účastníky, dobrou ekonomickou model, bezpečnost, navrhli jste governance a nyní je čas to vše vyzkoušet v praxi. V ideálním kryptoanarchistickém světě zveřejníte genesis block, konečný kód uzlu a validátoři to všechno sami spustí, nastaví všechny podporující služby a všechno se odehraje samo. Ale to je ve smyšleném světě, zatímco ve skutečném světě musí tým připravit poměrně mnoho podpůrného softwaru a různých manipulací, aby pomohl validátorům spustit udržitelnou síť. O tom je tento článek.
Spuštění sítí na základě konsensu jako „proof-of-stake“, kde jsou validátoři určeni hlasy držitelů tokenů systému, je poměrně specifickou záležitostí, neboť i spuštění tradičních, centralizované spravovaných systémů s desítkami a stovkami servery sama o sobě není jednoduchý úkol, a blockchain musí být spuštěn úsilím loajálních, ale nezávislých účastníků. A pokud v korporaci mají správci při spuštění plný přístup ke všem strojům, logům a celkovému monitorování, validátoři nikomu nepustí své servery a pravděpodobně upřednostní budování vlastní infrastruktury, protože ta kontroluje přístup k základním aktivům validátora – stakingovým hlasům. Takové chování umožňuje budovat distribuované bezpečné sítě - nezávislost použitých cloudových poskytovatelů, virtuálních a „baremetal“ serverů, různé operační systémy, to vše pomáhá učinit útoky na takovou síť velmi neefektivními – příliš mnoho různých softwarů je používáno. Například v Ethereum existují dvě hlavní implementace uzlu, jedna na Go a druhá na Rust, a útok, který je efektivní pro jednu implementaci, nefunguje pro druhou.
Všechny procesy spuštění a provozu blockchainů by měly být uspořádány tak, aby každý validátor, nebo dokonce malá skupina validátorů, mohla kdykoli vyhodit své počítače z okna a odejít, aniž by se cokoli rozbilo, a zbývající validátoři by měli nadále účinně udržovat provoz sítě a připojovat nové validátory. Při spuštění sítě, kdy je jeden validátor v Evropě, druhý v Jižní Americe a třetí v Asii, je docílení souhlasné práce několika desítek nezávislých skupin a jejich zainteresování na výsledku poměrně složité.
Validátoři
Představme si spuštění hypotetického moderního blockchainu (většina popisovaného se hodí pro blockchainy založené na jakémkoli moderním rodině blockchainů: Ethereum, EOS, Polkadot, Cosmos a dalších, které předpokládají konsensus proof-of-stake). Hlavními aktéry takových blockchainů jsou týmy validátorů, které se zabývají instalací vlastních nezávislých serverů, validují a vytvářejí nové bloky a získávají odměny, které síť poskytuje těm, kdo se účastní konsensu. K zahájení nových sítí je potřeba několik desítek validátorů (tolik jich nyní může více či méně efektivně dosáhnout konsensu během sekund), a proto projekt vyhlašuje registraci, při níž se validátoři dělí veřejné informace o sobě s uživateli, přesvědčují je, že mají v úmyslu kvalitně obsluhovat spuštěnou síť.
Validátorství je podnikání, které umožňuje velmi přesně hodnotit potenciální příjem validátora, rychle přesunovat síly mezi projekty, a v případě úspěchu vybrané sítě může validátor jako plnohodnotný účastník DAO a zodpovědná osoba rozvíjet projekt, nebo jednoduše poskytovat vynikající technické služby za zcela transparentní, poctivě vydělané peníze. Při výpočtu odměn pro validátory se projekty snaží zohlednit náklady validátorů a nastavit odměnu za bloky tak, aby to bylo ziskové podnikání, ale zároveň nedalo validátorům možnost zničit ekonomiku tím, že je zaplaví penězi a připraví je o ostatní uživatele sítě.
Podnikání s validátory vyžaduje zajištění vysoké dostupnosti služeb, což znamená vysokou úroveň přípravy DevOps a vývojářů a nákladné výpočetní zdroje. I bez potřeby hashování v sítích proof-of-work je blockchain node velká služba, která zabírá hodně paměti, vyžaduje mnoho výpočtů, validuje, zapisuje na disk a odesílá do sítě velké objemy dat. Pro uchování logu transakcí a blokových řetězců pro blockchain s několika tisíci malými transakcemi v bloku nyní vyžaduje úložiště od 50 Gb a více, a pro bloky by to měl být SSD. State database blockchainů podporujících chytré kontrakty již může přesahovat 64 Gb RAM. Servery s požadovanými charakteristikami jsou poměrně drahé, node Ethereum nebo EOS může stát od 100 do 200 $/měsíc. Přidejte k tomu zvýšené mzdy za nepřetržitou práci vývojářů a DevOps, kteří v době spuštění řeší problémy i během noci, protože část validátorů může být snadno v jiném hemisféře. Nicméně, v příznivých chvílích může vlastnictví node-validátoru přinášet značný příjem (v případě EOS až 10 000 $ za den).
Validátorství je pouze jednou z nových potenciálních IT rolí pro podnikatele a společnosti. Jak programátoři vymýšlí stále sofistikovanější algoritmy, které odměňují poctivost a trestají podvod a krádež, objevují se služby, které vykonávají funkce publikace důležitých dat (orákulů), vykonávají dohled (slashing vkladů a trestání podvodníků publikováním důkazů podvodu), služby řešení sporů, pojištění a opcí; dokonce je garbage collection potenciálně velkým trhem v systémech chytrých kontraktů, kde je potřebné platit za uchovávání dat.
Problémy spuštění blockchainu
Otevřenost blockchainu, která umožnila svobodné zapojení do sítě počítačů z jakékoliv země a jednoduché připojení jakéhokoli script kiddie podle návodu na GitHubu, není vždy výhodou. Honba za novým tokenem často nutí validátory "na začátku těžit novou minci", doufajíc ve zvýšení ceny a rychlou možnost výprodeje. To také znamená, že vaším validátorem může být kdokoli, dokonce anonymní, za kterého lze hlasovat stejně jako za ostatní validátory (pravda, anonymovi bude obtížné shromáždit hlasy od stakeholderů, takže strašidelné pohádky o anonymních kryptoměnách si necháme pro politiky). Nicméně
Tým projektu má úkol – nějakým způsobem získat do své sítě ty, kteří v budoucnu mohou zajistit stabilní chod uzlů, rozumí bezpečnosti, umí rychle řešit problémy, spolupracovat s ostatními validátory a jednat společně – od těchto vlastností plně závisí kvalita toho tokenu, do kterého se účastníci sítě chystají investovat svůj čas a zdroje. Adekvátní zakladatelé, hodnotící rizika, dobře chápou, že při spuštění takového rozsáhlého softwaru se nevyhnou chybám v kódu, konfiguraci uzlů, a že stabilita sítě závisí na tom, jak dobře budou vývojáři a validátoři společně řešit podobné problémy.
Tým je připraven hlasovat v mainnetu za jakékoliv validátory, jen by chtěl vědět, za které, kteří jsou dobří? S největším portfoliem? Ten nyní téměř nikdo nemá. Podle profilů týmů na LinkedIn? Zkušení devops nebo bezpečnostní experti vám žádné profily na LinkedIn nedají. Podle prohlášení v chatu, příspěvků a pomoci ostatním v přípravě? Dobře, ale subjektivně a nepřesně.
V takových podmínkách zbývá jedno – to, co dobře řeší problémy všech – hra, ve které si lze vybrat nejlepší validátory, ale hlavně – otestovat blockchain na pevnost a provést rozsáhlý bojový test blockchainu za aktivního používání, změn v konsenzu, výskytu a oprav chyb. Poprvé tuto proceduru představili jako hru kluci z projektu Cosmos, a tento nápad je nepochybně skvělý způsob, jak připravit síť k spuštění spolehlivého a odolného mainnetu.
Hra validátorů
Popíšu hru validátorů tak, jak jsme ji navrhli pro blockchain DAO.Casino (DAOBet) na základě fork EOS, který se nazývá Haya a má podobný mechanismus governance – validátoři jsou vybíráni hlasováním z jakéhokoli účtu, přičemž část zůstatku, kterým hlasují pro validátora, je zmražena. Jakýkoli účet, který má na zůstatku základní token BET, může hlasovat pro vybraného validátora jakoukoli částí svého zůstatku. Hlasy se sčítají a na základě toho se vytváří top validátorů. V různých blockchainech je tento proces uspořádán různě, a obvykle právě v této oblasti se nový blockchain liší od mateřského, a musím říct, že v našem případě EOS plně ospravedlňuje "OS" ve svém názvu, opravdu používáme EOS jako základní operační systém pro nasazení modifikované verze blockchainu pro potřeby DAOBet.
Budu popisovat jednotlivé problémy a jak je možné je řešit v rámci hry. Představme si síť, ve které může být váš server otevřeně napaden, kde abyste udrželi pozici validátora, musíte neustále interagovat se sítí, propagovat svého validátora a sledovat, aby produkoval bloky a ty byly včas doručeny ostatním validátorům, jinak bude validátor vyřazen ze seznamu.
Jak vybrat top vítěze?
Hlavním technickým požadavkem na hru je, aby její výsledky byly veřejně ověřitelné. To znamená, že výsledky hry: TOP vítězů, musí být vytvořeny striktně na základě dat, která může ověřit jakýkoli účastník. V centralizovaném systému bychom mohli měřit "uptime" každého validátora a odměňovat ty, kteří byli více online nebo přenesli maximální množství síťového provozu. Můžeme shromažďovat data o zatížení CPU, paměti a odměňovat ty, kteří svědomitě pracovali. Ale jakékoli takové shromažďování metrik znamená existenci centra sběru, a navíc všechny uzly jsou nezávislé a mohou se chovat, jak chtějí, a posílat jakákoliv data.
Protože přirozeným řešením je, že vítězové by měli být určeni na základě dat z blockchainu, protože podle něj lze vidět, který validátor který blok vytvořil a jaké transakce byly zahrnuty. Nazvali jsme to Validator Points (VP) a jejich získání je hlavním cílem validátorů ve hře. V našem případě je nejjednodušší, veřejně ověřitelnou a efektivní metrikou „užitečnosti“ validátora VP = počet_vytvořených_validátorem_bloků za dané časové období.
Takový jednoduchý výběr je dán tím, že governance v EOS už zahrnuje mnoho vznikajících problémů, protože EOS je nástupcem už tří generací skutečně fungujících blockchainů s bohatými zkušenostmi se složitým řízením sítě. Prakticky jakékoli problémy validátora se sítí, procesorem nebo diskem vedou pouze k jedné výchozí situaci — podepisuje méně bloků, za což dostává nižší odměnu, což nás opět dostává zpět k číslu podepisovaných bloků — pro EOS je to skvělá a jednoduchá varianta.
U jiných blockchainů se může způsob počítání Validator Points lišit. Například pro konsensy založené na pBFT (Tendermint/Cosmos, konsensus Aura z Parity Substrate), kde každý blok musí být podepsán několika validátory, dává smysl počítat jednotlivé podpisy validátorů, a ne bloky. Možná má smysl zohlednit nedokončené kola konsensu, která spotřebovávají zdroje ostatních validátorů, obecně to velmi závisí na typu konsensu.
Jak modelovat reálné podmínky provozu
Úkolem zakladatelů je ověřit validátory v podmínkách co nejbližších realitě, přičemž nemají žádnou centralizovanou kontrolu. Tento problém lze vyřešit pomocí faucetového kontraktu, který rozdává stejná množství základního tokenu validátorům a všem zájemcům. Aby bylo možné získat tokeny na zůstatek, je třeba vytvořit transakci a dosáhnout toho, aby ji síť zařadila do bloku. Tímto způsobem je pro validátora nutné neustále doplňovat svůj zůstatek novými tokeny a hlasovat pro sebe, čímž se dostává na vrchol. Tato činnost vytváří stálou zátěž na síti a parametry mohou být nastaveny tak, aby proud žádostí byl dostatečně vážný pro plnohodnotný test sítě. Proto plánujte faucetový kontrakt předem jako důležitý nástroj pro spuštění sítě a začněte jej parametry vybírat včas.
Žádost o tokeny z faucet a hlasování validátorů však stále nepřesně emuluje práci blockchainu, zejména v extrémně zatížených režimech. Proto se týmu blockchainu stejně tak či onak bude muset napsat dodatečné benchmarky, které umožní zatížit síť. Zvláštní roli v tom hrají předem vytvořené smart kontrakty, které umožňují testovat jednotlivé podsystemy. Pro testování storage kontrakt ukládá do blockchainu náhodná data, a pro ověření síťových zdrojů vyžaduje testovací kontrakt velký objem vstupních dat, čímž zvyšuje objem transakcí — spuštěním proudu takových transakcí v libovolných okamžicích času tým současně testuje stabilitu kódu a odolnost validátorů.
Samostatnou otázkou je aktualizace kódu uzlů a provádění hard forků. Je nutné, aby v případě výskytu chyby, zranitelnosti nebo spiknutí zlovolných validátorů měli validátoři připravený plán akcí, který již byl vyzkoušen v praxi. Lze vymyslet schémata pro přidělování VP za rychlé nasazení hard forků, například penalizováním všech validátorů, kteří ještě nenainstalovali novou verzi kódu uzlu, ale to je komplikované na realizaci a komplikuje výpočty. Simulovat situaci urgentního nasazení hard forků lze uměle „porušením“ blockchainu na určeném bloku. Výroba bloků se zastaví a ve výsledku budou mít výhodu ti, kteří se připojí dříve a začnou podepisovat bloky, takže VP na základě počtu podepsaných bloků je zde velmi vhodný.
Jak informovat účastníky o stavu sítě a opravit chyby
Ačkoliv mezi validátory panuje nedůvěra, je pro všechny výhodné získávat aktuální informace o stavu sítě včas, aby se mohly rychleji přijímat rozhodnutí. Proto tým projektu vyvíjí službu pro sběr a vizualizaci různých metrik ze serverů validátorů, která umožňuje vidět situaci najednou pro celou síť a rychle zjistit, co se děje. Také, jak validátorům, tak projektu se vyplatí, aby tým projektu rychle opravoval nalezené chyby, proto kromě sběru metrik má smysl ihned spustit sběr logů a dat o chybách z zařízení validátorů na server, dostupný vývojářům blockchainu. Zde nikomu neprospívá zkreslovat informace, proto tyto služby vytváří tým projektu a lze jim důvěřovat. Je rozumné sbírat systémové metriky od validátorů a rozhodně ty nejdůležitější metriky samotného blockchainu — pro DAOBet je to čas finalizace a zpoždění posledního finalizovaného bloku. Díky tomu tým vidí nárůst spotřeby paměti na uzlech při spuštění benchmarku, problémy jednotlivých validátorů.
Důležité body k provádění hry validátorů
Jak se ukázalo, pokud chcete oficiálně povolit validátorům útočit na stroje navzájem (neoficiálně to mohou dělat i tak) — je potřeba to právně formulovat jako testování bezpečnosti, protože podle legislativy některých zemí může být za DDoS nebo síťové útoky uložena pokuta. Další důležitou otázkou je, jak odměňovat validátory. Přirozenými cenami jsou tokeny projektu, které budou převedeny do mainnetu, ale masivní rozdělování tokenů komukoli, kdo dokázal spustit node, také není nejlepší varianta. Pravděpodobně budete muset balancovat mezi dvěma krajními možnostmi:
Rozdělit celý prize pool v souladu se získanými VP
to je velmi demokratické a umožňuje vydělat všem, kdo vložili čas a zdroje do hry validátorů
ale přitahuje do hry náhodné lidi bez připravené infrastruktury
Rozdělit prize pool top-N validátorům na základě výsledků hry
vítězi pravděpodobně budou validátoři, kteří nejstabilněji vydrželi během hry, velmi cílevědomí na vítězství
část validátorů nebude chtít participovat, nízko hodnotí své šance na vítězství, zejména pokud je mezi účastníky mnoho zavedených validátorů
Které variantě dát přednost — je na vás
Existuje ještě jeden moment — vůbec není jisté, že desítky validátorů se po vašem vyzvání přihlásí do hry, a z těch, kteří se rozhodnou zkusit, ne všichni dokonce nainstalují a spustí node — obvykle má projekty v tomto stádiu celkem chudou dokumentaci, vyskytují se chyby, a vývojáři pracující pod časovým tlakem odpovídají na otázky příliš pomalu. Proto je před spuštěním hry také třeba zvážit kroky, pokud nebude dosaženo požadovaného počtu validátorů. V tomto případě na začátku hry spustí chybějící validátory tým projektu, účastní se konsensu, ale nemohou být vítězi.
Závěr
Na závěr jsem se pokusil sestavit ze výše uvedeného seznam toho, co je potřeba vymyslet, udělat a spustit pro efektivní provedení hry validátorů
Co je potřeba udělat pro spuštění skutečné hry validátorů:
vyvinout svůj blockchain 🙂
- vytvořit a spustit webové rozhraní a poskytnout CLI pro hlasování za validátory
- Udělat tak, aby metriky z běžící uzlu validátoru mohly být zasílány do centralizované služby (například Prometheus)
- Zprovoznit server pro sběr metrik (Prometheus + Grafana) pro hru validátorů
- Vymyslet, jak budou počítány Validator Points (VP)
- Vyvinout veřejný skript, který počítá VP validátora na základě dat z blockchainu
- Vyvinout webové rozhraní pro zobrazení top validátorů a stavu hry validátorů (kolik času zbývá do konce, kolik má kdo VP atd.)
- Vyvinout a automatizovat spuštění libovolného počtu vlastních uzlů, navrhnout proces připojení validátorů do hry (kdy a jak vypínat své uzly, podávat a odnímat hlasy)
- Vypočítat, kolik tokenů je třeba vydat, a vyvinout contract-faucet
- Vytvořit benchmark skript (přenos tokenů, masivní využití storage, masivní využití sítě)
- Svolat všechny účastníky do jednoho chatu pro rychlou komunikaci
- Spustit blockchain o něco dříve, než začne hra
- Čekat na startovní blok, začít hru
- Otestovat síť několika typy transakcí
- Provést hardfork
- Změnit seznam validátorů
- Opakovat p.13,14,15 v různém pořadí, aby se udržela stabilita sítě
- Čekat na finální blok, ukončit hru, spočítat VP
Je třeba říci, že hra validátorů je nová historie a konala se pouze několikrát, takže není třeba tento text vnímat jako hotový návod. Neexistují žádné analogy v současném IT byznysu – představte si, že banky před spuštěním systému plateb soutěží mezi sebou, kdo lépe provede transakce klientů. Tradiční přístupy vám pravděpodobně nepomohou vytvářet velké decentralizované sítě, takže osvojujte nové obchodní modely, organizujte své hry, určujte zasloužené, odměňujte je a ať vaše distribuované systémy fungují rychle a stabilně.
Zdroj: habr.com
