Как запустить свой блокчейн: поднимаем основную сеть

Мы добрались до запуска основной сети (мейннета) проекта. Разработка, тестирование, запуск тестовой сети и выбор валидаторов уже позади. Впереди — раздача реальных балансов токенов участникам и ответственность за безопасность значительных сумм.

В данной статье руководитель отдела исследований MixBytes Сергей Прилуцкий расскажет о нюансах запуска основной сети.

Наиболее важные шаги для технической команды — запуск тестнета и игры валидаторов — завершены, и к этому моменту сеть должна быть технически готова. К сожалению, «децентрализованная сеть» вовсе не означает, что все запустится автоматически. Запуском основной сети придется активно заниматься команде, которая отвечает за код блокчейна.

Genesis и начальное состояние

Genesis-блок — первый блок основной сети. Проще говоря, он содержит всю начальную информацию: стартовые балансы, код основных смарт-контрактов, список первоначальных валидаторов.

На деле блоки не содержат данные, а только хеши состояний. Для большинства блокчейнов стартовое состояние — это сразу несколько файлов, часть из которых является снапшотом базы данных. Именно с него начнется жизнь базы данных состояния блокчейна на всех нодах сети. Любая нода основной сети обязана стартовать цепочку именно с этих данных, иначе весь блокчейн будет невалидным.

На старте у команды есть список адресов или публичных ключей тех, кто получит на баланс токены, и код основных контрактов. Список может меняться вплоть до последних часов перед запуском, поэтому имеет смысл сделать скрипт, который из списка адресов-балансов создает начальное состояние (genesis-блок и все необходимое). Скрипт может выводить на экран все адреса и информацию о начальном состоянии, а его запуск можно транслировать в онлайн-режиме на Youtube.

Так вы сможете задокументировать запуск, а повторить эту операцию сможет любой пользователь, который сомневается в честности распределения стартовых балансов или содержимом контрактов.

Старт производства блоков

Для старта производства блоков требуется участие нескольких валидаторов. Некоторые из них могут столкнуться с проблемами: часть команд может перепутать конфигурации тестовой и основной сетей, другая — использовать устаревшее начальное состояние, третья — неправильно оценить ресурсы серверов и т.д. Поэтому не стоит пугаться, если новые блоки вы увидите не сразу.

Наберитесь терпения или проектируйте запуск так, чтобы подключение новых валидаторов было постепенным. Например, запустите сеть на своих машинах, постепенно уступая места новым валидаторам, или подключите небольшое число валидаторов на старте сети и увеличивайте его по мере добавления новых.

Советую заранее подготовить скрипты, которые выводят список работающих валидаторов, а также чек-лист для их самопроверки.

Аккаунты валидаторов

Каждый валидатор сети имеет аккаунт, который используется для подписи блоков, голосований за других валидаторов и других важных функций. Для работы валидатора приватные ключи располагаются на сервере валидатора.

Этот сервер может быть атакован несколькими способами — от атаки на ПО валидатора до атаки на аккаунты девопсов, поэтому нужно использовать ключи, получение которых не позволит атакующему контролировать средства валидатора. Например, в DPoS консенсусах на адресе валидатора нет криптовалюты, но за него «голосует» другой адрес с отдельной машины. В случае взлома валидатора, можно запустить другого и переголосовать за него. Отличной практикой является передача вознаграждений за валидаторство на независимый внешний адрес.

Отдельно нужно отметить роль мультисиг-адресов (см. статью). Они являются обязательными, поскольку взлом любого из мультисиг-адресов не будет фатальным. Для полного доступа к средствам нужно получить доступ к нескольким (минимум двум) приватным ключам вместо одного (количество необходимых подтверждений может меняться).

Примером мультисиг-активности может быть участие в «выборах» валидаторов, для которых требуется стейкинг средств на смарт-контракте, выбирающем валидаторов. Сервер валидатора раз в сутки отправляет транзакцию-заявку, но она не является действительной, пока с другого адреса не будет отправлена транзакция-подтверждение. Подтверждение отправляется с любой независимой от валидатора машины, взлом которой также не даст полного доступа к средствам валидатора.

Несмотря на мощную защиту, многие валидаторы не любят мультисиг-логику, так как это дополнительные сервисы, за которыми нужно следить. Для подобной деятельности обычно используются скрипты, которые автоматически мониторят нужные валидатору адреса и подтверждают необходимые транзакции.

Подобное ПО обязательно должно проверять как минимум адрес, которому адресована подтверждаемая транзакция или тип вызываемой функции смарт-контракта. Без подобной проверки злоумышленник может создать транзакцию, выводящую средства с адреса валидатора, а скрипт автоматически подтвердит и подпишет ее дополнительным ключом — в этом случае защита с помощью мультиподписи теряет смысл.

Режим бога

Не всегда при запуске блокчейна можно быть уверенным, что все пойдет как надо. Возможно, вы захотите изменить системные смарт-контракты в первые месяцы существования сети или вам придется дорабатывать сеть на ходу из-за требований со стороны бизнеса.

Вам также может потребоваться оперативно вносить изменения в системные контракты без сложных процедур согласования. В этом случае допускается создание специальных «всемогущих» аккаунтов, которым разрешено менять код системных контрактов и иметь доступ к аккаунтам участников. В этом случае имеет смысл заложить и публично продемонстрировать логику, которая отключит этот функционал после определенного времени и повысит уровень доверия к сети.

