И така, вашият екип завърши alpha-версията на вашия блокчейн и дойде време да стартирате testnet, а след това и mainnet. Имате истински блокчейн с независими участници, добра икономическа модел, сигурност, проектирали сте управление и е време да опитате всичко това в действие. В идеалния криптоанархически свят, вие публикувате genesis блока в мрежата, окончателния код на нодата и валидаторите сами всичко стартират, настройват всички спомагателни услуги и всичко става само по себе си. Но това е в измисления свят, а в реалния живот екипът трябва да подготви доста спомагателен софтуер и различни манипулации, за да помогне на валидаторите да стартират устойчива мрежа. За това става дума в настоящата статия.
Стартирането на мрежи на базата на консенсуса от типа „proof-of-stake“, при което валидаторите се определят от гласовете на притежателите на токени в системата, е доста специфично начинание, тъй като дори стартирането на традиционни, централизирано управлявани системи с десетки и стотици сървъри себе си не е лесна задача, а блокчейнът трябва да се стартира с усилията на лоялни, но независими участници. И ако в корпорацията администраторите имат пълен достъп до всичките компютри, логове и общо наблюдение, то валидаторите не позволява на никого да се доближи до техните сървъри и вероятно ще предпочетат да изградят своята инфраструктура сами, тъй като тя контролира достъпа до основните активи на валидатора — стейковете на гласуващите. Именно такова поведение позволява изграждането на разпределени безопасни мрежи — независимостта на използваните облачни доставчици, виртуални и „baremetal“ сървъри, различни операционни системи, всичко това прави атаките срещу такава мрежа крайно неефективни — твърде много разнообразен софтуер се използва. Например в Ethereum се използват две основни имплементации на нодата, на Go и на Rust, и атака, ефективна за една имплементация, не работи за друга.
Следователно, всички процеси по стартиране и експлоатация на блокчейни трябва да бъдат организирани така, че всеки валидатор, или дори малка група от валидатори, да могат по всяко време да изхвърлят компютрите си през прозореца и да си тръгнат, без нищо да се счупи, и останалите валидатори да продължат ефективно да поддържат мрежата и да свързват нови валидатори. При стартиране на мрежата, когато един валидатор е в Европа, втори в Южна Америка, а трети в Азия, е доста трудно да се постигне съгласувана работа на няколко десетки независими групи и да се заинтересуват в резултата.
Валидатори
Нека си представим стартирането на хипотетичен съвременен блокчейн (голямата част от описаното подхожда на блокчейни от всяко съвременно семейство блокчейни: Ethereum, EOS, Polkadot, Cosmos и други, при които е предвиден консенсус proof-of-stake. Главните действующи лица в такива блокчейни са екипи валидатори, които инсталират собствените си независими сървъри, валидиращи и произвеждащи нови блокове и получаващи наградите, предвидени от мрежата за тези, които участват в консенсуса. За стартирането на нови мрежи се изискват няколко десетки валидатори (толкова в момента могат по-или-неправилно ефективно да постигат консенсус за секунди), затова проектът обявява регистрация, при която валидаторите споделят публична информация за себе си с потребителите, убеждавайки ги, че възнамеряват да обслужват качествено стартираната мрежа.
Валидаторството е бизнес, който позволява изключително точно да се оцени потенциалният доход на валидатора, бързо да се прехвърлят мощности между проекти, а в случай на успех на избраната от него мрежа, валидаторът може като пълноправен участник в DAO и отговорно лице да развива проекта, или просто да предоставя отличен технически сервис за напълно прозрачни и честно изработени пари. При изчисляване на наградата, проектите се стараят да вземат предвид разходите на валидаторите и да направят наградата за блокове такава, че този бизнес да бъде печеливш, но в същото време да не позволява на валидаторите да разрушат икономиката, заливайки я с пари и лишавайки останалите потребители на мрежата.
Бизнесът на валидаторите изисква осигуряване на висока отказоустойчивост на услугите, което означава – висок уровень на подготовка на девопсите и разработчиците, както и скъпи изчислителни ресурси. Дори без необходимостта от добив на хешове в мрежи с proof-of-work, блокчейн нода е голяма услуга, която заема много памет, консумира много изчисления, валидира, записва на диск и предава в мрежата големи обеми данни. За съхранение на логовете на транзакциите и веригите от блокове за блокчейн с няколко хиляди малки транзакции в блок, сега е необходима памет от 50 Gb и повече, а за блоковете трябва да бъде SSD. State database на блокчейни с поддръжка на смарт-контракти вече може да надвишава 64Gb оперативна памет. Сървъри с необходимите характеристики са доста скъпи, а нодата на Ethereum или EOS може да струва от 100 до 200 $/месец. Добавете към това увеличените заплати за круглосуточна работа на разработчиците и девопсите, които решават проблеми, дори и през нощта, тъй като част от валидаторите лесно може да се намира в другото полукълбо. Въпреки това, в благоприятни моменти собствеността на нода-валидатор може да донесе сериозни доходи (в случая с EOS – до 10,000$ на ден).
Валидаторството е само една от новите потенциални IT-роли за предприемачи и компании. С изобретяването на все по-изтънчени алгоритми от програмистите, които награждават честността и наказват измамата и кражбата, се появяват услуги, които изпълняват функции за публикуване на важни данни (оракулите), осъществяват надзор (слешинг на депозитите и наказание на измамниците чрез публикуване на доказателства за измама), услуги за разрешаване на спорове, застраховане и опции, дори garbage collection е потенциално голям пазар в системите за смарт-контракти, където е необходимо да се заплаща за съхранение на данни.
Проблеми със стартиране на блокчейна
Прозрачността на блокчейн технологията, която позволява свободно участие на компютри от всяка страна и лесното свързване на всеки script kiddie според инструкции от GitHub, не винаги е предимство. Ненаситната стремеж за нов токен често кара валидаторите да "копаят" нова монета в началото, с надеждата за растеж на цената и възможността бързо да продадат спечеленото. Освен това, това означава, че ваш валидатор може да бъде всеки, дори анонимен, за когото може да се гласува по същия начин както за останалите валидатори (въпреки че на анонимния ще му бъде трудно да събере гласове от стейкхолдерите, така че страшните приказки за анонимни криптовалути оставяме на политиците). Независимо от това,
Проектният екип има за задача — по някакъв начин да привлече в мрежата си онези, които в бъдеще са способни да осигурят стабилната работа на нодовете, разбират от сигурност, умеят бързо да решават проблеми, да се кооперират с други валидатори и да действат съвместно - от тези качества зависи качеството на самия токен, в който участниците в мрежата планират да вложат време и ресурси. Разумни основатели, оценявайки рисковете, разбират, че при стартиране на такова обемно ПО неизбежно ще се сблъскат с грешки в кода, конфигурацията на нодовете и че стабилността на мрежата зависи от това, колко добре разработчиците и валидаторите ще решават подобни проблеми заедно.
Екипът е готов да гласува в mainnet за всякакви валидатори, само че е хубаво да се знае за кои, кои са добрите? С най-голямо портфолио? В момента почти никой не го притежава. По профилите на екипа в Linkedin? Опитните девопси или специалисти по сигурност няма да ви предоставят никакви профили в Linkedin. По изказвания в чата, публикации и помощ на другите в етапа на подготовка? Добре, но субективно и неточно.
В такива условия остава само едно - това, което добре решава проблемите на всички - игра, в която ще може да се изберат най-добрите валидатори, но най-важното - да се тества блокчейнът за здравина и да се проведе мащабен бойен тест на блокчейна в условия на активно използване, промени в консенсуса, появата и поправянето на грешки. За първи път тази процедура бе предложена като игра от момчетата от проекта Cosmos, и тази идея несъмнено представлява прекрасен начин за подготовка на мрежата за стартиране на надежден и устойчив mainnet.
Игра на валидатори
Ще опиша играта на валидаторите така, както я проектирахме за блокчейна DAO.Casino (DAOBet) на основата на форка EOS, който се нарича Haya и има сходен механизъм за управление — валидаторите се избират с гласуване от всякакъв акаунт, при което част от баланса, с който се гласува за валидатор, се замразява. Всеки акаунт, притежаващ основния токен BET, може да гласува за избрания валидатор с част от своя баланс. Гласовете се сумират и в крайна сметка се изгражда топ списък на валидаторите. В различните блокчейни този процес е организиран по различен начин, и обикновено именно в тази част новият блокчейн се различава от родителския, и трябва да кажа, че в нашия случай EOS напълно оправдава „OS“ в името си, действително използваме EOS като основна операционна система за разгръщане на модифицирана версия на блокчейна за нуждите на DAOBet.
Ще опиша отделни проблеми и как те могат да бъдат решени в рамките на играта. Нека си представим мрежа, в която вашият сървър може да бъде открито атакуван, където за да задържите позицията на валидатор, е нужно непрекъснато взаимодействие с мрежата, промотирайки своя валидатор и следейки за това, дали той произвежда блокове и те навреме достигат до останалите валидатори, в противен случай валидаторът ще бъде изхвърлен от списъка.
Как да изберем топ победителите?
Основното техническо изискване към играта е да бъдат публично проверяеми нейните резултати. Това означава, че резултатите от играта: ТОП победителите, трябва да бъдат формулирани строго на основата на данни, които може да провери всеки участник. В централизирана система бихме могли да измерваме “uptime” на всеки валидатор и да награждаваме тези, които най-дълго са били онлайн или са пропуснали през себе си максимално количество трафик. Можем да събираме данни за натоварването на процесора, паметта и да награждаваме тези, които достойно са се трудили. Но всеки такъв сбор на метрики предполага съществуването на централен сбор, а и нодовете са напълно независими и могат да се държат както пожелаят и да изпращат каквито данни искат.
Следователно, естественото решение е победителите да се определят на базата на данни от блокчейн, тъй като чрез него може да се види кой от валидаторите е произвел кой блок и какви транзакции са били включени в него. Ние нарекохме това число Validator Points (VP), а неговото придобиване е основната цел на валидаторите в играта. В нашия случай, най-простата, лесно публично проверима и ефективна метрика за „полезността“ на валидатора е VP = брой_произведени_валидатором_блокове за зададен времеви период.
Такава проста структура е резултат от факта, че управлението (governance) в 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
- създайте скрипт-бенчмарк (трансфери на токени, масивно използване на storage, масивно използване на мрежата)
- съберете всички участници в един чат за бърза комуникация
- стартирайте блокчейна малко преди началото на играта
- изчакайте стартовия блок, започнете играта
- тествайте мрежата с няколко типа транзакции
- прилагайте хардфорк
- променете списъка на валидаторите
- повторете т. 13, 14, 15 в различен ред, за да поддържате стабилността на мрежата
- изчакайте финалния блок, завършете играта, изчислете VP
Трябва да се каже, че играта на валидаторите е нова история и е проведена само няколко пъти, затова не трябва да възприемате този текст като готово ръководство. Няма аналогии в съвременния ИТ бизнес – представете си, че банките се състезават помежду си преди старта на плащателната система за това коя ще провежда транзакциите на клиентите по-добре. Традиционните подходи вероятно няма да ви помогнат в създаването на големи децентрализирани мрежи, затова усвоявайте нови бизнес модели, провеждайте своите игри, определяйте достойните, награждавайте ги и нека вашите разпределени системи работят бързо и стабилно.
Източник: habr.com
