И така, екипът ви завърши alpha-версията на вашия блокчейн и е време да пуснете testnet, а след това и mainnet. Имате истински блокчейн с независими участници, добра икономическа модел, сигурност, проектирахте governance и сега е време да изпитате всичко това в действие. В идеалния криптоанархичен свят, вие публикувате genesis block, окончателния код на нодата и валидаторите сами пускат всичко, настройват всички помощни услуги и всичко се случва само по себе си. Но това е в измисления свят, а в реалния, екипът трябва да подготви доста много помощен софтуер и различни манипулации, за да помогне на валидаторите да стартират устойчива мрежа. За това говори тази статия.
Стартирането на мрежи на базата на консенсуси от типа "proof-of-stake", където валидаторите се определят от гласовете на притежателите на токени в системата, е доста специфично начинание, тъй като дори стартирането на традиционни, централизирано управлявани системи с десетки и стотици сървъри само по себе си не е лесна задача, а блокчейнът трябва да започне с усилията на лоялни, но независими участници. И ако в корпорациите администраторите при стартиране имат пълен достъп до всички машини, логове, общ мониторинг, то валидаторите няма да допуснат никого до своите сървъри и вероятно ще предпочетат да изградят собствената си инфраструктура, тъй като това контролира достъпа до основните активи на валидатора - стейковете на гласуващите. Именно такова поведение позволява изграждането на разпределени безопасни мрежи - независимост на използваните облачни доставчици, виртуални и "baremetal" сървъри, различни операционни системи, всичко това прави атаките срещу такава мрежа крайно неефективни - твърде много различен софтуер се използва. Например в Ethereum се използват две основни имплементации на нодата, на Go и на Rust, и атака, ефективна за една имплементация, не работи за друга.
Следователно, всички процеси по стартиране и експлоатация на блокчейни трябва да бъдат организирани така, че всеки валидатор, или дори малка група валидатори, да могат по всяко време да изхвърлят своите компютри през прозореца и да напуснат, без нищо да се счупи, а останалите валидатори да продължат ефективно да поддържат работата на мрежата и да свързват нови валидатори. При стартиране на мрежата, когато един валидатор е в Европа, втори в Южна Америка, а трети в Азия, постигането на съгласувана работа на няколко десетки независими групи и заинтересовани лица е доста сложно.
Валидатори
Нека си представим стартиране на хипотетичен модерен блокчейн (голяма част от описаното подхожда за блокчейни, базирани на всяко съвременно семейство блокчейни: Ethereum, EOS, Polkadot, Cosmos и други, в които е предвиден консенсус proof-of-stake. Основните участници в такива блокчейни са екипи-валидатори, които се занимават с инсталирането на свои независими сървъри, валидиращи и произвеждащи нови блокове и получаващи наградите, предвидени от мрежата за тези, които участват в консенсуса. За стартиране на нови мрежи са необходими няколко десетки валидатори (толкова в момента могат по-или-иначе ефективно да постигат консенсус за секунди), затова проектът обявява регистрация, при която валидаторите споделят публична информация за себе си с потребителите, убеждавайки ги, че възнамеряват качествено да обслужват стартираната мрежа.
Валидаторството е бизнес, който позволява изключително точно да се оценява потенциалният доход на валидатора, бързо да се прехвърлят мощности между проекти, а в случай на успех на избраната от него мрежа, валидаторът може, като пълноправен участник в DAO и отговорно лице, да развива проекта, или просто да предоставя отличен технически сервиз за напълно прозрачни честно из earned money. При изчисляването на наградата, проектите се стремят да отчетат разходите на валидаторите и да направят наградата за блокове така, че този бизнес да бъде печеливш, но в същото време да не позволява на валидаторите да сриват икономиката, преливайки я с пари и лишавайки останалите потребители от мрежата.
Бизнесът с валидатори изисква осигуряване на висока отказоустойчивост на услугите, което означава - високо ниво на подготовка на DevOps специалисти и разработчици, както и скъпи изчислителни ресурси. Дори без необходимостта да се добиват хешове в мрежи с proof-of-work, блокчейн възелът е голям сервис, който заема много памет, изисква много изчислителни ресурси, валидира, записва на диск и предоставя в мрежата големи обеми данни. За съхранение на логовете на транзакциите и веригите от блокове за блокчейн с няколко хиляди малки транзакции в блок в момента е необходима памет от 50 Gb и повече, а за блоковете това трябва да бъде SSD. Състоянието на базите данни на блокчейните, поддържащи смарт-контракти, вече може да надвишава 64Gb оперативна памет. Сървърите с необходимите характеристики са доста скъпи, а възелът на Ethereum или EOS може да струва от 100 до 200 $/месец. Добавете към това увеличеното заплащане на труда за денонощната работа на разработчиците и DevOps, които през периода на пускане решават проблеми дори през нощта, тъй като част от валидаторите лесно може да се намират в другото полукълбо. Въпреки това, в удачни моменти притежаването на валидаторски възел може да донесе сериозни приходи (в случая на EOS - до 10 000$ на ден).
Валидаторството е само една от новите потенциални ИТ-ролите за предприемачи и компании. Със създаването на все по-сложни алгоритми от програматорите, които възнаграждават честността и наказват измамата и кражбата, се появяват услуги, които изпълняват функции за публикуване на важни данни (оракулите), предоставят надзор (възнаграждавайки депозити и наказвайки измамници чрез публикуване на доказателства за измама), услуги за разрешаване на спорове, застраховки и опции; дори garbage collection е потенциално голям пазар в системите на смарт-контрактите, където е необходимо да се плаща за съхранение на данни.
Проблеми с пускането на блокчейн
Отвореността на блокчейна, която позволи свободно участие в работата на мрежата от компютри от всякакви страни и леснотата на свързването с мрежата за всеки, който следва инструкции в GitHub, не винаги е предимство. Ловът за нов токен често принуждава валидаторите да "минят нова монетка на старта" в надеждата за ръст на курса и бърза продажба на печалбите. Освен това, това означава, че ваш валидатор може да бъде всеки, дори анонимен, за него може да се гласува също като за другите валидатори (обаче на анонимния няма да му е лесно да събира гласове от стейкхолдерите, затова страшните приказки за анонимни криптовалути оставяме на политиците). Въпреки това
Екипът на проекта има задача — по някакъв начин да привлече в своята мрежа тези, които в бъдеще са в състояние да осигурят стабилна работа на нодовете, разбират от сигурност, умеят бързо да решават проблеми, да си сътрудничат с други валидатори и да действат съвместно — от тези качества в значителна степен зависи качеството на съответния токен, в който участниците в мрежата планират да вложат времето и ресурсите си. Адекватните фаундери, оценявайки рисковете, добре разбират, че при старта на софтуер от такъв мащаб неминуемо ще се сблъскат с грешки в кода, конфигурацията на нодовете и че стабилността на мрежата зависи от това, колко добре разработчиците и валидаторите заедно ще разрешат такива проблеми.
Екипът е готов да гласува в mainnet за всякакви валидатори, но би било хубаво да знаем за какви, кои са добри? С най-голямо портфолио? В момента почти никой няма такова. По профилите на екипите в Linkedin? Опитни девопси или специалисти по сигурността няма да ви предоставят никакви профили в Linkedin. Според изявленията в чата, постовете и помощта на другите на етапа на подготовката? Добре, но е субективно и неточно.
В такива условия остава едно — да направим игра, която решава проблемите на всички — игра, в която ще можем да изберем най-добрите валидатори, но най-важното — да проверим блокчейна на устойчивост и да проведем цялостно бойно тестване на блокчейна в условия на активно използване, промени в консенсуса, появяване и коригиране на грешки. За първи път тази процедура беше представена като игра от момчетата от проекта Cosmos и тази идея несъмнено е отличен начин да подготви мрежата за стартиране на надежден и отказоустойчив mainnet.
Игра на валидатори
Ще опиша играта на валидаторите така, както я проектирахме за блокчейна DAO.Casino (DAOBet), базиран на форка EOS, наречен Haya, който има подобен механизъм на управление — валидаторите се избират чрез гласуване от всякакъв акаунт, при което част от баланса, с който гласуват за валидатора, се замразява. Всеки акаунт, притежаващ основния токен BET, може да гласува за избрания валидатор с всяка част от своя баланс. Гласовете се сумират и накрая се формира топ на валидаторите. В различните блокчейни този процес е организиран по различен начин и обикновено именно в тази част новият блокчейн се различава от родителския. Трябва да кажа, че в нашия случай EOS напълно оправдава “OS” в името си, наистина използваме EOS като основна операционна система за разгръщане на модифицирана версия на блокчейна за задачите на DAOBet.
Ще опиша отделни проблеми и как те могат да бъдат решени в рамките на играта. Да предположим мрежа, в която вашият сървър може да бъде открито атакуван, където за да задържите позицията на валидатор е необходимо непрекъснато взаимодействие с мрежата, насърчавайки своя валидатор и следейки за това, дали той произвежда блокове и те навреме стигат до другите валидатори, в противен случай валидаторът ще бъде изключен от списъка.
Как да изберем топ победителите?
Основното техническо изискване към играта е резултатите ѝ да бъдат публично проверяеми. Това означава, че резултатите от играта: ТОП победителите, трябва да бъдат формирани строго на базата на данни, които всеки участник може да провери. В централизирана система бихме могли да измерваме “uptime” на всеки валидатор и да награждаваме онези, които са били онлайн повече време или са пропуснали най-много мрежов трафик. Можем да събираме данни за натоварването на процесора, паметта и да награждаваме тези, които са работили достойно. Но събирането на всякакви метрики означава съществуването на център за събиране, а нодовете са напълно независими и могат да се държат както си искат, изпращайки всякакви данни.
Следователно, естественото решение е победителите да бъдат определени на база данни от блокчейна, тъй като посредством него можем да видим кой от валидаторите е произвел кой блок и кои транзакции са включени в него. Ние нарекохме това число Validator Points (VP) и тяхното събиране е основната цел на валидаторите в играта. В нашия случай, най-простата, лесно проверима публично и ефективна метрика за "полезност" на валидатора е VP = брой_продадени_от_валидатора_блокове за даден времеви период.
Такъв прост избор е обусловен от факта, че управлението в EOS вече предвижда множество възникващи проблеми, тъй като EOS е наследник на вече три поколения реално работещи блокчейни с голям опит в управлението на мрежата, и практически всякакви проблеми на валидатора със мрежата, процесора или диска водят единствено до един проблем — той подписва по-малко блокове, получава по-малко заплащане за работата си, което отново ни води просто до броя подписани блокове — за EOS това е отличен и прост вариант.
В други блокчейни, начинът на изчисляване на Validator Points може да се различава, например за консенсуси, базирани на pBFT (Tendermint/Cosmos, консенсус Aura от Parity Substrate), където всеки блок трябва да бъде подписан от множество валидатори, има смисъл да се броят отделните подписи на валидаторите, а не блоковете, възможно е също да има значение счетенето на незавършените консенсусни рундове, които използват ресурсите на другите валидатори; общо взето, това зависи силно от типа консенсус.
Как да моделираме реалните условия на експлоатация
Задачата на основателите е да проверят валидаторите в условия, близки до реалността, без никакъв централен контрол. Този проблем може да бъде решен чрез контракт-faucet, който раздава равни количества основен токен на валидаторите и на всички желаещи. За да получат токени в баланса си, е необходимо да се състави транзакция и да се постигне, че мрежата да я включи в блок. По този начин валидаторът трябва постоянно да увеличава своя баланс с нови токени и да гласува за себе си, за да се издигне в класацията. Тази дейност създава постоянна натовареност на мрежата, а параметрите могат да бъдат настроени така, че потокът от заявки да бъде достатъчно значителен за пълноценен тест на мрежата. Затова планирайте контракт-faucet предварително като важен инструмент за стартиране на мрежата и започнете да подбирате параметрите му предварително.
Заявката за токени от faucet и гласуването на валидаторите все пак не е напълно честно емулира работата на БЧ, особено в крайно натоварени режими. Затова екипът на блокчейна ще трябва да напише допълнителни бенчмаркове, които да натоварят мрежата. Специално предназначени предварително създадени смарт-контракти играят особена роля в това, позволявайки тест на отделна подсистема. За тестване на storage, контрактът запазва случайни данни в блокчейна, а за проверка на мрежовите ресурси тестовият контракт изисква голям обем входни данни, което раздува обема на транзакциите — като стартира поток от такива транзакции в произволни моменти от време, екипът едновременно тества стабилността на кода и устойчивостта на валидаторите.
Един отговор, който заслужава внимание, е актуализирането на кода на възлите и провеждането на хардфоркове. Необходимо е, в случай на грешка, уязвимост или заговор между злонамерени валидатори, те да имат предварително изработен план за действия, разработен в играта на валидаторите. Могат да се измислят схеми за начисляване на VP за бързо прилагане на хардфорка, например, налагайки глоби на всички валидатори, които все още не са инсталирали новата версия на кода на възлите, но е сложно да се реализира, тъй като усложнява изчисленията. Симулацията на ситуация за спешно прилагане на хардфорк може да се извърши, като „разбием“ блокчейна на зададен блок. Производството на блокове спира, и в крайна сметка печелят тези, които по-рано се включат и започнат да подписват блокове, така че VP, базиран на броя на подписаните блокове, е подходящ тук.
Как да информираме участниците за състоянието на мрежата и да поправяме грешките
Въпреки недоверието между валидаторите, навременното получаване на актуална информация за състоянието на мрежата е от полза за всички, за да могат по-бързо да взимат решения, затова екипът на проекта разработва услуга за събиране и визуализация на множество метрики от сървърите на валидаторите, която позволява да се види ситуацията за цялата мрежа едновременно, бързо определяйки какво се случва. Освен това, и за валидаторите, и за проекта е важно екипът бързо да отстранява откритите грешки, затова освен събиране на метрики е разумно веднага да започне събирането на лог файлове и данни за грешки от машините на валидаторите на компютър, достъпен за разработчиците на блокчейна. Тук никой няма интерес да изкривява информацията, затова тези услуги се разработват от екипа на проекта и им може да се вярва. Има смисъл да се събират системни метрики от валидаторите и задължително най-важните метрики на самия блокчейн — за DAOBet това е времето за финализиране и забавянето на последния финализиран блок. Благодарение на това екипът наблюдава увеличаването на потреблението на памет на възлите при изпълнение на бенчмарка, проблеми с отделни валидатори.
Важно за провеждането на играта на валидаторите
Как се оказа, ако искате официално да разрешите на валидаторите да атакуват машините один на друг (неофициално те вече могат да го правят) — трябва да формулирате това като тестване на сигурността, тъй като в законодателството на някои държави за DDoS или мрежови атаки може да се наложи наказание. Освен това важен въпрос е как да награждавате валидаторите. Естествени награди са токени на проекта, които ще бъдат пренесени в mainnet, но масивното раздаване на токени на всеки, който успее да стартира нода — също не е най-добрият вариант. Вероятно ще трябва да балансирате между двете крайни опции:
Да раздадете целия награден фонд в зависимост от спечелените VP
това е много демократично и позволява на всеки, който е вложил време и ресурси в играта валидатори, да спечели
но привлича случайни хора с неподготвена инфраструктура в играта
Да раздадете наградния фонд на top-N валидатори въз основа на резултатите от играта
победителите вероятно ще бъдат валидаторите, които са издържали най-стабилно през играта, много настойчиви в стремежа си към победа
част от валидаторите може да не желаят да участват, ниско оценявайки шансовете си за победа, особено ако в състава на участниците има утвърдени валидатори
Кой вариант да предпочетете — е ваше
Има и още един момент — съвсем не е сигурно, че десетки валидатори ще се втурнат да участват в играта по вашия призив, а от тези, които решат да опитат, не всички дори ще инсталират и стартират нода — обикновено в този етап проектите имат доста оскъдна документация, срещат се грешки, а разработчиците, които работят на натоварено време, не отговарят на въпросите особено бързо. Следователно, преди стартирането на играта, трябва също да предвидите действия, ако нужното число валидатори не бъде набрано. В този случай в началото на играта, липсващите валидатори се стартират от екипа на проекта, участват в консенсуса, но не могат да бъдат победители.
Заключение
В заключение се опитах да събера от по-горе описаното списък на това, което трябва да се измисли, направи и стартира за ефективното провеждане на играта валидатори
Какво трябва да се направи за стартирането на истинска игра валидатори:
да разработите свой блокчейн 🙂
- да направите и повдигнете уеб интерфейс и да предоставите CLI за гласуване за валидаторите
- да прилагане на метрики от активния валидатор да се изпращат в централизирана услуга (например Prometheus)
- да се създаде сървър за събиране на метрики (Prometheus + Grafana) за валидаторите
- да се измисли как ще се изчисляват Validator Points (VP)
- да се разработи публичен скрипт за изчисляване на VP на валидатор на базата на данни от блокчейна
- да се разработи уеб интерфейс за показване на топ валидаторите и състоянието на играта на валидаторите (колко време остава до края, колко VP има всеки и т.н.)
- да се разработи и автоматизира старта на произволен брой собствени възли, да се проектират процесите на свързване на валидаторите с играта (кога и как да се изключват собствените възли, да се подават и отстраняват гласове за тях)
- да се изчисли колко токена трябва да се раздават и да се разработи договор-faucet
- да се създаде скрипт-бенчмарк (преместване на токени, масивна употреба на хранилище, масивна употреба на мрежата)
- да се съберат всички участници в един чат за бърза комуникация
- да се стартира блокчейн малко преди началото на играта
- да се изчака стартовия блок, да започне играта
- да се тества мрежата с няколко типа транзакции
- да се приложи хардфорк
- да се промени списъка с валидатори
- да се повтарят п.13, 14, 15 в различен ред, поддържайки стабилността на мрежата
- да се изчака финалния блок, да се завърши играта, да се преброят VP
Трябва да се каже, че играта на валидаторите е ново явление и е била провеждана само няколко пъти, така че не трябва да възприемате този текст като готово ръководство. Няма аналози в съвременния ИТ бизнес — представете си, че банките се състезават помежду си преди старта на система за плащания, кой по-добре ще извършва транзакции на клиентите. Традиционните подходи едва ли ще ви помогнат да създавате големи децентрализирани мрежи, затова се запознайте с нови бизнес модели, провеждайте собствените си игри, определяйте достойни, награждавайте ги и нека вашите разпределени системи работят бързо и стабилно.
Източник: habr.com
