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