Не рекомендуется оставлять такие аккаунты надолго, особенно после появления токена сети на биржах или его доступности для обмена — в этот момент возможна организация атак, способных полностью подорвать капитализацию сети.

«Всемогущий» аккаунт — заманчивая цель для атаки, способной нанести серьезный ущерб сети даже в корпоративных блокчейнах .

Мосты

Часто токены проекта сначала выпускаются в сети Ethereum, а для создания своего токена требуется лишь несколько несложных действий в браузере. Только после запуска основной сети держатели токенов могут перенести свои балансы в запущенную сеть. ПО, используемое для переноса токенов из одного блокчейна в другой, получило название «мосты».

Мост между двумя блокчейнами — это сервис, который мониторит одновременно обе сети. Когда пользователь хочет переместить токены, мост «забирает» их в исходной сети и «выдает» в требуемой.

Мосты могут быть однонаправленные (перемещают токены только из одной сети в другую), либо двунаправленные (перемещают токены в обоих направлениях). Механика работы мостов может быть очень разной в зависимости от того, какие виды смарт-контрактов поддерживают обе сети.

В большинстве случаев операторами мостов являются валидаторы сети. Они принимают токены вашего проекта в Ethereum на специальный смарт-контракт, и, убедившись в их получении, выдают соответствующую сумму токенов в вашем блокчейне и в обратном направлении.

Для сетей на базе Ethereum, EOS или других с полноценными многофункциональными смарт-контрактами существуют универсальные имплементации мостов (пример) или проверенные алгоритмы действий.

Мост с биткоинподобными сетями — это гораздо более сложная задача из-за UTXO-дизайна адресов.

Мосты должны быть спроектированы заранее и протестированы на этапе тестнета.

Мониторинг

В децентрализованной сети валидаторы отвечают за мониторинг и следят за работоспособностью своих серверов. Команда проекта, в свою очередь, тратит ресурсы на поддержку только своих валидаторов. Нужно ли собирать мониторинговую информацию со всех валидаторов сети и самим платить за поддержку серверов мониторинга?

Решать вам — для мониторинга в основной сети вам понадобится лишь пара дополнительных серверов для централизованного сбора метрик с валидаторов, а польза от этого сервиса довольно велика — все участники смогут получать общую, агрегированную информацию о работе сети.

При запуске вашей команде будет поступать большое число вопросов: какие валидаторы активны, корректно ли они работают, какова их производительность по сравнению с коллегами? Стоимость этих не очень требовательных серверов, возможно, окупит рабочее время ваших специалистов.

Не обязательно постоянно поддерживать этот сервис — вы в любой момент можете выключить его, а валидаторам будет достаточно запустить собственную копию и изменить пару адресов, чтобы запустить собственный мониторинг.

Дополнительное ПО

Обозреватель блоков

Без сомнения, это важнейший сервис блокчейна, отображающий информацию о блоках и транзакциях. Однако на этапе запуска транзакций и адресов крайне мало, и по сравнению с тестнетом или с игрой валидаторов обозреватель блоков не сильно интересен участникам на начальных этапах. Большинство активно работающих аккаунтов — это валидаторы и разработчики, которые предпочтут использовать различные специализированные утилиты для получения нужной информации.

Создание качественного и удобного обозревателя блоков основывается в первую очередь на опыте пользователей — а его пока крайне мало. Работать этот сервис должен, но на старте сети не требует чрезмерного внимания.

Портал валидаторов

В первые недели жизни сети портал для валидаторов крайне важен, так что я рекомендую потратить на него время и добавить хотя бы простейшую агрегацию данных. Например, uptime валидаторов, количество произведенных блоков, статистика по стейкингу, голосованиям и наградам валидаторов.

Предоставив участникам возможность проверять и контролировать себя, вы быстрее увидите потенциальные проблемы и сможете точнее отвечать на любые вопросы, касающиеся экономики сети.

Утилиты командной строки

Если нужно, чтобы валидаторы с первых запусков могли автоматизировать основные задачи, определять проблемы и реагировать на них — обязательно нужны утилиты, которые позволяют проводить голосования, узнавать статус валидатора, подтверждать multisig-транзакции и т.п.

Кажется, что обеспечить качество этого вида ПО намного проще, чем сделать хороший обозреватель блоков или кошелек. Однако на практике частые изменения в коде будут ломать схемы автоматизации на стороне валидаторов, что может привести сеть к неприятным сбоям и конфликтам.

Внимательно отнеситесь к этим инструментам, старайтесь не переименовывать параметры и их формат «для красоты» после запуска и жестко следуйте стандартам, принятым в разработке свободного ПО. По качеству именно этого ПО валидаторы будут судить о степени подготовки вашей команды.

Кошелек и основные приложения

Ради работы этого ПО и затевался блокчейн. К моменту запуска мейннета каждый пользователь на вес золота, поэтому любое исправление в коде кошелька или основного децентрализованного приложения сети должно быть быстрым. Для этого нужно отладить весь цикл выкатки кода еще в тестнете, добавить подробный мониторинг и бороться за каждого пользователя.

Предыдущие статьи цикла читайте на ForkLog:

1. Как запустить свой блокчейн: задачи и архитектура.
2. Как запустить свой блокчейн: выбираем алгоритм консенсуса.
3. Как запустить свой блокчейн: выбираем движок.
4. Как запустить свой блокчейн: поднимаем тестовую сеть и оцениваем производительность.
5. Как запустить свой блокчейн: проводим игру валидаторов.

Подписывайтесь на новости Forklog в Facebook!